12_中间件架构体系

面向构件软件过程 软件的发展 • 大约每隔5至10年，软件界就会重定义“问题”， • 将其焦点从“产品”转移到“过程”。 – Roger S. Pressman《软件工程：实践者的研究方法》 • Stephen R. Palmer曾指出，“好的过程清晰地定 义任务。任务焦点放在结果上而不是细节上……”。 • 因为具体实践是鲜活多变的，定义太多关乎“How” 的细节，不利于过程的适应性；而只有将过程划 分成不同的子任务，并清晰定义每个任务的目标 结果（What），才能更切入本质的东西，从而使 项目既可以有效地进行，又能适应一些非常事件 及环境的变化。 • 我们对面向构件软件过程的阐述，将贯彻 上述“两个强调”原则——即强调“任务”及其 产出的“核心工作产品”。在此基础上，再进 一步讲清楚各个任务之间的依从关系、以 及各个核心工作产品之间的跟踪关系。 深入理解软件过程 • 不同的软件过程（如RUP和XP），过程模型会有 很大不同。为了考察软件过程的共性，我们来研 究软件过程的元模型。 软件过程元模型（图片来源： Software Process Engineering Metamodel, version 1.1） • 软件过程元模型显示了任何软件过程都必不可少的角色、 活动、工作产品的概念。 – 角色是对个人或作为开发团队的一组人员职责的规定； • 角色的职责，具体体现在他执行的活动和负责的工作产品上。 – 活动是角色执行的工作单元； • 工作产品是由活动生产出来的——工作产品是活动的输出：比如制定 《编码 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 》。 – 而工作产品是工作的成品或半成品。 • 然而，活动本身也可能以工作产品为输入——活动可能要求使用工作 产品：比如编码活动要参考《编码规范》。 • 当然，工作产品可以既是活动的输入又是它的输出——活动修改工作 产品：比如修改《编码规范》。 面向构件软件过程的主要阶段 • 面向构件的软件过程分为如下五个主要阶段： – 需求阶段： • 捕获需求，识别业务构件，归纳业务构件需求； – 分析与高层 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 阶段： • 分析业务构件，识别服务构件，架构设计，归纳服务构件需求； – 并行开发与测试阶段： • 开发并测试服务构件、业务构件、应用系统； – 提交、发布与部署阶段： • 提交服务构件、业务构件到构件库，发布应用系统，部署应用系统； – 应用管理： • 对上线系统及其中的运行构件实施例行管理，以及各种突发情况的处 理维护。 面向构件软件过程的核心工作产品 • 对于任何软件方法论而言，工 作产品都是影响重大的——因 为产出工作产品的数量直接决 定了软件过程的敏捷程度。 • 而具体项目的实施，其规范程 度和敏捷程度应根据具体项目、 具体团队情况而定。因此，我 们强调对本软件过程至关重要 的核心工作产品，至于还需采 用哪些外围工作产品，可由项 目团队根据自身情况自行决定。 面向构件的软件过程的核心工作产品 • 业务构件需求 • 可复用业务构件列表 • 系统架构文档 • 业务构件设计文档 • 服务构件需求 • 可复用服务构件列表 • 服务构件 • 业务构件 • 应用系统 跟踪关系 • 下面说明这些概念之间的跟踪关系在面向 构件的软件过程中的体现 面向构件软件过程的主要角色 • 需求分析师 • 领域专家 • 架构设计师 • 开发人员 • 测试人员 • 构件库管理员 • 发布经理 • 工程实施人员 • 应用管理员 • 项目经理 需求分析师 • 需求分析师是需求捕获与整理方面的专家；并且 他应当熟悉面向构件的需求阶段工作的独特之 处，最终将需求归纳为业务构件需求。 • 需求分析师的主要职责： – 推动需求捕获工作 – 领导领域专家进行需求捕获和整理 – 归纳业务构件需求 – 需求归档 领域专家 • 既然面向构件方法非常强调企业知识的积累，那么领域专 家在该方法中的重要性，就比在一般的方法中要来得大； 充分发挥领域专家的作用，目的是更好地把他们头脑中的 知识最终转化为商业价值。 • 领域专家的职责： – 和需求分析师紧密配合，完成需求捕获工作 – 配合识别业务构件，尽量保证其符合特定业务领域的惯例 – 参与业务构件的评审 – 参与系统级的验收测试 架构设计师 • 架构设计师在应用系统的组织方式、构成要素、行 为契约、架构风格等方面做出决策，从而为后续开 发提供明确有力的指导。 • 架构设计师的职责： – 业务构件分析 – 应用架构设计 – 按照面向构件的思想，识别构件、确定构件接口和行为 – 决定服务构件需求 – 负责架构归档 – 协助项目经理制定并行开发 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 开发人员 • 如前所述，面向构件的软件过程提倡“为复用而生 产，为使用而组装”。因此，开发人员会有进一步 的角色分化（构件开发者和应用组装者）。 • 总体而言，开发人员的职责为： – 服务构件的详细设计与实现 – 对服务构件进行单元测试 – 实现业务构件 – 将业务构件组装成应用系统 测试人员 • 构件是为复用而开发的，测试人员的工作将凝聚 在构件之中，随着构件不断地被复用而发挥价值。 • 测试人员的职责： – 对业务构件进行集成测试 – 对软件系统进行系统测试（包含功能测试、非功能专 项测试、验收测试等） 构件库管理员 • 由于面向构件软件过程对构件复用的突出强调，所有构件 库管理员——作为构件积累专家——从需求阶段就会参与 可复用资产的分析工作，并且在后续阶段提供持续支持。 • 构件库管理员的职责： – 配合需求分析师进行可复用业务构件分析、确定业务构件需求 – 配合架构设计师进行可复用业务构件分析、确定服务构件需求 – 主持服务构件和业务构件的提交评审 – 主持服务构件和业务构件的提交工作 – 负责构件的完整性，将构件的相关文档和说明等工作产品一并入 库 – 构件库的日常管理和维护 发布经理 • 面向构件的软件过程对持续集成的天然支持，对 外表现为增量发布。发布经理负责具体的增量发 布工作。 • 发布经理的职责： – 决定发布内容（特定子版本应用系统、文档和手册等） 并实施发布 – Release Notes的编写者 – 产品包装等发布相关事宜 工程实施人员 • 最终的应用系统，在何种基础设施的环境之下进 行部署会有很大不同，工程实施人员负责该项工 作。 • 工程实施人员的职责： – 辅助用户方进行运行环境的决策 – 实施面向构件应用系统的部署 应用管理员 • 如您所知，维护和管理阶段，在软件的生命周期 中是最长的一个阶段。应用管理员负责相关工作。 • 系统管理员的职责： – 初始化 – 配置 – 监控 – 诊断 – 升级 – 热部署 项目经理 • 由于面向构件的软件过程提供了比传统的软件过 程明确得多的“工作产品的跟踪关系”，项目管理 可以更为有效。 • 项目经理的职责： – 项目计划，并行开发计划 – 项目组织 – 项目实施 – 项目度量 – 突发事件处理 面向构件软件过程总览 • 如上所述，面向构件的软件过程涉及到角色、活 动、工作产品等概念。 面向对象技术弱点 • 在中小规模的软件中，对象和对象之间的协作关 系就能够满足需要。 • 但是当软件规模扩大，复杂度上升的时候，面向 对象技术强调的协作却表现出另一个极端的特点 －耦合度太高导致的复杂度。 • 这时候就需要有一种新的方法来弥补面向对象技 术的弱点。 大规模软件的特点 • 大规模软件主要特点是复杂度。比较典型 的例子是集成性的项目。 –软件系统需要将各种各样的硬件、遗留系统、 外部接口整合起来。 –其间可能遇到不同的硬件接口，不同的操作系 统，不同的语言，不同的平台，不同的数据 库，不同的消息中间件，不同的网络介质。 –这些都使得系统变得非常的复杂。 职责分工和高度协作 • 面向对象技术的特点是通过对象之间的职责分工 和高度协作来完成任务。这样的好处是代码量较 少，系统布局合理，重用程度高。 • 但是当对象的个数大量增加的时候，对象之间的 高度耦合的关系将会使得系统变得复杂，难以理 解。 对象组织容器-包 • 以前对于这个问题的方法是采用包作为容器来组 织对象，对象之间的依赖性将转化为包之间的依 赖性。这种方法听起来有道理，但是在实际中仍 会出现难以解决的问题。 – 包仅仅只是容器。这意味着对对象的组织可以是任意 的，而包之间依赖关系的设计则还是取决于对象的依 赖。 – 此外，包的设计和对象一样，缺乏一个统一的风格。 而统一的风格正是大规模软件设计所必须的，因为这 样可以有效改进系统的可理解性，这一点非常重要。 面向组件编程 • 面向组件编程的缩写是COP。COP是对 OOP的补充，帮助实现更加优秀的软件结 构。组件的粒度可大可小，需要取决于具 体的应用。 • 在COP中有几个重要的概念：服务，服务 （Service）是一组接口，供客户端程序使 用。 –例如，验证和授权服务，任务调度服务。服务 是系统中各个部件相互调用的接口；组件，组 件（Component）实现了一组服务，此外，组 件必须符合容器订立的规范，例如，初始化， 配置、销毁。 • COP是对一种组织代码的思路，尤其是服 务和组件这两个概念。 –其中Spring框架中，就采用了COP的思路，将 系统看作一个个的组件，通过定义组件之间的 协作关系（通过服务）来完成系统的构建。 –这样做的好处是能够隔离变化，合理的划分系 统。而框架的意义就在于定义一个组织组件的 方式。 理解组件 • 组件不是一个新的概念，Java中的javaBean规范 和EJB规范都是典型的组件。组件的特点在于他 定义了一种通用的处理方式。 – 例如，JavaBean拥有内视的特性，这样就可以通过工 具来实现JavaBean的可视化。而EJB规范定义了企业 服务中的一些特性，使得EJB容器能够为符合EJB规范 的代码增添企业计算所需要的能力，例如事务、持久 化、池等。 • 组件比起对象来的进步就在于通用的规范的引入。 通用规范往往能够为组件添加新的能力（就像上 面所讨论的），但也给组件添加了限制，例如你 需要实现EJB的一些接口。以下我们将讨论组件 的一些相关问题： – 组件的粒度 – 针对接口 组件的粒度 • 组件的粒度是和系统的架构息息相关的。组件的 粒度确定了，系统的架构也就确定了。 – 在小规模的软件中，可能组件的粒度很小，仅相当于 普通的对象，但是对于大规模的系统来说，一个组件 可能包括几十，甚至上百个对象。 – 因此，对使用COP技术的系统来说，需要正确的定义 组件的粒度。较好的定义粒度的方法是对核心流程进 行分析。 针对接口 • 接口和实现分离是COP的基础，没有接口 和实现的分离，就没有COP。接口的高度 抽象特性使得各个组件能够被独立的抽取 出来，而不影响到系统的其它部分。 接口和实现分离好处 • 在模块/组件/对象之间解耦。 • 轻松的抽换实现，而不用修改客户端。 • 用户只需要了解接口，而不需要了解实现 细节。 • 增加了重用的可能性。 Inversion of Control（IOC） • IOC是Inversion of Control的简称。它的原 理是基于OO设计原则的好莱坞原则（The Hollywood Principle）： –不要访问我，我们将访问你。 –也就是说，所有的组件都是被动的 （Passive），所有的组件初始化和调用都由容 器负责。 IOC实现的类型 • 基于方法参数调用的Method-based(M) IOC，它把组件传 递给每个方法调用 • 基于接口的Interface-based(I) IOC（通常称为类型1）， 它使用接口来声明组件之间的依赖性,例如， Serviceable,Configurable • 基于Setter方法的Setter-based (S) IOC（通常称为类型 2），它使用setter方法来设置组件之间的依赖性 • 基于构造函数的Constructor-based(C) IOC（通常称为类 型3） • IOC模式称为Dependency Injection模式。 • IOC是框架开发的一个基本原理。 • 在开源软件中，不少的容器类框架都采用 了IOC的思路。例如: – PicoContainer(http://www.picocontainer.org/) – Spring（http://www.springframework.org/） 组件污染 • 在IOC的第一类型中，由于组件需要实现一些特 定的接口，或是从某个类集成。这将使得组件受 到一些约束（称为Invasive），例如组件移植不 便。 • 另一种情况是组件需要依赖于一个特定的容器， 最为典型的就是EJB，组件无法脱离容器单独存 在，这也使得组件受到约束。 • 这两种情况都属于组件污染。 • 最理想的组件是只专注于自身工作的组件，它没 有其它额外的逻辑。不过按照这种 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 ，目前大 部分的代码都是不符合的。 • 因此，目前在开源软件界出现了一些轻量级的容 器框架，典型的如上文提到的PicoContainer和 spring。他们的定位就是提供一个对组件管理的 统一模式，而组件可以单独的使用，也可以放在 另一个容器中，容器仅仅只是为组件提供了一些 额外的功能，和组件本身没有直接的依赖。 • 为什么我们说接口比继承好，很重要的一 个原因就是接口更加灵活，组件的依赖性 更弱，同样的，目前另一种做法则是采用 一些标记性的语言来实现比接口更大的灵 活度。 • 例如基于xml的配置文件，以及J2SE1.5中 将要引入的属性。 组件的测试 • 组件和容器的依赖脱离为组件测试提供了一个很 好的环境。我们在测试一节中讨论过容器内测试 往往是比较麻烦的，其原因就是在于上面所说的 组件污染问题。例如在spring框架中，组件是一 个标准的JavaBean，你可以直接编写代码来设置 组件的属性和定义组件之间的依赖关系（适用于 自动化测试），也可以把这项工作交给spring容 器（适用于开发和部署）。 • 组件测试在测试的分类中属于集成测试。 理解服务 • 在讨论组件时我们谈论了组件粒度的问题。当组件的粒度 不仅仅限于单个对象的时候。在构成组件的多个对象中， 有些对象处于组件内部，不和其它的组件交互，有些对象 需要和外部组件进行交互。后一种对象起的就是服务的作 用。 • 在设计模式中，这种设计被称为Fasade模式。而在OO语 言中，他们相当于接口的概念。不管如何比喻，服务订立 了组件和组件之间的契约。这种契约是稳定的（如果业务 需求是稳定的），不会随着组件内部的变化而发生变化。 • 要理解这一点也非常的容易。对于一个提供用户认证的组 件，一个可能的服务对用户进行认证和授权，至于组件内 部采用LDAP还是关系数据库来存放用户信息，对服务来 说没有任何的差别。 • 这样做的好处有很多，一是组件之间能够以一种稳定的方 式存在，组件内部的变化不至于扩散到整个软件系统。二 是软件设计将会转向重点设计组件之间的服务，而组件的 实现细节将会隐藏起来，这不但有助于设计者更好的把握 软件的全局架构，而且有助于分工的细化。 • 服务并不是什么新颖的概念，RPC、IDL都是类 似的技术。 • 但我们谈的服务侧重架构和理念，不涉及到具体 的技术，这一点同SOA和WebService的关系类似 －SOA是一个结构性的概念，而WebService是实 现SOA的一种适合的技术。 • 服务最好实现为接口。原则上服务可以是任何一种技术： JMS、WebService、RPC、或是简单方法调用。 • 但是出于服务的稳定性的考虑，我们不应该将一个服务和 具体的技术绑定起来，这样会使的服务发生变化的可能性 增大。 • 在Java语言中，接口是具有极大的灵活性的，因此，将接 口实现为普通的Java接口是较好的选择。不过，这样做的 话，我们也许就不能够使用远程调用，Web服务之类的功 能了，不过这并不要紧，以下就是原因。 服务适配器 • 客户端可以直接使用接口，也可以通过适当的适 配器来将普通的接口服务转换为特定技术实现的 服务。 • 个普通的接口通过适配器模式转换成和特定技术 相关的服务。在JMX技术中，也采用这种方式， JMX平台能够将一个普通的服务端口通过适配器 进行转换，以适用于各种的 协议 离婚协议模板下载合伙人协议 下载渠道分销协议免费下载敬业协议下载授课协议下载 ，例如http、 socket、snmp等等。 AOP技术对服务的帮助 • AOP作为OO技术的补足，能够以一种优雅的方式来处理 系统的横切点。服务层面是应用AOP的绝佳位置 • 一个普通的用户注册服务通过AOP可以动态的添加各种各 样的能力。AOP提供了几个好处： – 能够通过简单的代码为所有的服务添加功能，而不用为每个服务 编写代码，从而大大节省了代码量； – 把横切点分离出来，这样服务仅保留了核心的代码，提高了系统 的模块化程度； – 模块化的增加使得为服务动态的增加或删除功能成为可能，例 如，可以通过配置动态的将新的Aspect添加到用户注册服务上。 服务的测试 • 服务测试在测试的分类中属于接受测试。服务概念的引入 使得自动化的接受测试变得容易了。在大规模的软件设计 中，业务流程往往涉及到各种组件通过服务介面的相互协 作。所以这就是测试的重点。回到我们之前讨论的组件粒 度问题，如果此时你编写出的测试代码过于繁琐，说明组 件的设计粒度太小了，如果组件的粒度太大，你会发现有 些测试代码根本无法编写。 服务的管理 • 服务的管理是一个比较大的话题。一方面，在一个大规模 的系统中，虽然通过组件和服务的形式能够降低系统的复 杂度，但是服务仍然很多，需要进行管理；另一方面，服 务的状态，服务的可用性需要监控和管理，这对于大规模 应用来说是必须的。因此，服务需要一种管理形式。 • JMX规范提出的目的也是一个对各种不同的组件进行统一 管理。和我们所阐述的有类似之处。JMX分为规范和远程 接口两个部分，在J2SE1.5版本中，JMX已经纳入到J2SE 的范畴中了 软件总线（bus） • COP仅仅只是提出了一个系统划分的基础，要构 成一个完整应用，光有组件和服务还不够，还需 要将组件和服务以一种有效的方式组织起来，有 些文章把这种组织性的代码称为Fabric，有结构 和组织的意思。而在我们的文章中，称之为软件 总线（bus）。 软件总线是什么？ • 软件总线是什么？他和计算机的总线一样，它负责在各个组件中传递 信息流，将各个组件组织起来，完成一个具体的任务。总线是一个抽 象的概念，在实际中总线也是由具体的技术构成。 – 一个总线可能是一段代码，负责调用各个组件； – 总线也能是一个消息系统，负责收集和分派消息； – 总线也可能是一个工作流系统，负责系统信息的流转； – 总线还可能是一个JMX，负责将消息路由到目标组件。 • 但无论总线的实现技术是什么，总线的特点就是采用一种松耦合的方 式将组件组织起来。这样，总线本身和挂接在总线上的组件就是松耦 合的，至于组件挂接到总线的形式，也就是我们之前讨论过的服务和 服务适配器要做的事情了。 软件总线有三种可能的实现 • 目前的软件总线有三种可能的实现： – 直接调用/远程调用/WebService，MOM，以及工作流，根据应用 系统的特点可以采用不同的总线实现。例如以调用为主的总线适 用于那些流程比较明确的应用，因为流程是硬编码的，变化起来 相对麻烦一些。 – 工作流为主的总线适用于流程比较灵活，需要复杂的分支和人为 的干预。 – MOM为主的总线则适用于大型的分布式，或是异构的应用，不同 的应用之间以一种松散的方式进行协作。 总线模型（1） • 消息总线同时应用于层间 和外部应用 • 优点 – 模块化提高集成性 – 异构平台 • 问题 – 业务层依赖UI层的信息 – 消息总线要支持多种通讯 – 消息总线要实现满足层间和 外部应用的灵活性和可用性 总线模型（2） • 消息总线只应用与外 部应用之间 • 优点： – 系统效率 – 设计和实现简单 • 问题： – 降低了系统的扩展能力 服务和总线规范才是软件组织的 核心竞争力 • 但是无论采取哪一种的总线实现方式，组件和服务是不变 的，变化的是服务适配器，MOM的服务适配器和工组流 的服务适配器是不同的。 – MOM的服务适配器主要的工作是将消息中的内容翻译为POJO， 并调用服务； – 而工作流的服务适配器可能就只是一个基于当前工作流状态的调 用。 • 这样形成的系统架构就是相对稳定、松散耦合的，不论是 组件发生变化，还是总线的技术发生变化，只要服务和总 线的规范是稳定的，整体的软件系统就是稳定的。 • 而服务和总线规范才是软件组织的核心竞争力所在，而这 也正是软件总线的主要目的。