1. 什么是用例？

在介始用例方法之前，我们首先来看一下传统的需求表述方式-"软件需求规约"(Software Requirement Specification)。传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。一个典型的软件需求规约可能具有以下形式：

采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。由此常常导致这样的迷惑：系统需求应该详细到何种程度？一个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。在有些公司的开发流程中，这种需求被称为"内部需求"，而对应于用户的原始要求则被称之为"外部需求"。

功能分解方法的另一个缺点是这种方法分割了各项系统功能的应用环境，从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现一个完成的系统服务的。所以在传统的SRS文档中，我们往往需要另外一些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得SRS需求更象是一个设计文档。

1.1 参与者和用例

从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。用例模型主要由以下模型元素构成：

• 参与者(Actor)
  参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
• 用例(Use Case)
  用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
• 通讯关联(Communication Association)
  通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

这大三种模型元素在UML中的表述如下图所示。

以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、提款和转帐交易。

通讯关联表示的是参与者和用例之间的关系，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者；如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的（用例本身描述的就是参与者和系统之间的对话），并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。

1.2 用例的内容

用例图使我们对系统的功能有了一个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每一个参与者需要系统为它提供什么样的服务。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例我们可以用事件流来描述这一对话的细节内容。如在ATM系统中的"提款"用例可以用事件流表述如下：

提款-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 输入提款金额

4. 提取现金

5. 退出系统，取回信用卡

但是这只描述了提款用例中最顺利的一种情况，作为一个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效、输入密码错、用户帐号中的现金余额不够等，所有这些可能发生的各种情况（包括正常的和异常的）被称之为用例的场景(Scenario)，场景也被称作是用例的实例(Instance)。在用例的各种场景中，最常见的场景是用基本流(Basic Flow)来描述的，其他的场景则是用备选流(Alternative Flow)来描述。对于ATM系统中的"提款"用例，我们可以得到如下一些备选流：

提款-备选事件流

备选流一：用户可以在基本流中的任何一步选择退出，转至基本流步骤5。

备选流二：在基本流步骤1中，用户插入无效信用卡，系统显示错误并退出信用卡，用例结束。

备选流三：在基本流步骤２中，用户输入错误密码，系统显示错误并提示用户重新输入密码，重新回到基本流步骤2；三次输入密码错误后，信用卡被系统没收，用例结束。

…

通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。

1.3 用例方法的优点

用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。

与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述的是一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。

在RUP中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为一个主要的输入工件(Artifact)，如项目管理、分析设计、测试等。根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试一个系统服务，可以根据用例的各个场景(Scenario)来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。

回页首

2. 建立用例模型

使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容：

• 用例图(Use Case Diagram)
  确定系统中所包含的参与者、用例和两者之间的对应关系，用例图描述的是关于系统功能的一个概述。
• 用例规约(Use Case Specification)
  针对每一个用例都应该有一个用例规约文档与之相对应，该文档描述用例的细节内容。

在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每一个用例的用例规约。

2.1 寻找参与者

所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手：

• 系统开发完成之后，有哪些人会使用这个系统？
• 系统需要从哪些人或其他系统中获得数据？
• 系统会为哪些人或其他系统提供数据？
• 系统会与哪些其他系统相关联？
• 系统是由谁来维护和管理的？

这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。

2.1.1 系统边界决定了参与者

参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。

如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。

值得注意的是，用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM机系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个MIS管理系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。

2.1.2 特殊的参与者――系统时钟

有时候我们需要在系统内部定时地执行一些操作，如检测系统资源使用情况、定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这一类功能需求呢？对于这种情况，我们可以抽象出一个系统时钟或定时器参与者，利用该参与者来触发这一类定时操作。从逻辑上，这一参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。

2.2 确定用例

找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手（针对每一个参与者）：

• 参与者为什么要使用该系统？
• 参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？
• 参与者是否会将外部的某些事件通知给该系统？
• 系统是否会将内部的某些事件通知该参与者？

综合以上所述，ATM系统的用例图可表示如下，

在用例的抽取过程中，必须注意：用例必须是由某一个主角触发而产生的活动，即每个用例至少应该涉及一个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例；或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到一个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定一个新的用例，或者该参与者是一个多余的模型元素，应该将其删除。

可视化建模的主要目的之一就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是一个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合一定的命名约定，这样整个用例模型才能够符合一定的风格。如参与者的名称一般都是名词，用例名称一般都是动宾词组等。

对于同一个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择一种"最佳"（或"较佳"）的结果，一个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同一用例模型的理解应该是一致的。

2.3 描述用例规约

应该避免这样一种误解――认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有一个总体的认识。除此之外，我们还需要描述每一个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每一个用例的详细描述――用例规约所组成的。RUP中提供了用例规约的模板，每一个用例的用例规约都应该包含以下内容：

• 简要说明 (Brief Description)
  简要介绍该用例的作用和目的。
• 事件流 (Flow of Event)
  包括基本流和备选流，事件流应该表示出所有的场景。
• 用例场景 (Use-Case Scenario)
  包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
• 特殊需求 (Special Requirement)
  描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）。
• 前置条件 (Pre-Condition)
  执行用例之前系统必须所处的状态。
• 后置条件 (Post-Condition)
  用例执行完毕后系统可能处于的一组状态。

用例规约基本上是用文本方式来表述的，为了更加清晰地描述事件流，也可以选择使用状态图、活动图或序列图来辅助说明。只要有助于表达的简洁明了，就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如活动图有助于描述复杂的决策流程，状态转移图有助于描述与状态相关的系统行为，序列图适合于描述基于时间顺序的消息传递。

2.3.1 基本流

基本流描述的是该用例最正常的一种场景，在基本流中系统执行一系列活动步骤来响应参与者提出的服务请求。我们建议用以下格式来描述基本流：

1) 每一个步骤都需要用数字编号以清楚地标明步骤的先后顺序。

2) 用一句简短的标题来概括每一步骤的主要内容，这样阅读者可以通过浏览标题来快速地了解用例的主要步骤。在用例建模的早期，我们也只需要描述到事件流步骤标题这一层，以免过早地陷入到用例描述的细节中去。

3) 当整个用例模型基本稳定之后，我们再针对每一步骤详细描述参与者和系统之间所发生的交互。建议采用双向(roundtrip)描述法来保证描述的完整性，即每一步骤都需要从正反两个方面来描述:(1)参与者向系统提交了什么信息；(2)对此系统有什么样的响应。具体例子请参见附录。

在描述参与者和系统之间的信息交换时，需指出来回传递的具体信息。例如，只表述参与者输入了客户信息就不够明确，最好明确地说参与者输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内，可以在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。

2.3.2 备选流

备选流负责描述用例执行过程中异常的或偶尔发生的一些情况，备选流和基本流的组合应该能够覆盖该用例所有可能发生的场景。在描述备选流时，应该包括以下几个要素：

1) 起点：该备选流从事件流的哪一步开始；

2) 条件：在什么条件下会触发该备选流；

3) 动作：系统在该备选流下会采取哪些动作；

4) 恢复：该备选流结束之后，该用例应如何继续执行。

备选流的描述格式可以与基本流的格式一致，也需要编号并以标题概述其内容，编号前可以加以字母前缀A(Alternative)以示与基本流步骤相区别。

2.3.3 用例场景

用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

2.3.4 特殊需求

特殊需求通常是非功能性需求，它为一个用例所专有，但不适合在用例的事件流文本中进行说明。特殊需求的例子包括法律或法规方面的需求、应用程序标准和所构建系统的质量属性（包括可用性、可靠性、性能或支持性需求等）。此外，其他一些设计约束，如操作系统及环境、兼容性需求等，也可以在此节中记录。

需要注意的是，这里记录的是专属于该用例的特殊需求；对于一些全局的非功能性需求和设计约束，它们并不是该用例所专有的，应把它们记录在《补充规约》中。

2.3.5 前置和后置条件

前置条件是执行用例之前必须存在的系统状态，后置条件是用例一执行完毕后系统可能处于的一组状态。

2.4 检查用例模型

用例模型完成之后，可以对用例模型进行检查，看看是否有遗漏或错误之处。主要可以从以下几个方面来进行检查：

• 功能需求的完备性
  现有的用例模型是否完整地描述了系统功能，这也是我们判断用例建模工作是否结束的标志。如果发现还有系统功能没有被记录在现有的用例模型中，那么我们就需要抽象一些新的用例来记录这些需求，或是将他们归纳在一些现有的用例之中。
• 模型是否易于理解
  用例模型最大的优点就在于它应该易于被不同的涉众所理解，因而用例建模最主要的指导原则就是它的可理解性。用例的粒度、个数以及模型元素之间的关系复杂程度都应该由该指导原则决定。
• 是否存在不一致性
  系统的用例模型是由多个系统分析员协同完成的，模型本身也是由多个工件所组成的，所以我们要特别注意不同工件之前是否存在前后矛盾或冲突的地方，避免在模型内部产生不一致性。不一致性会直接影响到需求定义的准确性。
• 避免二义性语义
  好的需求定义应该是无二义性的，即不同的人对于同一需求的理解应该是一致的。在用例规约的描述中，应该避免定义含义模糊的需求，即无二义性。

回页首

3. 系统需求

RUP中根据FURPS+模型将系统需求分为以下几类：

• 功能(Functionality)
• 可用性(Usability)
• 可靠性(Reliability)
• 性能(Performance)
• 可支持性(Supportability)
• 设计约束等

除了第一项功能性需求之外的其他需求都归之为非功能性需求。

3.1 需求工件集

用例模型主要用于描述系统的功能性需求，对于其他的非功能性需要用其他文档来记录。RUP中定义了如下的需求工件集合。

• 用例模型：记录功能性需求
  • 用例图：描述参与者和用例之间的关系
  • 用例规约：描述每一个用例的细节信息
• 补充规约：记录一些全局性的功能需求、非功能性需求和设计约束等
• 词汇表：记录一些系统需求相关的术语

在实际应用中，除了这些工件之外，我们还可以根据实际需求灵活选用其他形式的文档来补充说明需求。并不是所有的系统需求都适保合用用例模型来描述的，如编译器，我们很难用用例方法来表述它所处理的语言的方法规则，在这种情况下，采用传统的BNF范式来表述更加合适一些。在电信软件行业中，很多电信标准都是采用SDL语言来描述的，我们也不必用UML来改写这些标准（UML对SDL存在着这样的兼容性），只需将SDL形式的电信标准作为需求工件之一，在其他工件中对其加以引用就可以了。总之，万万不可拘泥于用例建模的形式，应灵活运用各种方式的长处。

3.2 补充规约

补充规约记录那些在用例模型中不易表述的系统需求，主要包括以下内容。

• 功能性
  功能性需求主要在用例模型中刻画，但是也有部分需求不适合在用例中表述。有些功能性需求是全局性的，适用于所有的用例，如出错处理、I18N支持等，我们不需要在所有的用例中描述这些功能性需求，只需要在补充规约中统一描述就可以了。
• 可用性
  记录所有可用性相关的需求，如系统的使用者所需要的培训时间、是否应附合一些常见的可用性标准如Windows界面风格等。
• 可靠性
  定义系统可靠性相关的各种指标，包括：
  
  • 可用性：指出可用时间百分比(xx.xx%)，系统处于使用、维护、降级模式等操作的小时数；
  • 平均故障间隔时间(MTBF)：通常表示为小时数，但也可表示为天数、月数或年数；
  • 平均修复时间(MTTR)：系统在发生故障后可以暂停运行的时间；
  • 精确度：指出系统输出要求具备的精密度（分辨率）和精确度（按照某一已知的标准）；
  • 最高错误或缺陷率：通常表示为bugs/KLOC（每千行代码的错误数目）或bugs/function-point（每个功能点的错误数目）。
• 性能
  记录系统性能相关的各种指标，包括：
  
  • 对事务的响应时间（平均、最长）；
  • 吞吐量（例如每秒处理的事务数）；
  • 容量（例如系统可以容纳的客户或事务数）；
  • 降级模式（当系统以某种形式降级时可接受的运行模式）；
  • 资源利用情况：内存、磁盘、通信等。
• 可支持性
  定义所有与系统的可支持性或可维护性相关的需求，其中包括编码标准、命名约定、类库、如何来对系统进行维护操作和相应的维护实用工具等。
• 设计约束
  设计约束代表已经批准并必须遵循的设计决定，其中包括软件开发流程、开发工具、系统构架、编程语言、第三方构件类库、运行平台和数据库系统等等。

3.3 词汇表

词汇表主要用于定义项目特定的术语，它有助于开发人员对项目中所用的术语有统一的理解和使用，它也是后续阶段中进行对象抽象的基础。

回页首

4. 调整用例模型

在一般的用例图中，我们只表述参与者和用例之间的关系，即它们之间的通讯关联。除此之外，我们还可以描述参与者与参与者之间的泛化(generalization)、用例和用例之间的包含(include)、扩展(extend)和泛化(generalization)关系。我们利用这些关系来调整已有的用例模型，把一些公共的信息抽取出来重用，使得用例模型更易于维护。但是在应用中要小心选用这些关系，一般来说这些关系都会增加用例和关系的个数，从而增加用例模型的复杂度。而且一般都是在用例模型完成之后才对用例模型进行调整，所以在用例建模的初期不必要急于抽象用例之间的关系。

4.1 参与者之间的关系

参与者之间可以有泛化(Generalization)关系（或称为"继承"关系）。例如在需求分析中常见的权限控制问题（如下图所示），一般的用户只可以使用一些常规的操作，而管理员除了常规操作之外还需要进行一些系统管理工作，操作员既可以进行常规操作又可以进行一些配置操作。

在这个例子中我们会发现管理员和操作员都是一种特殊的用户，他们拥有普通用户所拥有的全部权限，此外他们还有自己独有的权限。这里我们可进一步把普通用户和管理员、操作员之间的关系抽象成泛化(Generalization)关系，管理员和操作员可以继承普通用户的全部特性（包括权限），他们又可以有自己独有的特性（如操作、权限等）。这样可以显著减速少用例图中通讯关联的个数，简化用例模型，使之更易于理解。

4.2 用例之间的关系

用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化(generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。

4.2.1 包含(include)

包含关系是通过在关联关系上应用<<include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。

包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。

在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。

在基础用例的事件流中，我们只需要引用被包含用例即可。

查询-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 选择查询

4. 查看帐号余额

5. 包含用例"打印回执"

6. 退出系统，取回信用卡

在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。

有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

4.2.2 扩展(extend)

扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。

例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。

在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。

值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把一些可选的操作独立封装在另外的用例中。

4.2.3 泛化(generalization)

当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

以下是一个用例泛化关系的例子，执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。

用例泛化关系中的事件流示例如下：

4.3 调整用例模型

用例模型建成之后，我们可以对用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性。主要可以从以下检查点(checkpoints)入手:

• 用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，可能需要将它们合并为一个用例。
• 多个用例之间是否有非常相似的行为或事件流？如果有，可以考虑将它们合并为一个用例。
• 用例事件流的一部分是否已被构建为另一个用例？如果是，可以让该用例包含(include)另一用例。
• 是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系(extend)来建立此模型。

回页首

5. 管理用例模型复杂度

一般小型的系统，其用例模型中包含的参与者和用例不会太多，一个用例图就可以容纳所有的参与者，所有的参与者和用例也可以并存于同一个层次结构中。对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，我们需要一些方法来有效地管理由于规模上升而造成的复杂度。

5.1 用例包

包(Package)是UML中最常用的管理模型复杂度的机制，包也是UML中语义最简单的一种模型元素，它就是一种容器，在包中可以容纳其他任意的模型元素（包括其他的包）。在用例模型中，我们可以用构造型(Sterotype)<<use case>>来扩展标准UML包的语义，这种新的包叫作用例包(Use Case Package)，用于分类管理用例模型中的模型元素。

我们可以根据参与者和用例的特性来对它们进行分类，分别置于不同的用例包管理之下。例如对于一个大型的企业管理信息系统，我们可以根据参与者和用例的内容将它们分别归于人力资源、财务、采购、销售、客务服务这些用例包之下。这样我们将整个用例模型划分成为两个层次，在第一层次我们看到的是系统功能总共分为五部分，在第二层次我们可以分别看到每一用例包内部的参与者和用例。

一个用例模型需要有多少个用例包取决你想怎么样来管理用例模型的复杂度（包括参与者和用例的个数，以及它们之间的相互关系）。UML中的包其实就类似于文件系统中的目录，文件数量少的时候不需要额外的目录，文件数量一多就需要有多个目录来分类管理，同样一组文件不同的人会创建不同的目录结构来进行管理，关键是要保证在目录结构下每一个文件都要易于访问。同样的道理存在于用例建模之中，如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。

5.2 用例的粒度

我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。

维护用户-基本事件流

该基本流由三个子事件流构成：

1) 添加用户子事件流
…

2) 修改用户 子事件流
…

3) 删除用户子事件流
…

但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。

应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。

用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。

5.3 用例图

用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。

在一个用例模型中，如果参与者和用例之间存在着多对多的关系，并且他们之间的关系比较复杂，如果在同一个用例图中表述所有的参与者和用例就显得不够清晰，这时我们可创建多个用例图来分别表示各种关系。

如果想要强调某一个参与者和多个用例的关系，你就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。

如果想要强调某一个用例和多个参与者之间的关系，你就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。

总之在用例建模过程中，你可以根据自己的需要创建任意多个用例图，用不同的用例来强调参与者和用例之间不同的关系。但是最重要的是要考虑整个用例模型的可理解性，如果可以用一个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。

在developerWorks中，有许多文章介绍了WPS和WID在流程整合中的应用，比如BPEL开发、CEI监控和selector等等，那么，在实际的应用中，通常会有这样的场景：流程调用的一些第三方系统都是需要人工去审批，流程引擎发出调用第三方系统的请求后，是一个需要人审批的长流程（Long-runing process）。因此，这个调用是一个异步调用，只有第三方系统把审批结果传回给主流程，流程才能继续往下运行。这和直接在BPEL中直接实现的human task节点是不同的，因为用到了SCA组件的装配技术。

本文将详细介绍如何在WPS中利用SCA的编程模型实现human task manager对第三方系统的调用，并通过实际的例子加以说明，使读者能够掌握使用SCA和human task manager来实现对第三方系统的异步调用。

二、产品及其基本技术框架简介

1 WebSphere Process Server及其开发工具Integration Developer

WebSphere Process Server V 6.0（WebSphere流程服务器V 6.0）基于SOA体系架构并提供了统一的、简化的编程模型，是新一代的业务流程服务器，能够帮助我们基于SOA架构模型实现企业的业务流程转型。WebSphere流程服务器采用基于开放标准的技术来整合业务流程，实现自动化的流程服务器。采用WebSphere流程服务器可以通过统一的编程模型将企业的人员、工作流程、应用、系统、平台和基础设施整合在一起。

基于Eclipse技术的WPS专用开发工具WebSphere Integration Developer V6.0则为快速组装、开发业务解决方案提供了新一代的开发工具。采用这一工具可以基于统一的编程模型通过BPEL（Business Process Execution Language， 业务流程执行语言）来描述各类流程。它易于使用，仅需要少量的相关技能即可使用，并且提供了开发、测试和将应用部署到流程服务器的功能。

2 基本技术实现框架

2.1 SCA(服务组件编程架构模型)

为了使客户能够更加简单的实现向这种面向服务架构的转变，IBM在推出一系列WebSphere新产品的同时，提出了一种新的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如POJO, EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性，这就是面向服务组件的架构（Service Component Architecture，SCA）。

2.2 human task

WPS V6中的人工任务管理器（Human Task Manager）模块实现了与人工任务相关的下列功能:

• 让用户启动业务流程或者其他Service 组件
• 实现业务流程中的Staff活动
• 流程管理(Administration)
• 动态创建含有与人工或者Service交互的任务

人工任务管理器针对三种基本场景：机器-人(Machine-to-Human)，人-机器(Human-to-Machine)，和人-人（Human-to-Human）。相应的，人工任务有四种不同类型，见下图。

其中，机器-人场景中的人工任务（participants）是我们这篇文章要主要介绍的，它使流程调用的service的执行中能融入人工交互，典型的例子是一个业务流程为参与业务执行的人创建任务。pTask是一个标准的SCA 组件，可以被用在任何希望引入人工交互的应用中而不仅仅是业务流程。

与其他工作流类的流程整合解决方案不同，WPS中引入了基于SCA service的人工任务，用户可以灵活地替换系统中基于SCA service的自动service和真正的人工实现。

2.3 Interface开发

在下面的实例中，我们是根据需求来确定出出第三方系统与主流程调用的接口（硬连接的方式），而在企业级应用中，也可以通过实施IBM WebSphere Message Broker来作为连接的应用接口，帮助WPS来连接企业应用。

三、样例背景及解决方案概述

3.1 方案背景

许多公司在不同时期都开发了企业内部的审批系统，某个部门内部的业务都各自有独立的系统来进行审批，而有的业务需要不同部门合作，那就只有通过人工来审批，手续相当繁琐，效率也不高。而为某项业务重新开发新的工作流引擎，又舍不得以前的IT投资，因此，企业就有了这样的需求：能否有这样的流程控制器可以将不同部门的独立系统统一的利用起来，实现跨系统的易更改工作流呢？

在我们这篇文章所举的范例中，是一个基于BPEL的审批流程，其中涉及到财务系统，项目管理系统2个独立的系统。其中财务系统是由Deiphi + OCX控件实现的，由SQL server存储数据；项目管理系统是一个J2EE系统，用DB2 数据库存储数据。

在需求中，项目管理系统必须依赖于财务系统才能进行审核等操作，需要把财务系统的数据传给项目管理系统，适当的时候，项目管理系统也要把相关数据传给财务系统。在此基础上，客户还可能有更高的需求，他们不但想要有流程的整合，还要有门户的整合，信息的整合。

3.2 IBM的解决方案

用WebSphere Process Server来做流程的整合，需要在不同的节点上完成与Deiphi和J2EE系统的异步调用，同时用Portal来做门户和信息的整合，并配置SSO， 用户只需要在Portal进行一次登陆，就可以相应的访问WPS系统、财务系统（DEiphi）、项目管理系统(J2EE)。相应用户登陆后可以看到自己的任务列表，如预算编制，项目建立，项目审批等。用户点击相应的任务，通过human task接口直接可以访问到第三方的系统，由第三方的系统得到与任务有关的数据，并直接组织数据发送给WPS.他们之间的通信方式是在SOAP协议上传输XML数据。

3.3 可行性分析

在WPS的装配图里可以实现的是，第三方的系统只需要提供一个接口，WPS就可以以异步或同步方式来访问组件。此需求里，客户要在系统里首先能看到自己的任务列表，点击不同的任务来决定到那个系统去。如客户任务列表里有一项的任务是"预算编制"，用户一点击"预算编制"，在Portal的另一个iframe就应把财务系统的相应界面调出来。Deiphi根据TaskID到WPS上把相应的数据取到本地并进行处理，用户进行适当的操作以后，Deiphi再把相应的数据发送给WPS，此过程可如下图所示：

四、解决方案开发

这一章将论述实现这个解决方案的每一个大的步骤，但并不详细论述如何step by step的实现，比如怎样定义BO,定义接口等，他们已超出了本次主题。因此，本文的读者必须对WID和WPS有一定的了解。

4．1 定义BO

BO是工作流平台与外界进行数据交互的数据格式，第一步我们首先明确工作流平台与第三方系统进行数据交互的定义，根据业务流程的需要，在每一个流程节点，第三方系统需要向WPS工作流平台放入哪些数据项，想要从工作流平台得到什么数据，都要定义出来。 如下图所示：

在BPEL每次调用第三方系统时，必须前期将输入输出的参数确定。主流程传出业务数据对象（BO），第三方系统接受后，进入自己的子流程，通过人工处理，将主流程需要的参数也以BO的方式传递给主流程，使流程能够继续运行。

在我们的例子中，主流程与2个子系统每次交互中，我们都定义了两个BO作为数据输入输出的数据格式，分别是OperationNameIN和OperationNameOut。在下图中，对应"编制预算"这个操作，我们分别定义2个BO，即BudgetBuildIn和BudgetBuildOut.

4.2 定义接口

这一步需要定义接口，如操作名称，输入数据及输出数据的定义，在WPS的开发流程里，每一个组件如果能在装配图里能被其他的组件所调用，就必须定义接口， Human Task 也不例外。

每个操作的输入和输出数据（input和output）的数据类型可以用默认的数据类型，如int、boolean等，也可以用我们定义好的BO。在我们的例子中，由于每次与财务系统或者项目管理系统交互时，都是组合数据，因此都用定义好的BO作为数据类型。如下图所示，在BudgetBuild接口中，定义了编制预算的操作：其输入输出的数据类型分别为budgetBuildIn和budgetBuildOut。

4.3 流程的具体定义

在Process里我们根据用户的具体业务需求，实现每一个节点，明确每一个节点是与那个系统进行交互的。整个Process有几次invoke，就表明与财务系统和项目管理系统有几次交互，即humantask实现的接口。

4.4 定义装配图

完成了所有的接口定义以后，我们需要在装配图里把他们都明确的用线连接起来，可以清楚地明确他们之间的调用关系及数据流向。如下图所示，把每个接口都拖入到装配图中，再分别用humantask来实现。最后，再把主流程Process拖到装配图中，通过"Wire to Existing"连接所有组件。

4.5 对外export 一个调用接口

所有的第三方系统通过这个component 来访问到WPS工作流平台。我们同样在装配图中建起连接。

4.6 实现一个统一的调用接口

如图所示，财务系统需要从WPS工作流平台得到与这个任务相关的数据，有人工处理以后，要传回到WPS工作流平台，并complete 这个任务。这里我们实现一个web service, 并对外提供两个接口供所有第三方系统进行调用，如Deilhpi, MQ WorkFlow, J2EE等。

该webservice的WSDL描述如下：

												
														      
  <wsdl:operation name="getHTInput">
         <wsdlsoap:operation soapAction=""/>
         <wsdl:input name="getHTInputRequest">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
			namespace="http://ForMIS.ibm.com" use="encoded"/>
         </wsdl:input>
         <wsdl:output name="getHTInputResponse">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
			namespace="http://ForMIS.ibm.com" use="encoded"/>
         </wsdl:output>
      </wsdl:operation>
      <wsdl:operation name="setHTOutput">
         <wsdlsoap:operation soapAction=""/>
         <wsdl:input name="setHTOutputRequest">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
			namespace="http://ForMIS.ibm.com" use="encoded"/>
         </wsdl:input>
         <wsdl:output name="setHTOutputResponse">
            <wsdlsoap:body encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
			namespace="http://ForMIS.ibm.com" use="encoded"/>
         </wsdl:output>
      </wsdl:operation>
      
												
										

实现操作如下所述：

实现getHTInput operation

1) 得到HumanTaskManager实例

												
														RelationshipService  relService = (RelationshipService) ServiceManager.INSTANCE
			.locateService("com/ibm/wbiserver/rel/RelationshipService");
		InitialContext ctx = new InitialContext();
		Object myObj = ctx.lookup(HTM_MANAGER_NAME);
		HumanTaskManagerHome myHome = (HumanTaskManagerHome) PortableRemoteObject.narrow
		(myObj, com.ibm.task.api.HumanTaskManagerHome.class);
	HumanTaskManager	humanTaskManager = myHome.create();

												
										

2） 根据taskID得到第三方系统的需要得到的数据

												
														   ClientObjectWrapper input = null;
	input = humanTaskManager.getInputMessage(id);
   
												
										

实现setOutput operation

1) 得到HumanTaskManager实例

												
															
RelationshipService  relService = (RelationshipService) ServiceManager.INSTANCE
			.locateService("com/ibm/wbiserver/rel/RelationshipService");
		InitialContext ctx = new InitialContext();
		Object myObj = ctx.lookup(HTM_MANAGER_NAME);
		HumanTaskManagerHome myHome = (HumanTaskManagerHome) PortableRemoteObject.narrow(myObj,
		com.ibm.task.api.HumanTaskManagerHome.class);
	HumanTaskManager	humanTaskManager = myHome.create();
	
												
										

2) 根据taskID，把第三方上传的数据赋给WPS相应的Human Task

												
														ClientObjectWrapper outputWrapper = humanTaskManager.createOutputMessage(id);
					BusObjImpl busObjImpl = (BusObjImpl) outputWrapper
							.getObject();
					busObjImpl.set(0, output);

												
										

3) 完成这个任务complete

												
														humanTaskManager.complete(id,outputWrapper);

												
										

4． 7 试与部署

首先访问Http://localhost:9080/bpc 用bpc explorer进行测试,证明所有的节点都可以走通，就可以部署到WPS服务器上，与Portal及第三方系统（Deilphi, MQ WorkFlow, J2EE）进行互联测试。运行实例演示如下：

4．7．1 下图是获取任务列表的演示效果：

登陆系统后，用户将在系统中看到自己的任务列表，点中任务，就可以在下方的portlet中进行信息输入和审批。

4．7．2． 与Deiphi进行交互的页面

流程进入财务系统后，将调用财务系统，在OCX控件中进行相应的操作和处理，然后再把流程往下运行所需要的数据再传回给process。

4．7．3． 与MQ WorkFlow 的交互页面

与财务系统一样，当流程调用到项目管理系统时，也出现了项目管理所采用的MQ workflow的界面，进行相应处理和审批后，将数据传回给WPS，于是流程就可以继续往下运行。

五． 结束语

本篇文章主要讲述了一个解决方案，即如何利用Human Task把第三方系统连接到WPS 里，并实现人工参与及异步通信。这里着重介绍了解决方案的大致步骤，而没有关注于细节的描述。

目前业界主要的软件厂商都在大力推广面向服务的架构（Service Oritented Architecture，SOA）的概念，但是对于很多客户来说，SOA的概念还是显得相对抽象的。为了使客户能够更加简单的实现向这种面向服务架构的转变，IBM在推出一系列WebSphere新产品的同时，提出了一种新的服务组件模型。这是一种全新的、跟语言无关的编程模型，它提供了一种统一的调用方式，从而使得客户可以把不同的组件类型，比如POJO, EJB, 流程组件，人工交互组件等都可以通过一种标准的接口来封装和调用。结合SDO的数据模型，这种服务组件的编程模型可以大大的简化客户的编程，提高应用的灵活性，这就是面向服务组件的架构（Service Component Architecture，SCA）。目前IBM 对SCA的支持是在最近推出的WebSphere Process Server（WPS）中，但是以后该服务组件模型将作为一个IBM软件重要的编程模型被应用到底层平台当中。本文将介绍SCA编程模型中的基本概念，并以一个简单的例子来说明它的一些基本用法，期待能够抛砖引玉，并为读者以后深入了解SCA打下基础。

1.1 SCA的起源

基于组件的编程一直是软件业简化编程和提高效率和质量的一个重要方法，但是往往对于不同语言我们有不同的组件模型，从而需要不同的调用方式。比如在J2EE技术领域，我们就有EJB，POJO，JDBC，JMS等，这对于开发人员来说是一个极大的挑战。为了给这些不同的接口提供一个统一的调用方式，IBM提出了WSIF （Web Service Invocation Framework，具体请参考http://ws.apache.org/wsif/ ），并将它贡献给Apache组织。WSIF作为Web Service领域的一个规范，提供了一种基于Java API统一调用各种服务的能力。但是WSIF没有形成一个基于组件的架构模型，因此IBM在此基础上推出了一个面向服务的组件模型（Service Oritented Architecture, SCA）。这个模型不但解决了统一调用的问题，还提出了一个基于组件的构建模型，并提供了许多面向企业计算的QoS能力。因此，从技术的角度来说，SCA是WSIF的延续和扩展。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。这种方式也使得客户的企业应用具有良好的分层架构，能够很好的分离应用的业务逻辑和IT逻辑，不但易于应用的构建，也易于应用的更改和部署。

1.2 SCA中的基本概念

服务组件模型（SCA）中提出了一些新的概念，比如服务组件，模块，共享库，导入和导出等。下面将分别解释这些服务组件中的基本概念。

1.2.1 服务组件

服务组件是SCA中的基本组成元素和基本构建单位，也是我们具体实现业务逻辑的地方。我们可以把它看成是构建我们应用的积木。我们可以非常容易地把传统的POJO，无状态会话BEAN等包装成SCA中的服务组件。 SCA服务组件的主要接口规范是基于WSDL（Web Service Description Language）的，另外为了给Java编程人员提供一个比较直接的接口，SCA的部分服务组件也提供了Java接口。因此，使用服务组件的客户端可以选择使用WSDL接口或Java接口。

服务组件提供给别的服务调用的入口叫Interface（接口）。而服务组件本身可能也需要调用别的服务，这个调用出口叫Reference（引用）。无论是接口还是引用，其调用规范都是WSDL或Java接口。SCA服务组件的接口模型请参考图 1：

WebSphere Process Server 充分利用了SCA的这种组件架构，并在产品中提供了一些与业务联系比较紧密的组件，比如业务流程，人工任务，业务状态机，业务规则等。这样用户就可以直接利用这些服务组件，构建自己的业务流程或其它业务集成的应用。在WebSphere Process Server V6.0.1中，服务组件及SCA在架构中的作用如图 2所示：

我们可以从图 2 中看到服务组件架构在WebSphere Process Server中的基础地位，也可以看到各种与业务相关的服务组件或技术相关的辅助服务组件的关系。关于WebSphere Process Server的体系架构这里不展开论述，具体请参考developerWorks专刊，2005年第三期的文章――WebSphere Process Srever V6体系结构概述。

SCA服务组件与传统组件的主要区别在于：

1． 服务组件往往是粗粒度的，而传统组件以细粒度居多。

2． 服务组件的接口是标准的，主要是WSDL接口，而传统组件常以具体API形式出现。

3． 服务组件的实现与语言是无关的，而传统组件常绑定某种特定的语言。

4． 服务组件可以通过组件容器提供QoS的服务，而传统组件完全由程序代码直接控制。

1.2.2 服务模块（Module）

服务模块（简称模块）由一个或多个具有内在业务联系的服务组件构成。把多少服务组件放在一个模块中，或者把哪些服务组件放在一起主要取决于业务需求和部署上灵活性的要求。模块是SCA中的运行单位，因为一个SCA模块背后对应的是一个J2EE的企业应用项目。这里之所以说是"背后"，原因是我们在开发工具WID（WebSphere Integration Developer V6.0）中，通过业务集成透视图看到都是SCA级别的元素。但是当你切换到J2EE透视图你就会发现这些SCA元素与实际J2EE元素之间的对应关系。因此，在WID中构建一个模块就相当于构建一个项目。另外，由于模块是一个独立部署的单元，这给应用的部署带来很大的灵活性。比如，只要保持模块接口不变，我们很容易通过重新部署新的模块而替换原有的业务逻辑，而不影响应用的其它部分。

由于一个模块中往往会包含多个服务组件，那我们如何来构建这些服务组件之间的相互调用关系呢？在WID工具中，我们只要简单地通过接口与引用之间的连线，就可以指定它们之间的调用关系而不需要写一行代码。另外，我们可以在这些连线上面设定需要的QoS要求，比如事务，安全等。

1.2.3 导入（Import）和导出（Export）

用户实际的应用经常是比较复杂的，因此实际的应用通常需要多个模块才能满足要求，而且这些模块之间又往往存在相互调用的关系。

另外模块中服务组件除了调用别的服务组件之外，也需要调用已有的一些应用，或者是让一些已有的应用来调用模块的服务，而这些应用可能不是基于SCA架构的。为了解决上述问题，在模块中我们引入了两个特殊的"端点"，一个是导入（Import），它的作用是使得模块中的服务组件可以调用模块外部的服务。另一个是导出（Export），它的作用是使得模块外部的应用可以调用模块中的服务组件。

由于涉及到模块内外的调用，因此需要指定专门的绑定信息。这些绑定信息包括了目标服务或源服务的调用方式，位置信息，调用的方法等。目前，在WebSphere Process Server V6.0中，导入端点提供了四种绑定方式，包括：JMS绑定，Web Service绑定，SCA绑定和无状态会话BEAN的绑定。导出端点提供了三种绑定方式，包括：JMS绑定，Web Service绑定和SCA绑定。对于SCA模块之间的调用，我们可以非常方便的把绑定方式设置为SCA绑定，但是对于非SCA模块与SCA模块之间的调用我们只能选择其它绑定方式。

1.2.4 共享库（Library）

当我们在构建了多个模块的时候，如果有一些资源可以在不同模块之间共享，那么我们可以选择创建一份可以在不同模块之间进行共享的资源，而不是在不同模块中重复创建。共享库就是存放这些共享资源的地方。共享库可以通过与模块类似的方式在WID中创建，但是共享库包含的内容只有：数据定义，接口定义，数据映射和关系。与模块最大的区别使共享库不包含服务组件，因此也就不包含业务逻辑。从包含的功能来看，我们可以把共享库看作是模块的一个子集。当一个模块需要用到共享库中的资源的时候，我们只需要使模块依赖于共享库即可。从部署的角度，一个共享库会对应一个JAR包。在部署的时候，模块所对应的J2EE企业应用会会自动包含所依赖的共享库JAR包。这里特别要注意的是，这里的共享库概念与WebSphere应用服务器中的共享库不是一个概念，它们之间没有任何联系，因此不要混淆。

1.2.5 Standalone Reference

模块中的服务组件是不能直接被外部Java代码使用的，为了外部的Java代码，比如JSP/Servlet使用模块中的服务组件，WID工具在模块中提供了一个特殊的端点，叫做Standalone Reference。这个端点只有引用（Reference），而没有接口（Interface）。只要把这个端点的引用连接到需要调用的服务组件的接口，外部的Java代码通过这个引用的名称来调用相应的服务组件了。具体如何调用请参考后面例子的实际代码。

至此，与服务模块相关的主要概念已大概介绍完了，它们之间的关系如图 3 所示：

1.3 同步调用和异步调用

我们知道，常见的方法调用都是同步调用，这种调用方式是一种阻塞式的调用方式，即客户端（主调用方）代码一直阻塞等待直到被服务端（被调用方）返回为止。这种调用方式相对比较直观，也是大部分编程语言直接支持的一种调用方式。但是，如果我们面对是基于粗粒度的服务组件，面对的是一些需要比较长时间才能有响应的应用场景，那么我们就需要一种非阻塞式调用方式，即异步调用方式。

SCA编程模式提供了三种方式的异步调用，它们分别是：

1． 单向调用方式。

2． 延迟响应方式。

3． 请求回调方式。

单向调用

单向调用方式是最为简单的异步调用方式，在这种调用方式中，客户端发出请求之后就不再关心服务端的情况，包括是否执行成功，返回值是什么等等。我们可以用下面的图 4示来描述这种单向调用方式：

单向调用方式是一种不管调用结果的方式，但是在很多情况下我们是需要知道调用结果的。我们需要知道调用是否成功，需要知道调用的结果，就算调用失败我们也希望知道错误代码等信息。在这种情况下，延迟响应和请求回调就是两种能够让我们知道调用结果的方式。

延迟响应方式

延迟响应方式是指客户端在发出调用请求之后继续执行，但是经过一段时间之后，客户端再调用相应的方法去检索返回结果，并通过参数指定如何根据调用的结果而执行进一步动作。由于是异步调用方式，因此，在第一次发出调用请求的时候，服务端需要返回一个称为票据（Ticket）的对象。这个对象会作为第二次发出检索结果请求时的一个参数。显然，这个Ticket对象的作用与WEB编程的SessionID非常类似。我们可以用图 5 来表示延迟相应调用方式：

请求回调

与延迟响应方式类似，请求回调方式也能得到服务端的响应，但是不同的是这个响应是由服务端通过回调方式来触发的，而不像延迟响应方式由客户端来主动检索的。请求回调方式的原理与许多编程语言中的回调机制类似，不同的是这里实现的层次比较高一点。我们可以用图6来表示请求调用方式：

1.4 SCA客户端的两种调用方式

从接口的角度，SCA的客户端编程模型有两种方式：

1． 静态调用方式

2． 动态调用方式

静态调用方式

静态调用方式是一种类型安全的方式，也是在一般Java编程中最为常见的方式。所谓类型安全指的就是在编译的时候就做类型的检查，而不是等到运行的时候发现类型错误问题。说明示例如下：

在SCA客户端编程中，静态方式就是直接拿到实际实现的接口类型，也即直接拿到Java接口。

动态调用方式

与静态调用方式相对，动态调用方式是一种非安全的方式。它的优点是调用非常灵活，但同时带来的不利之处是部分问题在编译的时候是发现不了的，只有等到运行的时候才能发现。说明示例如下：

像上面例子所示，在动态调用方式中，客户端通过invoke方法的字符串参数的方式来指定具体要调用的方法名称。很显然，在这种方式下，如果方法名有误是不能在编译时发现的。

关于动态调用方式另外要注意的一点是，在这种调用方式下，所有参数传递都是通过DataObject的方式，即SDO的方式。哪怕实际参数只是一个字符串，也需要包装成一个DataObject的方式。

接口类型与调用方式

实际上客户端采用哪种调用方式是与接口类型有密切的关系。当提供的接口类型是WSDL类型的，那么客户端的调用方式只能是动态调用方式。由于WSDL是SCA模型中主要的接口方式，这样就导致动态调用方式在SCA编程模型中非常普遍。但是如果提供的接口类型时Java类型的，那么客户端的调用方式可以是动态调用方式，也可以是静态调用方式。

1.5 SCA的第一个例子――HelloWorld

与学习一种语言一样，在初步了解一些基本概念之后，您是不是迫不及待的想自己动手写点东西了？让我们一起来写一个"SCA版"的HelloWorld。我们需要的开发环境就是一个WebSphere Integration Developer V6.0（WID），与IBM的许多其它的开发工具类似，这也是一个基于Eclipse 3.0的开发工具。下面简单描述一下WID与IBM其它开发工具如Rational Application Developer（RAD），Rational Software Architecture（RSA），WebSphere Business Modeler等工具的区别。如果采用基于角色的开发方式，我们一般可以把集成项目的主要开发人员分为下面四大类：业务分析人员，集成开发人员，软件架构师，J2EE/JAVA应用开发人员。他们的主要职责、技术要求和推荐使用的工具可以参见下表：

由上表可知，WID是一个主要针对集成开发人员的工具。除了专门的集成功能之外，WID工具也包含了RAD中的大部分功能。为了便于集成应用的测试，这个开发工具集成了一个测试环境，即WebSphere Process Server V6.0的运行环境。

这个例子的主要目的是帮助大家进一步理解前面描述的那些SCA基本概念。在HelloWorld应用模块中，我们会构建一个用Java实现的SCA组件，其接口为HelloWorldInterface.wsdl，其实现代码为HelloWorldImpl.java。为了使SCA模块外部的JSP文件可以调用这个SCA组件，需要一个Standalone Reference。在模块外部，我们构建一个index.jsp文件通过Standalone Reference来调用HelloWorld服务组件，并在页面上把调用结果显式出来。整个HelloWorld应用的基本图示如下：

1.5.1 构建的基本步骤

下面给出创建HelloWorld例子的基本步骤：

1． 创建模块。打开WID，切换到Business Integration透视图，新建一个模块，名称为HelloWorld。

2． 创建接口。通过点击HelloWorld模块左边的"＋"号展开，选择"Interface"，然后通过右键创建一个接口，名称为HelloWorldInterface。图示如下：

HelloWorld接口包含一个sengMessage操作，输入为一个名为message的字符串，输出一个名为status的字符串。可以通过点击接口编辑器上方的按钮来添加一个操作。通过和分别来添加输入和输出参数。图示如下：

3． 创建服务组件。双击打开HelloWorld模块的图形化编辑器，然后在控制面板上把Java组件图标 拖拉到编辑器中即生成一个Java服务组件，并把名称改为HelloWorld。如下图所示：

通过点击 按钮为HelloWorld组件选择一个接口，即我们前面定义的HelloWorldInterface。

通过双击上图中的HelloWorld组件，WID会自动生成HelloWorld组件实现类的基本框架HelloWorldImpl.java。如下图所示：

上图中高亮处显示的代码行就是我们可以给sendMessage方法添加业务代码的地方。比如，我们可以输入：return message + ". It's our first SCA example!";

4． 创建standalone reference。在工具栏中把 图标拖拉到编辑器中即生成一个standalone reference。如下图所示：

然后把Standalone Reference端点与HelloWorld组件连接起来。工具自动会为Standalone Reference创建一个匹配HelloWorld组件接口的引用。这里要注意的是，向导在自动创建Standalone Reference的引用时会弹出一个窗口询问需要创建一个Java接口类型的引用还是WSDL接口类型的引用。不同类型的接口会使得我们的客户端代码（在本例中是一个名为index.jsp的JSP文件）需要采用不同的调用方式。下面会分析两种不同类型的实现。

5． 生成JSP代码。如果我们在前面的引用接口类型中选择的是WSDL接口。那么Standalone Reference的属性如下图所示：

我们可以看到，引用的名称为HelloWorldInterfacePartner，接口为名称为HelloWorldInterface这个WSDL类型的接口。

如果我们在前面的引用接口类型中选择的是Java接口。那么Standalone Reference的属性如下图所示：

我们可以看到，引用的名称为HelloWorldInterfacePartner，接口为名称为world.hello.hello.world.interface_.HelloWorldInterface这个Java类型的接口。具体JSP代码参考下面的客户端代码分析部分。

6． 检查生成的项目。如果把WID切换到J2EE透视图的导航视图中，我们可以看到与HelloWorld模块对应的J2EE项目。J2EE企业项目为HelloWorldApp，其包含EJB项目HelloWorldEJB，Web项目HelloWorldWeb，J2EE客户端项目HelloWorldEJBClient。另外一个是名为HelloWorld的Java项目，这个项目的内容最终会以一个JAR文件的形式被HelloWorldApp应用使用。上一步中所提到的JSP文件需要在HelloWorldWeb项目中生成。具体如下图所示：

1.5.2 JSP客户端代码片断分析

那么如何在JSP页面中来调用我们的HelloWorld服务组件呢？按照前面的介绍，我们需要通过Standalone Reference来调用。那么我们如何才能得到这个Standalone Reference的引用呢？这里涉及到SCA编程模式中很重要的一个概念，那就是ServiceManager。ServiceManager是一个SCA环境的核心类，全名为com.ibm.websphere.sca.ServiceManager。这个类的作用主要就是能够让客户端去定位一个服务提供方。一般调用的方式是通过ServiceManager的locateService(String serviceRefName)方法。拿到服务之后，客户端就可以调用服务中所提供的方法了。（熟悉J2EE编程的人员可以联系对比JNDI的Lookup方法。）下面分别根据Standalone Reference引用的接口类型来分析主要JSP代码片断。

当接口类型是WSDL接口的情况

1．首先需要在JSP中导入相关的类，主要如下：

												
														<%@ page import="com.ibm.websphere.sca.ServiceManager" %>
<%@ page import="com.ibm.websphere.sca.Service" %>
<%@ page import="commonj.sdo.DataObject" %>

												
										

2．生成ServiceManager对象，并拿到相应的服务。

												
														ServiceManager serviceManager = new ServiceManager();
Service service = (Service) serviceManager.locateService("HelloWorldInterfacePartner");

												
										

这里locateService()方法中的参数是standalone reference的实际名称。从某种程度上我们可以把外部的JSP/Servlet的Java代码看成是Standalone reference的实现，这样来理解服务组件之间的相互调用。

3．调用服务的方法。

												
														String msg = request.getParameter("message");
DataObject resp = (DataObject) service.invoke("sendMessage",msg);

												
										

由于我们这里使用的是WSDL接口类型，因此返回结果是以DataObject的形式存在。

4． 显式得到的结果。

												
														<%=resp.getString("status")%>

												
										

通过调用DataObject的getString方法，我们拿到实际的返回结果，名为status的字符串。

当接口类型是Java接口的情况

1．首先需要在JSP中导入相关的类，主要如下：

												
														<%@ page import="com.ibm.websphere.sca.ServiceManager" %>
<%@ page import="com.ibm.websphere.sca.Service" %>
<%@ page import="world.hello.hello.world.interface_.HelloWorldInterface" %>

												
										

2．生成ServiceManager对象，并拿到相应的服务。

												
														ServiceManager serviceManager = new ServiceManager();
HelloWorldInterface service = 
(HelloWorldInterface) serviceManager.locateService("HelloWorldInterfacePartner");

												
										

由于Standalone Reference的接口变成了Java接口，因此这里返回的服务可以直接造型成HelloWorldInterface类型。

3．调用服务的方法。

												
														String msg = request.getParameter("message");
String resp = service.sendMessage(msg);

												
										

由于我们这里使用的是Java接口类型，因此调用的方式就是正常的Java接口调用。

4． 显式得到的结果。

												
														<%=resp%>

												
										

由于静态调用方式得到的就是实际定义的类型，因此这里字符串的显式比较简单。

具体实际项目的代码请参考本文附的项目交换文件包。

1.6 结束语

本文介绍了SCA的主要目的和一些基本的概念，并展示了一个最为简单的服务组件例子。从上面的讨论我们可以看到，SCA不但解决了统一调用的问题，而且提供了一个服务组件架构。这个服务组件架构将在构建面向服务的架构中起到举足轻重的作用，并在IBM的许多产品中会有所体现。

后记，在这篇文章完成之后，传来了一个关于SCA的好消息。SCA得到了业界几个主要软件厂商的支持。IBM、Oracle、BEA、SAP、Siebel、Sybase、IONA等厂商联合发布了SCA规范的0.9版本。具体规范可参见IBM DW的网址：http://www.ibm.com/developerworks/library/specification/ws-sca/

IBM® WebSphere® Process Server v6（以下称为 Process Server）是 IBM 提供的下一代业务集成软件，它基于包含了开放标准的面向服务的体系结构 (SOA)。它取代了 WebSphere Business Integration Server Foundation v5.1.x（以下称为 Server Foundation）。集成开发环境 (IDE) 也从 WebSphere Studio Application Developer Integration Edition（以下称为 Application Developer）v5.1.x 发展到了新的 WebSphere Integration Developer v6（以下称为 Integration Developer）。Integration Developer 是作为 Process Server 的补充的一个工具，它基于 Eclipse 3.0 并带来了基于组件开发的一个完整的新范例。

在将业务集成应用程序从 Server Foundation 迁移到 Process Server 时，您可以在以下两种方法中选择：

• 一种方法是运行时迁移，将整个 Server Foundation 配置（包括已安装的应用程序和配置文件）迁移到 Process Server 配置文件。应用程序二进制文件并没有变化，它们“只是”像在 Server Foundation 中那样运行。WebSphere Process Server v6.0.0 并没有提供这种迁移方法，但是正在考虑将其用于该产品的未来版本。
• 另一种方法是源构件迁移，它使用新集成开发环境中的迁移工具。这是 v6.0.0 中提供的唯一迁移方法。在这种情况下，将应用程序的源代码迁移到新编程模型并进行改写，以便您可以将迁移的应用程序部署到 Process Server。迁移向导将为您自动迁移所有 BPEL 文件和 BPEL WSDL 扩展，然后您必须执行一组手动迁移步骤以完成这一迁移。

本文描述了源构件迁移方法。您应该具有使用 Application Developer 的经验，并且对 Java™ 编程和业务流程相当了解。

源构件迁移概述

本文介绍了迁移一个简单服务项目（包含作为 EJB 公开并连接到 Java 服务的业务流程）的源构件的步骤。在本例中，业务流程只需调用 Java 服务，Java 服务反过来发送电子邮件。通过接收电子邮件，该操作帮助您了解应用程序何时成功执行。应用程序在 Application Developer 创建，在 Server Foundation 部署。我们向您展示了如何使用迁移向导将项目导入到 Integration Developer，如何重新连接组件，以及如何为在 Process Server 部署做好准备。

现有资源

现有的 Application Developer 项目交换 zip 文件包含构成企业应用程序的 6 个项目。应用程序的工作部分包含在 EmailService 服务项目中。EmailServiceCustomWeb 项目包括允许您从 Web 浏览器调用服务的 JSP。这两个项目都是在 EmailServiceEAR 定义的 EAR 中部署的。

我们将使用 Integration Developer 来迁移服务项目和自定义 Web 项目，并使用迁移的 JSP 测试业务流程。除了解压缩项目交换 zip 文件以外，所有步骤都是在 Windows® 平台上的 Integration Developer v6.0.0 中执行的。

将项目交换文件解压缩到一个临时文件夹。然后从 Windows 开始菜单启动 Integration Developer。选择 Start -> Programs -> IBM WebSphere -> Integration Developer V6.0 ->WebSphere Integration Developer V6.0。

使用迁移向导

有两种方式访问迁移向导。当您第一次打开 WebSphere Integration Developer 时，欢迎屏幕将显示几个图标。单击绿色箭头图标以启动迁移向导，如图 1 所示。

提示：在使用迁移向导时，关闭 Integration Developer 中的项目自动构建选项。请转到 Main Menu -> Project，然后取消选择 Build Automatically。如果您关闭该 AutoBuild 选项，请记住定期构建整个项目或者重新启用 AutoBuild 选项。

下一屏幕向您呈现了 3 个源迁移选项。单击具有 5.1 和一个箭头的图标，如图 2 所示。

另一种方式是通过 File Import 选项浏览 Integration Developer。要启动迁移向导，请使用主菜单：

1. 转到 File -> Import。
2. 从导入窗口中选择 WebSphere Studio Application Developer Integration Edition Service Project，如图 3 所示，然后单击 Next。这将启动迁移向导。
   
   图 3. 导入窗口
   
   
3. 单击 Browse 按钮，并转到您解压缩项目交换 zip 文件的临时文件夹。
4. 突出显示要导入的项目文件夹，并单击 OK。在本例中，导入图 4 中所示的 EmailService 项目。

   提示：该向导能够快速地填写它找到的模块名。如果它没有填写，请输入项目的模块名。我们建议您使用相同的原有项目名称。

   
   图 4. 指定源构件
   
   
5. 单击 Next 进入设置迁移选项的屏幕。
6. 请确保选择选项以在注释中保留原有的 BPEL Java 代码段。通过将它们包含在注释块中，保留所有现有的 Java 代码段。单击 Finish。
7. 迁移向导将创建一个新的“业务集成模块”项目，导入所有现有的 Application Developer 构件，并转换源构件。您会看到具有一些消息的 Migration Results 屏幕。

   在本例中，您将看到 5 条信息消息。其中有 4 条信息表示：“The following java package is not being migrated because it contains generated classes that are no longer valid”。这些消息是安全无害的。Application Developer 已经自动生成 java 包以将应用程序绑定到 Server Foundation 运行时。新工具将生成新的绑定。单击 OK。

   请注意：如果出现错误，您可以突出显示某一消息行，然后单击 Generate ToDo’s 按钮以在代码中生成 TODO，这样您可以稍后修复这些错误。

   如果您关闭了 AutoBuild 选项，可以再次打开（Integration Developer Main Menu -> Project -> Build Automatically）。

使用迁移的资源

现在您将使用迁移的资源。

1. 请转到 Integration Developer 中的 Business Integration 透视图。在导航窗格中，通过双击名为 EmailService 的 Assembly Diagram 图标，，打开最新创建的 EmailService 项目。该项目将在 Assembly Editor 中打开。
2. 您将在画布中看到一个名为 EmailBusinessProcess 的项。这是服务组件体系结构（Service Component Architecture，SCA）组件，它的实现是在业务流程执行语言（Business Process Execution Language，BPEL）中实现的电子邮件业务流程 (Email Business Process)。
   
   图 5. 显示一个业务流程组件的 Assembly Editor
   
   
3. Assembly Editor 左侧是工具面板。您需要第二个工具箱中的 Stand-alone References 工具，该工具箱由一个框式蓝色箭头图标表示。单击业务流程组件的左侧，然后单击工具并将其放在画布中。如果需要空间，可以将业务流程组件拖到右侧。
4. 在 Assembly Editor 工具面板中，单击绿色细线图标，，然后单击 Stand-alone References 组件，最后单击 Business Process Component (EmailBusinessProcess)。
5. 弹出的消息将通知您“a matching reference will be created on the source node. Do you want to continue?”。不要选择“Always create without prompt”框。单击 OK。
6. Select Interface 窗口弹出，如图 4 所示。您将看到可以创建引用的两个接口，即 ProcessPortType 和 MailSMTP。请选择 MailSMTP 并单击 OK。
   
   图 6. 接口选择屏幕
   
   
7. 将提示您是否希望为 Stand-alone Reference 生成 Java 接口，而不是 Web 服务描述语言（Web Services Description Language，WSDL）接口。由于您要使用 JSP 和 Java 客户机访问流程，因此选择 Yes。
8. 单击 Ctrl-S 保存与图 7 相似的组装关系图 (Assembly Diagram)。观察每一个组件的细节以及 Properties 窗格的 Details 选项卡中的连接。
9. 请选择 Stand-alone References Component。在 Properties 视图中，记住 Details 窗格中的 Partner Reference 的名称。在本例中，名称为 MailSMTPPartner。在 Details 窗格中，您可以找到客户机使用的自动生成的 Java 接口的名称。如图 7 中所示，接口为 com.scb.process.email.mail.smtp.MailSMTP。
   
   图 7. 显示属性窗格和两个连接组件的组装关系图
   
   

   请注意：我们为什么向业务流程组件提供独立引用呢？独立引用允许非 SCA 客户机（如类似于 JSP 的 J2SE 或者 J2EE 客户机）访问 SCA 组件。如果您只计划使用 BPC 资源管理器或者组件测试框架 (Component Test Framework) 调用流程，则不需要独立引用，这是因为这些内置工具使用 BPC 和 SCA API 直接调用流程。

10. 回到 Assembly Editor，选择 EmailBusinessProcess 组件的引用连接器（由右侧具有 1:1 的小框表示）。右键单击该引用连接器，并从上下文菜单中选择 Wire References to New -> Components。

    该操作将在 EmailBusinessProcess 组件的右侧创建与接口 MailSMTP 同名的通用 SCA 组件。这会自动将业务流程组件连接到新的通用组件。

11. 单击 Ctrl-S 保存组装关系图。
12. 右键单击 Generic Component MailSMTP，并从上下文菜单中选择 Select Implementation -> Java。该通用组件变成 Java 组件。在 Pick Implementation 屏幕的 Select entries 字段中，开始键入 mailsm，直到看到名为 MailSMTP 的类为止。突出显示这个类并单击 OK。

    提示：Qualifier 字段显示包的名称，该名称与包出现在原有的 Application Developer 服务项目中的名称相同。这就是在开始迁移流程之前您必须了解服务项目的结构的原因。

    由于这个 Java 服务示例的输入/输出参数具有简单的类型（字符串和布尔型），因此 SCA 框架自动等同于 SCA 组件公开的 WSDL 接口和 Java 类的接口。例如，在 EmailService 项目中比较 MailSMTP.wsdl 和 MailSMTP.java。转到 Java 透视图查看 Integration Developer 中的这些文件。

    如果您不确定 Java 接口是否与满足 Java 要求的 SCA WSDL 兼容，请不要选择 Select Implementation，而要选择 Generate Implementation。将要求您具有可以生成类的包。向导在组件公开的 WSDL 接口中生成与 SCA 兼容的 Java 接口。组件 MyComponent 的类名为 MyComponentImpl.java。

    现在，检查每个方法的输入参数的类型及其返回类型，以确保它们都匹配 Java 类的接口。如果它们不匹配，您有两种选择。第一种选择涉及到修改原有 Java 类的接口。或者，可以将生成的骨架作为实现类并编写自定义代码，以在生成的 Java 骨架中调用每个方法的原有 Java 类。当操作的输入或者输出类型很复杂时（例如，Customer 对象具有地址、姓名之类的子对象），通常会出现问题，因为在 SCA 范例中，它们是以 commonj.sdo.DataObject 表示的。而在原有 Java 类中，参数是以 Java bean 表示的。

13. 通用 SCA 组件变成 Java 组件，业务流程组件与其连接。画布与图 8 类似。画布中唯一的显著变化是“J”，表示 MailSMTP 是一个 Java 组件。
    图 8. 显示 3 个连接组件的组装关系图
    
    
14. 这就完成了。单击 Ctrl-S 保存组装关系图并关闭 Assembly Editor。

下一步要迁移 Application Developer 项目交换文件中包含的 Web 项目。

迁移用于调用业务流程的 JSP

在 Application Developer 项目交换文件中，EmailServiceCustomWeb 项目包含 JSP (index.jsp)，它从用户获得 4 个参数并使用 Facade Enterprise Java Bean (EJB) 调用业务流程。该 Facade EJB 是在 Application Developer 中生成的，它包含在 EmailServiceEJB 项目中。

在 Integration Developer 中，没有生成 Facade EJB 的捷径，因为它使用 SCA 编程模型中的新抽象层。因此，您必须迁移 index.jsp 以使用 SCA 编程模型，而这将调用业务流程。

1. 首先，从项目交换 zip 文件导入 EmailServiceCustomWeb 项目。在 Integration Developer 中，转到 File -> Import -> Project Interchange。单击 Next 并浏览到该 zip 文件。选择图 9 中所示的 EmailServiceCustomWeb 并单击 Finish。
   
   图 9. 项目导入屏幕
   
   

   许多在 Application Developer 中有效的环境变量在 Integration Developer 中不再使用，因此我们需要确定 Web 项目的类路径。

2. 转到 Java 透视图，Window -> Open Perspective - > Other -> Java，并选择 EmailServiceCustomWeb 项目。右键单击并选择 Properties。
3. 转到 Java Build Path，在 Projects 选项卡中，删除 EmailServiceEJBClient 上的依赖项。请确保 EmailService 上有一个依赖项，如图 10 所示。
   
   图 10. Java 构建路径上的项目
   
   
4. 在 Libraries 选项卡中，突出显示所有条目并单击 Remove，以从构建路径中删除所有 JAR 和类文件夹。
5. 单击 Add Library，突出显示 JRE System Library，然后单击 Next。在 Alternate JRE 字段中，使用下拉选择器选择 WPS Server v6.0 JRE。请不要 选择 WebSphere v6 JRE。单击 Finish。
6. 单击 Add Library，突出显示 WPS Server Target，然后单击 Next。选择“Configure wps server classpath”并单击 Next。您的属性屏幕将类似于图 11。
   
   图 11. Java 构建路径上的库
   
   
7. 单击 Project References。设置对 EmailService 项目的引用（如图 12 所示）并删除所有其他引用。
   
   图 12. 项目引用设置
   
   
8. 单击 OK 保存新设置。这将清除所有错误（除 index.jsp 中的 JSP 编译错误之外）。Application Developer v5.1 在 J2EE 1.3 级别。您可以将 Web 应用程序迁移到 Integration Developer v6.0 中可用的 J2EE 1.4 级别。

   提示：只有在工作区启用高级 J2EE 功能后才可以使用迁移选项。为此，请转到 Window -> Preferences -> Workbench -> Capabilities -> Advanced J2EE -> Enterprise Java，如图 13 所示。

   
   图 13. 启用工作台的功能
   
   
9. 在导航窗格中，突出显示 EmailServiceCustomWeb 项目。右键单击并从上下文菜单中选择 Migrate -> J2EE Migration Wizard。
10. 在 J2EE Migration Wizard 欢迎屏幕中，忽略警告并单击 Next。对于该场景，缺省设置是可以接受的。图 14 显示了缺省 J2EE 版本为 v1.4，目标服务器是 WebSphere Process Server v6.0。单击 Finish。
    
    图 14. 项目的迁移设置
    
    
11. 查找消息“Migration finished successfully”。单击 OK。由于这只是一个简单的项目，因此 Details 窗格指示许多项不需要迁移。
12. 还有最后一步。您需要将该自定义 Web 项目添加到为 EmailService 业务集成模块生成的企业应用程序中。该操作是在 Integration Developer 的 J2EE 透视图中完成的，包括几个步骤。
13. 转到 J2EE 透视图，Window -> Open Perspective -> J2EE。在导航窗格中，转到 Enterprise Applications -> EmailServiceApp -> Deployment Descriptor。打开 EmailServiceApp 的部署描述符。
14. 在主窗口中，单击 Module 选项卡。在 Modules 下面，单击 Add，如图 15 所示。弹出的 Add Module 窗口将查找 EmailServiceCustomWeb 项目。选择该项目并单击 Finish。
    
    图 15. 项目引用设置
    
    
15. 单击 Ctrl-S 保存应用程序的部署描述符。
16. 在 Integration Developer 中，不能再为业务流程生成 Facade EJB。您必须手动迁移这些代码以使用 SCA 编程模型调用业务流程。这就是您需要修复 index.jsp 文件中的错误的原因。

    在 J2EE 透视图中，编辑 index.jsp。在 Project Explorer 窗格中，转到 Dynamic Web Projects -> EmailServiceCustomWeb -> Web Content ->index.jsp。双击 index.jsp 打开该文件进行编辑。选择 JSP 编辑器的 Source 选项卡。您将看到“if”代码块内的错误，如图 16 所示。

    
    图 16. 编辑 index.jsp 文件
    
    
17. 使用下面的代码替换 if 代码块：
    
    

    com.scb.process.email.mail.smtp.MailSMTP service = (com.scb.process.email.mail.smtp.MailSMTP) com.ibm.websphere.sca.ServiceManager.INSTANCE. locateService("MailSMTPPartner"); boolean success = service.sendEmail( request.getParameter("server"), request.getParameter("from"), request.getParameter("to"), request.getParameter("contents"));

    
    
18. 保存对 index.jsp 和部署描述符的更改。

现在，您可以通过下面列出的三种方法进行测试，其中每一个测试都是相继测试应用程序的组件。

使用 Integration Developer 集成测试客户机测试迁移的组件

现在您可以在 Integration Developer 中测试迁移的应用程序。通过使用嵌入式测试服务器运行应用程序，集成测试客户机允许您单独测试每一个组件。

1. 转到 Business Integration 视图中的导航窗格。右键单击 EmailService 项目。从上下文菜单中选择 Test -> Test Module。对于要测试的组件，选择 MailSMTP。

   请注意：您可以选择调用的组件。在 MailSMTP 的第一个示例中，选择 Java 组件。稍后，确定 Java 组件正确工作后，您可以执行调用业务流程组件的更加全面的测试。

   
   图 17. 调用事件
   
   
2. 在 Events 屏幕中，输入 4 个输入请求参数的值（电子邮件服务器的名称、电子邮件地址以及用作电子邮件内容的文本），并单击 Continue。
3. Deployment Location 窗口弹出。请选择突出显示的 WebSphere Process Server v6.0 并单击 Finish。
4. 集成测试客户机将启动嵌入式 Process Server 测试服务器，安装并启动迁移的应用程序，并且使用您指定的参数调用 MailSMTP Java 服务。如果输入参数是正确的，您将看到返回结果的值为“true”，如图 18 所示。
   
   图 18. 返回结果
   
   
5. 通过检查电子邮件是否已发送到收件人，验证是否成功调用 Java 服务，如图 19 所示。
   
   图 19. 测试电子邮件
   
   

   该测试展示了如何使用 Integration Developer 集成测试客户机调用 Java 组件 (MailSMTP)。

使用 Integration Developer 集成测试客户机测试更多迁移的组件

1. 在 Business Integration 透视图中右键单击 EmailService 项目，回到 Events 屏幕，然后从上下文菜单中选择 Test -> Test Module。
2. 在 Component 字段中，单击下拉箭头并选择名为 EmailBusinessProcess 的组件。它是实现为 BPEL 流程的业务流程组件。它调用刚才测试的 MailSMTP Java 服务。这是一个更加全面的测试，演示了如何在业务集成模块中增量测试组件。
3. 如上一个测试那样，输入 4 个请求参数的值，然后单击 Continue。
   
   图 20. 选择组件
   
   
4. 这也将获得一个成功的测试。收件人获得了测试电子邮件，并且 Events 屏幕显示图 21 中所示的结果。
   
   图 21. 成功的结果
   
   

使用迁移的 JSP 测试迁移的应用程序

现在您可以使用迁移的 JSP 测试迁移的应用程序。这是一个全面的测试，因为它表示一个端到端场景。

1. 转到 J2EE 透视图中的导航窗格。展开 Enterprise Applications 并右键单击 EmailServiceApp 项目。从上下文菜单中选择 Run -> Run on Server。
2. 在 Server Selection 屏幕中，选择 WebSphere Process Server v6.0（如图 22 所示）并单击 Finish。
   
   图 22. 定义新测试服务器
   
   
3. Process Server 测试服务器启动后，应用程序发布到该测试服务器。在 Integration Developer 的主窗口中，Web 浏览器窗口打开。缺省情况下，它指向 http://localhost:9080/EmailServiceCustomWeb/，如图 23 所示。
   
   图 23. WebSphere Integration Developer 内的 Web 浏览器
   
   
4. 在 Web 浏览器屏幕中，输入 4 个输入请求参数的值，然后单击 Enter。请记住输入电子邮件服务器的名称和您自己的电子邮件地址。（作者不希望得到所有这些测试电子邮件！）
5. 如果一切进展顺利，您将看到在 Web 页面下部输出的消息“Result is: true”。验证 JSP 是否成功调用了业务流程。JSP 调用您创建的独立引用，独立引用反过来调用迁移的业务流程和 Java 服务。当收件人接收到电子邮件时测试完成，如图 24 所示。
   
   图 24. 测试电子邮件
   
   
   

   请注意：如果您关闭了 AutoBuild 选项，可以再次启用（Integration Developer Main Menu -> Project -> Build Automatically）。

您已经通过三种不同方式成功测试了迁移的应用程序，这就在环境中为您准备了一个完整的端到端场景。

结束语

本文介绍了如何迁移发送电子邮件的简单业务流程，如何在 WebSphere Process Server 运行时运行该业务流程，以及如何测试迁移的流程。从 WebSphere Studio Application Developer Integration Edition v5.1.x 迁移一个简单的服务项目以使其在 WebSphere Integration Developer v6.0 中工作是相当简单的，当服务项目具有一个项目文件（如 EmailService 示例和一些简单的 Java 代码）时尤为如此。我们了解这不是一个典型的 BPEL 业务流程示例，但是使用它在 Integration Developer 中引入了迁移向导并体验了源构件迁移。我们希望实际的迁移项目使用迁移向导，但是它也会涉及到大量的手动迁移工作。

在2004年10月， IBM 发布了 IBM® Software Development Platform, 包括新一代的建模和模型驱动开发 (MDD) 工具。IBM Rational® Software Architect是该次发布的设计和构建的中心，是一个为了建立构架良好的应用和服务，与 Unified Modeling Language (UML)一起支持MDD的广泛的、集成的设计和开发产品。

Rational Software Architect 支持使用现代软件工业技术的应用和Web 开发（静态的和动态的），包括：

• Java 2, Enterprise Edition™ (J2EE) 和 Web services 技术
• 对象管理组织 (OMG)的模型驱动体系架构 (MDA) 和面向服务的体系架构 (SOA)
• JavaServer™ Faces (JSF)支持快速应用开发的能力
• 支持基于资产开发的可重用资产规范 (RAS)

Rational Software Architect包括IBM Rational Application Developer for WebSphere Software (IBM WebSphere® Studio Application Developer产品的最新版本) 的所有能力，并且将他们增加到MDD技术中。结果：打包在单个产品中的一个集成的设计和开发解决方案。

本文的目的是从发展演化的角度来讨论Rational Software Architect，这是一个支持显著区别于那些由先前MDD产品支持的工作流和使用情景的下一代MDD产品。请注意这并不是Rational Software Architect的使用指南；IBM Rational计划不久将出版一部指南。

IBM Rational 建模工具的演化

为了理解Rational Software Architect 建模产品演化的规模，让我们简单回顾IBM Rational产品在这个方面的历史。

Rational Rose

IBM Rational Rose® 软件已经并且继续成为一个市场主导的可视化建模工具。它是一个独立的工具，在应用程序接口(API)层与市场主导的IDE结合，来支持各种编程语言和其它实现技术。然而，尽管Rational Rose已取得一定的成功，也推进了UML建模实践，但是仍然只有一小部分开发人员按照规定使用建模，Rational也已经尝试培训更多的人员。但是大多开发人员不想放弃他们的IDE而去使用额外的工具；他们想将可视化建模集成在IDE里面。

Rational XDE

为了满足这个需要，在2002年，IBM Rational推出了Rational XDE?软件，为当时出现的编程技术（Java 和 Microsoft .NET）提供了一个扩展的开发环境。我们把Rational XDE看成Rational Rose的下一代；严格地说，它并不是新版本的Rose（因而名字发生了变化），而且也未必取代Rose，因为我们有目的地限制Rational XDE只支持一定的IDE和实现技术。

通过将Rational XDE构造成流行IDE的插件，我们鼓励大量开发人员采用建模和模型驱动开发。Rational XDE通过支持功能强大的引擎，允许基于模式的开发，也推进了MDD的发展；另外，也使得软件设计层复用达到一个新的高度。之后加入了具体的定制化的能力，为IBM Rational对 MDA提供了早期的支持（(请参见下面的"对于模型驱动的体系结构的支持")。

2003年10月，合并到IBM之后，我们将Rational Rose 和 Rational XDE产品线加固到一个家族 -- IBM Rational Rose XDE Developer -- 这样，无论用户倾向于使用独立的建模工具还是一个直接集成在他们IDE的工具，他们都可以购买工具包，并根据自己的需要进行安装。

与Eclipse前所未有的结合的机会

即使在IBM并购Rational软件之前，这两个组织也是合作伙伴，致力于开发新的、更强大的方法来将MDD的能力集成进Eclipse框架和基于Eclipse的IDE 。这项工作早期的成果是在2003年添加到WebSphere Studio Application Developer中的轻量级作用的代码可视化和可视化编辑特性，这些特性是开发Java实施层模型的非常有效的方法。

该技术现在是IBM开发MDD工具的基础。不再是简单地与Eclipse集成，我们正在Eclipse之上构建新的MDD能力。这为Java 和 C/C++开发提供了前所未有的支持，也为集成其它生命周期工具提供了全新的能力。我们在2004年10月发布了新的工具，基于Eclipse的IBM Software Development Platform的远景逐渐变成现实。我们现在提供了软件开发的完整的集成平台，充分满足开发团队中每个角色的需要。软件开发可以真正成为一个核心业务流程，为我们的客户提供竞争的优势，新的收益和市场机会。

使用Eclipse我们现在能够为建模产品实现更深入和广泛的集成。我们能够影响基于角色的用户接口和工具扩展性；能够更好地将建模与生命周期的其它方面集成，比如需求管理。Rational Software Architect将先前定义的建模、开发和代码分析的实践转换成集成的、统一的设计和开发经验。在一个开放，而不是专有的环境中工作，所有的用户都可以更容易地根据需要定制他们的产品。

Rational Software Architect：集成的设计和开发

我们这个新的、基于Eclipse的Rational Software Architect是一个完整的设计和开发工具解决方案。如同我们前面所提及，它包括Rational Application Developer for WebSphere Software (WebSphere Studio Application Developer的新版本) 的所有能力，拥有代码可视化和可视化编辑特性；它是客户开始使用MDD的一个很好的入口。另外，它还包括Rational Web Developer for WebSphere Software (以前的 WebSphere Studio Site Developer) 全部的、更新的能力。

Rational Software Architec在Rational Application Developer的特性上构建，增加了对MDD的全力支持，包括UML 2建模、代码生成、模式、模型转换，以及实现 MDA开发风格的新途径。它并不是一个全新的产品，是特别为想要应用MDD的客户而设计的，展示了自然的演化和在IBM Rational工具中已拥有的能力。它特别为试图广泛应用MDD的用户而打包。

结构检查和控制

我们已经从客户处了解到，无论你将应用系统设计和构建得多么好，也总会在实现阶段经历代码层的演化，出现未检查的现象，最终导致架构性能的降低，严重影响软件的质量。

针对这个现象，软件架构师在实现之前检查已有的代码，以评估其真实的体系结构和质量。做这项工作的过程中，他们往往发现各种各样的问题：从设计到代码的不正确映射；代码级的改变引起设计和架构的依赖；编码标准、规则和样式方面不规范等。最终，应用系统的架构是由部署的代码来呈现的，所以软件架构师必须分析代码，以估计它的可维护性，并且在规则的辅助下，掌握架构的演化。

为了给这样的分析提供更自动的支持，Rational Software Architect引入了"Java 应用结构的检查和控制"特性。它支持基于模板的规则，并且使用高级别的软件可视化技术，允许用户看到J2EE 和 J2SE实现的架构。用户可以更容易地发现架构的不足之处，或者"反模式"，比如循环依赖、集线器之类的一些已逐渐加入到应用程序源代码中的问题。

通过代码可视化和开发人员级别的测试，进行自动结构的检查和控制之后，软件架构师能够显著地提高他们所设计和部署的应用系统的质量。我们在Rational Software Architect中引入的先进特性将开始改变架构师和开发人员考虑开发过程的方法。

运行时支持和语言支持

客户已经告诉我们，在应用的运行时支持环境中设计和开发工具所扮演的重要角色。Rational Software Architect在WebSphere应用服务器上为Java应用提供了极大的运行时支持；它也允许由开放工业标准支持的Java虚拟机和数据相互操作性的多平台执行支持。此外，因为Rational Software Architect 包括支持BEA WebLogic Server的Rational Application Developer，所以，使用Rational Software Architect部署的应用也是隐式的多平台。Eclipse C/C++ Development Tool (CDT)作为IBM Rational Software Architect的一部分而打包在内，同时也扩展了对C和C++开发的支持。基于Eclipse的解决方案允许我们在Rational Software Architect中复用一些特性，来支持上述语言和JAVA中的MDD。

培养现代建模生态系统

我们最近了所发布了一系列Rational Software Architect，为不需要代码生成或者可视化的用户着重建模和设计这两方面。Rational Software Modeler支持UML 2的所有建模特性，并且通过Eclipse Modeling Framework (EMF)提供高级扩展的特性。Eclipse框架的开放性和健壮的扩展性使Rational Software Modeler适合支持曾为Rational Rose的成功作出一些贡献的、支持与生态系统类似的客户和第三方扩展的建模"生态系统"。

Rational Software Architect 和 Rational Software Modeler只是IBM Software Development Platform之后阐明策略的两个实例：帮助业务自动化并集成软件开发。我们希望各角色的实践者都能够拥有他们所创建和获得的单一的用户体验，通用的定义和资产的管理。团队的每个人都能够简单地选择与他们角色和责任相匹配的产品。IBM Software Development Platform是关于团队和组织生产率的。

对模型驱动架构的支持

MDD为使用模型开发软件展示了许多风格，其中，模型驱动体系架构（MDA）是由对象管理组织 (OMG).1创建的。MDA基于一些OMG标准之上，包括Unified Modeling Language (UML 2)，以及涌现出来的关于如何最好地将建模应用到软件开发过程的哲理。MDA在抽象层定义了模型，然后定义映射和管理模型与各种实现技术之间关系的转换。以下是一些有用的MDA建模层的定义：

• 计算无关模型 (Computation-Independent Model , CIM) - 不考虑结构或者处理的情况下，处理系统环境和需求。
• 平台无关模型 (Platform-Independent Model , PIM) - 不考虑与特定平台相关的细节，处理系统的操作。
• 平台相关模型 (Platform-Specific Model, PSM) - 将PIM和与特定平台相关的细节结合起来。
• 平台模型 (Platform Model, PM) - 对于使用 PIM 定义组成特定平台的技术概念、元素和服务。
• 转化模型（Transformation Model, TM）- 定义并指定从特定PIM转换到PSM所需的转换。

尽管MDA并不是一个标准，它明确提倡使用一些已有的OMG标准。MDA指定了：

• Meta-Object Facility (MOF)用于定义元模型。
• UML 2用于指定应用开发模型和转化。
• MOF Query / View / Transform (QVT)用于指定转化（一旦它被规范化）。

一些客户称他们已经在应用MDA很长时间，并且IBM Rational员工与他们中的许多一起工作 - 以及OMG - 将MDA演化成当前状态。Rational Software Architect支持MDA的理论，也支持MDA建立的基本标准。

但是，我们不能将Rational Software Architect归为一个MDA工具，因为在某种程度上，MDA并不是一个标准，而且仍有一些争论。更重要的是，Rational Software Architect实际上支持一系列以代码为中心的、基于向导的设计和开发范例。换而言之，它支持MDA及其它的开发风格。

Rational Software Architect是否适合于你？

Rational Software Architect是IBM用于建模和模型驱动开发的最完整、最健壮的解决方案。但是它是否适合你？以下选择将帮助你回答这个问题。

你是否从事软件架构的工作？

我们近期发布的产品区分软件架构师与软件开发人员，以及软件架构师与数据架构师这几个角色。例如，这个更大的粒度反映在高度面向角色的IBM Software Development Platform的所有工具中。构建进我们产品名称中的角色定义和区别可以帮助用户基于他们的活动和责任，决定哪些工具最好地适合于不同的员工。但是，角色名字在企业、组织甚至项目线中变化，所以你应该把我们新产品的名称当作决定什么工具对开发团队的哪些人员最有用的起点。

软件架构师是开发团队中负责作出主要技术决定的人员。有时，是由一个人来负责，而这个人常常是项目的开发的领导人；有时，几个人，可能有一个来充当主要架构师，共同来承担这个角色；还有的时候，团队的所有开发人员在架构能力的同一时间操作-一个增长的趋势。经常地，较之他们的工作职位，架构师的概念往往与开发者关联更多些。

软件架构师的职责包括识别并记录应用架构的方面，包括需求、设计、实现和部署。这些方面需要不同的，但相关的应用视图。当然，在开始的架构设计和实际构建架构（真正在代码中运行的架构）之间也有区别。我们认为软件架构师需要一个帮助他们定义所需架构的工具，允许他们发现应用系统的真实架构，并且帮助他们协调两种视图。

Rational Software Architect能够完成这些所有的工作。它包括开发和查看实现中的帮助，以及维护和控制实现来保持架构集成。

如同我们上面所提到的，做架构工作的人员往往并不是架构师。可以从使用Rational Software Architect过程中获益的团队人员有：

• 需要开发代码的软件架构师。
• 需要理解并参与代码和模型工作的开发人员。
• 想要充分应用MDD能力的人员
• 那些负责检查和确认已有的架构或者想要看到架构演化的实施过程的人员
• 想在Eclipse 之上应用MDD的C++开发人员。

请记着，Rational Software Architect包括Rational Application Developer的全部能力，一个完全的IDE。客户得到打包进一个产品的完整的设计和构建解决方案。针对那些要求UML 2建模能力而不需开发架构的用户，我们提供了Rational Software Modeler。

你是否使用IBM Rational的其它建模产品？

如果你已在使用IBM Rational软件，建议你有必要时，考虑移植到Rational Software Architect 或者 Rational Software Modeler。这些新产品的优点包括：

• Eclipse 集成
• 通过EMF的高级建模和工具扩展性。
• 更容易使用。
• UML 2, 最新的建模技术。
• Rational Software Architect中的新的结构检查和控制特性。
• Eclipse之上，使用C++的MDD。
• 建立复杂转化的能力。
• 以静态次序图表方法可视化代码的能力。
• 代码检查的能力。
• 在Rational Software Architect中使用Java IDE和MDD工具。

如果你的团队当前在使用Rational Rose 或者 Rational XDE，那么对你而言，移植到Rational Application Developer也是有道理的。WebSphere Studio Application Developer的代码可视化和可视化编辑特性已升级到UML 2并且在Rational Application Developer中继续存在。尽管它不支持通用建模或者完全的MDD，却支持UML入门级的使用。如果你正使用Rational Rose 或者 Rational XDE，主要为了从代码中截取图形文档，那么这个级别的UML支持就有可能满足了你的需要。

对于Java和Web开发，我们鼓励用户从当前建模工具过渡到Rational Software Architect。除了移植到基于Eclipse的工具的技术优势，IBM还提供了一系列移植和升级的途径。请参照http://www-306.ibm.com/software/awdtools/architect/swarchitect/support/index.html 以了解最新升级的支持信息。

本文讨论企业整合(集成)的新发展：以服务为中心的集成（Service-Oriented Integration，简称 SOI）。 您将了解到什么是 SOI，推动 SOI 发展的因素以及SOI 带来的价值。作者讨论了 SOI 解决方案所涉及的要素，和这些要素相关的技术、标准以及IBM的产品支持，最后作为总结将它们包括在 IBM 的集成参考架构中，指出如何实现各种集成需求。本文还讨论了在企业集成实践中需要重点注意的事情，如战略规划和IT管理。本文的姊妹篇"以服务为中心的企业整合－案例分析"，用一个实际案例来说明基于 IBM 产品的实际 SOI 应用，帮助读者感性地理解 SOI。

1. 企业集成的新方向： SOI

什么是"以服务为中心的集成"？

"以服务为中心的集成"是英文词语"Service-Oriented Integration"的中文翻译，简称 SOI。 它可以定义为：在"以服务为中心的体系架构"（Service-Oriented Architecture，SOA）中，通过服务的交互来集成各企业的 IT 资源，如分布的应用或者数据，帮助企业 IT 部门将已有但老旧而不灵活的系统集成起来，释放其中功能或数据为可重用的服务与业务流程。

为什么需要"以服务为中心的集成"？

企业集成的推动因素。推动"企业应用集成"（Enterprise Application Integration, EAI ）的因素，来自商务和技术两个方面。从商务的角度，今天企业要在全球化的经济环境中求生存和发展，就必须努力适应越来越强的竞争和越来越快的变化，这意味着一个企业的业务模型要变得灵活以快速应变，也就是随需应变。在一个企业的业务模型变得灵活的转型过程中，需要将业务流程不断地自动化，然后跨部门横向集成它们，并且管理和优化它们，这意味着支撑这些流程的技术基础，即 IT 应用和数据资源等，需要在企业范围内集成。所以，业务灵活应变的能力是 SOI 的驱动因素之一。

在技术方面，IT 部门面临着业务部门越来越高的期望值，就是用更少的钱做更多的事情，但要做得更快、更好，这迫使 IT 部门考虑如何最大程度地重用已有应用的功能和数据资源，来支持新应用的开发。但这种重用面临着如何将高度异构、分布的各个应用集成起来的难题，SOI是目前最有效的解决之道。在 SOI 中，首先各个应用的功能被封装为基于标准来描述和供访问的服务；其次，借助于 SOI 的通用连接能力，这些来自不同应用的服务，不需要关心对方的位置和实现技术，以松散耦合的方式相互交互来完成集成，所以只要服务的接口描述不变，服务的使用者和提供者双方可以自由发生变化而互不影响；最后，通过服务组合，服务可以按不同的方式来组合成为不同的业务流程。当某个业务流程发生变化的时候，大多数时候，我们调整组装服务的方式来满足这种变化。总之，这种通过重用粗粒度服务而不是在底层编程来开发新应用以满足业务新需求的方法，使得 IT 组织能够以更少的投入、更快的速度、更好的质量来开发应用。综上所述，可以灵活应变的重用方式，是 SOI 的另一个驱动因素。

集成解决方案的发展沿革。集成企业应用的方法各种各样，初级一点的借助于简单的机制如应用编程接口，管道、共享目录和文件，或者某些传输协议如 FTP 来交换数据和互操作；高级一点的则使用各种消息中间件来提供消息的传输、转换、合并、路由和分发、事件的发布和订阅等；分布式计算技术，如 CORBA，COM 等，也有较广的使用。

在初期实践中，应用之间的连接拓扑大多数情况下是点对点的，硬编码的，所使用的协议是非标准的，功能的提供者和使用者之间是紧耦合的，功能的粒度通常较细，数据的表示也不统一。随着集成复杂度的增长，和实践经验的总结，开始出现一些从好的实践中总结出来的集成模式，如消息中枢（Message Backbone）、信息总线、应用集成中心（Application Integration Hub），这些模式从不同的角度以不同的方式来管理集成的复杂性，但都或多或少地尝试提供一个集成基础设施来简化应用之间日趋复杂的连接拓扑，提供异构数据和功能访问方式之间的转换，甚至提供一致的数据和功能表示与访问方式。通过元数据和应用相关的领域知识，这些集成基础实施提供了很多中介和转换的机制与模式来实现高级的功能，如路由、动态选择等能力。

随着互联网络技术的发展、普及和应用，相关技术和标准，如 XML 和 Web Service，被广为接受，这给应用集成带来了新的发展。企业应用架构的风格开始朝着以服务为中心的方向发展，而企业应用集成也转向以服务为中心的集成，服务的描述和访问基于开放一致的标准（如 WSDL），连接应用的基础设施继承了过去发展的成果，并通过支持开放标准，来提供通用的连接服务，包括基本的服务如消息传输、转换，事件的发布和订阅，服务的中介（选择、路由），和高级的服务如安全、事务、服务质量，以及可管理性，来使得服务在一个标准、开放、可靠、安全、可管理、满足服务质量要求的环境下，以松散耦合的方式相互交户，根据需求动态地进行企业应用集成，达成非常高程度的灵活应变能力和重用能力。SOI 是对现有集成技术与实践的总结和标准化。

SOI 的好处。SOI 继承和发展了传统的 EAI，比较而言，SOI 的好处在于:

• 定义良好而又基于标准的接口 - 服务的描述易于理解，而且标准一致
• 实现技术和位置的透明 - 提供服务功能的应用，它的位置以及所使用的实现技术被接口所屏蔽，事实上，不需要一个固定的服务提供者
• 灵活性 - 只要服务的接口不变，服务的提供者和服务的使用者都可以变化而不影响彼此，从而将变化带来的影响减少到了最少
• 重用能力
• 渐进式集成 - 在 SOI 中，通过将若干已有系统的相关功能转化为服务来进行集成。随着这些项目的进行，可重用的服务越来越多，最终，新的集成需求将绝大多数可以通过已有的服务来完成。所以，我们可以从当前重要的集成需求开始来封装已有系统的功能和开发必要的新服务，以渐进的方式逐步地扩展到整个企业范围内的集成。更重要的是，由于服务的灵活性，即使已有系统迁移到新的技术平台，甚至是被替代，都不会影响到依赖于这个应用所提供功能的那些应用，从而保证了集成对变化的适应能力，使得业务灵活性有一个坚实的基础。这也意味着从传统规模大、投入大、周期长、见效慢、风险高、专有技术，转向小步快跑、见效迅速、风险低、基于标准的集成方式。这对于如今面对业务需求快速变化的 IT 机构来说，SOI 在投入和工程方面的好处，是非常吸引人的

2. SOI解决方案

2.1. SOI解决方案的要素

通常，完整的SOI 解决方案包括如下要素：

• 代表应用的功能和数据资源的服务；
• 提供连接服务的基础设施即企业服务总线（Enterprise Service Bus, ESB），连接已有应用的连接器（Connector）和适配器（Adapter）；
• 元数据及其管理如服务描述和服务注册管理（Service Registry）等；
• 将服务组合成业务流程的引擎如 BPEL4WS 引擎；
• 业务流程管理和业务绩效管理的部分；
• 一个基于标准的编程模型以及支持它的建模、开发和组装、测试、部署和管理的端到端工具环境；

IBM的 Websphere 业务集成参考架构(见图1，以下称参考架构)是典型的以服务为中心的企业集成架构，本文接下来的讨论都将以此参考架构为背景进行。

以服务为中心的企业集成采用"关注点分离"(Separation of Concern)的方法规划企业集成中的各种架构元素，同时从服务视角规划每种架构元素提供的服务，以及服务如何被组合在一起完成某种类型的集成。这里架构元素提供的服务既包括狭义的服务（WSDL描述），也包括广义的服务（某种能力）。从服务为中心的视角看来，企业集成的架构按图1所示的方式划分为六大类：

• 业务逻辑服务(Business Logic Service)：包括用于实现业务逻辑的服务，和执行业务逻辑的能力。这其中包括业务应用服务(Business Application Service)、业务伙伴服务(Partner Service)以及应用和信息资产(Application and Information asset)。
• 控制服务(Control Service)：包括实现人(people),流程(process)和信息(information)集成的服务，以及执行这些集成逻辑的能力。
• 连接服务(Connectivity Service)：连接服务通过提供企业服务总线提供分布在各种架构元素中服务间的连接性。
• 业务创新和优化服务(Business Innovation and Optimization Service)：用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能和变化，采取措施适应变化的市场。
• 开发服务(Development Service)：贯彻整个软件开发生命周期的开发平台，从需求分析，到建模、设计、开发、测试，维护全面的工具支持。
• IT服务管理(IT Service Management)：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。

2.2. 连接服务 - 企业服务总线

企业服务总线(Enterprise Service Bus)，以下简称ESB, 是过去消息中间件的发展，ESB 采用了"总线"这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态地互联互通。

ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式，异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等。

ESB 所提供的基于标准的连接服务，将应用中实现的功能或者数据资源转化为服务请求者能以标准的方式来访问的服务；当请求者来请求一个服务时，ESB 中这种中介转化过程可能简单到什么也没有，也可能要很复杂的中介服务支持，包括动态地查找、选择一个服务，消息的传递、路由和转换、协议的转换。这种中介过程，是 ESB 借助于服务注册管理以及问题域相关的知识（如业务方面的一些规则等）自动进行的，不需要服务请求者和提供者介入，从而实现了解耦服务请求者和提供者的技术基础，使得服务请求者不需要关心服务提供者的位置和具体实现技术，双方在保持接口不变的情况下，各自可以独立地演变。

所以，ESB 采用总线结构模式简化了应用之间的集成拓扑，通过源自实践的模式，提供了基于标准的通用连接服务，使得服务请求者和服务提供者之间可以以松散耦合、动态的方式交互，从而在不同层次上使得SOI 解决方案是一个松散耦合、灵活的架构。

需要注意的是，ESB 是一种架构模式，不能简单地等同于特定的技术或者产品，但实现 ESB 确实需要各种产品在运行时和工具方面的支持。IBM 有很好的产品支持，运行时支持包括 WebSphere ESB 和 WebSphere Message Broker；而工具方面 IBM 则有 WebSphere Integration Developer，支持用户以图形界面的方式来完成相关的开发任务，如发布服务，使用各种模式，转换消息，定义路由等等。

2.3. 业务逻辑服务

整合已有应用 - 应用和信息访问服务。已有应用和信息是实现业务逻辑和业务数据的重要资产。通过集成已有的应用和信息将可以在已有企业系统上实现更多增值服务，所以集成已有应用和信息是企业集成中重要的一环。

以服务为中心的企业集成通过应用和信息访问服务(Application and Information Access Service)来实现对已有应用和信息集成。它通过各种适配器技术将已有系统中的业务逻辑和业务数据包装成企业服务总线支持的协议和数据格式。通过企业服务总线，这些被包装起来的业务逻辑和数据就可以方便的参与上层的业务流程，从而已有应用系统的能力可以得以继续发挥。这里的已有应用包括遗留应用、预包装的应用和各种企业数据存储。在参考架构中，主要有两类访问服务：

• 可接入服务(On-Ramp Service): 通过各种消息通信模式(单向、请求/应答和轮询)将业务逻辑和业务数据包装成企业服务总线可以访问的功能。
• 事件发现服务(Event Detect Service) : 提供事件通知服务将已有应用和数据中的变化通过事件框架发布到企业服务总线上。

整合新开发的应用 - 业务应用服务。和已有应用和数据类似，新开发的应用也作为重要的业务逻辑成为企业集成的目标。以服务为中心的企业集成通过业务应用服务(Business Application Service)实现新应用集成。一方面业务应用服务帮助程序员开发可重用、可维护和灵活的业务逻辑组件，另一方面，它也提供运行时的集成提供对业务逻辑组件的自治管理。在参考架构中，有三类业务应用服务：

• 组件服务(Component Service)：为可重用的组件提供应用的运行时容器管理服务，如对象持久化、组件安全管理和事务管理等。
• 核心服务(Core Service)：提供运行时的服务，包括内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理等。
• 接口服务(Interface Service)：提供和其他企业系统集成的接口，如其他企业应用，数据库、消息系统和管理框架。

整合客户和业务伙伴（B2C/B2B）－伙伴服务。以服务为中心的企业集成通过伙伴服务提供与企业外部的B2B的集成能力。因为业务伙伴系统的异构性，伙伴服务需要支持多种传输协议和数据格式。在参考架构中，提供如下服务：

• 社区服务(Community Service): 用于管理和企业贸易的业务伙伴，支持以交易中心(Trade Hub)为主的集中式管理和以伙伴为中心的自我管理。
• 文档服务(Document Service)：用于支持和业务伙伴交换的文档格式，以及交互的流程和状态管理，支持主流的RosettaNet、EDI和AS1/AS2等。
• 协议服务(Protocol Service)：为文档的交互提供传输层的支持，包括认证和路由等。

2.4. 控制服务

数据整合－信息服务。企业数据的分布性和异构性是应用系统方便访问企业数据和在企业数据之上提供增值服务的主要障碍。数据集成和聚合技术在这种背景下诞生，用于提供对分布式数据和异构数据的透明访问。

以服务为中心的企业集成通过信息服务提供集成数据的能力，目前主要包括如下集中信息服务：

• 联邦服务(Federation Service): 联邦服务提供将各种类型的数据聚合的能力，它既支持关系型数据，也支持象XML数据、文本数据和内容数据等非关系型数据。同时，所有的数据仍然在自己本身的方式管理。
• 复制服务(Replication Service)：复制服务提供远程数据的本地访问能力，它通过自动的实时复制和数据转换，在本地维护一个数据源的副本。本地数据和数据源在技术实现上可以是独立的。
• 转换服务(Transformation Service)：转换服务用于数据源格式到目标格式的转换，可以是批量的，或者是基于记录的。
• 搜索服务(Search Service)：提供对企业数据的查询和检索服务，既支持数据库等结构化数据，也支持象PDF等非结构化数据。

流程整合- 流程服务。企业部门内部的IT系统通过将业务活动自动化来提高业务活动的效率。但是这些部门的业务活动并不是独立的，而是和其他部门的活动彼此关联的。勿容置疑，将彼此关联的业务活动组成自动化流程可以进一步提高业务活动的效率。业务流程集成正是在这一背景下诞生的。

以服务为中心的企业集成通过流程服务来完成业务流程集成。在业务流程集成中，粒度的业务逻辑被组合成业务流程。流程服务提供自动执行这些业务流程的能力。在参考架构中，流程服务包括如下内容：

• 编排服务(Choreography Service): 编排服务通过预定义的流程逻辑控制流程中业务活动的执行，并帮助业务流程从错误中恢复。
• 事务服务(Transaction Service)：事务服务用于保证流程执行中的事务特性(ACID)。对于短流程，通常采用传统的两阶段提交技术，对于长流程，一般采用补偿的方法。
• 人工服务(Staff Service)：人工服务用于将人工的活动集成到流程中，一方面它通过关联的交互服务使得人工可以参与到流程执行中，另一方面它需要管理由于人工参与带来的管理任务如：任务分派，授权和监管等。

用户访问整合 - 交互服务。将适当的信息，在适当的时间，传递给适当的人是一直是信息技术追求的目标。用户访问集成是实现这一目标的重要一环，它负责将信息系统中的信息传递给客户，不管它在那里，它以什么样的设备接入。

以服务为中心的企业集成通过交互服务来实现用户访问集成。参考架构中的交互服务包括如下类型：

• 交付服务(Delivery Service): 交付服务提供运行时的交互框架，它通过各种技术支持同样的交互逻辑可以在多种方式(图形界面、语音和普及计算消息)和设备(桌面、PDA、无线终端等)上运行，比如通过页面聚合和标签翻译使得同一个Portlet可以在桌面浏览器和PDA浏览器上展现。
• 体验服务(Experience Service): 通过用户为中心的服务增强用户体验, 其中的技术包括：个性化、协作、单点登录等。
• 资源服务(Resource Service): 提供运行时交互组件的管理，如安全配置、界面皮肤等。

2.5. 开发支持

企业集成涉及面很广，不仅需要开发新的应用并使其成为可以被用于企业集成的功能组件，而且需要将被包装的已有的应用和数据用于集成；不仅有企业内部的集成，而且需要和企业外部的系统集成；不仅有交互集成和数据集成，还有功能和应用集成。考虑到这其中的每部分在技术上都会涉及到各种平台和中间件，企业集成的技术复杂性是普通应用开发不可比拟的。这种技术复杂性需要更强有力的开发工具支持。企业集成的开发工具需要有标准的工具框架，这些工具能够以即插即用方式支持来自多家厂商的开发工具。同时，企业集成的开发工具需要支持整个软件开发周期，以提高开发过程中各种角色的生产力。

在以服务为中心的企业集成中，除了需要支持整个软件开发周期和标准的工具框架以外，开发服务需要提供和服务开发相关的技术：

• 用于支持以服务为中心的企业集成方法学和建模，如SODA和IBM的SOMA（Service Oriented Modeling and Architecture）
• 用于服务为中心的编程模型，如WSDL, BPEL4WS,SCA和SDO等

开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同，有如下四类服务：

• 建模服务(Model Service)：用于构建可视化的业务流程模型
• 设计服务(Design Service)：根据业务模型，进一步分解为服务组件；设计服务用于设计和开发这些服务组件。
• 实现服务(Implementation Serivice)：用于将设计和开发的服务组件部署到生产环境中
• 测试服务(Test Service)：支持服务组件的单元测试和系统的集成测试

2.6. 业务创新和优化

一方面，以服务为中心的企业集成通过各种集成提高信息流转速度，从而提高生产效率。另一方面，以服务为中心的企业集成也为业务创新和优化提供了支持平台－业务创新和优化服务。

业务创新和优化服务以业务性能管理(BPM)技术为核心提供业务事件发布、收集和关键业务指标监控能力。具体而言，业务创新和优化服务由以下服务组成：

• 公共事件框架服务(Common Event Infrastructure Service)：通过一个公共事件框架提供IT和业务事件的激发、存储和分类等。
• 采集服务(Collection Service)：通过基于策略的过滤和相关性分析检测感兴趣的服务。
• 监控服务(Monitoring Service)：通过事件与监控上下文间的映射，计算和管理业务流程的关键性能指标(KPI)

业务创新和优化服务与开发服务是紧密相关联的。在建模阶段被确定的业务流程的关键性能指标被转为特别的事件标志被构建到业务流程中，建模过程中的业务流程也被转换为用于监控服务的监控上下文。在业务流程执行过程中，这些事件标志激发的事件被公共事件框架服务截获，经过采集服务的过滤被传递给监控服务用于计算关键性能指标。关键性能指标作为重要的数据被用于重构或优化业务流程。这种迭代的方法使得业务流程处于不断的优化中。

2.7. 管理支持

为业务流程和服务提供安全、高效和健康的运行环境也是以服务为中心的企业集成重要的部分，它由IT服务管理来完成。IT服务管理包括如下两部分：

安全和目录服务(Security and Directory Service)：企业范围的用户、认证和授权管理，如单点登录(SSO)；系统管理和虚拟化服务(System Management and Virtualization Service)：用于管理服务器，存储、网络和其他IT资源。

IT服务管理中相当一部分服务是面向软硬件管理的，而另外一部分服务，特别是安全和目录服务，以及操作系统和中间件管理，会通过企业服务总线和其他服务集成在一起，用于实现业务流程和服务的非功能性需求，如性能、可用性和安全性等。

2.8. SOI中技术标准和IBM产品支持

下面的表格列出乐SOI架构元素中的技术标准，和IBM的产品如何支持这些架构元素。

3. SOI 实践

企业集成首先是一个战略性的活动，在我们的经验中，有很多的企业将重点放在集成技术上，这导致了很多失败的案例。作为一个战略性的活动，企业集成首先要从全局出发，制定整个企业集成的策略。这种策略包括业务目标，集成路线图，技术规范，和对开发管理提出的新要求。

企业集成的目的是为了整合 IT 资源，形成一个灵活的 IT 基础设施，来满足业务随需应变的要求。所以要充分考虑业务面的压力和痛点，未来发展和转型对 IT 带来的新需求，以确定集成的战略目标。在环境发生变化时，要随业务面的调整作必要的修改。在我们的观察中，企业 IT 组织往往由于缺乏高级业务管理人员的参与，而无法制定与业务对齐的集成战略，失去企业集成赖以成功的最重要的基础。

在制定集成的战略目标后，要根据目标的优先级，考察当前 IT 环境，确定集成远景，分析差距，定义集成路线图。考察当前可得到的技术、产品、相关技能和服务的可获得状况，定义高层技术规范，包括集成方法、参考架构、技术和产品的选择标准、所遵循的业界标准等等。然后结合人力、物力和资金的投入情况，导出项目群。在我们的观察中，很多企业为了应付业务需求，匆忙上马，缺乏统一规划，导致企业 IT 架构越来越混乱，不能适应业务的变化而日渐被动。

由于集成是一个企业范围内的活动，一个集成项目往往影响若干个部门，其结果也由多个部门所共享使用，所以需要企业级的协调机制。这要求企业调整其已有的 IT 管理（IT Governance）机制，要有一个角色来协调集成项目，并被授权，利用 IT 开发管理的过程，保证相应集成规范得到执行。

另外值得注意的是关于成熟度的考虑，不同企业有不同的成熟度，包括业务本身、IT 系统、IT 组织自身在技能和管理方面，它们的成熟度，对企业集成的成功与否，也都有很大的影响。对成熟度的考察，会帮助我们制定更稳健、实际的集成策略。

服务建模（Service Modeling）是 SOI 活动中至关重要的活动。它包括如何找到和确定服务，如何处理服务的粒度，如何通过服务体现和实现业务目标，如何详细说明服务，如何确定服务与已有系统的关系等。在我们的实践中，这对很多 IT 组织机构都是一个难题，可以考虑一些专业公司的培训，如 IBM SOA 设计中心基于丰富的实践所提供的各种服务。

4. 结束语

以服务为中心的企业集成方法是对以往企业集成技术的继承与发展。它基于关注点分离、松散耦合等源自最佳实践的架构原则，继承了EAI，消息总线，流程集成，数据集成等优秀技术，结合以服务为中心（Service Orientation）的先进思想，正在给企业集成领域带来巨大的变化。随着SOI及相关技术的逐渐成熟，SOI正在成为企业集成的新方向。本文的姊妹篇"以服务为中心的企业整合－案例分析"，将用一个实际案例来说明基于 IBM 产品的实际 SOI 应用，帮助读者感性地理解 SOI。

了解 IBM 有洞察力的专家和领先技术开拓者对 IT 架构师在目前及将来面临的问题的评述，了解他们的观点与展望。本月，他们将对以下问题进行讨论：为什么应该考虑 SOA？何时应当选择 SOA，何时又不应该选择 SOA？

欢迎阅读观点与展望专栏

欢迎阅读第一期观点与展望，IBM 技术专家将在此 developerWorks 专栏中就 IT 架构师需要及时解决以完成其工作的问题提供指导。每个月，我们都将拜访 IBM 内部架构师社区（包括最知名的有洞察力的人、标准组织的投稿人、我们产品团队的架构师和每天与客户接触的顾问），邀请他们与大家分享他们对目前 IT 和软件架构师面临的最重要问题的看法。

无论您是跨越全球的大型团队的架构师，还是刚刚开始学习 IT 体系结构技术与实践的新手，他们的回答都将给您提供帮助，为您带来灵感并促进您的积极参与。这些观点和看法并不一定十分全面。有关此处涉及的主题的更多指导信息，可以参考 developerWorks Architecture area 的另一部分：IT Architecture resource round-up。另外，如果您有具体问题需要询问专家，或希望发表讨论，则请访问 developerWorks IT 体系结构讨论论坛。

引言

面向服务的体系结构 (SOA) 已成为了一项事实标准，用于开发基于组件的应用程序，可使用标准接口通过网络（Internet 或其他网络）访问这些应用程序。至少 IBM 高级管理人员和很多其他供应商、分析师、顾问和软件开发人员都这么说。他们还将告诉您，整个行业都在逐步采用 SOA，如果您尚未开始 SOA 开发，将很快跟不上时代的步伐了。

赞誉之词。但这些看法是否真的很有吸引力，能让您开始着手您自己的 SOA 吗？让我们来看看一位参加 Open Group 主办的 SOA 大会的架构师的问题。在 IBM Global Services 副总裁 Michael Liebow 的主题发言后的提问期间，这位架构师问道：“SOA 是不是我们需要知道的唯一体系结构？（顺便提一下，Liebow 先生的回答是“是的”）在稍后，另一位架构师大声问道：“SOA 和我们多年前就知道的组件体系结构很相似。如果我们采用了它，是否意味着我们又多添了一个技术竖井（另一个开发死胡同），从而需要进行更多的集成？”（而这次，会议参加者——包括平台供应商、企业 IT 架构师、顾问、系统集成商和其他人员——回答的是“不是。”）

这就提出了我们本月要向我们的专家询问的问题。如果您和 IBM 最近接触的很多架构师一样，那么您可能正在评估甚至采用 SOA 的过程中。但您可能仍在怀疑这是否是体系结构样式的必由之路，新东西很快由更为流行的东西取代，或者，这个体系结构是否真的适用。

我们的专家对此问题的回答包含了很多您之前听到的说法：SOA 促进了可重用性，提供了接口和实现之间的抽象级别以最小化依赖关系，将业务需求与 IT 功能结合，从而可以为您提供用于将业务需求转换为编程服务来实现流程自动化的机制，以及当前竞争激烈且快速变化的业务环境中所必需的灵活性，等等。另外，这些专家还根据他们与 IBM 内外开发先驱合作的实践经验提供了一些新颖的看法，将帮助您了解 SOA 在何时如何（甚至为什么）适合在您的 IT 体系结构和开发计划中使用。

在此对本月的专栏供稿编辑 Holt Adams 表示感谢。Holt 是 IBM Software Group 团队一位经验丰富的 IT 架构师，就您将要读到的内容为内部 IBM 社区提供了指导。他还提供了他自己对这个问题的回答“何时采用 SOA，何时不采用 SOA。”

好了，不再多说，下面就请了解一下我们的专家的观点吧。（有关回答问题的专家的更多信息，请参阅本专栏最后的关于专家。）我们邀请您就 SOA 提出您的看法。您可以访问我们的 IT 体系结构讨论论坛，或通过以下地址给我发电子邮件：pdreyfus@us.ibm.com。

Paul Dreyfus，编辑
developerWorks SOA and Web services

何时采用 SOA，何时不采用 SOA

IBM 的目标之一是在其产品内开发和采用开放标准。通过这样做，就能在您公司的 IT 基础结构中实现 SOA 的价值主张。SOA 能够优化业务需求与 IT 的一致性，能够将业务流程活动从服务实现中分离出来，还能够降低操作成本。只有在不固定供应商的情况下才能真正实现这些功能，此时面向 SOA 实现的技术可以无缝集成（考虑：“开放标准”），以构造全面的端到端解决方案。

不可轻易决定实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。 ——Holt Adams

当考虑了策略业务目标和活动时，理论上的 SOA 概念非常具有吸引力，更加容易得到支持。不过，不可轻易决定要实现 SOA。这与改变生活方式有些类似，因为开发和操作团队遵循的 IT 控制模式将完全不同。我提倡进行业务驱动开发。此过程涉及到将业务需求细化为 IT 要求，然后将 IT 要求细化为 IT 功能，以确定满足这些需求所需的技术。根据我过去四年开发基于 Web 服务的解决方案和更为成熟的基于 SOA 的解决方案的经验，以下这些相关因素通常会让我建议采用面向服务的体系结构：

• 集成成本持续增长，而并未因为可提供真正投资回报 (ROI) 的新业务机会而得到缓解。
• 兼并和收购是您公司扩大市场份额和获得新发展机会的业务模式的核心。
• 解决方案要求对来自异构系统和编程模型的业务功能进行集成。
• 业务的生存依赖于根据市场变化快速调整或即时响应竞争威胁的能力。
• 全球经济的影响要求您的公司事半功倍地开展业务，而且有必要依赖业务合作伙伴提供非核心业务功能。
• 就提高收益而言，与业务合作伙伴协作的效率对您的公司十分关键。
• 您公司业务资产的价值在减少，因为不能对其进行评估，以在最初用途之外的其他地方使用。
• 您公司员工的效率出现了问题，因为他们的大部分时间并没有花在提供公司业务模型的核心功能和服务上。
• 您公司的业务充满了机会型的业务工作。
• 您公司从头开始开发新应用程序。（我认为 SOA 应当作为定位将来的新应用程序的缺省体系结构样式，业务条件有其他限制时除外。）

在理想情况下，您和您的业务合作伙伴间没有预算限制、计划期限、技能差距和优先级差异，我想，此时完全可以说每个人都会采用 SOA，或者至少会考虑采用 SOA。不过，我们的选择实际上经常受到过去的决策的影响和限制（例如，技术投资、编程模型采用、服务的合同协定等）。因此，我们并不能总是自由地采用看起来能满足某个业务需求或技术要求的最佳选项。以下的注意事项会让我不建议采用面向服务的体系结构或说明现在实现 SOA 的边际收益：

• 您公司只将小部分 IT 预算用于集成活动。
• 您公司的大部分流程都是手动的或以文档为中心的，自动化的机会几乎为零。
• 您公司的大部分应用程序开发都使用相同的编程模型。
• 您公司的操作由一个或两个客户关系管理 (CRM) 和企业资源规划 (ERP) 应用程序管理，几乎没有集成要求。
• 您公司的现有技能库与实现支持 SOA 的基础结构所需的技能库之间存在重大差异。
• 未发现可从 SOA 提供的功能受益的业务需求或机会。
• 新业务服务的可用性将对现有的收益流带来负面影响。
• 您公司依赖的业务合作伙伴对公司间流程的自动化采用了不同的优先级。
• 您公司的主要业务的开展涉及到海量且同步性和实时性要求非常高的事务。

前面的列表只是一个示例，用以说明 SOA 是否是您公司最佳选择的原因。当然，每个合同或项目都具有唯一的要求，因此关于何时采用 SOA 的决策取决于您公司的业务状况。SOA 的价值主张十分诱人，但选择何时让您的公司采用 SOA 必须考虑业务环境的实际情况。采用 SOA 不一定要跨一大步，而通常是采用循序渐进的方式进行的。首先找到可以利用 SOA 概念和原则的项目，然后使用主要性能指标测定其价值，这是一种让大家受益的好方法。

将业务与 IT 结合起来

SOA 不仅是一个开发范例。该体系结构用于在业务和 IT 之间构建中间地段，其中包含双方都同意的一组与业务一致的 IT 服务，这些服务结合在一起，以实现组织的业务流程和目标。此范例提供了前所未有的灵活性：它允许将业务流程的结构化组成从为流中每个活动提供功能的服务中分离出来。它还允许将业务实现与其描述分离开来。进行了此分离后，公司能以增量的方式更改其后端遗留系统，并添加新功能来支持新需求，而不用受到供应商选择的限制。因此，可以在最小化对业务流程和 IT 系统的影响的前提下对软件包和自定义应用程序进行替换。

将访问功能从其实现分离的下一步工作就是 SOA。而且，除了此功能方面外，我们还可以将非功能方面外部化。例如，我们可以根据建立的业务策略确定哪些人应该可以访问特定的功能。我们还可以定义如何管理希望以灵活的、可重构的方式访问的技术资源。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。 ——Ali Arsanjani

软件工程发展的下一步就是此体系结构。它使我们从结构化对象转向分布式对象和组件，然后以一组公共服务为中心来将业务和 IT 加以结合（这些服务结合在一起，可以实现组织的流程和目标）。SOA 还允许将公司的部分业务流程向生态系统中的合作伙伴公开。

当需要支持业务灵活性的 IT 灵活性时，就可以使用 SOA。因此，对于两个程序需要进行通信并访问组合业务流程的行业应用程序而言，就非常适合选择 SOA。

使用 SOA 技术时，实时或被动系统通常不是进行实现的最佳选择，因为当前的技术不支持将 SOA 用于有大量并发使用情况的实时系统。不过，这些系统的建模也可以从 SOA 提供的分离和独立概念获益。

SOA 非常适合用于消除冗余及将业务与未紧密耦合到特定服务实现的 IT 功能相结合。它可以允许服务使用者选择后备服务提供者（不仅基于功能进行选择——我需要类似的功能，但不要此版本的服务中的额外依赖项，还可以基于设计及运行时策略和 Web 服务管理功能进行选择）。

企业体系结构基于 SOA 的公司具有稳定的基础，能从现有系统概念地抽象业务功能。它们还具有允许随着新软件包、系统和资产的提供和新需求的出现以增量的方式进行业务驱动的 IT 转换的基础。

一个重要但略显不足的机制

在企业范围中，大量的创新都出现在以下两个方面：企业边缘和企业之间。在边缘上，我们可以看到在中间件之上的框架投入了很多精力（独立于领域的框架，如 Ajax，以及特定于领域的框架，以特定行业为中心进行结合），也投入了很多精力进行与设备相关的工作 [ 典型的移动设备和具有无线频率识别（Radio Frequency Identification，RFID）标记的设备 ]。而在企业之间，我们可以看到系统（遗留系统和新系统）的系统的形成。

在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。 ——Grady Booch

在此类以 Web 为中心的系统中，服务已被证实为这两个方面的重要机制。在边缘，服务提供超越基础技术的行为。而在企业之间，服务提供了各种系统间语义丰富的强大通信方式。

虽然这样说，但在系统的构造中，服务是一个重要却略显不足的机制。这样说有些过于简单化，但总的说来，服务对于高频率或非常小粒度的连接而言，并不非常适合。而且，服务当然不是唯一适合各个系统的体系结构的分解机制。

SOA、Web 服务与优势保持

SOA 是一个使用得有些过量的首字母缩写，被从高级管理人员到开人员等各方面的人用（滥用）来传达多种（有时候是不一致的）语义。在我看来，面向服务的体系结构是一个框架，用于将业务流程和支持技术基础结构作为标准化且管理良好的组件——服务——进行集成，可以对服务进行组合、重用和调整以满足不断变化的业务优先级。

SOA 新手认为 SOA 和 Web 服务是等效的。可能存在不使用任何 Web 服务，而使用现有 IT 资产（从大型机事务到基于对象的系统）的基于 SOA 的有效解决方案。而且，我曾经看到过几个从部门级别发展出来的不是有效 SOA 应用程序的 Web 服务实现。这些 Web 服务岛通常并不完全遵循所有的核心 SOA 原则和特征——它们可能不是松散耦合、未抽象、不可重用、未组件化或不是独立于平台和协议的，最重要的是，它们可能不提供真正的业务价值。

由于 Web 服务提供了一个 Level 字段，供基础结构和应用程序供应商进行创新和互操作，很多规范、概要、术语都使得这一混淆扩大化了。Web 服务仅是一个标准和技术的集合（还有很多其他技术支持选项），用以实现基于 SOA 的解决方案。

在快速发展的全球经济环境中，企业要保持竞争优势，必须保持足够的灵活性。通过使用 SOA 原则将 IT 基础结构与核心企业流程结合，可以提供和保持这个优势。因此，理解和采用 SOA 所面临的问题不是如何或为什么，而是什么时候？基于 SOA 的企业解决方案已被证实能简化业务操作、提高效率、降低成本及消除冗余。

我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。 ——Sanjay Bose

不过，为了获得这些好处，必须正确地应用 SOA。必须具有相应企业范围内的远景和转换路线图，必须有业务执行人员的财务支持和承诺，并由有经验的架构师以增量迭代的方式进行部署。这些增量步骤应该首先针对关键业务问题进行，最终的解决方案应该能提供业务价值。这样可以帮助保持和促进使用 SOA 进行端到端企业转换。在采用 SOA 的过程中，SOA 将不断遇到各种重大的挑战，其中包括政治和文化的多样性。

从纯技术角度而言，SOA 平台（包括工具和运行时）也在经历着巨大的转变。开发工具环境包含大量的建模工具、行业根深蒂固的场景、重用模式、方案和丰富的可视表示和控件以及模拟技术。运行时也同样在不断发展，从而提供增强的服务质量、声明性的和基于策略的管理和吸引人的管理和监视 Dashboard（针对 IT 事件和业务事件），并使用具有自我修复功能的自动工具进行检测。我们正处在对解决方案生命周期的每个方面进行改革的浪尖上，而 SOA 则是关键的催化剂。不过，从长远来看，如果我们不谨慎的话，这个抽象和易用性可能会使 IT 架构师或开发人员和计算机科学与技术的根本基础脱离联系。

[ 编者注：有关此主题的更多观点，可以参考 Sanjay Bose 最近与人合著的新书 SOA Compass:Business Value, Planning, and Enterprise Roadmap（此书是 IBM Press 和 Prentice-Hall 联合出版的 developerWorks 系列丛书之一）。

模型驱动的开发和虚拟企业

您可能已经选择使用 SOA 了。大部分中型和大型企业都在其应用程序设计中应用了 SOA 元素。结构良好的 CICS® 和 IMS™ 程序通常符合 SOA 的要求。很多公司已构建了由消息驱动的应用程序组成的分布式系统。会话 Enterprise JavaBean 就是“类 SOA 的”。很多 ISV 系统都采用类似于服务的构造；例如 SAP IDocs。SOA 将结构良好的分布式系统的指南系统化，是结构化编程、模型对象 (OO) 的概念的子集和消息驱动的处理的自然发展。

在很短的时间内，我们行业的运行时互操作性和开发工具间的互操作性就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。 ——Don Ferguson

Web 服务是一组用于构建 SOA 解决方案的标准。基础结构供应商 (IBM、BEA、Microsoft) 和应用程序供应商 (SAP、Oracle) 正像采用任何软件技术一样迅速地采用 Web 服务。在很短的时间内，我们行业的运行时互操作性 [简单对象访问协议（Simple Object Access Protocol，SOAP）、HTTP、WS-Security、WS-ReliableMessaging] 和开发工具间的互操作性 [Web 服务描述语言（Services Description Language，WSDL）、WS-Policy、Business Process Execution Language for Web Services (BPEL4WS) ] 就达到了前所未有的水平。这个互操作性降低了迁移到 SOA 的成本，从而更容易获得其带来的好处。

都有什么好处呢？此处将不详细讨论全部或任何单个好处。我将简要地提一下两个好处：

• SOA 支持模型驱动的开发和从业务透视图进行解决方案监视。我们通过使用 WebSphere® Business Modeler 产生一个允许分析人员和业务专业人员进行推断和设计他们的业务流程的工具，从而有了很大进步。SOA 操作是流程中的任务或步骤的自然呈现，而组合服务的实现（BPEL4WS，业务状态机）则是流程的自然表示。根据简单业务规则（使用 WebSphere Process Server 启用），WS-Policy 和服务实现这两种方法都是业务策略的自然表示。
• Web 服务支持“虚拟企业”。MQ 和 Common Object Request Broker Architecture (CORBA) 等以前的技术主要针对企业内计算进行了优化。Web 服务协议和 WSDL 在 Internet 和内部网络中均可工作。这样就能使用以前用于企业内部应用程集成的相同模型来在 Internet 上实现简单的、快速开发的机会型 B2B 了。

控制问题

SOA 与已在 IT 行业存在了 30 年甚至更长时间的其他软件模块化流程相似。SOA 所不同的硬件和网络已足够成熟，可以支持这项基于标准的技术。从任何方面而言，SOA 都不是过去行业内的风行的热潮技术，但包含了广泛的行业标准和支持。

SOA 为企业提供了一个机会，以标识其核心能力和决定是否将这些核心能力作为服务向其行业和业务合作伙伴提供。另一方面的事实是；企业可以对作为其核心基础结构（不是核心能力）一部分的流程和应用程序进行标识，然后确定进行购买。请注意，其中一些服务（提供的或购买的）可能仅为业务流程。企业架构师可以牵头开展相应的工作，以发现企业中具有公共功能集的业务流程和 IT 流程。可以将执行功能打包为外部依赖性很小的组件，并作为服务提供。这就使得业务流程创建者或应用程序开发人员的工作得到简化，以将精力放在能满足股东的业务动力的唯一功能上。

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。 ——David K. Jackson

让 SOA 正常工作在很大程度上不是技术问题。让 SOA 正常工作是一个业务控制和 IT 控制问题。技术专家可以根据很多存在的成功模式构造一个 SOA 实现。然后让企业使用这些服务，而不再自己进行创建，这是另一个问题。恰当的体系结构控制将对其服务可供新应用程序使用的项目进行标识。要使得 SOA 投资最终能物有所值，唯一的办法就是让高级管理人员承诺控制预算，或采取某种方式保证业务线能不受干扰。IT 架构师还需要向执行股东报告业务从其 SOA 投资和投入方面获得的价值。

为了让 SOA 与业务合作伙伴协作，需要涉及企业已经建立的关系。现在，很少（如果有）客户在其建立的合同关系之外为合作伙伴提供或购买服务。服务级别协议和争议解决的相关事项要求配备封闭的协作系统。有关信任和安全的结构化信息系统发展组织（Organization for the Advancement of Structured Information Systems，OASIS）标准在过去两年中取得了长足的发展，但在等式的法律和业务一边，仍然更倾向于和企业已经了解的伙伴开展此类业务。

这里没有神话

关于为什么应该考虑 SOA 有三个简单的理由：

1. 这是目前最热门的领域之一；不要落后于时代的步伐。

2. 工具、基础结构和标准经过组合，可为整个 SOA 生命周期提供全面支持。了解我们的端到端编程模型。按照其中提供的详细步骤开展工作，亲身体验成功。

3. 如果您和我们一样不断地追求事半功倍，那么 SOA 可以为您提供帮助。寻找您可以再次利用的东西；不要所有东西都自己从头做起。寻找现有服务，对其进行调整，并加以使用。然后对其中一些服务进行共享。帮助创建一个生态系统，以便在将来能更快地装配更多有意义的解决方案。

可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，SOA 就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择。 ——Christina Lau

开始采用 SOA 与采用任何其他技术或体系结构没有什么区别。可以通过常识来看这个问题。如果您的项目处于十分关键的位置，而您的团队必须投入大量精力学习工具和 API，它就有可能是错误的选择。如果可以在小项目中试用 SOA，则是不错的选择；利用这个经验，可以帮助您定义和扩展到下一个更大的项目。循序渐进，这里没有神话。

回页首

只是业务而已

SOA 的支持者不断不畏余力地宣传 SOA 的主要技术优势：松散绑定，能够通过组件封装可重用业务功能，最后（但没有像通常那样刻意强调）还能提供更好的集成。

包括我自己也是 SOA 的支持者之一，但我不断在问自己一个问题：客户真的对这种技术推论感兴趣吗？

在过去两年，我一直在与希望获得 SOA 产生的价值主张的客户全面合作。在与客户沟通时，我经常发现客户认为，有很多其他体系结构能提供比我所提到的更多的技术价值。有些客户可能一厢情愿地得出结论，认为非常有经验的架构师和开发团队可以通过使用传统企业应用程序集成 (EAI) 体系结构获得很大价值。很多客户会争辩说，这些方法经过验证，实现风险并没有直接采用 SOA 进行设计的风险大。

虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。 ——Calvin Lawrence

这个观点可能会让架构师认识到在有些情况下，SOA 是错误的选择，或者，至少不是最好的选择。SOA 的技术可行性是否是选择其作为解决一系列业务问题的体系结构方法的原因？我会说不是：很多业务及 IT 相关的问题（例如缺乏有力的企业控制模型和策略）将减慢或阻碍任何构思良好的技术 SOA 活动的实现。

在最近一次为期三天的 SOA 研讨会上，一位汽车行业的首席技术官 (CTO) 告诉我下面的话：“我对 SOA 看法是‘只是业务而已’。”他告诉我他采用 SOA 的原因在于：

• 提高他和他的团队实现新产品和流程或更改现有项目的速度
• 降低实现和拥有成本
• 通过外包业务元素或从固定定价改为可变定价（根据业务量），从而支持灵活的定价模型
• 简化合并和收购所需的集成工作
• 实现更好的 IT 使用率和投资回报

这位 CTO 和他的团队仅关心如何使用其现有的技能（而不必放弃其现有的基础结构）在预算内按时达成这些目标。他们已经在其现有 EAI 基础结构中进行了大量投资。

这位特别的 CTO 的话与很多其他人的说法都不一样。他们只关心关键之处：我如何为股东提供回报？

当然，作为一个有经验的架构师（微笑），我知道一些解决此问题的体系结构备选方案：

1. 扩展其现有的 EAI 基础结构
2. 计划采用更多的事件驱动体系结构（完全分离的、发布/订阅，等等）
3. 或许可采用 SOA

由于这是一个 SOA 研讨会，而客户为此付费，因此我最初准备选择第三个选项。实际上，对于这个情况，我使用了一点 EAI，一点事件驱动和很多 SOA 方面的东西。SOA 允许在必要时包含 EAI 和事件驱动方法。

对于高速发展的汽车行业，为了保持竞争优势和按时在预算内提供产品，企业必须具有灵活性。这个客户的难点集中在对其业务流程进行管理和合并。正如我的同事在此讨论中指出的，将 IT 基础结构与核心业务流程结合，对于达成目标十分关键。SOA 相关的原则已被证明可以简化业务操作，能减少与实际代码关系很小而集中在人机交互和人员活动上的冗余项。在资金有限的业务环境中，几乎没有客户能为解决特定的业务问题无限制地投入资金，而有时间并愿意对其控制流程进行修整的客户则更少了。这样做听起来不错，但却不会实际这样做。

关键在于对现有基础结构、流程和现有控制模型加以利用和扩展。通过恰当地使用现有 SOA 原则，可以对整个设计和实现流程进行管理，如：

1. 标识问题。
2. 标识组成业务并是难点所在的流程。
3. 对这些流程进行建模，以对其进行简化。
4. 标识现有服务，并编写表示这些流程的其他服务。
5. 将这些服务部署到可提供运行时功能且操作效率高的环境中。
6. 监视这些服务和流程，以获得更高的效率。

那么，网络呢？虽然我们不知道其解决方案到底是什么样的，但应当客观地看待每一个问题。请同时根据技术指标和业务指标来确定是否采用 SOA。如果合适，就使用它。如果不合适，就不用它。SOA 概念和原则将始终可以通过某种方式应用到您的体系结构中。

康庄大道

我们现在都应该知道了整个行业对 SOA 的 ROI 和采用的赞颂之词——松散耦合、重用更好、推向市场的时间更短、易于集成以及互操作性更好。不过，务必了解，我们目前对 SOA 的关注只是实现即插即用企业（或者说是按需企业）的历程中重要的一步而已。

随着我们进入下一个十年，我们将开始着手大幅度减少将来自不同 IT 供应商的产品或组件组合成可行的有价值的端到端解决方案所需的工作量。供应商提供的业务组件将不依赖于基础结构，可以在各种平台上执行。因此，软件开发人员会将更多的精力放在有效集成供应商组件和确保有效的互操作性上。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。 ——Andras Szakal

客户的 IT 操作部门将主要负责选择最适合业务需求的运行时平台；即提供恰当部署和管理业务组件所需的必要服务质量和运行时支持的平台。

相反，IT 业务操作部门将主要关注如何通过定义业务组件（将由其对应的操作人员部署和管理）中包含业务规则实现组织的业务策略。这将通过 WebSphere Business Process Server 之类的业务流程管理系统完成。

IT 业务操作部门所属的人员将是业务和企业体系结构专业人士。无论您是如何定义业务或企业架构师的：为了实现这个远景，整个行业将需要更多的具有 IT 和企业体系结构背景的人士。

虽然这个远景可能十分诱人，仍然存在很大的风险，在进入组件天堂之前，我们必须小心地减小这些风险。在开始进行实现模型服务的体系结构的任务时，最重要的减小风险方法可能就是要求有强有力的管理良好的控制流程和策略。只有通过强有力的企业服务控制策略才能够避免更改管理问题、服务间的语义不匹配和系统功能结合方面出现的难于调试的问题。IT 部门可以通过制定的控制策略来减少风险，这些控制策略由执行监督团队（其中包括 CIO、CTO 和业务线执行官）提出并加以支持。

改善信息

当然，您已经对 SOA 有所了解了。您也知道 Web 服务、业务流程的重要性、模型驱动的体系结构和所有这些让人诚惶诚恐的 WS-* 标准。

但或许您是一名信息人员。您需要负责组织的信息的完整性和对其进行分析。您关心表示业务状态的数据库的性能和稳定性。正如您所知的，真正重要的部分。因此，您可能会问：“为什么我应该关心 SOA？”

SOA 表示的不仅是服务提供者和使用者的协定，而且也是信息提供者和使用者间的协定 ——Dan Wolfson

作为信息人员，我很关心 SOA。我之所以关心 SOA，是因为 SOA 具有直接和间接影响信息管理系统的能力——事实上可以影响信息本身。为了获得成功，我们需要在业务服务所涉及的信息的上下文中对其进行考虑。我们需要知道检索到的信息是准确的。被更新的信息经过了验证。交换的信息的意义对于服务提供者和使用者都是一样的。如果忽略了这些事情，服务的价值和可重用性就会减少。

直接来说，使用 SOA 时，我们需要在提供者和使用者之间形成一个信息协定，以便让各方知晓信息意义的内涵，并且仍然支持异构系统——换句话说，我们必须假定世界是杂乱无章的，必须对其进行整理，以提高信息的价值，了解不同的结构和意义之间的关系，并在可能的情况下就公共对象达成一致。

将信息作为服务公开还将让我们配备额外的信息服务器拓扑来容纳增加的信息负载。它还会要求我们建立可以对信息访问进行虚拟的点（这样用户就无需知道信息的真正位置以及其组织方式）。它还引入了一些方法，允许我们有效地对这些信息进行组合——通过集合或联合。如果没有建立更多的公共机制或引入经过改进的清除机制，则我们稍后很可能被迫投入巨额的额外资金和资源进行清除，从而导致将来的灵活性下降。

可以采用很多办法实现信息协定。其中一个变得越来越重要的就是主数据管理 (MDM) 领域。MDM 系统可为业务应用程序或服务提供经过清除、整合且特定于域的信息。最常见的 MDM 系统是作为客户和产品信息的信息集线器使用的系统。每个集线器都作为中心点使用，可以在此对信息进行添加、更新、审核、清除、搜索和查询。集线器放置于可以将更改传播到相关数据库或可以生产相关服务的事件的位置。MDM 系统可以是事务型的（在操作业务流程的主线中更新），也可以是引用型的（提供业务流程所引用的信息的一致来源）。但最重要的是，我们可以将 MDM 系统看作其本身提供了一个一致的服务集，以供在各种业务流程内使用和进行重用。

通过 MDM 等方法显式地实现信息提供者和使用者之间的协定，可以帮助我们实现 SOA 所承诺的灵活业务流程和服务可重用性，并同时为我们提供提高所管理信息的质量的机会。

适合与不适合的场合，以及需要注意的地方

SOA 是一种组织化的方法，用于应用到由面向服务和分布式对象计算组合而成的应用程序体系结构中。让我们来将这个定义分为几部分进行分析。应用程序体系结构 是应用程序各部分的宽泛组织，通常作为层实现。体系结构指定包含哪些部分以及它们如何一起工作。面向服务将功能封装为服务——宽泛的可重用任务，可以在没有任何前一上下文（除承载服务的系统的当前域状态外）的情况下运行。服务的上下文是作为从调用方传递的参数提供的，和函数调用的参数非常相似。分布式对象 以特定方式运行在独立进程中，通过这种方式，一个进程中的对象可以调用另一个进程中的对象上的方法。

服务支持对访问通过宽泛任务的经过良好定义的 API 公开的已良好封装的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。 ——Bobby Woolf

SOA 向分布式对象添加面向服务，从而可以在进程之间调用服务。它是一种用于设计应用程序体系结构的方法，以便应用程序的各个部分可以在不同的进程中运行，而且还允许不同的应用程序共享和重用正在运行的部分。它是分布式对象计算的演变，用以在多个对立方之间获得更好的平衡：需要访问彼此功能的应用程序；需要封装自己功能的应用程序；需要限制在其应用程序编程接口 (API) 中描述的对外公开的功能的应用程序；需要限制分布式调用的交互应用程序。服务支持访问通过各种任务定义良好的 API 公开的封装良好的功能，从而可以通过低频率的调用实现功能的高重用性。SOA 或许是所有方法中最好的一个。

以下给出了一些简单的技巧，用以确定何时采用 SOA 和何时不应采用 SOA 以及需要提高警惕的情况。

首先，适合采用 SOA 的情况：

• 当数据分布程度非常高时，使用 SOA。将操作数据的代码放置在与数据较近的位置，然后将其包装为服务，以供在任何地方进行访问。
• 希望功能具有高可用性时，使用 SOA。将功能作为服务部署在多个冗余的提供程序中，以在其中一些不可使用时，可以使用其他的对等服务。
• 当应用程序的各个部分需要独立开发、维护和更新时，使用 SOA。只要保持各个部分之间的接口，每个团队（如两个不同的 B2B 公司）就可以使用其喜爱的技术按照自己的计划实现各自的部分。
• 当多个应用程序需要重用功能和数据时，使用 SOA。共享的代码仅重用功能；服务则允许各个独立应用程序重用一组共享的企业数据，而无需将数据分发给所有应用程序。

以下是不适合使用 SOA 的情况：

• 当希望开发尽可能简单时，不要使用 SOA。使用一种语言实现，在单个线程中运行，且没有远程访问问题的应用程序复杂性较低一些，因此构建和调试更为方便。
• 当希望操作环境尽可能简单时，不要使用 SOA。要对松散耦合、事件驱动的分布式应用程序进行故障排除要困难得多，要求对应用程序实现细节和操作环境配置细节及其当前状态有全面的了解。
• 当网络不可靠或网速慢时，不要使用 SOA。服务组件运行于独立的计算机上，通过网络进行通信，因此，其速度和可靠性依赖于这些计算机及连接这些计算机的网络。
  （注：分布式冗余服务可以帮助减少硬件不可靠和网络延迟的影响。）
• 进行原型设计时，不要使用 SOA。原型开发应该简单，而 SOA 并不简单。

对于何时需要提高警惕的问题，坦白地说，随时都要提高警惕才行。以下是一些需要谨慎行事的具体情况：

• 当服务接口不确定时，使用 SOA 需小心。服务接口允许使用者和提供者独立地进行更改，但接口本身必须稳定。SOA 中的接口变化比在单个应用程序（特别是非分布式应用程序）中复杂得多，因为有很多在其他情况下不相关的开发团队必须就接口的更改进行合作。
• 当安全性极为重要时，使用 SOA 需小心。每个服务都是一个新的易受攻击的点，必须保证其安全性。可以轻易访问服务的人越多（如在公共 Internet 上的服务），可以尝试攻击该服务的人就越多。
• 当性能极为重要时，使用 SOA 需小心。进程之间的每个服务调用都比进程内的方法慢得多。
• 希望功能具有高可用性时，使用 SOA 需小心。正如所指出的，冗余服务可以提高可靠性；但同时，活动部分越多出现故障的可能性就大。SOA 应用程序只与其服务一样可靠。

这些列表根本不足以包含所有方面，但我希望这能让您更好地了解什么是 SOA 以及适合使用 SOA 的情况。如果您需要这方面的专业帮助，请访问 IBM Software Services for WebSphere，在其中可以找到各种参考资料。

祝您好运！

面向服务的体系结构（SOA） 为对业务应用程序进行智能且有效的设计、开发、部署和管理提供了一个广阔的基础设施。为了帮助更好地理解 SOA 是如何影响 Lotus 和 IBM Workplace 产品和技术的，我们访问了 Lotus 和 IBM Workplace 开发团队的几名成员，并探讨了 SOA 为您现实的工作带来了什么。

请简单谈一下你们在 IBM 的职责。
Fernando Salazar：我是 IBM Workplace 团队的高级技术人员。负责 Workplace Server 组件的整体体系结构和内容。

Robert Duffner：我是 WebSphere Portal 和 Workplace 产品的产品经理。还负责在 Workplace、Portal 和 Collaboration (WPLC) 产品部门中围绕 SOA 策略提供帮助信息。

Doug Wilson：我是 WPLC 部门的主要技术负责人，还是体系结构指导委员会和顾问组的成员。我的工作是确保跨 WPLC 产品的产品空间体系结构的一致性，并保证它们适合于整体 Software Group 体系结构策略。

概括地说，什么是 SOA？
Robert：SOA（面向服务的体系结构）并非新的思想。SOA 一直主要是关于如何正确地进行构建，如何创建一种体系结构蓝图，该体系结构蓝图允许进行可重用的构建，允许以更加松散耦合的方式工作，例如您构建了这样一个体系结构并要进行修改，那么无需打破原有设计。还有，如何在流模式下集成异构的 IT 系统。SOA 是真正支持使用可重用的组件或服务装配业务流程的体系结构，这些组件或服务独立于应用程序和它们运行的平台。

这里的关键点是服务为真正可重用的构建块。这些概念确实不是新的了。我认为现在很多供应商创建的产品开始支持 SOA 标准，比如 Web 服务这样的产品，使 SOA 在很多 CIO 的心中占据了优先和中心地位。大型跨平台供应商，如 IBM、Microsoft、Oracle 以及 SAP 都开始以能吸引客户的方式支持这些标准 —— 因为支持更多的标准能帮助客户降低风险，很多标准都是这样产生的。在这种形势下构建 SOA 的能力开始变得很有前景，这可能是今天的 SOA 最激动人心的地方。在这一过程中标准起到了很重要的作用。

Doug：我还要强调 SOA 包括面向服务的体系结构、对业务结构以及支持业务的 IT 系统进行推理的方法。事实上，SOA 是从顶层开始的，通过分析业务是如何运行的，以及如何把支持业务的业务流程分割为基本步骤 —— 人为执行的或者是通过多个自动片断执行的任务。SOA 的强大之处在于它给出了一种一致的方法，用于推理业务的结构，以及推理支持该业务的 IT 基础设施和组织。

Fernando：帮助推动 SOA 的新事物是企业服务总线（Enterprise Service Bus，ESB）这个概念。我们能够通过标准定义所有的服务，这样非常棒。但是，ESB 允许我们安排这些服务，并以满足应用程序需要的方式同步或异步地调用它们。接口和松散耦合是两个由来已久的软件工程概念，但是我认为企业服务总线是使这个概念成为可能的关键因素。企业服务总线是促使 SOA 产生的因素之一。

你们提到 SOA 不是一个新事物，但是看起来直到最近人们才开始关注它。关注背后的主要原因是什么呢？
Doug：我认为在该行业中有两个关键的变化，为考虑如何构造 SOA 重新注入了力量。Web 服务的描述功能与使用无处不在的互联网的 IT 系统相组合，可能是过去两年中许多 SOA 的思想重新热起来的驱动因素。什么都比不上公众的说服力，以及无处不在的技术解决方案，推动着前进的步伐。在过去，一些系统间互连的其他方式要通过专有的或是难于使用的协议，像 CORBA 和 IIOP，结果就我们需要取得一个单一的、通用的中间件基础设施 —— 具体内容要与规则保持高度的一致。Web 服务规范使人们只需很少的 IT 投资就能够解决这个问题。

哪类行业和公司是 SOA 的主要受益者？
Doug：这是一个很难回答的问题。推动 SOA 实施的一个因素是通过很低的投资，就能够为小型企业提供技术。我认为这在很大程度上能够促使人们接受它，因为您不会被限制在某个范围，就是说不是大型企业或小型企业的问题。问题是 —— 也是机会 —— 任何规模的企业都可以使用 SOA 策略。其中的一个驱动因素是在大多数情况下，小型企业都是较大型企业的服务提供者。例如，如果我想外包运输业务，或者是外包客户满意度跟踪，或者是一个较大业务流程中的几个小型业务，那么我需要一个 IT 结构允许我将行为或服务委托给小型企业。可能在实施的初级阶段，大型企业将是服务的中心，但是许多小型企业将作为较大型企业的服务提供者形式出现。

Robert：这一点十分好。显然，能够从 SOA 得到最大受益的组织，很可能是那些具有处于较高稳定状态的 IT 基础设施的组织。其中所有遗留下来的程序都不能进行及时修改，它们无法支持业务需求的变化。通常，您能够看到许多这样的组织可能支付这样的开销。一些即将成为行业先锋的公司正是那些具有投资和 IT 的公司，并且在这些公司中 IT 的使用比在其他公司中占有更大的比重。但是 SOA，在这一方面，能够从根本上转变 IT 基础设施，使其从业务的阻碍转变为业务变化的推动力。所以，如果您看一下像金融服务和银行之类的组织，它们通常都具有非常尖端的组织。

我还注意到，如果您稍微关注一下，就能够发现一些组织还建立了体系结构控制部门，或者是跨学科和跨区域的群组，他们实际上是整体地研究整个组织的 IT 基础设施和体系结构。这预示着在未来 SOA 将取得成功。

除了 IT 方面外，SOA 会以哪些其他方式影响公司经营业务的方式？
Doug：我认为事实上恰恰相反。业务方式的自我演化正迫使 IT 部门作出响应，SOA 就是由此而产生的强大支持模型。业务在不断地合并、放弃和重构，以及自我重组，并对 IT 部门跟上其发展提出了实质性的挑战。如果 IT 和企业能够为业务结构的推理形成统一的模型，并因此得到相应的 IT 结构，那么这将成为 IT 部门满足它们业务需要的强有力的推动力。

Robert：看一下很多关于 IBM 帮助开始随需应变业务的讨论，当我们考虑一个随需应变的业务时，我们认为企业需要跨他们的组织以及他们所需的全部合作伙伴、供应商和客户，对业务过程进行集成。但是更重要的是，他们能够做出非常灵活的响应，并且能够随客户的需求、市场机会或其他可能出现的任何类型的机会和威胁做出响应。从这一观点出发，只是一味地花费、花费、花费和不进行调整的日子结束了。IT 和业务线正在以过去未曾有的方式结合到了一起。你不再为所有这些 IT 系统持续地花费资金，并且还得不到最初进行这些投资时所预期的回报。有了 IT 和业务线的密切合作，将帮助推动使用 SOA，帮助实现随需应变的业务这一目标。

Fernando：我们描述的过程部分不仅采用了技术、标准和基础设施；并且还从工程的角度进行了分析，以确定什么是您所依靠的（我们将其称作 “原始的”）业务功能。原始的业务功能可能是像运输产品、重新进货报表或支付帐单这样的功能。当将它们作为服务进行嵌入时，就能够分离调用这些服务的逻辑，并且可以放到一个不同的位置。这是您真正获得适应性的地方 —— 如果这样做了，现在就可以用新的算法管理库存或运送包裹。逻辑是从原始的服务中分离出来的。当这样做时，就能够开始从适应性中获益。

SOA 将会成为新的 IBM 特性和产品吗？
Doug：当然。最近，我们宣布了整个产品系列，目的非常明确，是要在我们的客户中推动 SOA 实施。关于我们在世界范围内推动 SOA 这一事件，各种论坛上都有具体和详细的报导。

Robert：SOA 确实触及到了我们所有的软件生产线。请您看一下我们是如何定义 SOA 参考体系结构的，其中涉及建模、部署、变更和管理，我们有帮助实施 SOA 整个周期的产品。SOA 最大的优点是，公司不必一次性地完全加以实施；这里有很多的入口点，他们能够从这些入口点开始。这要依据组织正在做什么。一些组织可能非常依赖集成解决方案，例如消息传递。这些客户会问 “如何将系统集成到一起？如何确保可靠性和保证消息的传递？”。通常，当考虑高速消息传递和消息传递框架时，您将想到企业服务总线。我们有一个整套的产品线，主要为 WebSphere 品牌，我们还有已经宣布的带有业务集成的新产品，这些新产品还具有一些其他功能以支持 SOA 的核心。我们的其他产品，如 WebSphere Portal 和 IBM Workplace 产品，能够作为 SOA 的最好的组成部分。

某些组织可能会选择从一些有机会的项目开始。这可能比较简单，“我需要构建门户中的一部分。我该如何开始组织、构建并将其放在具有面向服务体系结构特征的系统中？换句话说，在可以较高程度的重用的地方该如何做？”。您可以从定义服务开始。一个服务可以简单到只有一个业务流程，或是客户必须进行的一个操作，例如检查某个产品订单的状态。这个服务可以在客户将要登录的门户中自我显示。这个门户和服务将显示为一个 portlet，占用屏幕的一小部分。我将登录到系统中 —— 我能够快速地查看订单状态。这就是客户将会看到的。客户还会问 “我们如何进行构建？我们如何进行软件生命周期管理？我们如何开发和部署这些产品？”。所以我们在支持 SOA 的 Rational 品牌中还有另外一组完整的产品线。这里还有 Tivoli 产品集，使您能够进行安全性管理，并保证这些系统能够正常运行。我们的另外一个产品线用于信息管理；例如 DB2 产品线。它们带来了一整套的产品用于 SOA 策略的所有方面。

最终情况依赖于我们的客户的需要。我们可以把更多的精力放在某些组织的整个能力的广度上，他们试图进行部署、考虑部署或者是想要部署面向服务的体系结构。在他们想从投资中获得回报时，就是他们开始的时机，这要根据业务的需求而定。

我们可以详细阐述一下在 SOA 中 WebSphere Portal 技术所扮演的角色吗？
Robert：按照 Gene Phifer 的说法，他是 Gartner Research 的一个门户权威，WebSphere Portal 是 SOA 出名之前的一种 SOA。回到互联网刚产生的时候，当我们过去使用门户时，我们中的很多人都理解门户和 portlet 的概念，这些门户如今在 Yahoo、AOL 和诸如此类的站点中变得十分流行。但是猜一猜怎么样？企业和大型组织想做同样的事情，但是在这种情况下内容不是必需的，却是有 “如何将所有的系统进行集成并提供单点访问？” 这一问题。因此，创建一个平台供重复使用这一想法实际上已经非常接近面向对象的体系结构。对许多组织而言，门户代表进入 SOA 的逻辑上的过渡，因为它允许组织做我们正在谈论的事情。您可以在一个基础设施上进行标准化，这样如果您开发了一个雇员门户，然后必须进行另外一个项目，那么您能够重用许多资产和基础设施，并开始从 SOA 中获益。对一些组织而言，门户是一个逻辑上、战略上的 SOA 入口点，这并不意味着您必须从这里开始，但是它为您提供了一个平滑的入口点。

Doug：大多数的业务流程在处理过程中需要用户的参与。门户为构造人与面向服务的体系结构之间的用户交互提供了一种较好的方法。将服务的用户界面映射到屏幕上特定的小矩形中，例如 portlet，是一种非常常见的操作。portlet 还对用户能够访问的服务类型进行管理，并安排这些服务呈现在用户前的方式。这些功能，诸如 WebSphere Portal 的处理功能，允许用户安排一组服务和一组用户界面间的用户活动流。我们将门户的这些非常常见的部分作为体系结构中 Web 服务的基本表现工具。想像一下门户作为 SOA 的前端。正是在这里 SOA 触及到了用户。

SOA 会影响其他 IBM 产品吗，例如 Notes/Domino 和 IBM Workplace？
Doug：Domino 作为一项集成技术，通过在 Domino 基础设施中添加定义 Web 服务并执行这些 Web 服务的功能，在支持 SOA 的过程中迈出了重大的一步。这是一个重要的新功能。许多 SOA 工作的初始阶段包括调整现有的系统，使之适应面向服务的体系结构。通常，这意味着在 Web 服务中封装这些系统的一些业务功能，并且在环境中显示 Web 服务。Domino 是这个领域中新的参与者。而 IBM Workplace 一开始就被设计为基于面向服务体系结构的应用程序系列。

Fernando：确实是这样。IBM Workplace 是一组协作功能，会在门户中用到这些功能，但是其本质结构都是面向服务的体系结构。主要协作功能有一些服务接口，例如创建文档、发送电子邮件消息、创建 Web 会议等等。这些接口可以被调用、组合并与想开发的任何其他应用程序中的其他服务集成。例如，使用 Workplace，完全有可能调整组织中新员工的注册以及他们在想参加的课程中的注册，这些课程是由 Workplace Learning 提供的。所有这些都可以通过 Workplace 提供的 Web 服务 API 来实现。我们从一开始就将这作为我们的功能的整体意图，并且我们一直在努力提高这些 API 的功能以与其他流程集成，并提高整个系统的功能以支持这些用户交互。

需要些什么才能够使 IT 部门对 SOA 的理解同对业务线的理解相匹配？
Robert：显然，要对 IT 部门进行创新。同时也要让业务线以不同于以前的方式加入进来。在我所工作过的某些组织中，技术从来不是阻碍成功的因素；而阻碍成功的因素通常与组织问题、部门问题、政治、组织间合作方式、设置管理方式等问题有关。用户不想定义业务线试图去做什么，而是将那些需求收集工作都交给 IT 人员，然后希望在 9 到 12 个月内就能取得巨大成果。

组织正在重新思考他们当前的组织方式。现在可以看到 IT 和业务线的跨学科、跨功能角色的信息都聚集到一起，以更好地理解什么是业务需求，从而更好地理解技术如何帮助他们从一种组织方式转换到另一种组织方式。这就是 IBM 的业务咨询服务的重要作用，他们能帮助公司了解他们如何重新处理或重新思考作为一个组织应该如何运作，以及如何以不同于以前的方式来利用 IT，因此 IT 能成为组织的极具竞争性的优势。

我希望 SOA 在组织中能像它在技术领域中那样流行，但通常并非如此。它实际上是让业务线和 IT 人员以更好地理解什么是需求的方式工作，从而确保项目取得成功，并理解每个需求在取得整个成功过程中都有其作用。而不是用户将项目交给 IT 人员，IT 人员又将其交给业务线这样一种运作方式。

Doug：从入门角度来说，有多种可能的方法。一种是自顶向下的方法，从业务开始，然后是业务分析、为组织建模，最后是对业务流程进行建模。这种方法受 Rational Software Architect 套件的工具支持。更常见的是 “双向逼近” 战略，IT 人员从认识 Web 服务和 SOA 的封装和集成战略开始，并构建一定数量的体系结构，然后加入到业务中以便在可能的情况下利用这些体系结构。正如 Robert 所说的，SOA 实际上是关于将业务和 IT 组织合并到一起，在粒度级和业务行为方面达成一致，从而由服务对其进行建模。

IT 组织如何能够使 SOA 被业务线获得和使用？
Robert：这又回到了我们刚才谈论的话题，就是关于如何使用 WebSphere Portal 技术来实现 SOA，并将 Workplace 作为 Portal 技术的一种超集。通过将服务目录映射到 portlet 目录（即为所提供的服务创建用户界面），并且通过使用 WebSphere Portal 来驱动服务和用户之间的用户交互，这是一个很好的过渡，适合于很多客户已经进行的 IT 工作。因此我们认为 WebSphere Portal 是业务线用户能够访问 SOA 的关键。

Fernando：要详细描述这一点，也可以这么说，IT 领域和业务线领域之间的常见分工是，开发人员在 IT 方构建标准的组件。这些界面可以作为 portlet，这些 portlet 访问企业服务，然后 IT 组织会将 portlet 组织到模板中。模板是服务的可重用组合，不同业务线的终端用户都可以访问这些服务，并根据他们的自身需要对这些服务进行定制（这是一个关键部分）。同时使用 WebSphere Portal 和 Workplace，用户的系统可以变得更灵活，由此可以为销售群组或研发部门定制能访问这些企业服务的标准模板，以包括特定类型的表单，从而收集自己的信息或涵盖您所感兴趣的项的特定文档集，或上面标记了对您的团队来说非常重要的事件和里程碑的特定日历。这是一种本地定制，这些本地格式化的企业工作空间使这些组织内的各个群组可以利用 SOA 的价值。

Robert：的确如此，他说出了我们工作的意义和 WPLC 组织是什么。随着组织开始使他们的基础设施变得合理，并试图提高工作效率，您将看到这些流程驱动的门户、企业工作空间、企业桌面 —— 这些是您所听到的用于描述这些事情的术语 —— 作为公司跨企业优化他们的协作业务流程的首选方法而出现。WebSphere Portal 和 Workplace 能扮演如此重要角色是因为它们是商业人士实际所用的工具。用户无需接触很多集成技术，因为这些都是底层技术。但是他们的确接触到了这些桌面 —— 这些企业工作空间。

你们如何看待 SOA 将塑造软件工业的未来（或是这方面的其他工业）？
Doug：我将更清晰地预测一下未来，我们已经说过 SOA 是业务和 IT 组织很好的交汇场所。我认为这将导致根本上的变化。我们还略微提到了一些 Web 服务，尤其是互联网上的 Web 服务，允许小型业务和大型业务集合到一起，使 IT 基础设施的花费同时适用于它们。并且其通过互联网创建大型的、面向服务的系统的能力，我认为前景非常广阔。随着互联网支持大量其他新出现的业务模型，我认为在服务提供者和服务消费者的领域，将会有一整套新的业务模型。

Robert：我认为服务的重点是继续强调虚拟化和适应的作用，这就像软件产品的交付。如今，我们经常需要深入了解软件系统的参数和选项才能进行安装，然后再来调整这些参数和选项。软件在某种程度上来说本身就是一种服务，用户将其添加到网络基础设施中并让其工作，现在该软件即是可以作为端点来访问的服务。可以对该服务进行管理，将其连接到其他服务，但是不需要深入了解这些服务的内部工作原理。用户更多的是注意它所带来的价值。作为软件开发人员，这对我们来说并不容易，实际上，我认为这是一件很难的事情。但是让我们所有的产品以相同的方式互相通信是我们的预期目标。

有什么需要补充吗？
Doug：我要再强调一下，我们将 WebSphere Portal 和 IBM Workplace 技术作为该行业的关键技术。随着人们在互联网上提供服务的改进和增加、组织内部对服务可用性的改进、业务线帮助他们自身和创建新的最适合其业务需要的服务组合的机会，这些都将越来越多地需要 IT 基础设施。IBM Workplace 是一种旨在允许业务线用户创建和构建他们自己的结构、能力以及应用程序的产品，以可用的协作服务和由 IT 组织或应用程序供应商带入到应用环境中的其他服务为基础。因此我们认为自我服务和用户驱动这两者相结合非常重要。

Robert：我将借用一下别人的展望和预测 —— 如果您看一下 IDC 上系统专家的分析，那么就会看到他们的确相信一个新的用户工作环境将在今后的五年中出现，一种新的、统一的、模块化的企业软件组合将为该环境提供支持，该环境构建在面向服务的体系结构之上。他们称其为企业工作空间，它将极大地改进应用程序和工作人员之间的交互，以及工作人员之间的协作。您将看到前所未有的效率水平。

摘自 IBM WebSphere 开发者技术期刊。

引言

在这一系列文章的第 1 部分，我们引入了服务组件体系结构（Service Component Architecture，SCA）作为编程模型来构建和组装集成解决方案，包括简要介绍什么是 SCA，以及一些相关术语的定义。我们还提供了一个通过 IBM WebSphere Integration Developer 使用 Java™ 构建 SCA 组件的示例，测试了该 SCA 组件，并使用 SCA 客户端编程模型构建了一个调用该 SCA 组件的示例 JSP 文件。在第 2 部分中，我们将继续描述引用和连线，并介绍如何使用它们来组装 SCA 组件。

概述

在第 1 部分介绍的示例中，我们使用了一个简单的 JSP 客户端来调用 SCA 组件。该示例只用于演示；当构建您自己的实际自定义应用程序时，您可能会使用标准 J2EE™ 组件模型来实现应用程序逻辑。J2EE Web 应用程序将继续调用 Enterprise JavaBean 来访问特定于应用程序的功能。实际上，SCA 编程模型是用于业务集成、应用程序组合和解决方案组装的，而不是用于 J2EE 应用程序开发的。SCA 客户端（它可以是 J2EE）通常在进程管理器外，例如它可以使用 BPEL 流程来编排工作流。与 BPEL 流程联合部署的 Web 应用程序也可以使用 SCA 编程模型来调用特定于应用程序的功能。图 1 显示了 SCA 生态系统的一个示例。

SCA 位于集成层。SCA 组件可以通过导入来调用 SCA 运行时外的应用程序。非 SCA 客户端可以通过导出调用 SCA 组件。在集成层内，可以通过定义引用和使用连线来组合 SCA 组件，这将在本文中重点介绍。有了连线和引用，您就可以在开发时定义运行时调用的特性；例如，使调用同步或异步，标记调用的转换边界，等等。这些特性是在部署时读取的，它们可以启用所需的运行时行为。图 2 阐释了这些高级概念。

再次说明，我们关注的是集成层，而不是应用层。另外，我们介绍的是较高级的集成，例如工作流编排或与 EIS 系统的高级集成。然而，出于演示目的，我们使用简单的 Java 示例来显示如何将组件连接到集成层中，强调的是连线和引用的功能而不是组件本身的实现。（在后续文章中，我们将介绍如何将 SCA 组件实现为 BPEL 流程和状态机，以及如何应用连线技术。）因此我们使用一个按比例缩减的模型来阐释引用和连线，如图 3 所示；然而，我们要记住图 2 中合适的 SCA 使用远景。

引用

正如第 1 部分所讨论的，SCA 组件被打包成一个 SCA 模块。一个模块中的 SCA 组件通过对调用的 SCA 组件定义引用来彼此交互，并且将这些引用连线到相同模块中的其他 SCA 组件。图 4 阐释了这一概念。

对调用组件的引用是用 SCDL 表示的，如下所示：

												
																		
<scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0"
xmlns:ns1="http://CreditApproval/CreditRequest"
xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0"
xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0"
displayName="CreditApproval" name="CreditApproval">
  <interfaces>
    <interface xsi:type="wsdl:WSDLPortType" portType="ns1:CreditRequest">
      <method name="calulateCreditScore"/>
    </interface>
  </interfaces>
  <references>
    <reference name="CreditHistoryPartner">
      <interface xsi:type="java:JavaInterface" 
      interface="approval.credit.credit.history.CreditHistory">
        <method name="getCreditLimit"/>
      </interface>
      <wire target="CreditHistory"/>
    </reference>
    <reference name="CreditAgencyPartner">
      <interface xsi:type="java:JavaInterface" 
      interface="approval.credit.credit.agency.CreditAgency">
        <method name="getCreditScore"/>
      </interface>
      <wire target="CreditAgency"/>
    </reference>
  </references>
  <implementation xsi:type="java:JavaImplementation" 
  class="sca.component.java.impl.CreditApprovalImpl"/>
</scdl:component>
												
										

引用的好处之一是能够定义调用期间的服务质量。当在 Assembly Editor 中连线组件时，可以指定服务质量 (QoS) 限定符。这些限定符定义了调用期间在 SCA 运行时管理组件的必要条件。

限定符

使用 SCA，您无需编程或更改服务实现代码就可以对组件应用 QoS 限定符（例如事务、安全性和可靠的异步调用）。在连线组件时，您可以指定限定符来为组件以及访问服务的客户端提供扩展的服务质量。在 IBM WebSphere Process Server 中，您可以在三个地方定义 SCA 限定符：

• 引用
• 接口
• 实现

在运行时，这些规范确定了客户端如何与目标组件进行交互。运行时环境可以提供所需的任何额外处理，这取决于所指定的限定符。

用于引用的限定符

引用限定符可以指定异步调用的可靠性，以及是否应该联合目标组件的方法，使之成为任何客户端事务的一部分。

引用限定符包括：

• Asynchronous reliability - 允许发生异步调用。这些限定符还允许您指定消息的可靠性、请求和响应超时。同时也能配置 Service Integration Bus——它在 IBM WebSphere Application Server 运行时中提供消息传递平台，因此对 WebSphere Process Server 可用。（有关 Service Integration Bus 的信息，请参阅参考资料。）

• Suspend transaction - 对于同步调用，当使用同步编辑模型进行调用时，客户端全局事务上下文始终会被传播到目标组件。（此限定符只影响客户端全局事务，因为本地事务从不传播到目标组件。）对于客户端不想让目标组件与客户端事务联合的用例，需要使用挂起事务限定符设置来进一步限定引用：

  • True 会在通过服务引用调用组件之前挂起当前全局事务。
  • False（缺省值）指示运行时在通过服务引用调用组件之前不要挂起全局事务。

• Asynchronous invocation - 确定是否应该进行异步调用（作为任何客户端事务的一部分）。值：

  • Call（缺省值）指示运行时在进行服务调用的同时将消息提交给异步调用的目的地。
  • Commit 指示运行时将消息提交给异步调用的目的地的工作交给当前工作范围单元处理。

• Suspend activity session - 活动会话能够对可能不支持分布式事务的资源进行更高级的协调。集成解决方案中更可能出现此类情况；客户端不想让目标组件与客户端的活动会话相联合，所以需要使用挂起活动会话限定符设置来进一步地限定引用：

  • True 会在通过服务引用调用组件之前挂起当前活动会话（如果存在）。
  • False（缺省值）指示运行时在通过服务引用调用组件之前不要挂起任何处于活动状态的活动会话。

您可以指定引用限定符，以便它们应用于服务组件的所有引用或者只应用于独立引用。如果需要，您还可以为每个引用指定这些限定符，在这种情况下它们将重写任何顶级限定符设置。在 Properties 视图中以灰色表示继承的限定符，以黑色表示已赋值的限定符。继承的限定符不能更改，除非您选择定义它们的所在元素。

用于接口的限定符

接口限定符说明了被目标服务支持的QoS，因此代表了一个与该服务客户端的约定。

接口限定符包括：

• Join activity session - 确定目标服务是否愿意加入传播的活动会话范围。值：

  • True 指示运行时不要在接口边界挂起活动会话（如果存在）。
  • False（缺省值）指示运行时在接口边界挂起活动会话（如果存在）。

• Join transaction - 确定目标服务是否愿意加入传播的全局事务。值：

  • True 指示运行时不要在接口边界挂起全局事务（如果存在）。
  • False（缺省值）指示运行时在接口边界挂起全局事务（如果存在）。

• Security permission - 使您能够在 SCA 组件上定义 J2EE 角色。只有与声明的角色相关联的客户端才能调用该组件。

所有接口限定符都可以应用于组件的三个级别：

• 用于其所有接口
• 用于单个接口
• 用于某个接口的单个操作。

操作的限定符覆盖接口的限定符；接口的限定符覆盖组件的所有接口的限定符。

用于实现的限定符

实现限定符提供确定服务权限和/或表示其对事务环境的需求的功能。

接口限定符包括：

• Activity session - 确定组件的处理是否在一个活动会话中执行，除了全局事务上下文所提供的，它还提供一个备选的工作范围单元。值：

  • True：组件将在活动会话的上下文中执行。如果活动会话是在调用时出现的，则会添加该组件。
  • False（缺省值）：组件将在现有的全局事务（如果存在）或本地事务的上下文中执行。实现限定符为 activitySession=false 的组件必须使用接口限定符 joinActivitySession=false。
  • Any：如果存在活动会话，则组件会加入当前活动会话。如果不存在活动会话，则组件会在现有的工作范围单元或本地事务的上下文中执行。

• Transaction - 确定组件处理执行的逻辑工作单元。对于逻辑工作单元，事务期间所做的全部数据修改都是作为一个单元一起提交或作为一个单元回滚的：

  • Global：组件将在全局事务的上下文中执行。如果在调用时存在一个全局事务，则该组件会被添加到该全局事务范围。如果不存在全局事务，则会建立新的事务范围。
  • Local（缺省值）：组件将在本地事务的上下文中执行。
  • Any：如果存在一个全局事务，则组件将加入当前全局事务范围。如果不存在全局事务，则组件将在本地事务的上下文中执行。

• Security identity - 使您能够指定组件担当的身份，与部署描述符上的 J2EE Run-As 约束类似。

限定符是在 SCDL 文件中定义的：接口限定符是在接口部分定义的，实现限定符是在实现部分定义的，引用限定符是在引用部分定义的。（有关详细信息，请查阅 WebSphere Process Server Information Center。）

连线组件

在对引用有了新的理解之后，我们现在可以将一些组件通过连线连接起来。我们将使用的示例十分简单，但在这个过程中我们也会检查各种可用的服务质量。我们将继续介绍在第 1 部分使用的信贷审批示例。

在我们的示例中：

• Credit Approval 组件必须调用 Credit History 组件以及 Credit Agency 组件。
• Credit Approval 组件将作为这两个服务的一个 Facade。
• Credit Approval 组件需要连线到其他组件。

这一练习所需要的文件可以从本文所附带的下载文件中获得。

设置工作区

1. 启动 WebSphere Integration Developer 并创建一个新的工作区（图 5）。

   
   图 5. 在 WebSphere Integration Developer 中创建工作区
   
   

2. 关闭欢迎屏幕（图 6）。

   
   图 6. WebSphere Integration Developer 欢迎屏幕
   
   

3. 要从下载的文件导入项目交换文件，请右键单击 Business Integration 视图并选择 Import（图 7）。

   
   图 7. 导入下载文件
   
   

4. 选择 Project Interchange，然后单击 Next（图 8）。

   
   图 8. 导入项目
   
   

5. 假设您已经将下载的文件解压缩到 C: 驱动器，则选择 CreditApprovalPart2.zip 文件，然后单击 Select All 和 Finish（图 9）。

   
   图 9. 导入项目
   
   

检查组件

在我们的示例中，我们将使用自底向上的开发风格：我们有一个现有的 SCA 组件集并准备对它们进行集成。从 Business Integration 视图中，您可以检查该 SCA 模块：

6. 展开 CreditApproval 模块（图 10）。

   
   图 10. 展开的 Credit Approval 模块
   
   

7. 请注意，它有三个接口和三个 Java 实现。打开 CreditApprovalImpl Java 实现并转到 calculateCreditScore() 方法。请注意，calculateCreditScore 同时与 CreditAgency 组件和 CreditHistory 组件进行交互来完成其服务。您很容易想到将 CreditApproval Service 实现为 BPEL 流程或其他组件类型，但在本例中，我们用一个简单的 Java 组件来作为 Facade。

   
   清单 2
   

   public DataObject calulateCreditScore(DataObject creditApp) { ServiceManager serviceManager = new ServiceManager(); BOFactory bof = (BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory"); DataObject creditRating = bof.create("http://CreditApproval", "CreditRating"); creditRating.setString("customerId", creditApp.getString("customerId")); CreditAgency creditAgency = (CreditAgency) serviceManager.locateService("CreditAgencyPartner"); Integer creditScore = creditAgency.getCreditScore(creditApp); CreditHistory creditHistory = (CreditHistory) serviceManager.locateService("CreditHistoryPartner"); Double creditLimit = creditHistory.getCreditLimit(creditApp); creditRating.setInt("creditScore", creditScore.intValue()); creditRating.setDouble("creditLimit", creditLimit.doubleValue()); return creditRating; }

   
   

8. 要打开 Assembly Editor，请双击 CreditApproval 集合（图 11）。当 Assembly Editor 打开时，会显示三个组件（图 12）。

   
   图 11. 打开 Assembly Editor
   
   
   图 12. Assembly Editor 中的组件
   
   

连线组件

CreditApproval 组件通过使用简单的 SCA 客户端 API 来与 CreditAgency 和 CreditHistory 进行交互。然而，要让运行时正确地调用这些服务，需要将组件“连线”起来，使用 WebSphere Integration Developer 来进行这一操作非常简单。在我们的示例中，我们将接受缺省值。

9. 选择 CreditAproval 组件并将其连线到 CreditAgency 组件（图 13）。

   
   图 13. 连线组件
   
   

10. 将显示一个对话框（图 14），表明将在 CreditApproval 组件上创建一个引用。选择 OK。

    
    图 14. 匹配引用对话框
    
    

11. 由于 CreditApproval 组件是一个 Java 组件，所以我们需要用 WebSphere Integration Developer 生成 Java 接口以便能够调用该组件。因此，在下一个对话框（图 15）中选择 Yes。如果 CreditApproval 已经是一个完整的 BPEL 流程，则选择 No。（请记住，在大多数情况下将使用 WSDL 作为集成层中的接口选择。如果 User Interface 是与集成解决方案联合部署的，则可以使用 Java 接口。）

    
    图 15. 生成 Java 接口对话框
    
    

12. 重复步骤 9 到 11，将 CreditApproval 组件连线到 CreditHistory 组件。结果应该与图 16 类似。

    
    图 16. 组件连线完成
    
    

单元测试组件

因为我们使用 Java 作为我们的实现，所以可以在 Java SE 环境中对组件进行单元测试。正如在第 1 部分所做的，我们很容易在 WebSphere Integration Developer 中调出单元测试工具：

13. 右键单击 CreditApproval 组件并选择 Test Component（图 17）。

    
    图 17. 测试组件
    
    

14. 将显示单元测试工具。该单元测试功能的一个很好的优点是它允许独立测试组件，并且可以检测引用和创建模拟器。在我们的例子中，我们自己测试集成，所以需要删除模拟器。

15. 切换到 Configurations 选项卡。

16. 展开 Module CreditApproval 模块，突出显示 CreditAgency 和 CreditHistory，并将它们从 Emulators 列表中删除（图 18）。现在，测试 CreditApproval 组件将导致调用 CreditHistory 和 CreditAgency 组件，而不会模拟交互。

    
    图 18. 删除模拟器
    
    

17. 切换回 Events 选项卡并突出显示 Invoke 项（图 19）。

    
    图 19. Events 选项卡
    
    

18. 填充输入，如图 20 所示。

    
    图 20. 数据参数
    
    

19. 单击 Continue。

20. 选择 Eclipse 1.4 JVM 选项（图 21）。

    
    图 21. 选择部署位置
    
    

21. 检查每个步骤的流程。您可以实际看到流经组件的数据（图 22）。

    
    图 22. 事件流
    
    

22. 最终结果应该与图 23 类似。

    
    图 23. 测试结果
    
    

23. 关闭测试编辑器，不进行保存。

检查服务质量

引用和连线是集成解决方案的关键，因为它们抽象出调用的方式和场合。当在 WebSphere Process Server 中运行时，您可以定义想为调用设定的服务质量。例如，您可以使调用异步化、可以更改事务上下文，或者使异步调用更加可靠。这里我们将通过检查引用属性来查看各种 QoS 选项。

24. 选择 CreditApproval 组件上的 CreditAgency 引用，如图 24 所示。

    
    图 24. 组件引用
    
    

25. 转到 Properties 视图。您将注意到该引用被选中。

    
    图 25. 选中的引用
    
    

26. 在 Details 选项卡上（图 26），将显示被调用的接口和多样性，以及作为目标的连线。您可以更改调用的多样性；对于异步调用，这样可以以一种发布/订阅方式调用几个组件。

    
    图 26. 引用详细信息
    
    

27. 切换至 Qualifiers 选项卡（图 27）以设置特定服务质量。

    
    图 27. Qualifiers 选项卡
    
    

28. 单击 Add 按钮来查看几个可用的服务质量（图 28）。

    
    图 28. 服务质量限定符
    
    

29. 作为自我练习，您可以试验这些限定符，请记住，这些质量需要在 WebSphere Process Server 运行时中测试。这些限定符包括事务质量和异步质量；要测试事务工作，您需要与资源交互的组件。特定服务质量是在接口中定义的。这使得该组件能够控制其他组件调用它的方式。

30. 突出显示 Assembly Editor 中的 CreditApproval 接口（图 29），或者导航至 Properties 编辑器。

    
    图 29. Assembly Editor 中选定的 CreditApproval
    
    

31. 检查服务质量限定符（图 30）和实现限定符。请注意，这些限定符是在被调用的服务（而不是调用它的服务）上定义的。

    
    图 30. 检查限定符
    
    

在 WebSphere Process Server 测试环境中测试

要测试服务质量，您通常需要在 WebSphere Process Server 中运行，或者在 WebSphere Integration Developer 中为测试提供的 WebSphere Process Server 运行时运行。

32. 在 Servers 视图中，右键单击该服务器并选择 Start（图 31）。

    
    图 31. 启动测试环境中的服务器
    
    
    图 32. 服务器已启动
    
    

33. 当服务器启动后，您可以按照管理控制台中的指示（图 32），以一种类似于添加 J2EE 应用程序的方式将该 SCA 模块添加到服务器中，因为 SCA 模块被包装成 EAR 文件（如第 1 部分所提到的）。再次右键单击服务器并选择 Add and remove rojects...（图 33）。

    
    图 33. 添加和删除项目
    
    

34. 选择 CreditApprovalApp 并将它添加到已配置的项目一侧（图 34）。

    
    图 34. 将项目添加到服务器
    
    

35. 检查管理控制台，确保 SCA 模块已启动（图 35）。

    
    图 35. 表明 SCA 模块已启动的控制台消息
    
    

36. 要使用同一 WebSphere Integration Developer 单元测试功能来测试该组件，请按照前面所执行的操作，再次右键单击该组件，然后选择 Test Component（图 36）。

    
    图 36. 测试 SCA 组件
    
    

37. 再次说明，请删除模拟器，以使测试能够流经 SCA 组件（图 37）。

    
    图 37. 删除模拟器
    
    

38. 键入输入参数，如图 38 所示。

    
    图 38. 数据参数
    
    

39. 选择 WebSphere Process Server V6.0 作为部署位置（图 39）。

    
    图 39. 选择部署位置
    
    

40. 检查测试结果。

作为自我练习，请更改组件以进行数据库更新，然后试验事务属性。您也可以在管理控制台中使调用异步化以及检查基础 Service Integration Bus 配置。

结束语

本文介绍了使用 WebSphere Integration Developer 组装服务组件体系结构组件的上下文中的引用和连线。这一系列的下一篇文章将讨论导入和导出，以便您能够集成 SCA 模块。该系列以后的文章还将介绍更复杂的组件以及与非 SCA 组件相集成。

致谢

作者真诚感谢 Eric Herness、Keys Botzum 和 Paul Ilechko 对本文的审阅。

下载

名字	大小	下载方法
CreditApprovalPart2.zip	23 KB	FTP|HTTP

引言

对于任何应用程序来说，保护信息访问的安全都是最基本的要求。由于按 SOA 原则构造的实现的服务、应用程序以及跨组织操作的松耦合，因此安全对其甚至更为重要。这种环境往往会暴露现有安全实现的弱点或局限性。

即使不考虑通过由模型驱动的开发和基于 SOA 的服务管理所提高的效率，业务应用程序仍须保护信息。只保护周边设施（如防火墙和路由器）是不够的，因为随需应变的企业必须能够随着其合作伙伴、客户和雇员之间的关系发展而建立和断绝动态信任关系。因此，安全的随需应变企业需要灵活的、可自定义的基础设施，以适应新要求和规章制度。要提供这种灵活性，不应将策略生搬硬套到基础设施中；应该通过由策略驱动的基础设施满足安全模型的要求，这任务可不简单。

本文将阐释业务应用程序利用随需应变安全基础设施的安全功能的方式，以及建立用于保护面向服务的应用程序的编程模型的设计原则。

业务应用程序和安全基础设施

安全集成以及对业务应用程序和信息的访问通常是通过身份验证、授权和责任实现的。企业探讨管理身份验证、授权和责任的方式在很大程度上取决于其对客户、雇员和合作伙伴之间的信任关系的看法；这些关系对业务应用程序安全的影响；以及这些应用程序的相对重要性和安全性。

在业务合作伙伴之间交换敏感信息时，敏感信息必须受到保护。可能还需要用安全的方式保存敏感信息。必须保证消息源的完整性（如通过公证服务）才能在必要时启用验证、审核和认可。可能需要对敏感信息进行加密以实现机密性，或对其进行数字签名以实现完整性。（数字签名也可用于认可。）完整的 SOA 设计必须不但涵盖消息级和传输级安全性，而且还要满足保护保存的内容以遵守政府规章制度和业界最佳实践的需要。

安全策略的制定和执行以及所执行的安全级别，基本上都取决于企业及其雇员、客户和合作伙伴之间的信任关系。证书和密钥之类的相关技术可用于反映和管理这些信任关系。工具可用于建立业务合作伙伴、客户和企业等之间的信任关系模型并指定信任关系，还可以将信任定义转换成适用于 IT 环境的技术。

SOA 安全模型

SOA 安全模型基于 Web 服务可能需要其中的传入消息以验证一系列声明的过程。名称、密钥、权限和功能都是声明的例子。根据所提供的证据，会在请求者、服务端点和一系列可能的中介之间应用适当的信任模型。

消息可能会通过请求者和目标服务之间的若干中介。端到端安全性必须考虑到请求者、中介和最终端点服务（提供者）之间的信任模型，如图 1 所示。

对于消息处理，网络和传输中介（如防火墙、路由器和代理服务器）一般不受信任。应该防止传输中的所有消息受到不可靠中介的篡改。

OASIS Web 服务安全性（Web Services Security，WSS）规范提供对传输中的简单对象访问协议（Simple Object Access Protocol，SOAP）消息的保护。可用 WSS 防止消息的真实性、完整性和机密性受到不可靠网络和传输中介的攻击。

并不是所有中介都不可靠。Web 服务网关和企业服务总线中介服务都是消息转换中介的例子，其在 SOA 内的功能包括检查，在某些情况下还包括对消息有效负载的修改 [请参阅此系列中的第 4 部分，“IBM 企业服务总线简介”（developerworks，2005 年）]。在设计 SOA 安全基础设施时，请考虑允许某些受信任的中介。

处理请求者和应用程序服务主机之间的信任关系的消息代理可能是另一个受信任的中介。在这种设计中，安全责任由代理和服务端点来分担。如图 2 所示，消息中介将负责消息级安全、请求者和提供者环境之间的身份联合，以及管理请求者和服务提供者之间的信任关系。服务只有为了满足特定于服务的安全要求（如建立（通过中介映射和联合）访问特定于消息有效负载中应用程序数据的服务、完整性和机密性数据的身份）才会继续起安全作用。通过分解业务应用程序中脆弱或复杂的基础设施代码并将其委派给容器，基于 SOA 的安全方法可以提高灵活性并降低发生不测事件的可能性。

消息安全性

WSS 规范还提供一系列有助于 Web 服务开发人员保护 SOAP 交换的基本消息级完整性、机密性和身份验证机制。可用各种方式组合这些机制，以便用各种加密技术建立各种安全模型。

WSS 还提供可扩展的机制，以便将安全令牌与含有各种身份验证及授权格式和机制的消息相关联。例如，客户机可能会提供身份证据及其具有特定业务证书的已签名声明。然后收到这种消息的 Web 服务就可以确定是否要信任其声明和信任的程度。

安全令牌声明可由授权机构核准或不核准。一组已核准的声明通常表示为安全令牌（经过数字签名或受到授权机构加密保护）。X.509 证书就是一个熟悉的已签名安全令牌例子；它断言某人的身份和公钥之间的绑定关系。安全令牌可以“推送到”消息中或者在消息中携带安全令牌，也可以通过引用表示安全令牌，以便接收方从授权机构“拉取”该声明。

因为安全令牌是在信任域内起作用的，所以需要有链接信任域作用范围的方式。可通过协议或通过实现一系列规则强制执行信任策略来手动链接。这样，如果发送方和接收方之间有已确立的信任关系，则可信任未经核准的声明。例如，如果发送方和接收方使用的是其通过带外信任关系建立的可靠连接，则发送方为 Bob 的未核准声明足以让某些接收方认为发送方实际上就是 Bob。在本例中，此可靠连接的存在可作为确凿的证据。

防止消息内容受到非法访问（机密性）或非法修改（完整性）是主要的安全事务。WSS 规范提供通过对主体、标题、附件或其任意组合（或部分）进行加密和/或数字签名保护消息的方法。

身份验证请求基于可选网络、由传输支持的安全性和消息中已批准的信息（声明）的组合，这种技术称为消息源身份验证可能更好一些。通过网络和由传输提供的安全性、消息中已批准的声明，以及用收件人已知的密钥对请求进行加密，请求者可以对收件人进行身份验证。

信任模型

演示安全令牌已授权应用的一种方式是，添加采用相关联密钥（来自于占有证据令牌）的数字签名。这会使请求者可通过将安全令牌（如 X.509 公钥基础设施（Public Key Infrastructure for X.509，PKIX）证书或 X.509 证书）与消息相关联来证明所请求的声明组。

如果请求者没有向服务证明请求的声明所必要的令牌，则可与相应的授权机构（我们称为安全令牌服务）联系，并用正当的声明请求所需的令牌。安全令牌通过发布一系列安全令牌（可用于在不同的信任域之间代理信任关系）来形成信任的基础。

一种机制是应用 WS-Trust（对于有关 WS-Trust 规范的更多信息，请参阅参考资料）中所定义的质询回应协议。这种机制由 Web 服务用来对请求者进行更多质询，以确保消息不过时，以及验证安全令牌的使用是否已经授权。图 3 所示的就是此模型，可以看出任何请求者也都可以是服务，请求者和目标服务都具有受信任的第三方安全令牌服务，这种服务有助于验证每个目标服务策略所需的安全令牌。

此 SOA 安全模型（声明、策略和安全令牌）还含有并支持若干特定模型，如基于身份的授权、访问控制列表和基于功能的授权。通过该模型可使用现有的技术，如 X.509 公钥证书、基于 XML 的令牌、Kerberos 共享秘密票证，甚至口令摘要。SOA 模型结合 Web 服务安全对话语言（Web Services Secure Conversation Language，WSSC）和 Web 服务策略框架基本要素，这足以构造高级密钥交换、身份验证、基于策略的访问控制、审核和复杂的信任关系。

将对 Web 服务应用策略，Web 服务会从请求者收到可能包括安全令牌的消息，还可能会对其通过 WSSC 机制应用某些保护措施。下面是由 Web 服务的信任引擎执行的主要步骤：

• 验证令牌中的声明是否足以遵从策略，以及消息是否与策略一致。
• 验证申请人的特征是否可由签名来证明。在代理式信任模型中，签名不可以证明申请人的身份；签名可以证明中介（只是可断言申请人的身份）的身份。声明经过批准或不是基于策略。
• 验证安全令牌（包括所有相关和即将颁发的安全令牌）的颁发者是否可信，可以颁发其所作的声明。信任引擎可能需要外部验证或代理令牌（也就是向安全令牌提供服务发送令牌，以便用其交换其他可直接用在其评估中的安全令牌）。

如果满足了这些条件，而且请求者有权执行操作，则服务可以处理服务请求。

可将 IP 安全（IP Security，IPSec）或传输层安全/安全套接字层（Transport Layer Security/Secure Sockets Layer，TLS/SSL）之类的网络和传输保护机制与此 SOA 安全模型结合使用，以支持不同的安全要求和方案。如果可用，作为附加安全技术，请求者应该考虑采用网络或传输安全机制，以便在颁发、验证或更新安全令牌时对收件人预先进行身份验证。

编程模型设计原则

从安全的角度来看，编程模型包括对于谁负责实现安全策略（如基础设施或应用程序）所作的决策，以及需要让请求者得到此信息的哪一部分。除了操作方面，某些设计期间的策略（如在 J2EE 描述符中捕获的）也有助于管理应用程序。是通过使基础设施能够实现安全模型，还是通过将安全的实现转换成每个应用程序中的代码来最大程度地满足业务需求，这是关键实现决策之一。要考虑的另一方面是调用服务的变数。服务的消费者是否通过可在订阅期间定制的选择得到了灵活性？最后，在实现安全解决方案时，应该考虑安全工程——用于构建安全应用程序的工程方法。

由基础设施管理的安全与由应用程序管理的安全

每个组织通常都会让某些人负责确定和实现其安全策略。在许多情况下此过程都是手动的，从而导致组织投入大量资源在不同的实体和应用程序之间协调访问。

我们建议复杂的组织在基础设施中集中实现与解决方案相关的安全策略——也就是验证用户质询（如用户 ID/密码）、控制对应用程序的访问（如对 travelService 执行 reserve() 方法），以及委派身份（如运行方式 travelAgency id），以确保方法一致。可在某些部署构件（如 J2EE 应用程序的部署描述符）中定义初始应用程序安全策略。部署完毕后，熟悉大部分应用程序逻辑时就可以向部署环境提供策略信息了。可将策略声明概括成高级策略要求，以备将来细化成实现约束条件，这被认为是部署阶段的工作。

应用程序设计中引入了有关由基础设施管理的安全与由应用程序管理的安全的决策。安全约束和条件是附加到实现构件的。决定是让基础设施处理安全，还是将安全转换成应用程序中的代码的时机在实现阶段，此时通常可以得到有关应用程序平台（如 Java™ Platform Enterprise Edition (J2EE) 和 Microsoft® .NET）的信息。

我们建议将应用程序的重点放在业务逻辑、延迟服务访问的保护和送往基础设施的消息（承载应用程序的运行时容器）上。在这种由基础设施管理的方法中，附加到设计构件的安全策略将被转换成特定于平台的策略 [例如，通过统一建模语言（Unified Modeling Language，UML）模型表示的要求将转换成 J2EE 部署描述符]。

在由应用程序管理的方法中，安全实现是在应用程序中实现的，必须实现相应的安全调用。即使是由应用程序管理的安全也必须通过 Java 身份验证和授权服务（Java Authentication and Authorization Service，JAAS）将其安全调用（如 authenticate()）转换成相应的特定于平台的功能[如 loginContext.login()]。

授权和访问控制的粒度粗细不等。细粒度访问（对于解决方案本身）与粗粒度访问（对于其操作之一）的选择通常取决于业务和技术考虑。粒度也会受各种因素的影响，包括信息实体的实例（如特定游客的信用帐户概要信息）、上下文信息，如用户特征（如旅行社）、时间约束（如从早上九点到下午五点）、访问目的（如进行旅游预订的目的）、访问路径（例如，内部网请求与外部请求），以及许多其他因素。

可通过定义应用程序角色概括与授权相关的策略，其中的角色是指一组通过其可对特定应用程序资源执行某些操作的权限。例如，旅行应用程序可声明对 ReservationBean 执行的 view() 或 change() 预订方法可由 TravelAgent 角色访问。换句话说，TravelAgent 是由实现方案定义的角色，可以确定可由“旅行社”执行的操作；根据一组用于对各自企业 JavaBean（Enterprise JavaBean，EJB）调用特定方法的权限。在实现阶段不大可能定义的是谁拥有 TravelAgent 特权。用户到角色的指派通常是在部署时开始的，然后会在应用程序的整个生命周期内对其进行管理。清单 1 所示的是用于定义某些基于角色的方法权限的示例代码。

												
														<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
<method-permission>
<role-name>TravelAgent</role-name>
<method>
   <ejb-name>ReservationBean</ejb-name>
   <method-name> view</method-name>
   <method-name> change</method-name>
</method>
</method-permission>
			
												
										

在执行某些业务逻辑之前要求提供通过身份验证的身份信息的应用程序必须从基础设施中得到该信息。例如，在 J2EE 环境中，运行时会在身份验证后确定用户的身份；应用程序可通过 API（如 getCallerPrincipal()）检索此信息。

选择的灵活性

客户机运行时有时需要某些对访问服务本身的要求或约束（包括身份验证、完整性和机密性要求）。而支持各种客户机运行时（如浏览器客户机、非浏览器客户机和 PDA 瘦客户机）可能是令人满意的。要支持各种客户机运行时，请发布断言客户机运行时必须确保消息机密性，并必须提供用户身份的证据（用户 ID/密码或证书）的策略。身份验证的策略概括可列出替代选项，如可接受的凭据类型，或所信任的凭据颁发机构。

例如，TravelService Web 服务可声明其要求某些安全令牌类型的意图和机密性要求。实现方案可通过描述符支持意图声明。工具则可进而生成必要的机器级详细信息（如 WS-SecurityPolicy 表达式），如清单 2 所示。

												
														<wsp:Policy>
  <sp:SymmetricBinding>
    <wsp:Policy>
      <sp:ProtectionToken>
        <wsp:Policy>
          <sp:KerberosV5APREQToken
              sp:IncludeToken=".../IncludeToken/Once" />
        </wsp:Policy>
      </sp:ProtectionToken>
      <sp:SignBeforeEncrypting />
      <sp:EncryptSignature />
    </wsp:Policy>
  </sp:SymmetricBinding>
  <sp:SignedParts>
    <sp:Body/>
    <sp:Header
       Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"
    />
  </sp:SignedParts>
  <sp:EncryptedParts>
    <sp:Body/>
  </sp:EncryptedParts>
</wsp:Policy>
			
												
										

安全工程

在开发安全解决方案的过程中，安全工程是最佳实践之一——请遵循定义明确的模式，以使您的应用程序、服务或组件可以完全实现其设计者和用户的期望。您应该估计每个实现方案构件中固有的风险，对其进行设计和实现以防其暴露在弱点下（例如，高效的内存管理并避免出现隐蔽的通道）。工具支持和代码评审也有助于将对从中部署解决方案的环境的损害降到最低（或彻底避免）。

总结

SOA 编程模型必须确保每个服务调用都符合对请求者和服务端点均有效的安全策略。安全基础设施（包括对请求者进行身份验证和对其授予服务访问权的能力、基于基本信任模型跨 Web 服务请求传播安全上下文、审核重要事件，以及有效地保护数据和内容）形成了有助于保护组件和服务的 SOA 环境的结构。所有 SOA 安全的核心都是基于策略的基础设施和策略的管理。在理想的情况下，SOA 应用程序的重点在于业务逻辑、委派安全策略的实现，以及处理基础设施的信任关系。基于 Web 服务安全规范的 Web 服务安全模型和方法有助于解决保护面向服务的应用程序的难题。

为什么需要基于组件的编程模型？

推动 IBM 的 SOA 编程模型的远景依赖于两个重要的观察结果，请看以下两段引言中的精辟描述：

“根据时髦词语设计 (Design-by-buzzword) 是一种常见的情况。至少在软件行业，这种行为或多或少与缺乏对一组给定的有用体系结构约束的理解有关。换句话说，在选择要重用的软件体系结构时，设计人员并没有真正弄清楚这些体系结构之所以好的原因。”
——Roy Thomas Fielding，“Architectural Styles and the Design of Network-based Software Architectures”（请参阅参考资料以获得指向此研究报告的链接）。

这个问题可以通过将详细了解体系结构约束的原因的人的经验融入一组模式、编程构件和工具来解决。

第二个重要的观察结果同人以及人与技术的交互有关：

“创建面向服务的体系结构 (SOA) 意味着重新考虑当前用于构建系统的实践、组织的技能，以及团队成员协作的方式。面向服务的作用在于通过组装不同的应用程序来开发解决方案，SOA 是体系结构样式，强调独立服务提供者的松散耦合。”
——A.W. Brown 等，“Realizing service-oriented solutions with the IBM software development platform”（请参阅参考资料以获得指向这篇文章的链接）。

基于 XML 的 Web 服务标准使人想到了基于组件的编程模型的某些方面。诸如 Web 服务互操作性 (WS-I)、Web 服务描述语言 (WSDL) 和 Web 服务策略 (WS-Policy) 之类的标准尝试创建与平台无关的抽象和统一的框架来进行业务软件集成。而 Web 服务的价值来源于在 SOA 中使用它们。

大多数关于 Web 服务的资料都集中于互操作性协议和服务接口及其使用。而本文把重点放在用于实现服务并将服务组装成解决方案的编程模型上。组件模型简化了构建和组装服务的过程。

良好定义的组件应该支持生态系统中的各种用户角色——例如业务分析人员、集成开发人员、适配器开发人员和解决方案管理员——通过实例化、使用、组装和自定义符合用户目标、技能和概念性框架的不同组件类型，来创建面向服务的应用程序。（注意：编程人员作为专业人员和重要的软件开发角色仍然存在，但并非每个人都必须成为专业编程人员才能高效地使用 SOA 构件。）

Web 服务标准中的组件模型明确地定义了组件和组件类型，以及定义和构造组件的方式，以便由适合角色的工具重用和操作，这与我们对技术使用中人的方面的观察结果是一致的。

基于组件的编程模型有许多好处，最显著的好处是可以减少复杂性。没有哪个角色需要了解实现功能的所有方式或所有的系统接口。公开给每个角色的复杂性是有限的，而公开给开发人员角色的复杂性有助于他们使用适合于其任务的工具以定义良好的方式开发解决方案。

组件模型必须是抽象的，并且与语言无关，因为它的作用在于隐藏技术细节和差异。

组件模型还必须简化非编程人员组装和定制“解决方案部分”的过程。因此，与组装和调整有关的组件（或组件集合）的所有方面必须以与语言无关的方式显式地声明，这样无需编程人员修改源代码就可以通过工具操作它们。我们使用 XML 来表示这些声明。

SOA 的确切特征还有待探讨，不过一些关键的方面已经得到广泛承认：

1. SOA 是一种分布式组件 体系结构。不管在企业内部还是企业外部，SOA 组件都是透明的，并且可以通过一系列统一支持的、可互操作远程过程调用和消息传递协议来统一访问。接口定义标准支持开发人员工具之间的互操作性。网络上 (on the wire) 协议互操作性——相对于代码可移植性——是 SOA 组件的中心部分，支持统一访问和平台独立。调用方不知道组件的基础实现技术，例如 Java™ 2 Platform、Enterprise Edition (J2EE)、Microsoft® .Net 和 PHP。
2. SOA 组件封装功能，并支持通过业务分析人员和业务模型建模的抽象级别的重用。这使 IT 功能和它所支持的业务功能之间的映射更加直接，从而提高了可靠性。
3. 声明性的、计算机可处理的约定允许第三方访问 SOA 组件提供的服务。这些约定显式地声明功能性特征以及非功能性（服务质量或 QoS）特征和需求。SOA 组件使用 WSDL 记录它们的操作。还可以使用用于 Web 服务的业务流程执行语言 (BPEL4WS) 来定义组件的有效操作序列。
4. 可以动态地发现、选择、绑定（通过其声明性属性）和集成（使用组合机制，例如本系列第 3 部分“Process choreography and business state machines”（developerWorks，2005 年 7 月）中描述的组合机制）SOA 组件。

组件实现和专用组件类型

开发人员可以选择使用 J2EE、PHP 或其他工具实现基本组件。作为一种编程模型，从根本上讲，SOA 更多地关系到与组件的交互以及如何将这些交互集成到复合组件、应用程序和解决方案。

我们的编程模型还引入了一些定义良好的组件类型，可以建模开发人员生产和部署到解决方案中的常见构件。其中包括 Plain Old Java Objects (POJOs)、Business Processes (BPEL4WS)、Structured Query Language (SQL) 服务、Adaptive Business Objects、通过 J2EE Connector (J2C) 体系结构资源适配器访问的 Customer Information Control System (CICS) 程序、使用 SAP 的业务应用程序编程接口的应用程序、J2EE 无状态会话 Bean 和 IBM MQSeries® 应用程序。

因为在性质上 SOA 组件模型是虚拟的，所以许多 SOA 组件自然支持多种实现技术。另一方面，不同的实现技术更好地适合于不同的任务。为了提高透明度，我们引入了服务组件类型的概念，每种类型都适合于具有特定技能、执行特定任务和使用特定工具的开发人员。对于查询，编程人员实现了一个 SQL 文件和一个包含一组 XQuery 语句的文件；对于文档转换，使用为此任务优化的工具实现 XSLT 样式表等等。不需要知道 Web 服务、Enterprise JavaBean (EJB) 或其他组件是在部署时生成的，这是因为总体结果是作为通用 SOA 组件公开和使用的。

编程人员构建一种适合于该任务的特定组件类型，集中于要解决的问题和要使用的工具，而不是结果构件。SOA 开发工具应该集中于开发人员的技能和他或她理解的概念。后续文章将简要介绍一些组件类型，通过三个完全不同的示例——Java 对象、信息管理系统 (IMS) 事务和 SQL 语句——演示如何将任何实现技术映射到公共 SOA 组件模型，同时满足特定开发人员的需要。

组合

虽然可以使用特定于平台的技术实现 SOA 组合，但是新的以 SOA 为中心的组合类型可以自己实现，而无需转换为另一种编程模型。

使用组合模型，可以发现具有所需的接口和所需的基础设施 (QoS) 策略的服务，并且将这些服务聚合到新的服务、模块和解决方案中。可以组合这些新的服务。

我们的方法统一了创建和访问业务逻辑的范型。我们的 SOA 编程模型比现有的编程构造复杂，隐藏了实现技术之间的不同。在这种模型中，组件组装到模块中，而模块又可以组合到解决方案中。组件公开了可以通过可寻址接口调用的接口。接口是使用 WSDL、Java 或其他语言描述的。实现可能有无法解析的对所需服务的引用，这些服务是执行之前由连接在一起的组件提供的。可以由解决方案集成人员或解决方案组装人员使用适合于角色的工具进行连网操作，他们可以运用可能不为最初开发这些组件的人所知的企业策略和企业服务总线 (ESB) 部署拓扑知识来进行工作。

在没有进行编程的情况下自定义

不可能始终在没有进行配置、自定义或调整的情况下按原样重用服务。在需要更改时，当前的技术发展水平是修改源代码。然而，是否能够交付可以大量重用的组件在很大程度上取决于组件适应其使用环境的功能。SOA 编程模型应该支持构建“编程人员”可以在没有修改源代码的情况下进行自定义的服务和模块。当使用组件的编程人员与构建组件的编程人员不在一个单位时，这一点尤为重要。

基于组件的 SOA 编程模型提供了几种在没有进行编程的情况下自定义组件的机制。

旨在重用的组件可以打包成具有可变点 (points of variability) 的模板，在将模板放入解决方案时可以对其做一些调整。这种适应性是我们的编程模型最重要的部分，此外，编程模型还包括规则语言和相关工具，用于给新的用户提供自定义功能。

中介主要用于处理动态消息。通常可以在没有进行编程的情况下组合中介。作为一个多协议构造，企业服务总线发挥了重要的作用，可以将服务组件组合在一起进行无缝交互，另外，还允许在消息的路径中插入称为中介 的组件，以在不改变现有端点的情况下代理服务之间的交互，从而在主要方面解决整个企业范围内的问题，例如审核、记录、路由、不匹配接口的适应性、等效组件的增量替换和安全性。

SOA 编程模型的另一个好处（来源于前面提到的特性）是能够在软件生命周期的不同阶段用一个组件替换另一个组件。通过将声明的接口延迟绑定到支持这些接口的实现可以做到这一点。企业为什么需要替换功能单元，有许多方面的原因。其中最重要的原因可能是减少在大型企业中管理更改的困难。以增量的方式引入更改并且通过遵循定义的接口限制其影响可以提高灵活性。这种做法也适合于松散耦合，而松散耦合常常是大型组织的特征。此外，使用服务组件，有不同的技能、需求和时间安排的组可以以人力资源和系统资源两方面的效率都最高的方式在 IT 基础设施中协同工作，这样企业就可以快速地响应业务级的更改，从而使企业大大获益。

组件定义

我们的 SOA 是由以下规范定义的：

1. 服务规范 以组件提供和使用的一组服务的形式提供了组件的视图。它由以下三组规范定义：
   • 接口，通常是 WSDL portTypes。
   • 策略，记录 QoS 属性，例如事务行为和安全性。
   • 行为描述，例如 BPEL4WS 抽象流程。另一个例子可能是统一建模语言 V2 (UML2) 状态模型，该模型指定了哪些操作对不同的状态和操作所引发的状态事务是有效的。调用方可以通过状态模型计算有效的操作序列。
2. 服务组件实现 是由以下四组规范定义的：
   • 提供的服务规范。
   • 需要的服务规范。
   • 可以在组件上设置以调整或自定义的属性。
   • 为此提供基本支持的属性；更复杂的方案使用可变点和对自定义组件的外部调用。
   • 对所有实现实例都保持不变的容器指示（策略）。
   • 定义组件实现的实现构件（例如 Java 类、BPEL 文档或 XSLT 规则集）。
3. 服务组件（实例）由以下规范定义：
   • 名称。
   • 服务组件实现。
   • 实现的任何属性的值，设置用于调整实例。
   • 任何服务的规范，解析实现需要的服务规范。它们可以是连接组件实例的“网络”，也可以是在运行时执行以查找组件的“查询”，所查找的组件实现相关接口，具有相关的 QoS 策略，并且匹配指定的行为（例如抽象流程或状态模型）。

有两种定义 SOA 组件的基本方法。这些定义可以通过开发工具生成，也可以由开发人员手动创建。

第一种方法是控制文件，顾名思义，控制文件即关联或联接组件的所有部分的文档。例如，控制文件可以引用 WSDL 定义（提供的接口）、实现组件的 Java 类（实现构件）或相关的策略文档（策略断言）。 它们可以是对文件系统、类路径、源代码管理系统或 Web URL 的引用。控制文件方法将多个单独开发的构件聚合在一起组成组件。应用程序开发工具可以帮助定义控制文件。

第二种方法是使用 pragmas，指定相同信息的语言元素，但是包含在单个源文件的主体中。Java 方面的支持正在不断增加（例如，JSR 175 中的 XDoclet 标记），以用 Java 语言编写这些批注部分。但是这种方法尚不支持其他等同的有效 SOA 组件实现技术（如 SQL 或 XQuery 语句集）。每种组件类型都有用于其实现构件的相关源文件格式，例如 Java 文件、状态机或 SQL 文件。IBM WebSphere® Rapid Deployment 中的批注支持可以生成所有组成包含 pragmas 的源文件中的组件的单个元素。例如，Java 源文件中的结构化注释指示哪些 Java 方法将成为所生成的定义组件的服务接口中的 Web 服务操作。

总结

基于组件的编程模型——由面向任务的工具和运行时基础设施支持——是快速采用 SOA 的关键。借助于期望的优势（如新的软件重用方法），专业人员（不必是编程人员）可以在新的业务需求出现时使用 SOA 组件创建新的业务解决方案和改写现有的业务解决方案。

引言

在本系列的第 2 部分中，我讨论了可以如何实现原始应用程序 Web 服务的业务流程并确定系统可以承载的可互操作 SOA 的最大个数，以避免 SOA 过载。在本系列的第 5 部分中，我强调了将业务流程规则作为优化 Web 服务的首要事项的重要性，并给出了一些示例，以说明可以如何减少 Web 请求的数量和执行时间。

在这一部分中，我将讨论基于 XML 的 Web 服务应用程序是如何变得过于庞大的。当大量使用 Web 服务时，这些 Web 服务将阻塞网络通信，从而导致系统过载。为了解决此问题，我将讨论可以如何应用 XML 二进制优化打包 (XOP) 规范（请参阅参考资料）来加速 Web 服务。

此标准草案旨在比当前 XML 解析器更有效地处理 Web 服务。解析器的行为更像解释器，而不是编译器。当解析器读写大型文件（特别是文本格式的大型文件）时，并不能达到其读取较小的文件或计算简单函数时的性能。甚至加密也可能使 Web 服务陷于停顿，因为必须执行复杂的计算才能获得希望的结果。

两个场景

我在第 2 部分中提到，从企业应用程序提取组件，然后将其重新构造为外部 Web 服务，这种做法更为恰当。如果这样，您就可以更改 Web 服务中的代码，而不用重新设计并编译长时间运行的大型复杂应用程序。

第一个 SOA 中经过重新设计而显得更加紧凑的应用程序（请参见图 1）可以通过发送 Web 请求来与第二个 SOA 中的外部企业 MRP（托管资源原型）Web 服务进行动态链接。而 MRP Web 服务又指向第三个 SOA 中的外部企业 CRM Web 服务。客户关系管理 (CRM) Web 服务随后将请求和信息发送到该应用程序以进行进一步处理。

让我们假定在任何给定时间都可能出现对多个基于 XML 的 Web 服务的多个 Web 请求。链接到其他遗留系统或大型企业系统的企业应用程序未在上图中显示，而这些系统又与接收多个 Web 请求的多个 Web 服务链接。当大量使用时，Web 服务会变得过于庞大，从而阻塞网络通信。

一个解决方案就是向基于 XML 的 MRP 和 CRM Web 服务应用 XOP 包（请参见图 2），从而以二进制格式进行处理。

在第二个场景中，可以首先开发业务流程规则，然后开发根据现有 Web 服务构建新的 Web 服务所需的基于 XML 的 Web 请求。如果新的 Web 服务（业务逻辑 Web 服务或以数据为中心的 Web 服务）可以提供更好的或额外的服务和功能，则必须减少或完全消除冗余的 Web 请求、执行时间、访问时间和带宽。

问题在于，当创建新的 Web 服务并大量使用时，它们将会变得过于庞大。与第一个场景类似，您需要将 XOP 包应用于 Web 服务。对于这两个场景，您都需要与系统管理员协作，以确定在不引起系统过载的情况下可以使用 XOP 包的 Web 服务的最大数目。

XOP 处理前的 Infoset

为了理解 XOP 的工作方式，我将首先讨论一个与 SOAP 消息相似的 XML Infoset，其中描述了包含一张图片和一个签名的 XML 文档。在清单 1 中，我使用粗体来突出显示原始 XML Infoset，以说明哪些原始元素在 XOP 处理之前。

												
																		

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope' 
    xmlns:xop='http://www.w3.org/2003/12/xop/include' 
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
    
      
														
																
																		
																				<m:photo xmlmime:content-type='image/png'>
        /aWKKapGGyQ=
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        Faa7vROi2VQ=
      </m:sig>
																		`
      
    </m:data>
  </soap:Body>
</soap:Envelope>
  

														
												
										

正如您所看到的，其中有两个元素：m:photo 和 m:sig。m:photo 元素采用 base64 编码的内容为 /aWKKapGGyQ=，而 m:sig 元素采用 base64 编码的内容为 Faa7vROi2VQ=。这些元素也称为元素信息项。内容是元素的子项。请将该元素当作此子项的父项。子项是字符信息项，即包含字母数字字符的项。例如，m: photo 是子项 /aWKKapGGyQ= 的父项。该子项的名称不便阅读且难于发音，很容易出现键入错误。

当通过 XOP 处理放置 XML Infoset 时，可以解决此问题。XOP 的工作方式是：从原始 Infoset 提取优化内容，然后创建 XOP Infoset。优化内容是我刚刚谈到的经过缩减的内容。在清单 2 中，我突出显示了要删除的内容。

												
																		

<m:photo xmlmime:content-type='image/png'>
        /aWKKapGGyQ=
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>`
        Faa7vROi2VQ=
      </m:sig>


												
										

XOP 处理后的 Infoset

XOP 处理涉及到三个步骤。第一步，使用 Infoset 中的二进制元素替换文本元素。第二步，在包含已替换元素的 Infoset 前添加 MIME 包。第三步，在该 Infoset 后添加另一个包。

第 1 步：替换元素

XOP 包使用名为 xop:Include 的新元素信息项来替换删除的内容。xop: Include 元素包含一个属性信息项，带有指向 XOP 包部分的链接，XOP 包承载从原始元素中删除的数据的二进制表示。在清单 3 中，我突出显示了替换原始 Infoset 中的图片和签名元素的内容的 xop: Include。

												
																		
 <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
       
 
												
										

正如您所看到的， href='cid:http://example.org/me.png'/ 是图片元素的属性信息项，而 href='cid:http://example.org/my.hsh' 是签名元素的属性信息项。

更新 Infoset 部分（请参见清单 4）。而行数保持不变。

												
																		
<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xop='http://www.w3.org/2003/12/xop/include'
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

												
										

第 2 步：在 Infoset 前添加 MIME 包

为了完成更新，需要使用 MIME Multipart/Related 包中的 XOP 对原始 Infoset 进行序列化。XOP 是一种更有效的方法，用于序列化包含特定类型的 Xquery 和 Xpath 2.0 元素内容的 XML Infoset。

在更新后的 Infoset 前后各添加一个 MIME 包，以分别描述包含文本格式和二进制格式的图片和签名的 XML 文档。在清单 5 中，我突出显示了 XOP 包识别 8 位文本格式的 XML Infoset 的代码。

												
																		
 MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
	      type=text/xml;start="<mymessage.xml@example.org>"
Content-Description: An XML document with my picture and signature in it

--MIME_boundary

														
																
																		
																				Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
																		
Content-ID: mymessage.xml@example.org

 
														
												
										

第 3 步：在 Infoset 后添加 MIME 包。

清单 6 显示了 XOP 包如何识别已被删除的数据的二进制表示。

												
																		
  --MIME_boundary

														
																
																		
																				Content-Type: image/png
Content-Transfer-Encoding: binary
																		
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary

														
														
																
																		
																				Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
																		
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--
      
  
														
												
										

正如您所看到的，Infoset 后的 Content-ID 的二进制内容，xop: Include element 中提到的链接代替了 Infoset 前的消息的文本内容。

最终结果

在清单 7 给出了序列化为 XOP 包的整个 XML Infoset。尽管其中还有其他行，但是此包比原始 Infoset 的 XML 解析器的效率高得多。

												
																		

MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
	      type=text/xml;start="<mymessage.xml@example.org>"
Content-Description: An XML document with my picture and signature in it

--MIME_boundary
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-ID: <mymessage.xml@example.org>

<soap:Envelope
    xmlns:soap='http://www.w3.org/2003/05/soap-envelope'
    xmlns:xop='http://www.w3.org/2003/12/xop/include'
    xmlns:xmlmime='http://www.w3.org/2004/06/xmlmime'>
  <soap:Body>
    <m:data xmlns:m='http://example.org/stuff'>
      <m:photo xmlmime:content-type='image/png'>
        <xop:Include href='cid:http://example.org/me.png'/>
      </m:photo>
      <m:sig xmlmime:content-type='application/pkcs7-signature'>
        <xop:Include href='cid:http://example.org/my.hsh'/>
      </m:sig>
    </m:data>
  </soap:Body>
</soap:Envelope>

--MIME_boundary
Content-Type: image/png
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/me.png>

// binary octets for png

--MIME_boundary
Content-Type: application/pkcs7-signature
Content-Transfer-Encoding: binary
Content-ID: <http://example.org/my.hsh>

// binary octets for signature

--MIME_boundary--
        

												
										

结束语

为了运行具有 XOP 包的 Web 服务，需要事先进行计划，以确定应该如何设计应用程序，从而避免高峰时过载。应该就优化 Web 服务时应采用何种编码技术与系统管理员团队进行沟通。

您会发现解决这些问题后，您的 Web 服务应用程序优化工作变得容易得多。您可以使用 IBM Relational Web Developer for WebSphere® Software 来开发基于业务流程的 Web 服务，然后在 SOA 内部及各个 SOA 之间将其与 XOP 包一起使用。管理员会发现，解决了这些问题也使得他们的网络管理工作变得更加轻松。他们能确定在不引起系统过载的前提下，可以将多少应用程序与 XOP 包一起使用。

引言

在本系列第 4 部分“使用 Rational 开发工具构建 SOA 中间件应用程序”（请参阅参考资料）一文中，我讲解了如何使用 Web 开发工具创建 SOA 中间件应用程序。在本系列第 5 部分“使用 WebSphere Business Integration 工具优化 Web 服务应用程序”（请参阅参考资料）一文中，我讲解了如何使用业务流程工具集成和优化 Web 服务应用程序。在第 5 部分，我还讲解了减少 Web 请求数量、执行时间、访问时间和带宽量的方法，这些方法都可以用来优化 Web 服务应用程序。

在本文中，我介绍了负载应用程序的某些问题如何影响了 Web 服务应用程序间的互操作方式。文中包含了一个流量瓶颈的实例，导致该瓶颈的原因是：在特定期间有太多的访问者基于业务流程发送了太多的请求到一个 Web 服务应用程序。接着又讲了如何从负载平衡技术中获益。

请记住，Web 请求与访问者的请求是不同的。Web 请求的数量不仅依赖于访问者的请求数量，也依赖于由访问者请求生成的、已优化的 Web 请求的类型和内容。

响应迟缓

为了更好地认清这种差异，请看接下来的这个实例。如果某个访问者在将请求通过 Web 服务发送到一台服务器后等了很久才得到回复，那么该访问者很可能为了获得更快的响应时间而转向使用另一种 Web 服务或网站。该始发端 Web 服务将处理传入的访问者请求，以生成并优化传输到目标 Web 服务的 Web 请求。

始发端 Web 服务响应迟缓，可能表明目标服务器繁忙，或是没有足够的系统空间来处理多个访问者请求（多线程处理）。处理这种负载问题的方法之一是平衡服务器间的负载，这样访问者就不会为得到答复而等待太久。这种技术称为负载平衡。

加快响应

平衡服务器间负载要优于外包 Web 服务，负载平衡技术不仅全面考虑到增加的服务器容量、改善的站点设计和使用独立磁盘冗余阵列（Redundant Array of Independent Disk，RAID）的能力，而且也提供了处理预期高峰流量所需的带宽。在服务器的长期运行中，它们会消耗更多的服务器资源。通过使用负载平衡技术，我们有更好的机会来提高服务器的性能和可靠性，并同时减少带宽量、执行时间和访问时间（假定服务器中包含故障转移机制 ）。

由于上述原因，负载平衡技术成为了大多数公司在处理大流量时（尤其在高峰流量期间经受服务器停滞时）的首选技术。这些公司希望更快地响应用户需求，从而在较短的时间内完成更多的工作任务。

您可以将负载路由到域名系统中不同的服务器主机地址，或者将一台服务器要处理的工作总量分摊到两台或多台服务器上。您不仅需要使用另外一台服务器智能化地选择出将工作分配给哪台服务器，还需要使用故障转移和备份服务将这些服务器联合到一起，以防某台服务器出现故障（尤其当服务器集散于不同地理位置时）。

类比购物车

作为一个类比，请把负载平衡服务器看为超市的 4 个付款台。让我们瞧瞧超市是如何在 4 个付款台间实现“负载平衡”的。

假设您排在 1 号付款台前的长队中，您可以粗略地估算出大概需要多久时间才能排到自己付款。如果您发现这条队伍移动缓慢，而且此时看到一名收银员走向 4 号付款台打开机器准备工作，那您一定会推着购物车快速地跑到 4 号付款台（请参见图 1）。

接着又有一名收银员打开了 3 号付款台，并挥手示意第一队排在您前面的购物者到 3 号付款台排队。这些购物者当然会移到 3 号付款台。2 号付款台此时仍然保持关闭状态。

减少服务时间

让我们看看另一种负载平衡方式。如果您推着一辆满满的购物车，里面装着您一家十口一个月的杂货，您可能希望将货物分给多个付款台结帐。在没有家人陪同的情况下，这种想法尤为强烈。您可以将购物车中的物品分为几份，然后分从几个清闲可用的付款台结帐，这样就减少了付款时间。

虽然这在实际生活中是不可能的，但您可以使用负载平衡器实现类似的目的，它能把在线购物车（Web 服务应用程序）的请求从繁忙的服务器上转移到其他清闲可用的服务器上（请参见图 2）。如果其他服务器通过优化可以满足服务需求，就没必要再启用新服务器。

问题

您该怎样解决该问题？更快地跑到付款台前（增加带宽）？增加付款台数量（增加服务器容量）？找其他人帮您买（外包）？这些方法都不适用。

请您回答以下这些问题：

• 您将要平衡哪种应用程序的负载？
• 在整个分布式网络中，该应用程序是否为长期运行？
• 一台服务器或一个服务器集群超时接收了多少请求？
• 在高峰流量期间，需要多少流量和带宽量？
• 怎样利用服务器平衡应用程序负载？
• 在不同时段，预计有多少访问者？
• 访问者最多能够发送多少请求？

在您答完这些问题后，请与一名网络管理员或系统管理员检查和整理这些答案，以促进相互了解。然后使用某种算法、技术或工具开发一个负载平衡程序，实现将繁忙的服务器上的访问者和 Web 请求重定向到清闲可用的服务器上。

负载平衡技术

负载平衡技术包括以下几种：

• 简单路由
• DNS Round Robin
• 复杂算法
• 智能路由

由于实际工作中的流量需要按优先级处理，所以在开发 Web 服务应用程序时，请考虑上述技术中的最后两种技术。因为包含要求更快响应的服务器和访问者的分布式网络正在不断地扩张。由于前两种技术不需要按流量的优先级进行处理，所以我们将不在有关流量瓶颈的问题中讨论它们。

当您使用复杂算法时，分发请求是基于服务器性能、服务器使用的硬件种类和处理客户优先级的方法等等。这表明，最快的服务器将获得更多具有最高客户优先级的请求。智能路由基于请求的内容和（在始发端服务器发生故障时）流量重定向到另一台服务器的方式。

基于服务器的软件

虽然您可以使用软件、硬件或两者来达到负载平衡，但您最好还是在应用程序服务器集群上使用基于服务器的软件。基于服务器的软件的价格要远低于基于硬件的专用服务器。硬件升级的价格要远高于相应软件升级的价格。

在将基于服务器的软件添加到网络中之前，请检查网络是否配置正确，负载平衡器是否“灵活”。“灵活”在这里的解释是：虽然负载平衡器可能已为目前的 Web 服务应用程序做好了充分的配置，但它还必须能够通过扩展满足未来应用程序的需求。

IBM WebSphere Application Server 就是一款基于服务器的软件，它在负载平衡和故障转移中同时使用了复杂算法和智能路由。它的负载平衡器有能力根据 Web 服务应用程序的未来需求进行扩展。您需要为负载平衡建立一个服务器集群，并测试其故障转移机制（请参阅参考资料）。

面向多平台的 WebSphere Edge Server V2.0 是另一款基于服务器的软件。它专门设计用于改善服务器选择、负载优化和容错。它还附带了网络地址转换（Network Address Translation，NAT）和用于 Cisco CSS 交换机的 WebSphere Edge Server Consultant，并且支持内核级的基于内容路由（Content Based Routing，CSR）。（请参阅参考资料）

结束语

Web 服务应用程序的负载平衡需要提早计划，以确定在高峰流量期间如何在服务器间平衡负载。在设计 Web 服务的过程中，请多与系统管理员交流负载平衡技术相关的问题。

解决这些问题能使您更容易地创建负载平衡的 Web 服务应用程序。您可以在 SOA 内部（或跨 SOA）基于业务流程开发 Web 服务和平衡 Web 服务负载。解决这些问题还能使管理员更容易地平衡 Web 服务应用程序的负载，并确定在 SOA 中使用哪种负载平衡方法，以及能够平衡多少应用程序的负载。

1. 什么是架构？什么是基于SOA的架构？

1．1 什么是架构

从架构设计师的角度来看，架构就是一套构建系统的准则。通过这套准则，我们可以把一个复杂的系统划分为一套更简单的子系统的集合，这些子系统之间应该保持相互独立，并与整个系统保持一致。而且每一个子系统还可以继续细分下去，从而构成一个复杂的企业级架构。

当一名架构设计师在构建某个企业级的软件系统时，除了要考虑这个系统的架构以及其应具有的功能行为以外，还要关注整个架构的可用性，性能问题，容错能力，可重用性，安全性，扩展性，可管理维护性，可靠性等各个相关方面。有的时候一名好的架构设计师甚至还需要考虑所构建的系统架构是否合乎美学要求。由此我们可以看到，我们衡量一个好的架构设计并不能只从功能角度出发，还要考虑很多其他的因素，对任何一个方面的欠缺考虑都有可能为整个系统的构建埋下隐患。

1．2 什么是基于SOA的架构

SOA本身就是一种面向企业级服务的系统架构，简单来说，SOA就是一种进行系统开发的新的体系架构，在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是service）组合构建起来的。因此，基于SOA的架构也一定是从企业的具体需求开始构建的。但是，SOA和其它企业架构的不同之处就在于SOA提供的业务灵活性。业务灵活性是指企业能对业务变更快速和有效地进行响应、并且利用业务变更来得到竞争优势的能力。对企业级架构设计师来说，创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的IT架构。

利用基于SOA的系统构建方法，如图1中所示的一样，一个基于SOA架构的系统中的所有的程序功能都被封装在一些功能模块中，我们就是利用这些已经封装好的功能模块组装构建我们所需要的程序或者系统，而这些功能模块就是SOA架构中的不同的服务（services）。

因此，SOA架构本质上来说体现了一种复合的概念：它不仅为一个企业中商业流程的组织和实现提供了一种指导模式，同时也为具体的底层service开发提供了指导。

2. SOA架构设计师的角色

2．1 SOA架构设计师应该具备什么？

谈到SOA架构设计师的角色，我们首先要了解架构设计师应具有的能力。总体上来说，一个好的架构设计师不仅应该是一个成熟的，具有实际经验的并具有快速学习能力的人，而且他还应该具有良好的管理能力和沟通能力。只有具备了必需的能力，架构设计师才能在关键的时刻作出困难的决定，这就是一名架构设计师应该承担的责任。从角色上来看，SOA 架构师不仅会负责端到端的服务请求者和提供者的设计，并且会负责对系统中非功能服务请求的调研和表述。

对于任何一名经验丰富的架构设计师来说，不论他是采用基于传统的架构设计方法（基于J2EE架构或者.NET架构）还是采用基于SOA的架构设计方法来构建一个企业级的系统架构，具有相关商业领域的知识对于架构设计师来说都是必不可少的，架构设计师往往可以通过实际的工作经验积累以及接受相关的专项培训来获得这些商业领域的知识。除了具有相关商业领域的知识以外，一名合格的架构设计师必须具有较广泛的技术背景，这可能包括软硬件，通信，安全等各个方面的知识。但这并不是意味着要成为一名架构设计师就必须熟悉每一门具体技术的细节，架构设计师必须至少能对各种技术有一个整体上的了解，能够熟知每种技术的特点以及优缺点，只有这样架构设计师才能在特定的应用场景下正确地选择各种技术来设计企业整体架构。

2．2 什么是SOA架构设计师的职责？

那什么是企业级SOA架构设计师的具体角色呢？什么是SOA架构设计师与设计和开发人员之间的差别呢？相信这些都是使大家最容易产生迷惑的问题。举个实际的例子来说，当构建一个基于SOA架构的系统的时候，针对一个具体的 service，系统设计人员主要应该关注的是这个service能够为外部用户提供什么样的服务，也就是说系统设计人员关注的是这个service所提供的功能。而对于SOA架构设计师来说，他们更关心的可能是当有一千个用户同时调用这个 service的时候，什么会发生？也就是说架构设计师关注的应该是一些商业需求和服务级别（service-level）需求。所有的架构设计师的角色都包含了在构建一个系统的一开始就应该尽量减少可能存在的技术风险。而技术风险一般指的是一切未知的、未经证明的或未经测试所带来的风险。这些风险通常与服务级别（service-level）需求相关，偶尔也会与企业具体的业务需求相关。无论是哪种类型的风险，在项目初期设计整体系统架构的过程中更易于发掘这些风险，如果等到架构实施时再发觉这些风险，那么很可能会致使大量的开发人员等在那里，直到这些风险被妥善解决。如果进一步的细化，我们可以看到SOA架构设计师的主要任务包括对整个系统解决方案轮廓的构建，需求分析，对体系结构的整体决策，相关组件建模，相关操作建模，系统组件的逻辑和物理布局设计。

作为SOA架构设计师必须要能够领导整个开发团队，这样才能保证设计和开发人员是按照构建好的系统架构来开发整个系统的，这一点十分的重要。这就要求一名架构设计师不仅要有很好的技术洞察力，同时还要具有一定的项目管理和项目实施的能力。在系统开发的过程中，架构设计师必须要有良好的沟通和表达能力，这就体现在由架构设计师构建的系统模型是否具有很好的可读性和易理解性。如果由架构设计师构造出的系统模型不是很清晰的话，就可能会影响设计和开发人员对于整个系统架构的理解。为了避免这种情况的出现，定期由架构设计师主持的开发团队内部讨论是十分重要的。

3. 构建SOA架构时应该注意的问题

3．1 原有系统架构中的集成需求

当架构师基于SOA来构建一个企业级的系统架构的时候，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。我们都知道，面向服务的体系结构是当前及未来应用程序系统开发的重点，面向服务的体系结构本质上来说是一种具有特殊性质的体系结构，它由具有互操作性和位置透明的组件集成构建并互连而成。基于SOA的企业系统架构通常都是在现有系统架构投资的基础上发展起来的，我们并不需要彻底重新开发全部的子系统；SOA可以通过利用当前系统已有的资源（开发人员、软件语言、硬件平台、数据库和应用程序）来重复利用系统中现有的系统和资源。SOA是一种可适应的、灵活的体系结构类型，基于SOA构建的系统架构可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。因此，当SOA架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统，因为如果考虑到有限的预算，整体系统替换的成本是十分高昂的。

当SOA架构师分析原有系统中的集成需求的时候，不应该只限定为基于组件构建的已有应用程序的集成，真正的集成比这要宽泛得多。在分析和评估一个已有系统体系结构的集成需求时，我们必须考虑一些更加具体的集成的类型，这主要包括以下几个方面：应用程序集成的需求，终端用户界面集成的需求，流程集成的需求以及已有系统信息集成的需求。当SOA架构师分析和评估现有系统中所有可能的集成需求的时候，我们可以发现实际上所有集成方式在任何种类的企业中都有一定程度的体现。针对不同的企业类型，这些集成方式可能是简化的，或者没有明确地进行定义的。因而，SOA架构师在着手设计新的体系结构框架时，必须要全面的考虑所有可能的集成需求。例如，在一些类型的企业系统环境中可能只有很少的数据源类型，因此，系统中对消息集成的需求就可能会很简单，但在一些特定的系统中，例如航运系统中的EDI（Electronic Data Interchange 电子数据交换）系统，会有大量的电子数据交换处理的需求，因此也就会存在很多不同的数据源类型，在这种情况下整个系统对于消息数据的集成需求就会比较复杂。因此，如果SOA架构师希望所构建的系统架构能够随着企业的成长和变化成功地继续得以保持，则整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成。

3．2 服务粒度的控制以及无状态服务的设计

当SOA架构师构建一个企业级的SOA系统架构的时候，关于系统中最重要的元素，也就是SOA系统中的服务的构建有两点需要特别注意的地方：首先是对于服务粒度的控制，另外就是对于无状态服务的设计。

服务粒度的控制

SOA系统中的服务粒度的控制是一项十分重要的设计任务。通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。从技术上讲，粗粒度的服务接口可能是一个特定服务的完整执行，而细粒度的服务接口可能是实现这个粗粒度服务接口的具体的内部操作。 举个例子来说，对于一个基于SOA架构的网上商店来说，粗粒度的服务可能就是暴露给外部用户使用的提交购买表单的操作，而系统内部的细粒度的服务可能就是实现这个提交购买表单服务的一系列的内部服务，比如说创建购买记录，设置客户地址，更新数据库等一系列的操作。虽然细粒度的接口能为服务请求者提供了更加细化和更多的灵活性，但同时也意味着引入较难控制的交互模式易变性,也就是说服务的交互模式可能随着不同的服务请求者而不同。如果我们暴露这些易于变化的服务接口给系统的外部用户，就可能造成外部服务请求者难于支持不断变化的服务提供者所暴露的细粒度服务接口。而粗粒度服务接口保证了服务请求者将以一致的方式使用系统中所暴露出的服务。虽然面向服务的体系结构（SOA）并不强制要求一定要使用粗粒度的服务接口，但是建议使用它们作为外部集成的接口。通常架构设计师可以使用BPEL来创建由细粒度操作组成的业务流程的粗粒度的服务接口。

无状态服务的设计

SOA系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态，即SOA架构中的服务应该是无状态的服务。当某一个服务需要依赖时，我们最好把它定义成具体的业务流程（BPEL）。在服务的具体实现机制上，我们可以通过使用 EJB 组件来实现粗粒度的服务。我们通常会利用无状态的Session Bean来实现具体的服务，如果基于Web Service技术，我们就可以将无状态的Session Bean暴露为外部用户可以调用的到的Web服务，也就是把传统的Session Facade模型转化为了 EJB 的Web服务端点，这样，我们就可以向 Web 服务客户提供粗粒度的服务。

如果我们要在 J2EE的环境下（基于WebSphere）构建Web服务，Web 服务客户可以通过两种方式访问 J2EE 应用程序。客户可以访问用 JAX-RPC API 创建的 Web 服务（使用 Servlet 来实现）；Web 服务客户也可以通过 EJB的服务端点接口访问无状态的Session Bean，但Web 服务客户不能访问其他类型的企业Bean，如有状态的Session Bean，实体Bean和消息驱动Bean。后一种选择（公开无状态 EJB 组件作为 Web 服务）有很多优势，基于已有的EJB组件，我们可以利用现有的业务逻辑和流程。在许多企业中，现有的业务逻辑可能已经使用 EJB 组件编写，通过 Web 服务公开它可能是实现从外界访问这些服务的最佳选择。EJB 端点是一种很好的选择，因为它使业务逻辑和端点位于同一层上。另外EJB容器会自动提供对并发的支持，作为无状态Session Bean实现的 EJB 服务端点不必担心多线程访问，因为 EJB 容器必须串行化对无状态会话 bean 任何特定实例的请求。 由于EJB容器都会提供对于Security和Transaction的支持，因此Bean的开发人员可以不需要编写安全代码以及事务处理代码。 性能问题对于Web服务来说一直都是一个问题，由于几乎所有 EJB 容器都提供了对无状态会话 Bean 群集的支持以及对无状态Session Bean 池与资源管理的支持，因此当负载增加时，可以向群集中增加机器，Web 服务请求可以定向到这些不同的服务器，同时由于无状态Session Bean 池改进了资源利用和内存管理，使 Web 服务能够有效地响应多个客户请求。由此我们可以看到，通过把 Web 服务模型化为 EJB 端点，可以使服务具有更强的可伸缩性，并增强了系统整体的可靠性。

4. 结束语

本文简要介绍了有关架构设计师以及SOA架构的知识，分析了SOA架构师在设计SOA系统架构时有哪些应该特别注意的地方。

本文的第二部分将向您介绍在构建基于SOA架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度，SOA是一种新的设计模式，方法学。因此，SOA本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的SOA系统开发设计人员起到一定的帮助作用。

1． SOA 为企业级架构设计带来的影响

1．1 SOA 的特点及其使用范围

SOA 既不是一种语言，也不是一种具体的技术，它是一种新的软件系统架构模型。 SOA 最主要的应用场合在于解决在Internet环境下的不同商业应用之间的业务集成问题。Internet环境区别于Intranet环境的几个特点主要是：

(a)大量异构系统并存，不同计算机硬件工作方式不同，操作系统不同、编程语言也不同；

(b)大量、频繁的数据传输的速度仍然相对较缓慢并且不稳定；

(c)无法完成服务（service）的版本升级，甚至根本就无法知道互联网上有哪些机器直接或者间接的使用某个服务。

SOA 架构具有一些典型特性，主要包括松耦合性，位置透明性以及协议无关性。松耦合性要求 SOA 架构中的不同服务之间应该保持一种松耦合的关系，也就是应该保持一种相对独立无依赖的关系；位置透明性要求 SOA 系统中的所有服务对于他们的调用者来说都是位置透明的，也就是说每个服务的调用者只需要知道他们调用的是哪一个服务，但并不需要知道所调用服务的物理位置在哪里；而协议无关性要求每一个服务都可以通过不同的协议来调用。通过这些 SOA 架构所具有的特性我们可以看到，SOA 架构的出现为企业系统架构提供了更加灵活的构建方式，如果企业架构设计师基于 SOA 来构建系统架构，就可以从底层架构的级别来保证整个系统的松耦合性以及灵活性，这都为未来企业业务逻辑的扩展打好了基础。

1．2 SOA 架构的分层模型

接下来简要介绍一下 SOA 系统中的分层模型，整个 SOA 架构的分层模型如图2所示。

在 SOA 系统中不同的功能模块可以被分为7层：第一层就是系统已经存在的程序资源，例如ERP或者CRM系统等。第2层就是组件层，在这一层中我们用不同的组件把底层系统的功能封装起来。第3层就是 SOA 系统中最重要的服务层，在这层中我们要用底层功能组件来构建我们所需要的不同功能的服务。总的来说，SOA 中的服务可以被映射成具体系统中的任何功能模块，但是从功能性方面可以大致划分为以下三种类型：(1)商业服务（business service） 或者是商业过程（business process）。这一类的服务是一个企业可以暴露给外部用户或者合作伙伴使用的服务。比如说提交贷款申请，用户信用检查，贷款信用查询。(2)商业功能服务（business function service）， 这类服务会完成一些具体的商业操作，也会被更上层的商业服务调用，不过大多数情况下这类服务不会暴露给外部用户直接调用，比如说检索用户帐户信息，存储用户信息等。(3)技术功能服务（technical function service），这类服务主要完成一些底层的技术功能，比如说日志服务以及安全服务等。在服务层之上的第4层就是商业流程层，在这一层中我们利用已经封装好的各种服务来构建商业系统中的商业流程。在商业流程层之上的就是第5层表示层了，我们利用表示层来向用户提供用户接口服务，这一层可以用基于portal的系统来构建。以上这5层都需要有一个集成的环境来支持它们的运行，第6层中的企业服务总线（ESB）提供了这个功能。第7层主要为整个 SOA 系统提供一些辅助的功能，例如服务质量管理，安全管理这一类的辅助功能。

2． SOA 架构中的非功能性服务级别（service-level）需求

除了系统的业务需求，架构设计师还必须要保证构建出来的系统架构能够满足系统中的非功能性服务级别（service-level）需求以及服务质量（QoS）方面的需求。在项目初始及细化阶段，架构设计师应该与系统所有涉及方（Stakeholders）一起，为每一个服务级别需求定义其相关的衡量标准。构建出的系统架构必须要能满足以下几方面的服务水准要求：性能、可升级性、可靠性、可用性、可扩展性、可维护性、易管理性以及安全性。架构设计师在设计架构过程中需要平衡所有的这些服务级别需求。例如，如果服务级别需求中最重要的是系统性能，架构设计师很有可能不得不在一定程度上牺牲系统的可维护性及可扩展性，以确保满足系统性能上的要求。随着互联网的发展，新构建的系统对于服务级别需求也变得日益重要，现在基于互联网的企业系统的用户已经不仅仅局限于是本企业的雇员，企业的外部客户也会成为企业系统的主要用户。

架构设计师的职责之一就是要尽可能地为提高系统设计人员和系统开发人员的工作效率考虑。在构建整个企业系统架构的过程中，需要充分重视各种服务级别需求，从而避免在系统开发和运行的时候出现重大问题。一个企业级系统中的服务级别需求往往是十分错综复杂的， SOA 架构设计师需要凭借丰富的专业经验和扎实的理论知识来分离和抽象系统中不同的服务级别需求，图3展示了这种分析的过程。

经过 SOA 架构设计师分析和抽象的服务级别需求主要分为以下几类：

• 性能是指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等；
• 可升级性是指当系统负荷加大时，能够确保所需的服务质量，而不需要更改整个系统的架构；
• 可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力；
• 可用性是指一个系统应确保一项服务或者资源永远都可以被访问到；
• 可扩展性是指在不影响现有系统功能的基础上，为系统填加新的功能或修改现有功能的能力；
• 可维护性是指在不影响系统其他部分的情况下修正现有功能中问题或缺陷，并对整个系统进行维护的能力；
• 可管理性是指管理系统以确保系统的可升级性、可靠性、可用性、性能和安全性的能力；
• 安全性是指确保系统安全不会被危及的能力。

1) 性能

我们通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能；另外，我们也可以通过系统能够处理的交易量（每秒）来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于 SOA 的架构中使用了很多Web Service来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于 SOA 的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。

2) 可升级性

可升级性是指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于 SOA 的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于 SOA 的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。

3) 可靠性

可靠性是指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，你的系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于 SOA 来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于 SOA 架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个 SOA 系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。

4) 可用性

可用性是指一个系统应确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于 SOA 来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持；第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在 SOA 架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的 SOA 系统架构中的关键性业务能具有较高的可用性。

5) 可扩展性

可扩展性是指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素：低耦合，界面(interfaces)以及封装。当架构设计师基于 SOA 来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为 SOA 架构中的不同服务之间本身就保持了一种无依赖的低耦合关系；服务本身是通过统一的接口定义（可以是WSDL）语言来描述具体的服务内容，并且很好地封装了底层的具体实现。在这里我们也可以从一个方面看到基于 SOA 来构架企业系统能为我们带来的好处。

6) 可维护性

可维护性是指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。同系统的可扩展性相同，当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素：低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了 SOA 架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于 SOA 的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口（可以是WSDL）、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为 SOA 架构设计师构建企业 SOA 架构提供很好的文档参考和支持。

7) 可管理性

可管理性是指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求（QoS）的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时， SOA 架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架（Framework）上。对于 SOA 架构设计师来说，可以选择的底层系统框架有很多，可以选用基于MQ, MessageBorker，WebSphere Application Server等产品来构建企业服务总线（Enterprise Service Bus）以支持企业的 SOA 系统架构，也可以选用较新的基于WebSphere Application Server 6中内嵌的Sibus来构建企业的ESB以支持 SOA 系统架构。具体选择哪种底层框架来实施 SOA 系统架构要根据每个系统各自的特点来决定，但这些底层的框架都已经提供了较高的系统可管理性。因此，分析并选择不同的产品或底层框架来实现企业系统架构也是架构设计师的主要职责之一。有关于如何利用已有底层架构来构建 SOA 系统，中国 SOA 设计中心已经发表了一系列相关的文章，大家可以在DeveloperWorks中的 SOA 专栏看到它们。

8) 安全性

安全性是指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当 SOA 架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业 SOA 架构中的一些服务是由Web Service实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为Web Service带来一定的执行效率损耗。

3．结束语

本系列两部分介绍了有关架构设计师以及 SOA 架构的知识，分析了 SOA 架构师在设计 SOA 系统架构时有哪些应该特别注意的地方并在最后简要介绍了在构建基于 SOA 架构的企业系统时应该怎样保证所构建的系统架构能够满足系统中不同的服务级别需求。从架构设计师的角度， SOA 是一种新的设计模式，方法学。因此， SOA 本身涵盖了很多的内容，也触及到了系统整体架构设计、实现、维护等各个方面。本文的内容只是涉及到了有关于架构方面的一部分内容，希望能对广大的 SOA 系统开发设计人员起到一定的帮助作用。

面向服务的体系结构的用户界面

在文献中，对 Web 服务的讨论通常是在程序到程序 (program-to-program) 交互的上下文中进行的。然而，

模型-视图-控制器（Model-View-Controller，MVC）范例是现代大多数 UI 应用程序框架的基础。SOA 操作提供模型层，而 UI 位于视图层。UI 技术可以在各种设备上呈现信息，这些设备包括的范围很广，从窗口小部件和智能电话到浏览器和能够进行大量客户端处理的富客户机。中间件和工具将视图层 UI 技术连接到模型层 Web 服务和数据。

在 SOA 方法中，宿主组件的环境抽象成容器，它提供已知的服务集。从 UI 的角度来说，承载客户端 UI 组件的三个主要的容器是：

• 基本 Web 浏览器。
• 使用 Java™Script 和动态 HTML 增强的 Web 浏览器。
• IBM Workplace™ Client Technology™——具有本地 IBM WebSphere® Application Server 客户机支持的 Eclipse 富客户机。

这些容器可以通过支持下列技术得以增强：Servlet、JavaServer Page (JSP) 和 JSP Tag；用于页面排序的 Struts；用于高级页面组合的 JavaServer Face (JSF)；以及合并在同一页面上的多应用程序视图的 Portlet 技术。

UI 开发框架

UI 开发框架可以简化创建面对用户的复杂应用程序的过程。通常使用下列的 UI 框架来创建 UI 组件：

• Struts，拥有最大的开发人员社区和异常工具支持，是 Apache 开放源代码项目，它早于 Java Portlet 规范 JSR 168（请参阅参考资料以获得 Struts Web 站点的链接）。Struts 是使用 servlet/JSP 范例开发基于服务器的 UI 的多页 MVC 框架。Struts 的一个特殊版本 V1.1 库支持 IBM WebSphere Portal 上的 JSR 168 Portlet。
• JavaServer Faces 是 Java Web 应用程序的 MVC 实现，以增量方式构建于以前的技术之上。它很好地适应了 Portlet 开发，提供 Portlet 和 Servlet、声明处理、确认和事件处理。JSF 页面具有一个或多个与该页面上的 UI 控件交互的本地模型。这些控件将 UI 属性呈现给输出，而复杂的逻辑确保它们的表示是在“正确的”地方。客户端模型可以连入企业服务总线 (Enterprise Service Bus) 来发送和接收事件。
• Java Widget Library (JWL)，是一个可供门户和 Portlet 程序员使用的扩展窗口小部件集，向 JSF 添加 JavaScript 客户端处理，而且将得到 IBM Rational® Suite® DevelopmentStudio 的支持。更新客户机本地视图省去了往返服务器的过程，缩短了几个数量级的响应时间，而且极大地改善了用户体验。

门户 提供了最好的 UI 支持。在门户体系结构中，Portlet（通常是使用上面提到的某种 UI 框架开发的）是基本构件。使用这种体系结构，开发人员可以把主要精力放在他们的应用程序的独特方面，并且将生命周期、每个用户的自定义、聚合以及与其他组件的集成等公共功能委派给中间件。

下面几部分将单个服务和门户的 Portlet 组件描述成服务聚合机制。

面向服务的 UI 的 Portlet

Portlet 组件实现了标准服务接口和协议。Java Portlet 规范和用于远程 Portlet 的 Web 服务（Web Services for Remote Portlet，WSRP）标准分别定义了 Java 和 Web 服务的这个接口（请参阅参考资料以获得更多关于 WSRP 的信息）。这两个标准非常相似，以致如果存在合适的容器或者代理，为任一接口编写的 Portlet 都可互换。

Java Portlet 示例

每个 Java Portlet 都实现了该 Portlet 接口或者扩展了实现它的类。这个接口定义了 Portlet 和它的容器之间的服务约定，以及 Portlet 的生命周期：

• 初始化 Portlet 并将其放入服务中（init 方法）
• 处理请求（processAction 和 render 方法）
• 除去服务的 Portlet（destroy 方法）

在处理请求期间，Portlet 容器调用 Portlet 的：

• processAction 方法来通知 Portlet 用户行为。每个客户机只有一个基于用户的行为被触发。Portlet 可以发出一个重定向、改变它的 Portlet 模式或窗口状态或者更改它的状态。
• render 方法来请求标记片段。

Portlet 还可以调用更多的服务来执行所需的功能。清单 1 示例使用 Web 服务来检索和显示特定用户的股票报价。

												
																		public class StockQuotePortlet extends GenericPortlet {

	private ServiceManager serviceManager;

	public void init(PortletConfig config) throws PortletException {
		serviceManager = new ServiceManager();
	}

	public void doView(RenderRequest request, RenderResponse response) throws PortletException, IOException {
		
        	response.setContentType("text/html");    

        	// invoke autogenerated wrapper to locate service
		NetXmethodsServicesStockquoteStockQuoteServiceLocator loc = 
			new NetXmethodsServicesStockquoteStockQuoteServiceLocator();
		NetXmethodsServicesStockquoteStockQuotePortType port = 
			loc.getNetXmethodsServicesStockquoteStockQuotePort();

		// loop through all stock quotes the user is interested in
		PortletPreferences prefs = request.getPreferences();
		Iterator quoteKeys = prefs.getMap().keys().iterator();
		String key;
		Float quote;
		StockBean quoteBean = new StockBean();
		while ( quoteKeys.hasNext() ) {
			key = quoteKeys.next();
	    		quote =  port.getQuote (key);
			quoteBean.add(key, quote);
		}

		request.setAttribute("StockQuoteBean", quoteBean);

		// render stock quotes using a JSP        
        PortletRequestDispatcher rd = getPortletContext().getRequestDispatcher("jsp/View.jsp");
        rd.include(request,response);

	}
}
			
												
										

这一部分演示了您可以如何使用 Java Portlet 规范来实现 UI 服务，以及您的 Portlet 可以如何调用其他 Web 服务。下一部分将展示如何使用 WSRP 将 UI 作为 Web 服务发布。

用于远程 Portlet 的 Web 服务

WSRP 是远程呈现 Portlet 的标准，使门户能够从多个源聚合内容。WSRP 将 Web 服务的集成能力扩展到面向表示的组件，并将视图层公开为跨平台、实现语言和供应商共享。可以发现内容和应用程序提供者并将其插入遵循标准的应用程序中，而不必进行任何额外的编程工作。

典型的 Web 服务使用远程表示范例，这意味着所有的视图逻辑在客户机上执行，而应用程序逻辑和数据层（控制器和模型）则驻留于服务器上。与此相反，WSRP 使用分布式范例将客户机和服务器的表示分开。

上图展示了这一差异。左边是典型的面向数据的 Web 服务，它提供了无格式的数据；它必须完全依赖于客户端的呈现代码来表示数据。（这意味着需要在客户机上安装和管理客户端应用程序组件。）右边是 WSRP 服务；它的分布式表示逻辑将表示任务分成：

• 生成标记语言。
• 将标记片段聚合成一个 Web 页面（没有显示）。
• 通过标准客户端容器呈现标记语言。

WSRP 示例

清单 2 展示了一个通过简单对象访问协议（Simple Object Access Protocol，SOAP）从 WSRP 使用者发出的 WSRP getMarkup 请求的示例。

												
																		<?xml version="1.0" encoding="UTF-8"?>
   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" 				 
   xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> 
      <soapenv:Body>
         <getMarkup xmlns="urn:oasis:names:tc:wsrp:v1:types"> 
            <registrationContext>
               <registrationHandle>192.168.66.57_1096235652731_0</registrationHandle> 
            </registrationContext>
            <portletContext>
               <portletHandle>0.1</portletHandle>   
            </portletContext>   
            <runtimeContext>    
               <userAuthentication>wsrp:none</userAuthentication>    
               <portletInstanceKey>ProxyTest_row1_col1_p1</portletInstanceKey>    
               <namespacePrefix>Pluto_ProxyTest_row1_col1_p1_</namespacePrefix>   
            </runtimeContext>   
            <userContext>    
               <userContextKey>dummyUserContextKey</userContextKey>   
            </userContext>   
            <markupParams>    
               <secureClientCommunication>false</secureClientCommunication>    
               <locales>en</locales>    
               <locales>de</locales>    
               <mimeTypes>text/html</mimeTypes>    
               <mode>wsrp:view</mode>    
               <windowState>wsrp:normal</windowState>    
               <clientData>     
                  <userAgent>WSRP4J Proxy Portlet</userAgent>    
               </clientData>    
               <markupCharacterSets>UTF-8</markupCharacterSets>    
               <validNewModeswsrp:view</validNewModes>    
               <validNewModes>wsrp:help</validNewModes>    
               <validNewModes>wsrp:edit</validNewModes>    
               <validNewWindowStates>wsrp:normal</validNewWindowStates>>    
               <validNewWindowStates>wsrp:maximized</validNewWindowStates>    
               <validNewWindowStates>wsrp:minimized</validNewWindowStates>   
            </markupParams>  
         </getMarkup> 
      </soapenv:Body>
   </soapenv:Envelope>
 			
												
										

WSRP 生产者对这个请求的响应是 HTML 片段，使用者（通常是门户）可以将其聚合成一个完整的文档，例如门户页面。

不是将每个应用程序或 Portlet 部署到有意使用它的每个服务器上，而是跨网络边界共享应用程序，这具有明显的优势。WSRP 支持：

• 更简单的管理——门户管理员可以浏览要提供的 WSRP 服务的注册中心，而不是管理可插入组件的本地部署。用户受益于及时使用随需应变的新服务和内容集成。
• 负载分配——跨多个服务器分配负载。
• 减少基础设施成本——应用程序可以共享承载的基础设施。例如，只分配后端银行应用程序的表示层（通过 WSRP）保护了应用程序提供者的安全计算环境，而与此同时，用户仍可以与共享的 UI 进行交互。
• 控制内容表示——在门户重新分配内容时，内容和应用程序提供者可以极大地扩展新用户的范围。

门户：面向服务的 UI 的动态集成

门户的视图层将多个后端服务的 UI 集成为一个集中管理的 UI，这样可以统一分离的 IT 基础设施，并通过控制单一的 UI 向用户提供 IT 服务的单一视图。最初分开设计的应用程序可以连接起来构成组合应用程序，用于支持新的功能。例如，连接到协作 Portlet 的电子邮件 Portlet 可以过滤收件箱，使仅当寄件人在线并可以聊天时才显示所收到的电子邮件——这种能力是这两个原始应用程序所不具备的。

这种 portal 模型的重要意义在于改善了随需应变业务 (On Demand Business) 的敏捷性。管理员成为应用程序集成者，定义新的页面，向它们添加 Portlet，将 Portlet 连接在一起并设置权限（访问控制）——不用编程——来创建新的组合应用程序。自服务的门户使用户可以改变他们的工作环境，以适应他们独特的需求。门户体系结构解放了应用程序开发人员，使其能够全神贯注地创造新的业务价值。

将来，门户甚至能够集成组合服务，因而能够在更高的层次上聚合 UI。门户可以无缝地与来自其他门户的内容相集成，从而提供水平的、企业级的内容集成。

总结

使用门户/Portlet 体系结构，将 SOA 概念应用到用户界面，并委派公共的软件生命周期功能给 UI 容器，这改善了软件开发人员的时间价值 (time-to-value)。WSRP 标准通过 Web 服务交付 UI 组件，为内容提供者和内容使用者提供便利，从而在不用进行任何编程的情况下支持某种类型的应用程序集成。

Globus Monitoring 和 Discovery Service

Globus Monitoring 和 Discovery System（MDS）是一组 Web 服务，用来监视和发现网格中的可用资源和服务。顾名思义，人们通常会认为资源发现的过程就是发现新的资源。然而，在网格环境中，资源发现是确定哪些网格资源最适合完成某个任务的过程，要求时间最短，利用资源的效率最高。这个过程是从识别可以满足或超过当前作业需求的资源开始的。这通常是可用资源的某个子集。

接下来，我们需要通过选择最适合的资源来细化这个清单。这个选择过程需要静态和动态的信息。通常，静态信息（例如 CPU 数量、时钟速度、物理内存总量、虚拟内存以及可用磁盘空间）可以帮助确定哪些资源能够满足或超过任务的需求。在细化这个清单时，也要考虑一些动态信息。动态信息包括可用 CPU 的个数，队列中等待执行的作业个数，当前资源的利用率。现在这已经成为一个调度问题，必须考虑业务策略、优先级和服务级别协定（SLA）。

调度并不是本文的重点，因此让我们保留整个主题改天再来讨论。Globus MDS 提供了有关资源的信息，这样就可以制定智能的调度决策，从而最好且最有效地利用可用资源。MDS 也可以监视资源，在状态发生变化时通知感兴趣的团体，并根据预先定义的条件采取行动。

Index 和 Trigger Service

我们对 MDS 所搜集到的有关资源的状态进行监视。搜集这些信息的 MDS 服务称为 Index Service。MDS Index Service 的工作方式与注册表非常相似。它搜集信息，然后将其作为资源属性发布。它通过一个 Web 服务接口将所搜集的信息提供给客户机。客户机可以向 MDS 查询信息，或者订阅所感兴趣的资源属性，即表明如果这些属性的值发生了变化，它们非常乐于被及时通知。这些信息代表了资源属性的配置和状态。Globus MDS 可以监视资源，并跟踪所选择的资源属性。它可以通知订阅者属性值发生了变化。

这种功能是由另外一个名为 Trigger Service 的 MDS 服务提供的。它与 MDS Index Service 类似，都要从资源中搜集数据，但是它同时还要对所搜集的数据进行监视，这样就可以在数据到达某个极限值时执行某些预定的操作。Trigger Service 的配置就是订阅某些属性，并指定当某个属性值达到某个预定的极限时应该采取什么操作。要采取的操作可以非常复杂，例如当利用率太高时提供更多资源；也可以非常简单，例如通知系统管理员某个文件系统已经满了。MDS Trigger Service 通过 Web 服务提供此功能。客户机使用这个 Web 服务来注册触发器事件。为了进行注册，客户机要提供程序的名字、一个 XPath 查询表达式以及一个值。当 XPath 查询所返回的值等于注册时所提供的值时，就运行这个程序。MDS Trigger Service 通过对所搜集到的信息和在 MDS Trigger Service 注册和配置文件中所指定的条件进行比较，来提供这种功能。

												
																		
$GLOBUS_LOCATION/etc/globus_wsrf_mds_trigger/trigger_registration_aggregation.xml

												
										

这个配置文件使用 XPath 查询表达式的格式定义了一些规则。每个规则都有一个当满足该条规则时所要执行的操作，以及该操作重复的频率。下面这个例子实现了触发器规则、相关操作以及频率的语法，这些都是在前面的触发器注册和配置文件中指定的。

												
																		
       <trigger:TriggerRuleType>
          <trigger:matchingRule>//*[local-name()='GLUECE']</trigger:matchingRule>
          <trigger:actionScript>glue-trigger-action.sh</trigger:actionScript>
          <trigger:minimumFiringInterval>600</trigger:minimumFiringInterval>
       </trigger:TriggerRuleType>

												
										

MDS Aggregation Framework

MDS Index 和 Trigger Service 都是在 MDS Aggregation Framework 之上构建的。MDS Aggregation Framework 用来构造搜集和聚集数据的高层服务。这些聚集器服务将从各种资源搜集来的信息汇集到一个集中的位置。这个概念的范围很广，从在某个容器中运行的所有服务的集中注册表，到一个网格范围的 Index Service，这可以通过配置 Index Service 与其他 Index Service 一起来存放内容。Index Service 可以按照一种层次化的方式进行配置，上层可以从底层的 Index Service 中提取信息。上层 Index Service 可以当作是这个层次中的上游资源，底层 Index Service 可以当作是下游资源。Index Service 在这个层次中的位置是在层次配置文件中使用上游和下游服务这两个术语进行定义的。

												
																		

$GLOBUS_LOCATION/etc/globus_wsrf_mds_index/hierarchy.xml 

												
										

这个层次文件指定了上游和下游 Index Service 的 URL。下面这个样例声明中包括了主机名、端口和默认的 Index Service 的标识。清单 2 显示了 Globus Toolkit 4 测试环境中上游和下游服务的声明。

												
																		

     <upstream>https://gt4-primary:8443/wsrf/
     services/DefaultIndexService</upstream>

     ...

     <downstream>https://gt4-secondary:8443/wsrf/
     services/DefaultIndexService</downstream>

												
										

MDS 资源属性

正如前面介绍的，用户可以向 Globus MDS 查询资源的属性。这些资源属性代表了资源的配置和状态。我们可以为永久资源和临时资源维护一些属性。Globus MDS 中的信息通过为资源数据关联一个超时时间来保证其反映最新情况。这个值被称为生命周期。MDS Index Service 中保存的所有服务都有一个相关的生命周期。如果在这个生命周期指定的时间内没有更新，数据就过期了。这种方法可以通过只在相关的资源属性进行更新时维护这些资源的配置和状态，从而对临时资源进行处理。当资源不再可用时，资源属性就不会更新了，这些信息就会超时并被删除。

MDS 资源特性

Globus MDS Index Service 信息是作为一组 Web Services Resource Framework（WSRF）资源属性进行维护的。客户机可以使用 WSRF get-property 和 WS-Notification subscribe 操作来查询信息或在信息发生变化时收到通知。这些信息也可以使用命令行工具 wsrf-get-property 或 wsrf-query 进行查询。Globus MDS Index Service 通过用 XML 格式提供所请求的信息来对查询进行响应。下面这个例子执行了一个通用的 DefaultIndexService 查询。–a 选项指定可以进行匿名验证，–s 选项指定了服务的 URL，–z 选项定义了验证类型可以是自己、主机或 none。请参阅 清单 3。

XPath 查询

查询可能会产生非常大的 XML 文档。XPath 可以用来帮助定位 XML 中的不同部分。下面让我们来看几个例子，以此展示怎样扩充简单查询来搜集更详细的信息。下面这个例子可以通过统计那些属性匹配 FreeCPU 状态的 ComputingElements，来查询空闲 CPU 的个数。

												
																		
[globust@gt4-test sbin]$ wsrf-query -a -z none -s 
https://127.0.0.1:8443/wsrf/services/DefaultIndexService
 
"count(//*[local-name()='GLUECE']/glue:
ComputingElement/ glue:State/@glue:FreeCPUs)"

2

												
										

利用前面的例子，下面这个查询展示了一个布尔检查，看是否有指定个数的 CPU 可用。请参阅 清单 5。

监视服务

我们已经讨论了上面这些物理资源的概念，但是 MDS 还要监视服务的配置和状态信息。MDS Index Service 会搜集有关容器上运行的其他服务的信息。服务指定了在 Aggregation Service 注册信息时，要将哪些信息保存在 MDS 中。我们稍后会讨论 Aggregation Service，但是首先介绍一下服务注册这个主题。

服务可以使用 mds-servicegroup-add 命令进行注册。每个注册后的服务都有一个类似于前面介绍过的生命周期属性的生命周期。如果某个服务的注册项在一段指定的生命周期中没有更新，就会过期。更新生命周期的一种方法是在后台运行 mds-servicegroup-add 命令，这样它就可以持续在 MDS 中更新服务注册项并刷新服务的生命周期了。

MDS Aggregation Service 从所有的已注册服务中搜集信息，并通过一个 Web 服务接口将这些服务信息提供给客户机。Globus Toolkit 发行版本中提供了一个简单的例子来展示如何在 MDS Aggregation Service 中注册服务。这个例子使用了下面这个位置上的服务注册定义文件。

												
																		
$GLOBUS_LOCATION/etc/globus_wsrf_mds_
aggregator/example-aggregator-registration.xml

												
										

这个样例聚集文件定义了服务的注册表。每个注册项都定义了一个网格资源、该资源应该注册的服务组以及服务配置参数。这个文件可以与 mds-servicegroup-add 命令一起维护网格资源与 Index Service 之间的注册。这个文件定义了 Index Service 的位置，它被称为默认的 Service Group End Point Reference。

												
																		
<defaultServiceGroupEPR>
   <wsa:Address>https://gt4-test.tacc.utexas.edu:8443/
   wsrf/services/DefaultIndexService</wsa:Address>
</defaultServiceGroupEPR>

												
										

example-aggregator-registration 文件中包含了 GRAM 和 RFT 服务的样例注册项。在 ServiceGroupRegistrationParameter 块中定义的每个资源都要在 Index Service 中进行注册。 清单 7 显示了一个 GRAM 和 RFT Service 注册项的例子。

MDS Aggregation Service 也可以对外部信息源的信息进行聚合。这些信息源可以代表本地服务可能需要的远程资源。本地服务可以查询 MDS Index Service 来定位远程资源，并确定这些资源的状态。举例来说，下面这个例子就展示了将 Hawkeye 在默认的服务组中注册为一个信息源。Hawkeye 是一个外部信息源的例子。它使用 Condor 技术（例如 ClassAds）来搜集和存储有关 Condor 池中的资源的信息。清单 8 显示了如何注册 Hawkeye，这样就可以通过 Index Service 来使用有关 Condor 的信息了。

												
																		
<ServiceGroupRegistrationParameters
   xmlns="http://mds.globus.org/servicegroup/client" >
    <RegistrantEPR	`
      xmlns:agg="http://mds.globus.org/aggregator/types"
      xmlns:gram="http://www.globus.org/namespaces/2004/10/gram/job"
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/03/addressing">
      <wsa:Address>
          https://gt4-test:8443/wsrf/services/mds/test/subsource/IndexServiceEntry
      </wsa:Address>
      <wsa:ReferenceProperties>
         <gram:ResourceID>Hawkeye</gram:ResourceID>
      </wsa:ReferenceProperties>
   </RegistrantEPR>
   <RefreshIntervalSecs>600</RefreshIntervalSecs>
   <Content xsi:type="agg:AggregatorContent"
      xmlns:agg="http://mds.globus.org/aggregator/types">
      <agg:AggregatorConfig xsi:type="agg:AggregatorConfig">
         <agg:ExecutionPollType>
            <agg:PollIntervalMillis>60000</agg:PollIntervalMillis>
            <agg:ProbeName>globus-mds-cluster-hawkeye</agg:ProbeName>
         </agg:ExecutionPollType>
      </agg:AggregatorConfig>
      <agg:AggregatorData/>
   </Content>
</ServiceGroupRegistrationParameters> 

												
										

当服务进行注册时，它们可以提供搜集服务信息的程序名。这个程序称为执行聚集器，在清单 8 中是使用 ProbeName 的形式指定的。MDS Aggregator Service 可以查询资源属性信息，也可以订阅资源属性信息，这样就可以推动后续的更新了。要注册服务，可以使用位置 3 所给出的 example-aggregator-registration 文件作为 mds-servicegroup-add 命令的参数。下面这个例子展示了使用 mds-servicegroup-add 命令来注册默认的 example-aggregator-registration.xml 文件中所定义的服务。–s 参数告诉 MDS 这些服务应该要进行注册。请参阅 清单 9。

可以使用 wsrf-query 命令验证服务是否成功注册。下面这个例子显示了一个 ContainerRegistryService 查询，用来获得容器中正在运行的服务的地址。要在另外一个环境中使用这个查询，请替换 URL 的主机名部分。

												
																		
wsrf-query -s https://gt4-test.tacc.utexas.edu:8443/wsrf/
services/ContainerRegistryService
 "/*/*/*/*[local-name()='Address']"

												
										

MDS 聚集类型

我们已经介绍过 Web 服务会发布资源属性。一个服务应该注册的最小资源属性集包括服务名、服务的版本号以及这个服务是何时启动的。有些服务（例如 GRAM 或 RFT）会发布其他信息或更详细的信息。MDS 中的信息是使用 3 个聚集器源（Aggregator Source）进行搜集的。这 3 个聚集源是 Query Aggregator、Subscription Aggregator 和 Execution Aggregator。

前面用来展示服务组注册的那个例子就是一个 Execution Aggregator。Query Aggregation Source 会对注册的服务进行挑选来产生信息。Subscription Aggregation Source 订阅服务数据，这样在服务数据值发生变化时，就可以接收到通知。Execution Aggregation Source 运行一个程序来搜集信息。发布资源属性或用来搜集服务数据的程序有时称为信息提供者（Informational Providers）。GRAM 就是一个信息提供者，因为它会发布有关网格资源的 CPU 和内存信息，以及与作业队列和所提交的作业有关的调度器信息。类似地，可靠文件传输服务（RFT）也是一个信息提供者，它发布的是有关传输器和服务器的状态信息。除了这些信息提供者（它们都是 Globus 发行版中的一部分）之外，MDS 还可以与其他外部信息提供者进行集成，例如 Ganglia 和 Hawkeye。

Ganglia 是一个分布式的监视系统，主要用来监视高性能系统，例如集群。Hawkeye 是一个监视系统，它使用 Condor 工具和 ClassAd 机制来收集有关分布式资源的信息。Ganglia 和 Hawkeye 使用 GLUE 模式的 CML 映射来搜集资源信息，并将这些信息发送到一个 GRAM 服务，这些信息将在这个服务中作为资源属性发布。Ganglia 信息包括主机属性，例如主机名、处理器、内存、操作系统以及文件系统，还有负载信息。如果在 gluerp XML 文件中定义并配置了适当的信息提供者，MDS 就可以汇集 Hawkeye 或 Ganglia 的信息。

												
																		
$GLOBUS_LOCATION/etc/globus_wsrf_mds_
aggregator/example-aggregator-registration.xml

												
										

Globus 默认的配置说明没有信息提供者。要指定 Hawkeye 或 Ganglia 作为信息提供者，请修改 gluerp.xml 文件中的适当项，这个文件位于 Globus 安装目录中的 etc/globus_wsrf_mds/usefulrp 目录中。下面这个例子展示了指定 Hawkeye 作为信息提供者的正确定义。后面的例子将展示如何配置 Ganglia 作为信息提供者。

												
																		
<config xmlns="http://mds.globus.org/2004/10/gluerp-config">
   <defaultProvider>shell /usr/local/globus/globus-4.0.0/
   libexec/globus-mds-cluster-hawkeye </defaultProvider>
</config>

   ...

<config xmlns="http://mds.globus.org/2004/10/gluerp-config">
   <defaultProvider>java org.globus.mds.usefulrp.glue.
   GangliaElementProducer</defaultProvider>
</config>

												
										

webMDS

我们在前面已经看到可以使用 wsrf-query 命令来查询 MDS 信息。实际上，MDS 信息也可以使用 webMDS 进行查看。webMDS 是一个用来查看 MDS 中所包含的资源属性信息的前端。webMDS 是一个 servlet，它可以查询 Globus MDS Index Service，并使用 XSLT 转换对数据进行格式化，从而可以很好地在 Web 浏览器中显示。

Web 管理员可以使用 HTML 表单选项定制 webMDS。他们可以配置不同的插件来搜集数据，并使用 XSLT 转换对这些数据进行格式化，从而创建自己的定制视图。webMDS 可以配置为从 MDS 中的各种源搜集信息，并使用 XSL 转换对这些信息进行过滤。如果 Globus Toolkit 是使用默认配置安装的，那么 webMDS 就可以查询 MDS Index Service，而不用修改任何配置。我们测试环境中使用的 webMDS URL 如清单 12 所示。要在另外的环境中使用 webMDS，请使用您自己的主机名替换其主机名部分，如果您不是在默认端口上运行容器的，还需要修改端口号。

												
																		
http://gt4-test.tacc.utexas.edu:9080/webmds

												
										

可以通过编辑下面的 indexinfo 文件并修改默认的 URL 来改变 webMDS URL ：

												
																		
$GLOBUS_LOCATION/lib/webmds/conf/indexinfo

												
										

要部署 webMDS，首先为 Globus （GLOBUS_LOCATION） 和 Tomcat （CATALINA_HOME） 设置环境变量，然后使用下面的命令为 Tomcat 创建一个 context 文件：

												
																		
$GLOBUS_LOCATION/lib/webmds/bin/webmds-create-contex-file
  \ $CATALINA_HOME/conf/Catalina/localhost

												
										

在成功运行这个命令创建 context 文件之后，请重新启动 Tomcat，以便使用新的配置信息。重新启动 Tomcat 可以使用下面的命令：

												
																		
$CATALINA_HOME/bin/shutdown.sh
…
$CATALINA_HOME/bin/startup.sh

												
										

重启 Tomcat 容器之后，可以在浏览器的地址栏中键入 webMDS 的 URL（请参阅清单 12）来访问 webMDS。这个 URL 中需要替换上您安装使用的主机名和端口号。注意，这是 Tomcat 中运行 webMDS 的 URL，而不是在 Globus 容器中运行的 MDS 服务的 URL。

这个样例表单是由 Globus 发行版提供的，用来展示 webMDS 的功能。也可以使用模板来创建新的定制请求。

通过 webMDS 来查询 Index Service 可以显示在 Index Service 中注册的资源。每个服务都提供了一种资源类型、惟一标识符和一个链接（指向更详细的信息）。选择资源项可以产生有关资源的详细信息。我们已经介绍过 GRAM 和 RFT 服务都在 Index Service 中进行了注册。图 1 是一个显示与 RFT 服务有关的详细信息的例子。

如果 GRAM 配置用来与资源管理器一起使用，例如 LSF、PBS 或 Condor，那么每个资源都会存在这样一个注册项。

图 2 和图 3 显示了与 LSF 服务有关的详细信息。

图 4 显示了与 Condor 服务有关的详细信息。

webMDS 是 MDS Index Service 的一个简单易用的接口。我们在前面已经展示了 mds-servicegroup-add 命令可以用来在 MDS 中注册服务，聚集源可以配置为对来自服务和外部信息提供者的信息进行汇集。这些信息提供者运行了一个程序来搜集信息，它们都是 Execution Aggregators。这很容易展示，可以手工运行信息提供者，并验证这些信息和格式与通过 webMDS 所提供的信息和格式完全相同。下面这个例子显示了 Hawkeye 信息提供者的情况，这是由清单 8 中下面这一行定义的：

												
														<agg:ProbeName>globus-mds-cluster-hawkeye</agg:ProbeName>

												
										

请参见 清单 15。

结束语

我们首先概要介绍了 Globus MDS，然后了解了某些底层服务的详细知识。Index Service 是一个注册表，负责搜集信息并以资源属性的形式来发布这些信息。Trigger Service 使客户机可以订阅资源属性，并在数据达到某个极限值时执行预定义的操作。这些服务都是构建在 Aggregation Service 之上的，后者也可以对来自外部信息源的信息进行聚集。这些信息可以汇集到一个集成的注册表中，称为网格 Index Service。Index Service 以编程方式向客户机提供了资源属性信息，这可以通过 Web 服务、命令行接口或浏览器来接收。

三年前，我们这些处于 Rational Software Corporation 前沿的一组人坐下来撰写了一篇有关利用面向服务的体系结构（service-oriented architecture，SOA）式样¹来开发解决方案问题的文章，并且从那以后发生了许多事。我们所面临的一个问题是 Rational Software 有一组建模工具，但没有 IDE 来实际地开发我们所建模的服务实现。随着 IBM 对 Rational 的收购，我们现在有了一个世界级的 WebSphere Studio Application Developer（现在是 Rational Application Developer，或 RAD）形式的 IDE。我们还面临着一个问题，许多关于 SOA 的思想都不成熟，并且许多是被错误驱使的 —— 一个我们在文章中考虑的问题。既然支持 SOA 的 IBM 平台已经相当地成熟，并且我们的开发工具已经增加了按照灵活快捷的方式开发服务的功能，我们决定再次访问我们在前面文章中概括的服务设计的概念。

此讨论的结果是一个新的理解：我们的价值不是在表现 WSDL（Web 服务描述语言）和 XML 的所有三角地的模型开发，而是允许设计人员和架构师用恰当的功能指定恰当的服务并实现 SOA 式样的潜在益处。 此理解将我们引向一些长远的讨论，这些讨论是关于 1) 用来表现服务模型的恰当抽象级别，和 2) SOA 式样的开发影响 Rational Unified Process®，或 RUP® 的方式。

本文的前三分之一介绍了我们为变更所设置的范围，包括我们所关注的需求。接下来我将描述一些关键的主题，我们将这些主题用作对 RUP 的变更框架，及用于支持面向服务的解决方案开发的 Rational Software Architect（RSA）补充。最后，我将描述一些在我们的思想中使用的情境，这些情境随时间得到了改进，但还需要一些关键客户的验证。

设置恰当的范围

我们决定不仅开发一个新的用于 RSA 的建模概要文件，还要开发添加到 RUP 中的指导，为帮助实践者在预想和开发面向服务的解决方案中实际地使用工具。

然而，众所周知，对于任何项目最关键的方面之一是设置恰当的范围：太小，您就会做出对任何人没有实际意义的东西（除了可能能够拿出您自己的要获得利益的目的），太大，就很可能要煮沸整个海洋。所以我们建立了以下标准：

• 我们开发的模型必须要处于当前实现技术和标准之上的抽象级别上（WS-* 规范，就是各种 Web 服务规范），然而，还要将 SOA 的概念作为头等的要素。
  
  
• 结果的模型必须是可扩展的，可以考虑到相关的额外规范，如安全性、服务质量，可管理性，等等。
  
  
• 模型必须在 IBM Rational Software Modeler（RSM）和 IBM Rational Software Architect（RSA）中实现，最初作为一个 UML 概要文件。
  
  
• 指导不得不向基础 RUP 添加具体的 SOA 概念。然而，我们想要在现有的 RUP 中利用尽可能多的东西，因此，为了使更新很容易地添加到现有的 RUP 配置中，我们最初选择不改变任何存在的东西。
  
  
• 我们的工作应该考虑在提供 SOA 指导中 IBM 已经完成的工作，如 IBM Global Services SOMA 技术。²

因此我们定义了一组三个可交付使用的标准，每一个都可以从 IBM developerWorks 中得到：

• 描述 UML Profile for Software Services 的文档，³它依照的是 OMG 概要文件文档的式样。
  
  
• 实现 UML Profile for Software Services 的 RSM 或 RSA 插件，⁴它使模型构建于工具之中并符合上面的概要文件。
  
  
• 包含了所有关于 SOA 体系结构⁵和设计主题指导的 RUP 插件，它提供了关于依照上面的概要文件开发服务设计模型的具体指导。

幸亏 RSM 和 RSA 工具具有可扩展机制，我们才能够不仅交付 UML Profile for Software Services，还交付一个模板模型（当您选择 File -> New -> UML Model 时可用）和两个添加到 Sample Gallery 中的示例。

这是我们考虑的一个合理的标准集合并可以交付。所以让我们看看在 2005 年 5 月 IBM developerWorks 中实际交付的内容。

关键概念和主题

首先，什么是 SOA？流行着许多定义，但让我们以一个软件工程师的角度去看，简单地说 SOA 是一个“体系结构式样”的实例。这又引出一个问题，什么是体系结构式样？这里有一个来自 Roy Thomas Fielding 的很好的定义：

体系结构式样等同于限制体系结构要素的作用或特性及任何体系结构中符合该式样的那些要素之间的容许关系的体系结构约束。⁶

举个例子，一个已编制的体系结构式样是管道和过滤器样式，它包含了将管道作为连接器来关联过滤器的独立的要素。在管道连接的两个过滤器之间存在着数据类型必须遵照的具体的约束，且存在着一些令式样适应于某些环境的特征。

知道了这些，我们可以开始列举 SOA 的体系结构要素，以及具体到其式样的关系和约束。有了这个有用的体系结构式样的定义，Fielding 还提供了一个非常及时的建议：

设计这个强意词是普遍发生的。至少软件行业中的某些此种行为还缺乏对为什么已知的体系结构约束集合是有用的的理解。换句话说，在选择复用那些体系结构时，好的软件体系结构背后的原因对设计人员不是显然的。⁷

我们希望通过提供 RUP 中的具体附加内容集的简明及时的指导来缓和此精确的行为。此指导描述了体系结构的式样、要素和关系，以及在整个开发生命周期中他们是如何被识别、指定和管理的。同事还要注意，通常体系结构的目标，特别是体系结构建模，提供了一个适当的抽象级别，在此级别上，可以容易地识别体系结构的要素，并且在不隐藏那些应该添加到针对实现更低层细化级别的细节的情况下，对要素进行控制。

在下面几个部分中，我们将讨论针对 SOA 的 RUP 更新中的一些关键主题 —— 特别是，要素、关系和每个主题引入的约束。

服务的识别和说明

我们的标准规定，关键的 SOA 概念必须作为头等要素通过模型表现出来，因此这些关键的概念是什么？如您所预想的，其中一个概念就是服务本身，然而，与其作为模型建立的中心，还不如实际地成为次要的要素（不是重要的，但作为模型的要素，因为它不能独立存在）。要构建一个表现 WSDL 所定义服务的服务模型，我们必须首先开发服务规范以及服务供应商。

服务规范有三个规范要素，所有都同样重要，虽然在某种情况下，根据服务的建模类型可对它们进行选择：

• 结构规范。它可以用标准的 UML 或 Java 接口考虑。其定义了可以调用的操作和由这些操作销毁或创造出的消息。
  
  
• 行为规范。它表示出服务客户和所指定服务之间的任意预期的有意义的协议或会话。例如，服务也许要求您在调用另一个操作之前先登录，这称为伪对话服务。服务也许还要求客户实现特殊的接口，以便接口可以被回调，且协议可以展示这点。
  
  
• 策略规范。它表示服务的策略主张和约束。策略主张可能包括安全性、可管理性等等。

那么，例如，如果我们设想一个订单管理服务，我们也许期望看到列出“下订单”、“取消订单”和“更新订单”作为可用操作的结构规范。此订购服务的行为规范可能会说明，您如何不能更新或取消没有订购的订单，或者在您取消订单之后就不能再对其更新。最后，策略规范可能要求加密订单的某些要素，指示要使用的加密技术、要使用的证书等等。

我们在 RUP 中已经交付的指导的一个方面是一组技术（新的行为识别服务中进行了描述），用来从业务过程模型、用例或现有的各种清单资产中确定服务。这种行为和这些技术集允许架构师和设计人员制造出候选服务模型，这些模型是经常用于描述用来实现过程或需求集的“理想化”服务的服务规范。

我们介绍术语“候选服务”，因为许多这些服务经常不得不被重构来 1) 符合现有服务，2) 适应现有功能体系结构的框架，或者 3) 被分开以考虑更细致或并行的开发。

管理服务组合

SOA 式样解决方案的开发的一个主要优点是在开发一个应用程序时（收集需求、设计并实现解决方案，且管理项目），不用将应用程序作为一个固定的边界考虑。在 SOA 中，我们看到的应用程序是一个动态的实体，一个满足特殊业务需求集的服务配置。要达到这种状态，我们显然需要在企业中设计、实现并管理作为可用功能组合的服务集。

该需求就是为什么我们指定前面提到的新的识别服务行为的原因。我们不仅是在识别候选服务时考虑组合，我们还由服务的原始形式进行重构以适应组合中服务的形式。该级别的复用不仅应该得到设计工具的支持，不仅应该得到关于服务组合的信息存储库的支持，还应该 —— 最重要的 —— 得到以恰当的方式开发恰当的服务时指导参与者的过程支持。

这确实导致了一个特别的问题，在传统情况下，我们关注软件开发生命周期，视其为一个由项目限制时间的过程，项目受到解决方案的某些离散部分的开发时间的限制。就服务组合本身而言（关于已安装的服务的元数据和考虑复用的设计模型的组合），我们看到这样一个生命周期，它横切了使用它并对它做出贡献的单个项目，如图 1 所示。

图 1：服务组合生命周期

图 1 所示的服务组合管理过程是一个不断进展的活动。注意单个项目与服务组合交互的方式，在项目的细化阶段从单个的项目中提取需要组合的服务，在项目的构造阶段组合的服务被实现。

划分面向服务的解决方案

不管多大规模的模型（或实际上是要素的任意集合）都存在的一个问题就是如何管理模型，如何对要素分类，以及如何以任何检查模型的不同涉众都可以理解的方式来组织要素。

服务模型的此种结构在服务的识别和服务的管理过程中变得重要起来。让我们暂时考虑 UML 1.x 中的模型管理 —— 包 —— 的典型方法。关于包的问题是它们通过所有权或聚合来管理模型要素，换句话说，一旦将一个要素放入单个的包中，不同包中的要素可以对其访问但不能将其“放置”在一个以上的包中。此刻，对于我们这些具有程序设计语言背景的人来说，这似乎不是主要问题，它反映出包、模块或命名空间在语言中工作的方式。

然而，我们真正需要表示的是模型的视图，因为对业务所有者有用的结构集合不同于软件架构师、设计人员、开发人员、操作人员等所需要的集合。出于该原因，我们推荐不要将包作为管理模型视图的主要机制（不是说包中不出现服务，只是说包应该用于模型的更平凡结构）。取而代之，我们指望 UML 2.0 规范的复合结构概念，其提供了表示使用“部件”和“连接器”的分类器的内部结构功能。

我们利用这些技术划分所管理的服务，换句话说，根据逻辑分类方案进行组织，不需要让服务所属于任何一个分区。例如，我们可能有两个不同的组合视图：一个表示不同的业务线，另一个表示提供服务的应用程序“类型”，如图 2 所以。

图 2：根据逻辑分类方案利用分区进行组织，不需要让服务所属于任何一个分区

注意，相同的服务（较小的方框）出现在一个以上的分区中（较大的方框），顶部的三个分区表示业务线，且底部的三个表示应用程序类型。从此处我们可以看到，虽然业务的供应链拥有并管理着 Shipping、Validation，和 Warehouse 服务，但我们可以看到 Shipping 服务由 ERP 包提供而 Warehouse 和 Validation 服务是定制开发的。

该技术不仅在管理已开发的服务集方面体现价值，还在服务的识别过程中体现价值。分区可以用于表示服务分组，并作为服务规范进行开发，可以将服务放置于不同的分区中以可视化关系和它们之间的依赖。

RUP 更新

对 SOA 的 RUP 更新已经在许多（和谐的）地方得到扩展，以提供关于体系结构开发和面向服务解决方案的设计模型的具体指导。但 RUP 的许多领域仍旧不受到该更新的影响。例如，我们在早期决定的更新的开发，尽管一些行业作家已经引入了支持 SOA 的新开发角色，但我们相信当前 RUP 的Software Architect 和Designer 角色对于我们所需要的更新是足够的。

新的和更新的工作流

在更新 RUP 以引入对于 SOA 解决方案构建的指导的过程中，我们只添加了以下两个新活动：

• 识别服务。由 Analysis & Design 和 Refine the Architecture 工作流中的 Software Architect执行。
  
  
• 服务设计。由 Analysis & Design 和 Design Services 工作流中的 Designer 执行。

识别服务活动是软件架构师在概括解决方案的体系结构时所执行的一个活动，活动的输出是服务模型。该服务模型中包含一组已识别的，已经是候选的服务，这些服务要作为服务设计活动的一部分由设计人员进一步细化。

新的和更新的工件

更新将整个服务模型（表示 UML Profile for Software Services）和其附属的要素引入到 RUP 中。模型表示面向服务解决方案的体系结构抽象，该抽象使软件架构师和设计人员在这样一种环境下开发模型，在这种环境下，服务的概念和对 SOA 的具体关注是头等的模型要素。模型不直接表示任何实现技术，如 WSDL。

图 3：UML Profile for Software Services

新的和更新的指导方针

除了在服务模型中描述工件的具体内容，更新还包括与上面描述的主题相关的概念以及在开发 SOA 模型时反映对重要性所关注的额外的指导方针。这些关注包括：

• 消息设计和消息附件。设计消息，管理可复用的消息目录和消息方案的一致性。
  
  
• 服务数据封装。围绕服务中数据管理的服务设计特性和数据方案与服务边界之间的关系。
  
  
• 服务仲裁。有关一般作为 SOA 式样一部分（特别是 Enterprise Service Bus，或 ESB 视野）的仲裁组件的概念的具体指导。
  
  
• 状态管理。对有状态和无状态服务的优点的讨论，包括对于规范的技术和管理资源状态的服务设计。

我们还提供了指导方针 Going from Services to Service Components（从服务到服务组件），其论证了从服务设计模型到传统的设计或实现模型的一种可能的变换。

更新还包含两个报告描述，描述创建服务模型的 RSA 工具指导者，和表现服务模型开发的相当完整的实例。

RSM 或 RSA 插件

IBM Rational Software Modeler 和 IBM Rational Software Architect 的新插件（今后称为 RSM 或 RSA 插件）提供了 UML Profile for Software Services，一个您可以使用的模板模型，和一对论证概要文件使用的示例模型。该插件可以在 IBM developerWorks 下载，并可以利用标准的软件更新机制将其添加到工具中（注意下载的压缩文件表示一个存档更新站点）。

在 RSM 或 RSA 中，在软件服务的插件安装完之后可以很容易地创建新的服务模型。以下的步骤是必要的（注意是在 Modeling Perspective 中）：

1. 如果在您的工作区中已经有了一个 UML 建模工程，您可以将服务模型添加到该工程中或创建新工程（参见步骤 2）。
   
   
   • 右键单击工程并选择 New -> UML Model 或者在 File 菜单中选择 New -> UML Model。
     
     
   • 当您看到 New UML Model 向导时，如图 4，转到步骤 3。
2. 要创建新的 UML 建模工程，到 File 菜单中并选择 New -> Project，UML Project 处在 Modeling 目录下面。
   
   
   • 在结果向导中，给出工程的名称并选择 Next。
3. 在 New UML Model 向导中，如图 4 所示，确保正确设置了目标文件夹，从模板列表中选择 Service Design Model，并给模型命名。

图 4：New UML model 向导

这将创建并打开带有 UML Profile for Software Services 的 UML 模型和一个模板结构，您可能由该模板结构开始为 SOA 解决方案建模。模型还包含一组可以在创建一些复合要素时有用的可复用模型要素，至少使用这些要素要比手动创建更简单。

三个情境

以下的部分概述了我们从与客户的讨论（不论客户认为面向服务的解决方案的开发如何适应他们的软件开发生命周期）中总结出的三个情境。我们先认明三个开发服务的方法，而它们当然不是不相容的（真实的工程使用技术的组合），它们在阐明不同方法和思想方面是有用的。

在任何可能的地方，我将把在这些情境中描述的任务与 RUP 中定义的结合起来。

1. 以消息为中心的设计

在消息为中心的设计中，焦点在服务领域中。例如领域工程或面向对象分析和设计（Object-Oriented Analysis and Design，OOAD）的技术提供了许多对抽象领域模型开发的洞察，并且这些技术通常生成对应消息方案的高度可复用模型。服务设计常常是次要的活动，尽管有时候并行地完成。例如，在电子数据交换（Electronic Data Interchange，EDI）中，不存在真正的服务接口概念，因为 EDI 系统通常有一个单个的全球的消息收件箱和发件箱。

该方法的一个实例可能是在传统的B2B 环境中，以 EDI 标准化作为代表。在此种情况下，主要的设计活动涉及开发某些行业或其他范围内取得一致的消息方案，这被认为是表示一类消息的方案 —— 例如，EDI⁸Purchase Order、ACORD⁹Claim Inquiry，或者 SWIFT¹⁰Credit Transfer。

在许多现代标准活动中，如 SWIFT 或 RosettaNet，¹¹经常存在一个用于标准的设计过程，包含了一个混合的以消息为中心并以服务为中心的方法，在该方法中使用了如用例分析的技术。

情境

在此实例中，客户是一个大的保险供应商，开发新的应用程序以支持其中一条业务线。在该公司中业务和 IT 支持之间的结合相当的好，且严密关注通过 IT 传递到业务的价值。

此情境中的项目扩展了两个索赔处理系统，以便两个系统可以提供将要启动策略集成并使公司收回一个系统并将所有索赔处理系统移到一个单个的系统中的面向服务的接口。

业务人员希望服务能够支持一些现有的业务过程，但他们清楚地知道这些过程随时变化，所以将服务与过程结合是不切实际的。作为回应，该业务领域的软件架构师相信更加适合的方法可能会集中于过程中的业务工件，主要是索赔本身。除了这些，他们已经在 IBM IAA 中投了资，¹²这为工件提供了定义良好的且标准的模型，如索赔。

在这点上，对于主要工件的实际数据模型已经由 IAA 指定，所以主要的工作是理解在当前系统中使用这些工件的方式及围绕着不同的实现如何开发新的外观。

活动

业务分析人员开始编制需求，还利用业务过程模型来描述系统的功能需求。非功能需求在需求数据库中进行描述，依附于业务过程模型中的任务或项。过程模型是为两个当前系统和两者的交集开发的。

软件架构师拿到了这些模型和需求并与业务分析人员一起开发集中于两个系统间一般工件的流程的更具体的过程。软件架构师还与业务分析人员一起理解当前系统的数据需求及它们到 IAA 数据模型的关系。

数据架构师与软件架构师一起描绘出针对新的过程中工件的逻辑和物理表示的方案。

软件架构师开发了一个将过程活动划分成一组服务操作的候选服务模型。该模型还包括每个服务的消息需求及这些消息到下面的数据模型的关联。

软件架构师与集成专家一起（不是通常的 RUP 角色，但对应该角色的描述是为 RUP 设计的）定义从候选模型到当前实现所需的映射（在它们存在的地方）。这些映射将在所选的中间件中实现，但不应该像引入主要性能问题那样麻烦。

2. 以服务为中心的设计

在此方法中，设计人员牵扯到展示（作为服务或一组服务）预期的业务或应用程序的功能。在此种情况下，我们不必要知道服务的客户会选择什么来利用服务，但我们知道此种客户期望的交互类型。因此，与第一个情境相反，消息是次要，并且被作为对操作的需求响应被开发。

该方法的实例是由 Amazon 和 eBay 表现的 Web 服务 API（Web Services APIs presented by Amazon，AWS）¹³。此服务接口没有将业务过程强加于客户，一般地，它们甚至没有将所期望的接口强加于客户，但它们使第三方开发人员以清晰直观的方式接触到了各自的服务供应商的操作。

如前面所提到的，以服务为中心的建模通过了解参与者的需求（服务的外部客户）并提供支持那些需求的操作（浏览目录、向购物车中添加物品、付账等）有助于用例驱动的方法。

成为次要关注的消息的问题在 Amazon API 中是明显的，在 Amazon API 中肯定能够将普通的方案定义从当前设计中分析出来，这证明消息是为每个操作请求和响应而分别开发的。

情境

此处我们的实例是一个为化学加工行业提供零件的在线供应商。商家可以提供一个 Web 门户，客户可以通过该门户购买零件，商家还可以通过电话和传真管理进一步的业务。但需要为客户提供通过比 Web 本身更程序化的方法对购买门户进行的访问。这种对核心订购功能的访问使公司成为客户供应链中的关键要素，一个可以直接与客户核心业务应用程序集成的要素。商家试图实现 EDI 购买解决方案，但初始部署的成本和必要的基础结构证实是不可行的的。执行团队相信许多客户正在向其他的能够提供此种购买门户的供应商转移，因为这些竞争者已经能够通过更自动化的过程更好地集成。

与我们的第一个情境比较，此项目由 IT 组织推动。以一个商家的观点，项目目标是简单地提供一个机制来执行同样的订购操作，不需要让客户花时间将数据输入到 Web 门户或者商家输入来自传真订购清单的类似数据。IT 组织被允许独立做出许多决定，只要能够生成比前一个 EDI 尝试花费少的解决方案。

两个重要的影响设计的观察已经由 IT 组织的高级团队做出来了。

1. 提供的功能必须不得少于通过 Web 或人工订购提供的当前功能。
   
   
2. 操作集不是由我们的业务过程所推动，而是由客户所使用的，作为他们过程的一部分。针对该原因，我们必须假设关于这些操作使用的可能性越少越好。

软件架构师生成了一组描述客户所期望的功能的用例文档，并且确保业务团队同意。然后用例被断成一组离散的操作，且数据需求（消息）被指定。这些操作集合成一组三个用于搜索、订购和账户管理的服务。此步骤倾向于受到经验和判断的影响比受到精确的规格影响要多，因而此步骤是迭代的。

一旦知道了服务和操作集，团队就可以更加正式地定义服务规范，包括针对每个接口的协议和服务客户所需要的任意策略信息。该步骤非常的重要：它向客户提供了在服务可用时，不能够通过简单地阅读由商家部署的 WSDL 就能够被理解的信息。

活动

业务执行者（不是当前的 RUP 角色，但似乎我们都承认他们）传达了这样一个需要，就是当客户感觉他们的收入正在被当前提供这些功能的更大的供应商抢走时，必须向客户提供可编程访问业务服务的能力。

软件架构师打算开发一组提供 Web 订购系统的核心功能的服务。提议包括一组用例，描述了客户通过 Web 执行的活动（与来自在线业务的业务分析人员一起开发）。同时也包含了初始阶段的模型，这个模型展示了对于当前后端系统的候选服务和他们之间的关系。

软件架构师，赞成该项目，迭代候选服务模型以在后端应用程序分区（公然地展示所需的业务功能以支持服务）中识别服务。同时，软件架构师让设计人员观察当前的 Web 应用程序及如何与后端系统交互，挖掘出要由服务实现的任何所需的业务逻辑和需求。

软件架构师和业务分析人员一致同意把所需的功能集作为服务执行的操作和任意所需的约束或策略来提供。此模型的迭代显示了三个具体的服务和初始服务规范，尽管在过程的这一点上这些只指定了服务的结构方面。

软件架构师与 Web 应用程序团队的开发人员一起了解对于已识别的操作集的具体数据需求。这被交给了具有 XML 技术的数据架构师，来开发将会生成由操作销毁和生成的消息方案的消息模型。

设计人员可以开始连接服务模型和将用来描述提供业务逻辑的组件的实现模型（J2EE）并连接到现有的后端应用程序。

软件架构师和设计人员最终用细节根据服务规范细化了服务模型，主要提供可以使客户了解如何与服务交互的协议和策略细节。

我们现在有一组完整的模型：

• 描述客户期望的用例模型
  
  
• 描述客户视角（服务规范）和供应商视角（服务、分区等）的服务模型
  
  
• 描述实现服务规范的软件组件的实现模型

现在开发人员能够实现准备由客户使用的试验系统。

继续的行动

在成功部署试验工程之后，要注意的是，向客户提供的服务涉及 Web 系统特定功能的并行实现。建议建立新的工程来重新配置 Web 应用程序以复用这些服务，这项工作应该包含于 Web 应用程序的常规计划更新中。这样的重配置将某些业务逻辑从 Web 应用程序中移到服务中，因而一个单独的组件集合由基于 Web 和服务的客户使用。

为了满足 Web 应用程序团队对性能的关注，除了向合伙人提供的 SOAP/HTTP 绑定之外，服务还需要被重配置，以在 Web 应用程序中访问服务时，服务能够提供更有效的 Java 绑定，。

3. 以协作为中心的设计

在协作为中心的方法中，重点是两个或多个服务的协作，这是服务的过程视角，它与传统业务建模的相关性要比与软件开发活动的相关性更大。在此方法中，服务作为协作中的实现角色，因此服务规范成为为跨一个或多个协作的角色而定义的责任。

这样一种方法将对那些涉及到 RosettaNet Partner Interchange Processes（PIPs）的开发和 OAGIS¹⁴标准的开发中的人是可识别的（然而，在这些情况下协作远不完全）。这样的方法在业务中对于业务过程设计或在业务集成活动（在活动中 IT 系统的组件作为服务出现）中而言是普遍的。

通常在这样的情境中，服务规范可能直接源自协作，而该方法倾向于较少关注于导致需要实现完整性的混合方法的消息内容。

情境

此情境涉及一个已经决定通过收购而继续扩充策略的中型银行企业，这意味着对于该企业来说，IT 不只是一个必须拥有的部分，而且还是在吸收所收购操作过程中发挥竞争优势的业务的一部分。

银行已经开发了一个领先的得到谨慎管理的组合，以确保成本和功能的效率。然而，很清楚的是某些技术和文化方面的阻碍出现在视线中，在整个企业中提供应用程序的一般集合。由于这些阻碍，公司已经决定使用服务方法来提供它们的 IT 功能并以此式样开发所有的新功能。企业已经经过多年开发了一套以过程为中心的东西。这些很好理解，一般的过程使它们有效地集成所收购的企业并指导他们的 IT组织来支持这些过程。

在我们的情境中，银行将一个遗留应用程序引入了服务组合中，这给我们提供了一个机会来观察帐户统一的过程模型，即一个令企业帮助客户有效利用帐户的业务服务。此过程模型已经由许多“黑盒子”活动设计而成，意味着一个活动通常由一个没有作为服务组合的一部分而启动的系统执行或者以还没有细化的方式执行。模型将这些活动表示为“黑盒子”并不提供更多的细节。团队已经注意到特定的遗留应用程序系统参与了帐户统一过程的三个活动，且其他过程模型的分析揭示了使用同一应用程序的两个其他的过程。

在企业所依靠的方法中，过程模型是分析和需求收集的主要工件。过程本身表现出通过 IT 和相应的人员，业务功能需求的完全体现，附属的且正式定义的文档描述了非功能的需求。在配置管理之下这些过程模型得到了小心的维护，并且为每个操作过程而发布，这样它们不仅指导过程的开发还为过程中的银行职员培训提供了材料。

早期提及的服务组合是一个 RAS¹⁵存储库，其考虑了基于由每个资产中的 RAS 名单所定义的标准的搜索。资产是所部署的服务，而名单包含了描述服务的核心组合及描述业务信息（如所有权、策略等等）的范围。

在开发服务以提供遗留应用程序的功能过程中，包含了业务和 IT 代表的团队致力于作为业务过程实现的服务之间的协作。该方法使业务端将结果看成是传统的业务过程模型，而 IT 端将同样的模型看成是服务之间的协作。

活动

业务分析人员要么创建新的业务过程模型，要么更新现有的业务过程模型。此模型是按照商家所展望描述的新过程，该过程更新还包括由过程活动管理、消除或产生的业务文档定义。软件架构师创建了差距分析文档，这个文档对新业务过程的需求和现有服务组合进行了比较。

业务分析人员将关键性能指示器（Key Performance Indicators，KPI)¹⁶定义为业务过程本身的一部分。这暗示着参与过程的服务必须支持可以查询的用来确保与 KPI 的一致性的度量。

数据架构师改进来自业务过程模型的消息定义，确保与现有方案的通用性，然后开发可以用于生成服务所需的 XML 方案的消息模型。

软件架构师用新的服务或向现有服务中添加新的规范来更新服务模型。数据架构师开发的消息模型用于（或复用于）这些服务规范。

软件架构师和业务分析人员更新早期定义的过程模型以将活动映射到新的或更新的服务上。对于服务更新，模型是完整的了，现在就可以对其进行转换并发布。

软件架构师和设计人员开发了包含协议和策略信息的具体服务规范。这样一个具体的规范作为供应商和客户之间的合约，不能由任何一方打破。

开发人员创建针对遗留应用程序的适配器和/或变换，用来实现具体的规范。

开发人员必须开发用于监控的度量生成器。这些通常是具体的操作，需要监控基础结构来查询对应一般状态和度量状态的服务。

集成专家使用新的服务来更新过程的编排 —— 在此种情况下，业务过程被转化为编排语言，业务过程执行语言（Business Process Execution Language，BPEL）。在某些情况下，在部署之前还要用一些额外的信息更新生成的编排。

业务分析人员用业务 KPI 定义和它们到具体度量的关系来更新监控中间件，以便可以监控新的服务。

接下来的步骤

IBM Rational 团队已经与许多客户一起工作，并在IBM 的内部项目中展示并使用了 RUP 和 RSM/RSA 插件。我们已经收到足够的反馈信息，通过这些信息我们得知尽管我们还有许多事情要做的，但我们已经建立了良好坚实的基础。现在我们正致力于一组具体的工程，其设计用来延伸我们所做的工作，并且了解我们可以在哪里添加更多内容，特别是在用于建模工具和额外的 RUP 指导主题的策略规范的领域。

引言

理想的基于面向服务的体系结构系统设计的需求是在服务消费者与服务提供者之间进行解耦。解耦可采用多种形式，其范围从静态（在编译时通过请求端存根来解耦）到全动态解耦（在所有服务调用的运行时完全封装并建立解耦）。显然，全动态解耦是一个严格的要求。如果一个服务被动态解耦，然后服务特性中的更改导致了服务实现中的修正，但是所有其它的系统元素，特别是调用机制，仍旧保持不变。这种设计的优点显而易见。

对于 SOA 与 Web 服务的更强大功能与性能的日益增长的期望与需求经常导致显著增长的软件复杂性。今天，SOA 实现的实际情况是，尽管规划了服务的功能模块化，但是它们仍旧经常与独立的中间件或通信协议（如基于 MOM 的 JMS、HTTP/SOAP 等等）耦合。在大多数组织中，当应用程序扩展功能时，开发者关注的，在某种程度上，是静态解耦（通常是指绑定），并强制为每一个 Web 服务创建独立的客户端，而不是单独的能够同时访问多个服务的客户端。

静态绑定的局限性是非常明显的——代码中的静态绑定阻止了不同应用程序中贯穿整个企业的服务的重用。简而言之，即使需要提取并封装所用的不同中间件及协议来执行服务组件之间的交互，这些组件被包括在服务消费者与服务提供者的交互中，这样的需求非常普遍，但是封装了 Web 服务接口的体系结构还未得到广泛应用。造成这种状态的其中一个主要原因就在于，尽管动态绑定的几种机制已被设计用来适应这种局限性，但是对动态绑定相关联的实际技术依然存在很多的误解。

Web 服务调用的剖析

已经有许多关于 SOA 最重要的概念——服务接口（换句话说，调用功能）及在运行时如何定位并调用它们的文章。换句话说， Web 服务调用应该在后期绑定。需要指明的是 Web 服务调用已经被设计为传统的 Remote Procedure Call（RPC）方法，该方法准许一个应用程序调用由第二个应用程序发布的功能。RPC 工作方式如下（如图 1 所示）：

• 被调用的应用程序的功能是以本地功能的形式展示给调用的应用程序的。
• 通过向调用的应用程序提供功能存根达到定位透明性。
• 功能存根，当它被调用时，访问一个中间件层，该层向被调用的应用程序传输调用及其相关的数据。

在 Web 服务中，存根代码通常是自动产生的，并且是基于使用被调用的功能的接口描述，它通过 Web 服务描述语言（Web Services Description Language，WSDL）来表示，并创建了存根 shell。此外，存根通常是在应用程序开发的编码阶段产生，因为存根是主要是从应用程序代码中直接调用，而且，结果是必须在编译时解决的（换句话说，即所谓的前期绑定）。

大多数应用程序开发者，主要是 Java 开发者，认为使用这样的存根是必要的，因为对他们来说，如何处理从调用服务返回的复杂数据类型是不清楚的。当然，来自被调用应用程序功能的数据必须同 SOAP 消息相分离，而且，当使用 Java 的时候，必须有一个相对应的（兼容的）实现序列化接口的类。显然，同样的存根产生工具被用于产生那些所需求的类。

本文的首要思想就是，一般来说，通常自动化是双刃剑。一方面，自动化准许行业内 Web 服务的快速适应，其原因是，有了自动化工具，大多数应用程序开发者的行为不再发生在 WSDL 自身的级别上。另一方面，不幸的是，市场仍需要一种主要的工具来选择需要使用的调用形式——显式的存根（存根在编译时解析）或隐式的存根（存根在运行时解析）。隐式的存根通常被当成 Web 服务的无存根调用。

大多数基于 Java 的 Web 服务工具提供了一些 Web 服务接口的运行时后期绑定功能。来自 webMethods 的 Glue 产品与 J2EE Web Services Developer 组件的 JAX-RPC 包就是两个例子。然而，这些尝试大多导致了软件深受供应商特定逻辑的影响。而且，问题并不仅仅存在于供应商指定的代码。在许多情况下，供应商专有的解决方案产生了实际的可管理性与可维护性的问题。

现在让我们回顾提到的问题点，例如用于后期绑定的 webMethods Glue 方式。目前，Glue 是广泛使用的工具。由于使用了一个代理用于 Web 服务的接口，Glue 看起来好象是无所不能。然而，仅仅通过自身使用一个代理并不能消除所有的问题。下面的 Java 代码片断描述了在它们的应用中的一个典型的负面情形：

												
														public class lateBindingGlue 
{ 
public Document serviceInvocationGlue() 
throws Throwable { 
String wsdlName = "http://…../Service.wsdl?WSDL"; 
String operation = "…….."; 
String args[] = {  }; 
/* first, Glue creates a SOAP interceptor */ 
SOAPInterceptor responseHandler = new SOAPInterceptor(); 
/* second, Glue registers the SOAP interceptor to catch incoming responses */ 
ApplicationContext.addInboundSoapResponseInterceptor( 
(ISOAPInterceptor)responseHandler ); 
try { 
/* third, Glue gets a proxy to the Web service through its WSDL */ 
IProxy proxy = Registry.bind( wsdlName ); 
/* here, service's operation is invoked through a proxy */ 
proxy.invoke( operation, args ); 
} catch( java.rmi.UnmarshalException e ) { 
// Glue is catching the UnmarshalException that is perfectly expected 
} 
/* forth, Glue generates an XML document containing the SOAP body, */
/* and passes the whole document for parsing  */ 
 return new Document( responseHandler.getResponse() ); 
} 
} 
class SOAPInterceptor implements ISOAPInterceptor { 
private Element soapBody; 
public void intercept( SOAPMessage message, 
Context messageContext ) { 
try { 
soapBody = message.getBody(); 
} 
catch( Exception e ){ 
 System.err.println( e.toString()); 
} 
} 
public Element getResponse(){ 
 return soapBody; 
} 
} 

       

												
										

您能从上面的例子中学到很多东西。首先，由 Glue 引入的代码是一个两层代码。一层“消除”了 SOAP 分离的负面效应，通过使用 Java 异常处理程序和一个专门的组件——SOAP 拦截器来拦截这种特定的应用程序异常而实现。第二层将服务调用的结果作为完整的 XML 文档来提交给调用应用程序。然后，XML 文档通过使用一个诸如 DOM 结构的工具进行分离。显然，这样的方法不能“安全地”移植到其它 Web 服务工具中。但更重要的是，尽管拦截应用程序异常的技术广为人知，但它真的适合于 Web 服务调用吗？

一般而言，异常是 Java 语言极为有用的特性，特别是，这意味着一种检测错误位置、无计划的编程操作（如使用空指针）的简单方式。使用这种技术作为一个计划的控制操作，而不是写一个 if-then 逻辑段来测试一个指针是否真正为空，使代码的可管理性与可维护性显著地复杂化。显然，SOAP 分离并不同于空指针。您不能通过一个简单的 if-then 代码测试出来。不过，它们的负面影响是相同的——抛出异常并捕获它，这是一项代价非常高昂的技术，特别是如果您需要获得每秒数千次的 Web 服务调用的话。换句话说，运行时异常应该专门针对意外情况作为“防御线”而保留，以应对软件的错误。

我进一步指出为什么分离 SOAP 的问题不能通过一个 Java Exception API 进行处理的更多原因。但是，让我们先来看看引用的范例所显现的另外一个问题。由于调用操作需要直接分析 XML，它不得不访问响应信息的 XSD 定义，而且必须依次成为提供的 WSDL 文件的一部分（且被存根产生工具所使用）。这里的最终结果就是甚至一些后期绑定的形式也存在于引例之中；在 Web 服务伙伴之间的紧耦合依旧存在。换句话说，Web 服务的客户端必须访问 WSDL 文件，并且在大多数情况下，它必须是一个完整（而不是部分）的 WSDL 文件。

还存在一个与使用 JAX-RPC API 相关的问题。记住这是非常必要的：在 Java 语言中，由于在 XML schema 中的数据类型不能直接准确地映射到 Java 语言的数据类型当中，所以在调用的应用程序端 WSDL 中产生的服务终端接口将与 JAX-RPC 编译器在调用端产生的 WSDL 的形式不同。而且，生成的服务接口也将依赖于 SOAP 采用的编码体制。例如，使用文档文字编码利用了每个方法类的封装版本，并造成了额外的可管理性与可维护性的问题。

Web 服务编程构件的自由应用程序逻辑：最佳实践设计模式

根据到目前为止的讲述，您容易想到使用任何种类的动态调用技术（如后期绑定的动态代理），不幸的是，许多开发者都是这样做的。关于 Web 服务其中一个最常见的误解就是，使用动态调用取代静态存根的好处并没有那么大，而且最好是坚持用生成的存根作为 Web 服务调用的主要方法。

最后，我们的讨论转到第二个，而且是最重要的原则——它不是真正的编程技术，它确保不依赖服务编程构件（如 WSDL），但是取而代之的是，它的价值体现在高级设计中。这对于获得 SOA 的真正利益是必要的，因为随着服务的发展，服务消费者的代码将完全不受影响。无论如何，基于 SOA 的应用程序必须注重于提供弹性体系结构，且更少的关注于公共通信协议（比如 SOAP）。服务与应用之间不应该具有严格的界限。一个终端用户的应用程序可以被看作是其它终端用户的服务。整个企业 IT 环境应该被设计成高度模块化，允许开发者能够挑选适合他们需要的服务与应用组合。

在良好的 SOA 设计中，Web 服务消费者的应用逻辑能够使用两个基础体系结构原则来从服务构件完全解耦：

• “保持可适应性”——创建一种方法来支持多接口继承（理论上，这将不受限制），在开发有限数量的具体实现（在面向对象的设计当中，经常将匿名的内部类作为对象适配器使用，考虑上下文，允许工作行为的定制，实际上是嵌入在子类之中）。
• “使用所谓的好莱坞原则：不要调用我们，我们将调用您”——Web 服务调用模型应该只通过动态代理框架来指定发现，并假定客户端事先对服务一无所知；因此，Web 服务提供方应该能够通过将存根类信息声明到 XML 文档，从而在运行时宣传他们的服务。那实际上就以一种开放且可执行的方式，提供了发现之外的另一种调用方法（换句话说，优于 UDDI）。

最终设计目标是，为 Web 服务消费者应用提供一组类，这些类根据上面引述的原则组成了可重用适配器层。这种适配器层封装了使用存根及其生成的类的代码。适配器的公共 API 并不公开任何存根类；而是将其映射到 Web 服务消费者应用可以理解的类。

为了得到最好的适配器灵活性与可扩展性，适配器的总体类结构均通过使用下列设计模式的组合来构建：

• 动态代理是一种结构模式，它定义了一组类与方法调用，这些类和调用被分派给调用句柄（在动态代理类生成的时候指定）。使用动态代理是 Java 编程中模拟多实现继承的关键。通过动态代理，定制的 InvocationHandler 能够由一组表示合成子类的超类来构建；该子类的接口将是这些超类实现的接口的联合。
• 适配器是一种结构模式，它通过对实现的抽象进行解耦来影响类层次（比如继承层次）的创建，因此两者可以单独改变。这种允许在运行时选择实现的解耦避免了抽象与其实现间的永久绑定。作为 Web 服务客户端的调用应用的类仅处理抽象。
• 服务配置器是一种行为模式，它使您可以改变适配器超时性能，并添加或去除附加功能，这样就改变了调用框架的规范。例如，如果一个 Web 服务提供方引入了一个新的协议（如在 RMI 上的 SOAP），那么它只需要“宣传”新的传输性能。因此，适配器演示了这种新服务能力与这种调用功能的任何实现。使用一些元数据表示作为结果，必须具备一种方法能够引用提供了独立于特定规范与实现的功能类的接口。
• 工厂方法（Factory Method ）是一种结构模式，它使一个类延迟实例化到子类。在 Web 服务调用的情况下，本地与远程实现类都必须是子类，以实现它们的特定于服务的实现。需要访问服务的调用应用将得到这个工厂的一个句柄，并给服务一个调用。因此，根据从服务配置器得来的信息，工厂封装了访问服务必须使用的实现知识。
• 装饰（Decorator）模式是一种结构模式，它定义了缓存、发布与交换服务声明的封装器，用于连接合适服务与可重用的代理类。 通过使用装饰模式，实现执行调用的代码与提供缓存的代码相分离，将非常简单。

关键实现指南

图 2 演示了使用上面引用的设计原则而设计的“好莱坞”类型适配器的概念模型。 图 3 展示了使用适配器时的基本交互的序列图。

创建一个使用适配器的服务，包括创建一个使用服务描述符（代表 SOAP 服务）的服务类。这个描述符被包括在服务类成员之中。服务类被作为 SOAP 来部署，例如，使用来自 Open Source Foundation 的 Axis。

服务描述符包括：

• 类名：包含服务实现的全限定类名的元素。
• 名称：包含服务名的元素。
• 版本：包含服务版本名的元素。
• 创建者：包含服务创建者名称的元素。
• AssertURI：包含指向一个 XML 文件的统一资源标识符（URI）的元素。其中，XML 文件包括服务声明（规范）。
• 描述：包含服务描述的元素。

现在，有一个关于 Axis 的耦合注意事项。使用 Axis 作为 SOAP 引擎非常有助于实现 Web 服务的松耦合，理由如下：

1. 因为 Axis 定义了消息处理节点，该节点能够被封装以供服务请求者（客户端）与服务提供者（服务器）使用，适配器能够使用部署描述符作为一个 Web 服务部署描述符（WSDD），应用一个消息处理节点来部署 SOAP 服务。
2. Axis 中的服务通常是 SOAP 服务的实例，它包含请求与响应链，但是必须包含实际服务类的提供方。结果是，通过将消息上下文传递给消息处理节点来完成 SOAP 服务的处理。
3. Axis 客户端处理能够通过使用服务描述符和 XML 声明文件创建包含服务细节的调用工厂实例，从而构建调用对象。调用对象的属性被设定为使用相关的目标服务。然后，调用对象就通过调用 Service.createCall 工厂方法来创建。一旦建立起调用，Call.SetOperation 就通过被调用的方法名称来指定。然后，Call.invoke 通过相关的请求消息而被调用，它驱动 AxisClient.invoke，处理结果消息上下文，并向客户端返回响应消息。

在适配器的设计中，应该对性能进行特殊考虑。使用动态代理类具有性能含义。访问目标的直接方法快于访问代理类的方法。然而，这不应是在稳健体系结构与性能之间进行选择。这就是为什么目前适配器实现缓存封装器的原因。通过应用缓存，使用静态存根与基于适配器的解决方案之间的差异相对较小。根据如何实现缓存，必须提到可能的解决方案之一——记忆（Memoization）。 记忆是一种广泛使用的技术，它在 Lisp、Python 与 Perl 这样的功能编程语言中使用，给功能赋予预先计算的值。记忆一个功能将为功能添加一个透明的缓存封装，因此已经得到的值将从缓存中返回而不是每次都重建。记忆可以显著提高动态代理调用的性能。

总结我们关于此处描述的适配器的讨论，允许支持本地和远程服务实现的设计是非常重要的。服务类对适配器来说将是本地的，而远程 Web 服务则可以相互替换，因为服务类和代理类使用同样的接口来访问远程 Web 服务。本地服务类将实现与 Web 服务器远程实现相类似的方法 getFunction() 来返回功能的结果。下面的 Java 代码片断进一步说明了这一点：

												
														public class LocalServiceImpl implements IService
{
/* get the service results */
public ….. getFunction() 
{
………..
return …………;
}
}


												
										

实现了 IService 的代理类采用了方法 getFunction()，但并未考虑该方法需要访问远程 Web 服务的代码。这些代码代表了需要用来访问部署在适配器内的任意 Web 服务的代理代码。

												
														public class RemoteServiceImpl implements IService 
{
/* get the service outputs */
/* outputs are from the web service running in the location */
/* mentioned in the serviceURI */

public ….. getFunction()
{
adapter.examples.Function service = null;
String serviceURI = "http://……../Function/";
String wsdlURI = "http://localhost:8080/Function/";
Try
{
// init the lookup
WebServiceLookup lookup = (WebServiceLookup)
……….
// get the instance of the Web services interface
// from the lookup
service = (adapter.examples.Function)
lookup.lookup(wsdlURI,
adapter.examples.Function.class,
serviceURI);
}
catch (Exception e) 
{
e.printStackTrace();
}
// now, call the methods on your Web services interface
return service.getFunction();
}



												
										

结束语

显然，使用 Web 服务的静态存根与前期绑定是 Web 服务调用的最简单的形式。但是简单化也带来了明显的缺点。与紧耦合方法不同，使用本文提出的适配器方法将给您留下可高度重用和可配置的 Web 服务代码。由于 Web 服务 调用全部通过部署了服务描述符的公共适配器来引导，因此您能够动态地决定调用什么服务——在部署代码时或在运行时。

同样，那些可能寻找商业产品作为 Web 服务松耦合调用定制解决方案的组织应该研究企业服务总线（Enterprise Service Bus，ESB）技术（参见参考资料），该技术提供了类似于上面所引述的功能的选项来连接企业内部及跨企业的可作为 Web 服务的应用程序，并具备一套功能来管理并监视已连接应用之间的交互。

迁移到 SOA 和网格

网格应用程序的一个永恒的问题是，使其足够灵活，以在各种平台和环境中使用。尽管早期的网格使用了专用的解决方案，其中采用的是严格受控的硬件和环境，但是最近的发展已经清楚地表明，将网格应用程序放到更为广泛的平台上运行，这样您只需要添加一些机器就可以很容易地扩展网格的范围和处理能力。

然而，平台之间微小的差异可能会导致非常令人头疼的事情。例如，Windows® 不同版本之间的改变，甚至是 Windows NT 和 Windows 2000 之间的差异，也都会导致那些网格环境中通常经过严格设计和优化了的应用程序出现问题。一个显然的解决方案是去掉那些高度与平台相关的元素，并切换到一个更加通用的环境中。

SOA 幕后的准则遵守一些基本的规则。SOA 是一个用来构建应用程序的基于组件的模型，可以将应用程序划分为很多离散的服务，这些服务各自执行某个特定的功能，但是可以将它们组合在一起构成更大的应用程序。

SOA 的基本原理现在已经并不新鲜了。面向对象的概念已经出现了很多年，分布式对象也已经在很多技术中存在很多年了，例如 CORBA。主要的区别在于，SOA 是基于面向对象和 Web 服务两个概念的组合，并在一个用来描述可用接口的开放系统中采用了这种结构。通过使得 Web 服务可以更容易发现和识别，SOA 可以极大地简化基于 SOA 应用程序的部署和分布。由于 Web 服务都是基于开放标准的，在其定义中就保证了体系结构和平台的无关性，因此基于 SOA 的应用程序可以部署到各种平台上。

简而言之，SOA 是一种对外提供服务的方法，让计算机可以彼此进行交谈，并共享自己的处理能力和功能。网格正在慢慢地朝 Web 服务架构发展，首先是 Globus 采用开放网格标准基础设施（OGSI），然后是发布 Globus Toolkit 4.0（GT4）。SOA 和网格技术正基于诸如 Web Services Resource Framework（WSRF）以及其他的一些解决方案，朝 Web Standards Interoperability 技术方向发展。

您还可以看到 SOA 和网格都可以为对方提供很多东西。这并不是网格技术利用 SOA 准则的情况，或者反之。从 SOA 的观点来说，网格为信息和资源的分布提供了一个异常模型，这是 SOA 模型的一个关键特性。从网格的观点来看，SOA 为调整网格解决方案的架构以及促进其透明性和更好地支持广泛的平台和环境，提供了一些可选的而又非常灵活的方法。

下面让我们来了解一下传统的网格模型，然后介绍一下基于 SOA 的网格模型，从而比较二者之间的区别，以及如何开始将网格和 SOA 应用程序作为一个单一的资源进行考虑。

传统的网格模型

为了全面地理解 SOA 如何才能改进网格服务，以及需要如何修改应用程序，下面让我们来看一个基于传统的网格技术的典型网格服务，包括基本的 Web 服务。这个服务的基本结构非常简单。

在图 1 中您可以看到一个典型的网格环境的结构图。其中我故意没有说明网格软件的类型，因为大部分网格软件都可以根据相同的原理进行工作。

总体上来看，这个结构相当简单。我们有一个网格协调者负责分发信息并与各个节点进行工作。这个协调者（它还有很多别的名字，包括分发和管理节点）的职责就是运行网格。协调者与工作节点之间的通信可能在很多解决方案中都存在，不过大部分系统（包括 Globus）都是依赖于 Web 服务的。此处使用的模型通常都称为级联服务，因为信息和工作请求都是通过服务进行级联，从而将其从某个地方分发到各个节点上。

然而，不管采用哪种通信系统，其方法大体上是相同的：

• 严格结构的意思是说，节点都是使用一个特定的 Web 服务或 Web 服务接口与某个软件的特定部分进行联系的，从而处理来自节点协调者的请求。
• 任务提交是通过协调者进行处理的，它分布在各个节点上，通常使用一个 Web 服务来提交任务。在工作节点上，有一个类似的客户机将完成的任务发回给网格协调者。
• 网格节点所需要的其他信息（例如大型的数据结构或引用材料）可以在网络上通过另外一个服务进行访问，Web 服务可能支持，也可能不支持。例如，有些网格使用一个集中的 SQL 数据库来存储节点不通过 Web 服务接口而是直接访问的信息。

总体来说，大部分网格服务（直到最近）都是基于大型的单一代码基础的，它使用了一些私有的方法来进行通信和共享信息。这使得 Web 服务模型也正在发生改变，但是即使采用了 Web 服务标准之后，很多解决方案也都可以对原有的单一应用程序使用一个 Web 服务接口。例如，从上面这个传统的模型中我们可以看出，将任务提交到一个节点是通过一个 Web 服务接口提交给网格节点的，这实际上会将面向 Web 服务的接口暴露给原来的应用程序。

这种单块方法存在一个问题，即使使用 Web 服务，它也会限制扩展和增长的能力。采用这种单块风格，将应用程序移植到其他平台和环境就会变得更加复杂。如果您的系统不是基于 Web 服务的，那么问题可能就更加严重。增长之所以会受到限制是因为它依赖于单个协调系统来负责在网络间分发信息。如果您的客户机也是一个单块接口（即使它同时还使用 Web 服务来提供接口），那么将网格应用程序部署到很多机器上也会变得更加困难。

SOA 应用程序模型

SOA 并不是使用 Web 服务来集成应用程序不同部分并在其间进行通信的另外一个简单术语。SOA 要走得更远，它定义了一种方法来部署应用程序，这样可以将注意力从由多个函数和对象组成的单个应用程序转移到一种将整个应用程序划分为多个单一服务的结构上来。例如，考虑一个记帐程序，它有一些组件负责开具发票并提供一种方法进行支付。除了传统的组件应用程序模型之外，您还可能会希望为这两个任务定义一些对象和相关方法。

在一个简单的 Web 服务环境中，您要为对象和方法构建一个接口来允许访问需要远程访问的内容。例如，开具发票这个任务可能需要您通过网络连接进行访问。在所有的可能性中，Web 服务都会在一台专用的机器上有一个专用的接口，为其构建一个接口需要了解这台服务器上都在运行什么服务，以及为其提供接口需要的详细信息。

在一个 SOA 中，这个记帐应用程序中的每个功能从技术上来说都可以作为一个 Web 服务。每个服务都会在网络上广播自己的存在，您可以在任何经过适当授权的机器上执行任何操作。而且，由于每个服务都是自己可以控制的一个组件，因此它们可以存在于网络上的任何地方。我们不再需要一台专用的服务器来处理请求。例如，我们可以使用一个服务器农场，由于服务会广播自己的存在，因此我们不必担心如何发现这些服务。

从上面的介绍中，我们可以确定 SOA 的主要元素是：

• 可以作为一个单独的服务使用 —— 所提供的服务质量的级别还需要作为一项标准确定。例如，我们还不知道是否要提供一个可以处理多个操作和多个服务的单一发票服务，每个都支持不同的操作，例如开具发票、支付发票或修改发票。
• 独立性 —— 我们并不关心它们是如何来实现我们请求的任务的。它们只要实现这个功能就好了。类似地，服务也并不关心如何来达到这个结果。
• 服务会广播自己的存在。

因此从理论上来说，应该可以将一个应用程序划分为更小的组件，然后可以将其连接在一起（通过相互调用），从而构成最终的应用程序。由于这些单元也可能会扩展到多台机器上，因此我们需要从这种单块、级联结构切换到一种更加灵活的分布式、自由通信的结构。在图 2 中您可以看到一个 SOA 结构的例子。

SOA 网格模型

从上面对于 SOA 模型的介绍以及目前网格技术朝着 Web 服务结构发展的趋势可以清楚地看出，二者正在不断融合。使用简单的术语来说，网格是一个共享资源的分布式系统，而 SOA 则是一个分布式体系结构，后者最关注的是服务的相互操作能力、易于集成、简单性、可扩展性以及安全访问的特性。这两个系统有一些共同的问题，包括延时、并发和局部故障等问题。

二者都使用了 Web 服务，图 3 给出了一个可以在 SOA 和网格环境中使用的简单布局。二者都大量地采用了 SOAP、XML Web 服务标准以及相关的安全性、管理和其他系统。