刚才说了很多负面的东西，先贬后褒吧！

7. 看到很多队伍，特别是本科队伍，在有课程安排的情况下还坚持搜集了很多资料，写blog，作品应该很完成得很棒，经常做到晚上2，3点。自叹不如，应该向你们学习！
8. 有很强的开源精神，技术充分共享，想法充分交流。
9. 团队协作在很多团队的blog里体现得很充分，分工合理，充分沟通，共享资源。不但把自己的本质工作做好，还能为他，为整个团队做出持续的贡献。这样的团队是NB的，1+1绝对大于2！

以下是我经历这个初赛的一些想法和看法，和大家分享一下。估计已经开始结仇家了，哈哈！
*/

我的回复内容：

1.恩，集体重装机器。从微软的C一套集体过渡到IBM的java一套，哈哈。
2.我们队目前乱七八糟的文章加起来有179篇，不属于您说的这种情况。
3.我感觉我们队伍还是很有希望的，想给评委点儿好印象，就提前一周交了。
4.以前回过10个帖子以内，最近回了20个左右。算混脸否？
5.我们在报名的时候写blog了，http://www.cppblog.com/zhangji198543
6.我们有50篇的文档是报名的第一天的时候就发上去了，那些是我选的一些文章,一是方便其他队员再寻找文章,另一个是为了大家能够多用SOA思想武装自己,最后统计有60篇技术文档。

7.我们队伍3个人都是本科生,上午上课,下午1点半到晚上10点半在公司实习.周末有时候加课.2.3点是正常.呵呵.您是在说我们吗?
8.这一点我们做的不够好,很多东西没往上面发.
9.这点是必须的,我觉得很多团队都会做的很好.

• 参赛团队可以根据该网页中的要求整理出相应的设计文档，至少应该包括文档清单、项目综述、系统架构设计、组件设计、系统开发实施计划安排等内容，可以增加业务模式分析设计、服务模型分析设计以及对SOA在项目中的体现和理解方面的内容，此外还可以根据大家的设计与创新，增加其他的文档。
• 参赛团队也可以将所有的文档整合成为一个大的单一文档提交，但是要保证在该文档中建立了明确、清晰的文档结构图或者索引图，以便我们浏览检视。
• 文档的篇幅原则上不做要求，但是希望大家能够在清晰陈述设计的基础上，尽量保证语言的简洁和篇幅的短小精干。一般来说，所有文档的总页数不应该超过100页。
• 如果方便，请同时提交项目团队成员的个人简历，供我们参考。
• 请以PDF（推荐）或者Word格式提交所有的文档。

流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出。例如，技术文档搜索流程从 Web 页面提取客户的搜索请求，并生成可选的文档列表。

对流程进行建模是非常大的挑战。建模应当确保捕获的相关信息的一致性及完整性，以便业务分析员及开发人员能够理解模型所捕获的业务需求。在建模过程中，除了正常操作以外，标准流程的其它操作和异常必需获取。具有不同领域兴趣的专职人员和专家可以构建适合于大范围业务对象的流程模型。例如，分析员需要对流程有高度的见解以做出战略性决策，并进行诸如仿真之类的流程分析。开发人员将流程模型作为输入来实现解决方案。

分析员基于从业务需求所有者中所收集的需求构建业务流程 (BP) 模型。通过使用适当的工具（例如 PowerPoint、spreadsheets、IBM® Rational® Requisite Pro 或者其它任意工具组合，并且在适当的时候可能是流程建模工具本身）来收集这些需求。分析员将这些需求及对现有流程的分析作为构建模型的输入条件。现有的流程模型用于对其进行分析或者通过修改现有的模型来创建新的流程模型，而不用从头重新创建。

通过将 BP 分成子流程开始建模过程。随后是对感兴趣的各子流程进行分析以确定组件、服务、输入输出数据、策略及测量。通过使用 WebSphere® Business Integration Modeler 软件工具 (Business Integration Modeler) 将这些元素编码到 BP 模型中。

使用一种名为流程元素的建模构件来定义 BP 段，将其设计为可复用。流程元素是一种定义流程段的构件资产，在 BP 模型中，这种流程段被设计为可复用的构件来管理。它们将已建立的一系列任务、决策、对数据对象的引用、策略、角色及测试合并起来。例如，登录流程元素包含一系列活动，登录证书数据以及完成用户登录过程的登录规则。

这些流程元素表示可接受的操作行为，类似的需求也可复用它们，例如，作为子流程模型以检验和为购物篮中的商品定价。

服务元素是预先定义的服务，可以被导入到 Business Integration Modeler 中以集成到模型中。这些服务元素指定了输入、输出以及发布的 Web 服务的操作。例如，服务元素可以指定发布远程部件提供者的 Web 服务。

进行 BP 建模的工具

Business Integration Modeler 为分析员提供了工具以进行建模、分析、仿真，并在将它们转换或导出到 Rational XDE 的 UML 模型或 WebSphere Business Integration Server Foundation (Business Integration Server Foundation) 的 Web 服务的业务流程执行语言 (Business Process Execution Language for Web Services，BPEL4WS) 中之前改进了业务流程。我们使用 Business Integration Modeler V5.1 来创建 BP 模型并且将它们导出到 WebShere Studio Application Developer Integration Edition V5.1.1 (Application Developer) 中，如图 1 所示。

Business Integration Modeler V5.1 提供了一套丰富的流程建模功能，包括许多图形化及文本编辑器、业务操作模型 (business operations model，BOM)，以及用于将 BOM 转换成相应的目标平台构件的转换机制。

如图 2 所示，分析员在适当的编辑器（例如，用于 BP 工作流（包括活动及它们之间的连接）的图形表示的用户流程编辑器）中创建了各种流程元素。这些流程元素作为 BOM 存储在磁盘文件中。Business Integration Modeler 自动应用 BOM 上的相应确认。在模型导出的后期，分析员将应用适当的转换机制将 BOM 转换成相应的目标构件。图 2 显示了受支持的四种类型的输出构件：

1. Business Integration Modeler 构件（业务流程执行语言 (BPEL)+/XML Schema 定义 (XSD)/Web 服务描述语言 (Web Services Description Language，WSDL)）
2. MQ 工作流的 FlowMark 定义语言 (FlowMark Definition Language，FDL)
3. UML
4. 受限文本

业务流程建模包含：

1. 收集 BP 需求。
2. 模型业务项目。
3. 模型角色和资源。
4. 模型服务。
5. 模型策略。
6. 模型关键性能指示器 (Key Performance Indicators，KPI)。

我将在接下来的部分中详细地介绍每一步。

收集 BP 需求

BP 分析员与 BP 所有者及领域专家协作来获取所需的全部信息以构建 BP 模型。例如，分析员使用适当的工具收集角色、任务、序列信息、资源、数据、叙述、需求，等等，并将它们作为构建 BP 模型的输入内容。通过在 Business Integration Modeler 中创建流程模型，业务分析员所获取的信息可以轻易地导出给工作流开发人员，使他们在 Application Developer 工具中使用这些信息。

模型业务项目

业务项目是业务文档、工作产品或者在业务操作中使用的商品。业务项目的一些实例包括订单文档、客户地址及材料帐单。分析员可以导入以 XML schema 格式定义的数据模型或者使用 Business Integration Modeler 来创建新数据模型。

数据建模的元素包括创建如下内容：

• 数据目录
• 业务项目
• 业务项目模板
• 业务项目实例

数据目录是用于组织业务项目、模板及项目实例的文件夹。数据目录的创建是可选的；如果没有选择，那么将会以 Business Integration Modeler 默认的业务项目数据目录来创建数据模型。

创建业务项目并将其添加到现有的数据目录中。随后将业务项目属性添加到业务项目中。例如，我们有 order 业务项目，它有诸如 orderItems 和 valid 之类的属性。这些属性可能是简单类型（String、Integer、Boolean 等等），也可能是同一或不同数据目录中的业务项目。例如，order 业务项目可能包括 OrderItem 类型的属性 orderItems，该类型位于同一或不同数据目录中。

业务项目模板可以用于创建具有公共属性的业务项目。新建的业务项目可以添加新的模板中没有的属性。例如，可以创建具有适当属性的 orderItem 模板，然后使用该模板无需输入完整的 orderitem 属性就可以创建 purchase order 和 manufacturing bill of materials 项目。此外，可以通过添加新的属性来添加适当的扩展名。例如，您可以从 orderItem 模板中创建 purchase order 项目，然后加入额外的属性，如 purchase date、location、store 等等。业务项目实例表示具体的业务项目事件，例如，制造号码为“1xDBCS”的订单。

对业务项目进行建模的指导

可以将规则与业务项目和它们各自的属性联系起来。但是，由于目前 BPEL 输出不支持该功能，所以它应当被添加到模型中以帮助开发人员开发。我们推荐将创建数据目录及业务项目作为流程建模的第一步，以便它们可以与其它任务相关联。

通过设置项目属性的最小值和最大值来创建业务项目的定购序列（数组）。无论何时只要可以就使用 WBI 模型中的 XSD 引入选项从现有的 XML schema 元素中引入业务项目。将数据目录映射到 java 包及 XSD schema 的目标命名空间中，因此我们推荐使用适当的使用数据目录名称以避免开发问题。

模型业务角色和资源

资源是指人、设备及执行任务所用的材料。角色为资源添加了额外的特征。例如，雇员可能是经理。为任务指派角色主要为了在具有员工活动的流程中使用。例如，管理员可能处理任务中的异常（例如，无效的命令、系统崩溃）。通过调整资源分配来进行流程分析。该分析提供了资源利用级的详细信息并且有助于计算耗费及周转时间。这有助于优化和改进流程。此外，对于工作流而言，角色用于将人分配到员工活动中。

模型服务

在 Business Integration Modeler 中，服务被定义为外部实体（不包括在被建模的流程之内），可以从组织流程的内部使用这些外部实体。

在 Business Integration Modeler 中，可以将一套输入分组作为输入标准。每个输入标准都定义了特殊的输入组合，这些组合可以启动流程、服务或任务。如果输入不止一个，那么默认按照与的条件。对于或条件，可以创建额外的输入标准。向 BPEL 导出时，限制每个元素只能有一个输入标准。类似地，使用输出标准将输出分组。在 Web 服务 WSDL 接口模型（portType 定义）中，这些输入及输出标准分别被映射到操作输入及输出的消息中。

对业务服务进行建模的指导

虽然可以为每种服务创建许多输入及输出标准，但是在 BPEL 中这是不允许的。对于基于 BPEL 的可执行的工作流来说，推荐有限的一个输入标准及一个输出标准。WSDL portType 操作接受单一的输入消息及单一的输出消息。清单 1 展示了如何将输入标准及输出标准映射到 portType 操作的输入及输出消息中。

												
														<portType name="ValidateGenerateTopologyPT">        
<operation name="sendValidateGenerateTopology_InputCriteria">
   <input message="tns:InputCriteriaMessage" 
name="InputCriteriaMessage"/>            
<output message="tns:OutputCriteriaMessage" 
name="OutputCriteriaMessage"/>        
   </operation>    
  </portType>
  					
												
										

目前还不能通过复用现有的服务 WSDL 来创建服务元素。要复用现有的 WSDL 需要更改已生成的代码。随后开发人员应当通过 BPEL partnerLinks 与适当的外部服务相关联。

模型业务策略

分析员可以指定需要的策略，但是需要显式的、可执行的规则来实施这些策略。策略通常是要声明的，例如，“仅美国客户可以定购机器 X”。在实施中每个策略可能需要一个或更多的实施点。实施点可以作为流程的显式步骤或代码中的指定位置来实现。处理事件的时候也可能出现实施点。规则对于实现策略实施点来说是有效的方式。规则是强制性的且在逻辑上是可执行的。清单 2 展示了一个简单规则的实例。

												
														"If !(location(customer) == "USA") then reject(order);"
												
										

在某些情况下，没有显式地声明策略，但是在实现中隐含地定义了策略。换句话说，实际的已实现的实施点和规则定义了策略。

分析员将策略写入每个任务的注释中。开发人员负责将策略转换成规则。分析员可以向模型中添加服务元素，这代表了提供实施点的现有服务。他们还可以添加任务来表示实施策略的代码的占位符。开发人员为实现该任务添加必要的代码，换句话说，就是执行适当的规则。（详细信息请见“随需应变业务流程的生命周期”系列文章的第 4 部分——请参阅参考资料）。

为流程建模

为流程建模的任务包括定义业务流程的细节，并为所有数据、资源及流程中所使用的其它元素建模。业务流程包含一些流程步骤，它们通过控制流相连接，这些控制流将活动与决策点相连。决策点遵循业务规则（转换条件），使用这些业务规则来确定流程应当依照什么路线进行。建模包括将 BP 分解成子流程并将所需的流程元素添加到模型中。分析员可以将现有的模型构件（例如，服务或流程元素）用于促进并加速模型的构建。文章“使用 WebSphere Business Integration Modeler 进行业务流程建模”（“随需应变业务流程的生命周期”系列文章中的部分）描述了从建模构件中构造流程模型（请参阅参考资料）。

模型关键性能指示器

关键性能指示器 (KPI) 是为跟踪业务的关键因素的成败而设计的。BP 监视功能使流程所有者及管理员能实时监视 KPI。这些功能有助于分析员确定现有流程中的问题及瓶颈，从而结束开发循环，如该系列文章中的第 1 部分中所述（请参阅参考资料）。Business Integration Modeler 提供了将 KPI 添加到流程中的工具，来记录我们希望跟踪的那些流程的关键因素（详细信息请见文章“使用 WebSphere Business Integration Modeler 进行业务流程建模”）。

其他的建模指导

• 在 Business Integration Modeler 中存在三种模式：FDL、BPEL 和 Operational。如果将在 Business Integration Server Foundation 中执行流程，那么应该使用 BPEL 模式建模。这有助于在导出模型之前在 Error View 中查看并且确定验证错误。
• 应该使用高级业务建模的用户配置文件来添加运行时需求，如控制任务执行的输入标准和对资源的使用。
• 业务项目建模细化——可以不定义业务项目的所有细节，随后将其细化成更多的细节，如新的属性。它们也可以从 XSD 文件中引入。
• 故障处理不应是模型中的内容，而应留给流程开发人员处理（例如，对服务超时的处理）。

流程模型的验证

将模型放置在 BPEL 模式中，这样就启动了 BPEL 验证检查装置。任何错误及警告都会出现在 Error View 中。您可以通过过滤该列表来显示错误信息或警告信息，并且从整个项目到仅所选定的元素中选择模型级别。可以导出有错误的模型，但是最后应该找出这些错误以防止在以后的导出中再次重复出现。

流程模型导出

模型人员将所需的 BPEL、XSD 及 WSDL 文件导出到 Application Developer 工具中——或者导出到现有的服务项目中或者导出到一个文件夹中，以后在导出到服务项目中。

图 3 显示了所生成的文件，以及流程模型元素与生成的文件中相应的构件之间的关系。例如，生成复合业务项目作为 XSD Complex 类型。可以导出整个业务建模项目，或者项目中所选定的部分。在导出时另一个重要的选项是流程执行模式。存在三个不同的选项，默认值是长期运行（请求-应答）。

流程执行模式

当将流程模型导出到基于可执行的流程构件的 BPEL 中时，三种可用的执行模式是：

1. 长期运行（接收/应答）——该选项将可执行的 BPEL 工作流模式设置成长期运行的流程并将流程操作指定为具有输入及输出消息的双向操作。长期运行的流程是可中断的，这使得引入员工和其它活动需要可中断的流程。
2. 长期运行（接收回调）——该选项将可执行的 BPEL 工作流模式设置成长期运行的流程并将流程操作指定为单向操作，即仅接受输入消息而不接受输出消息。然而，创建回调操作使得流程能够将结果返回给调用者。创建了 BPEL 相关性设置，但没有添加相关性属性。期待开发人员以后添加必要的属性。
3. 微流程——该选项创建了接受双向消息的流程操作。然而，这些流程是不可中断的，所以不能向流程中添加员工活动。如果流程模型包含具备资源的任务及基于员工的角色，那么可以导出具备员工活动的模型。然而，输出的可执行模型存在验证问题，开发人员必需更正这一点。

结束语

业务分析员的组织管理严密的建模过程是随需应变业务流程生命周期方法学的关键。业务流程模型定义了技术架构以校准 IT 开发的业务规范。共享的模型存在于业务流程的整个生命周期中，有助于保持业务和 IT 视图的同步性。本文介绍了一些流程建模概念，通过这些概念分析员可以使用 WebSphere Business Integration Modeler V5.1 来定义业务流程。此外，本文还给出了一些建模指导，并描述了 Business Integration Modeler 中的各种输出选项及生成的作为开发工具输入的构件。

附录

Business Integration Modeler V5.1：核心功能

WebSphere Business Integration Modeler V5.1 是特别为业务用户设计的易于使用的工具，使他们能够捕获并编制业务流程的具体步骤。包括下列核心功能：

用户配置文件：Business Integration Modeler 提供了三种不同的用户配置文件，使得对于同一流程模型可以有不同的视图。这三种配置文件是：初级、中级、高级。这些配置文件与不同的用户角色相联系。业务领域的专家或分析员使用初级配置文件，它将业务任务作为活动序列，而其余的模型信息作为文档来获取。中级配置文件在技术上更针对于数据模型的细节、表达式及基数信息，并且它更适合于业务架构师。高级配置文件提供了更详细的流程及数据模型的信息。此配置文件非常适用于解决方案中或适合于 IT 架构师。注意，转换配置文件不会改变基本的数据模型。

技术模式：存在三种技术模式：操作、BPEL 及 MQ Workflow FDL。依照技术专家对所需细节的看法，您应当在模式之间进行切换。在某些模式中一些选项及符号元素可能失效了，所以选择合适的模式有助于为目标流程的执行环境定义适当的构件。注意，转换模式不会改变基本的数据模型。

目录：这些是对类似的建模实体的逻辑分类。包括：

• 数据（例如定购、产品之类的业务项目）
• 流程（主要的流程、子流程、服务、任务）
• 资源（例如客户服务代表、销售经理之类的角色，或者例如 Web 服务器、应用服务器之类的资源）
• 组织（组织层次、位置）
• 报告（总结、比较、文档）

这些分组增强了建模实体的可复用性。

流程：流程是活动的顺序、执行这些活动时所规定的条件的顺序、执行活动所需要的资源顺序，以及活动同服务交互时传递的数据流的顺序。通过使用工具提供的图表符号来将这些流程建模。

仿真：流程模型仿真帮助组织观察在不同的输入下流程是如何执行的。该功能提供了对于输入的更改、对于消耗因素的关联，以及对于资源或当前配置的调整，来模拟真实的业务场景。这些分析增强了对于关键路径、最短路径、周转时间及对于流程模型的耗费/时间的测量的分析。

报告：该功能为流程分析及重新设计提供了非常有价值的指导。存在各种可用的报告功能，包括流程摘要、对于两个流程模型的比较、ROI 测试中的 As-Is 和 To-Be 的比较、文档及过程（规则、策略及过程）报告。

分析：在流程模型中可以进行两种分析：静态分析及动态分析。在静态分析中，大多数信息是从模型中提取出来的，并用于分析消耗、时间管理、性能、流程有效性及资源水平。动态的分析是由基于输出日志或事件的模拟流程的输出过程来完成的。存在两种动态分析：聚合分析（基于多个流程模型元素的执行过程）和实例分析（使用流程元素的特定序列的执行实例）。

Process modeling
Swimlane modeling
Visio Import
Eclipse integration
Six Sigma Support
Reporting
Crystal Reports Integration
Team support (CVS/ClearCase)
Basic, Intermediate and Advanced Editing Modes

WebSphere Business Modeler Advanced

Basic plus…
Performance simulation
Swimlane simulation
Business analysis (static/dynamic)
WebSphere Process Server support
WebSphere MQ Workflow support
WBI Server Foundation support
UML, XML, XSD support
Business Measures (Monitor) support
Collaboration support

WebSphere Business Modeler Collaboration Server

One-step process model Web publishing
Web-browser-based Portal interface
Access control at process, catalog or project level
Feedback on specific artifacts or entire processes
Attach documents and URLs

WebSphere Business Modeler Collaboration Edition

Bundle:

WebSphere Business Modeler Collaboration Server
10 licenses of WebSphere Business Modeler Advanced

虽然 SOA 可以带来许多好处，但同时也可能受到以下一个或多个问题的困扰：

• 高复杂性和短上市时间，这样会增加失败的风险
• 由于高成本和量化投资回报 (ROI) 困难而导致较难容忍出现错误
• 需要恰当管理的动态要求和业务需求

如果您使用了软件方法——软件开发的系统方法——来在初始 SOA 推出期间提供所需的严格控制和过程，并在优化 SOA 的过程中进行调整，就可以避免这些问题。在考虑此处给出的软件方法之前，请阅读本系列的第二篇文章，该文指出，在面向服务的体系结构成熟度模型的第 3 级或第 4 级的“面向服务的体系结构成熟度模型”组织应使用 RUP 等正式的软件方法进行开发工作。只要达到了第 5 级，他们就应该使用 XP 之类的灵活方法了。

您的企业如何在保持开发过程一致的前提下过渡到较高的成熟度级别呢？本文将介绍一种最佳组合的方法，面向服务的统一过程 或 SOUP，用于开展构建工作并随后进行持续优化。在继续阅读本文之前，您应当对 RUP 和 XP 的工作方式有基本的了解。请参阅参考资料，以获得可帮助您了解相关知识的链接。

什么是 SOUP？

SOUP （Service-Oriented Unified Process）是一种使用 RUP 和 XP 中的最佳部分来构建和管理 SOA 项目的软件方法。它的目标是任何组织中正在进行的 SOA 项目。

典型的软件开发项目包含应用程序开发过程、项目管理以及所使用的技术。此外，软件开发项目通常具有四个变量：时间、预算、范围 和质量。任何一个变量的变化对整个项目都有影响。不断变化的业务需求使得范围和质量成为两个最难管理的因素。技术复杂性可能导致时间和预算管理方面出现问题。

SOA 项目比通常的软件项目复杂得多，因为它们要求配备更大的跨功能的团队，并且还有因此而带来更复杂的团队间沟通和日常管理工作。

虽然 SOA 可以为组织带来许多好处，但同时也可能带来很大的成本支出和时间消耗。如果项目没有经过良好定义，并且在项目启动时没有关于最终结果的远景，则失败的可能性就非常大。

可以帮助 SOA 成功完成的关键因素有：

• 明确定义的开发过程
• 与业务相关的项目团队之间增强的沟通渠道
• 明确的支持和控制策略

在初始开发过程中，采用正式软件方法是尽可能地减少已确定的风险的最好办法。成功建立了 SOA 项目后，可利用正式的维护和增量开发方法来增加项目的 ROI。然而，XP 之类的灵活方法可能不够正式，不适合在初始阶段使用。SOUP 方法可帮助减少 SOA 推出阶段的风险，并能让您随后进行持续 SOA 优化工作。

SOUP 是一个由六个阶段组成的软件开发方法。每个阶段代表对于 SOA 成功推出非常关键的一组特有的活动。当然，和在任何项目中一样，您将需要根据所在组织的情况对相关过程进行调整。

图 1 显示了 SOUP 过程。此方法也没有非常特别的地方：所有软件或 SOA 项目都是采用类似的方式定义的。

我将 SOUP 过程分为两类：

• 用于初始 SOA 部署的 SOUP
• 用于后续 SOA 管理的 SOUP

用于初始 SOA 部署的 SOUP

图 2 显示了用于初始 SOA 部署的 SOUP 的各个阶段。

每个阶段都包含主要交付内容和活动：

初始

在此阶段，将确定组织对 SOA 项目的需求。您可以通过应用 SOA 成熟度模型来确定组织的体系结构成熟度水平并确定 SOA 的驱动因素。此时，您将需要向为业务服务的所有项目团队说明 SOA 的基本概念，并拟订与反馈和建议流程有关的策略计划。

此阶段的主要交付内容有：

• SOA 远景和范围：给出项目的整体远景。它还提供了确定项目范围的边界，该范围至少应包含两个业务线或项目。
• SOA 策略：说明项目将如何执行的概略计划。
• ROI 分析：给出此项目将带来的成本支出和节省情况。
• 沟通计划：说明 SOA 团队将如何与其他项目团队和业务用户进行沟通。

客户（即业务干系人）通常并不能完全了解新软件产品可以带来的好处。定义 SOA 策略的企业团队需要利用项目团队的专业知识来帮助确定业务问题以及简化操作的方法。

跨功能分析人员和项目管理人员将对客户的业务进行分析，以确定基于 SOA 的解决方案的优势。分析人员将对客户的内部操作进行研究，此外还要分析其与合作伙伴、供应商以及他们的客户的交互情况，而且也会研究其总体业务模型。这些因素有助于分析人员制定 SOA 策略并向客户推荐。

在此阶段，您还需要对推荐的 SOA 策略进行全面的 ROI 分析。此分析应当清楚地表明短期、中期和长期的成本优势。

此阶段最重要的交付内容是沟通计划。项目 IT 团队和业务干系人比体系结构团队和分析人员更了解业务。沟通计划可以确保这些内部干系人能够理解并参与到开发过程中来。

定义

到目前为止，定义阶段是 SOA 项目中最为关键的阶段。此阶段业务和项目团队的参与将最终决定项目的成功。团队成员需要积极地参与到作为初始 SOA 推出的一部分开发的需求定义和用例方面的工作中来。

项目生命周期的此阶段的活动包括：

• 收集需求
• 分析需求
• 定义非功能需求
• 制定项目计划，其中包含时间安排和项目估算
• 定义技术基础设施
• 定义和实现用例
• 定义和记录总的体系结构

此阶段的主要交付内容有：

• 功能需求文档：详细描述 SOA 将作为业务服务提供的所有业务流程。
• 非功能需求文档：包括性能注意事项、服务水平协议 (SLA) 和基础设施要求。
• 用例和用例实现：详细说明将构建的所有业务服务的用例。
• SOA 体系结构文档：描述项目总的体系结构，包括硬件和软件组件。
• SOA 适用性文档：说明哪些项目将在 SOA 项目的范围内以及如何在 SOA 的基础上构建后续项目。
• 基础设施定义文档：包括详细的基础设施部署图，其中列出相关服务器以及实现 SOA 所需的服务器的连接和连接位置。
• 项目计划：整个项目的详细计划，包括里程碑和依赖关系。
• 支持和控制模型：描述将如何支持和控制 SOA。其中包括各种注意事项，如 SLA 监视和管理。

研究（请参阅参考资料）表明，与需求相关的问题是软件项目失败的首要原因；SOA 项目也不例外。软件质量 有时定义为软件对其需求的满足情况。但是，测定软件质量的更好办法可能是通过其满足的需求的质量 测定，而不是通过其满足的需求的数量 测定。

在明确说明了交付内容后，SOUP 方法将建议一个用于进行需求收集和管理的正式流程。XP 并不定义用于收集和记录需求的正式流程；而 XP 开发人员将创建一些用户案例（请参阅参考资料）并按逻辑顺序对这些案例进行排列，以提供一个需求序列。在此开发阶段，这样的流程并不够用。在 RUP 中，相应的流程更为详细，并使用更多的正式技术来确保举行相关的需求收集会议、对需求进行记录并加以验证。我建议使用需求存储库，该存储库将与用例、设计和代码紧密结合，以在项目进行的整个过程中提供可跟踪性。该存储库可以为 IBM Rational® RequisitePro® 工具或您组织选用的任何其他需求管理工具。更改管理流程也很重要。

此阶段最重要的交付内容是支持和控制模型。组织将如何支持 SOA？控制指导方针有哪些？如果推出了一个 SOA，但没有人使用，则项目就失败了。支持和控制模型文档可以防止发生这种情况。

企业应当在制定了真实可行的计划和目标的情况下启动项目。其他需求应留待以后解决。如果在预期的时间和预算内，可以完成有关需求的有效业务-IT (B2IT) 协作，则可以帮助确保项目的成功。

请在项目早期定义支持整个 SOA 所需的技术基础设施。这包括服务器、网络基础设施和培训要求方面的详细评估。

设计

在设计阶段，您将对定义阶段确定的设计构件进行细化。用例实现和软件体系结构文档将转化为详细的设计文档。

此时，SOA 架构师（通常为企业架构师中的一部分）需要与项目架构师合作，以确保 SOA 团队给出的设计可以供具体的项目使用。SOA 架构师甚至可能选择完成一些概念验证 (proof-of-concept) 项目，以证明 SOA 远景。此阶段的主要交付内容有：

• 详细设计文档：描述如何设计和构建服务。
• 应用程序编程模型：提供有关设计开发项目的结构的指南。涉及的主题包括使用的流程和技术、编码标准以及部署过程。
• 数据库模型：包括 SOA 使用的数据库的实体关系图。
• 测试和 QA 计划：详细说明测试和 QA 计划，并在其中包括测试用例。

构造

在构造阶段，将使用您选择的迭代构建方法来构建 SOA。此阶段中包括新的开发和集成活动。您的活动不仅限于软件方面，还涉及到与基础设施相关的子项目，如硬件整合项目或服务器承载集中化工作。虽然整个工作是在单个 SOA 项目中进行管理的，但仍然很有可能将由各种小型子团队进行不同的构造活动。

项目生命周期的此阶段将涉及到各种活动，如：

• 迭代开发
• 迭代 QA 和测试
• 用户文档

此阶段的主要交付内容有：

• 基本代码：该代码应存储在某类源代码管理存储库中。
• 测试结果：执行测试用例和 QA 计划的结果应可供进行检查分析。
• 文档：文档中应包含关于代码以及对设计文档的任何更新的详细信息。

部署

在部署阶段，您将向各个项目团队推出 SOA，这些项目团队将开始在其生产环境中的项目上使用此 SOA。此阶段最明显的主要交付内容或许就是投入生产环境中使用的应用程序。然而，SOA 试验项目的计划却是更为重要的交付内容。这将导致进入 SOUP 方法的下一个步骤，该步骤将确定后续项目如何使用新体系结构。此阶段的其他主要交付内容有：

• 部署模型：给出总的 SOA 部署结构。
• 用况模型：提供有关如何使用 SOA 的指南。随着各个项目团队和业务线开始使用新体系结构，此模型会变得非常重要。
• 后续支持级别模型：将对定义阶段开发的支持和控制模型的任何更新进行系统化。

支持

软件开发周期的这最后一个步骤非常重要。在支持阶段，您将确保提供后续 SOA 支持、错误修正和进行新功能开发。项目生命周期的此阶段将涉及到各种活动，如：

• 维护
• 错误修正
• 培训
• 持续项目投入

您的 SOA 现在已经投入生产了。但项目团队如何从该体系结构受益呢？为了构建使用现有服务的应用程序，或设计使用现有 SOA 的新服务，他们是否需要遵循上面详细列出的所有步骤？正如您将在下面的部分中看到的，实际上，他们可以从一个更为轻量级的方法中获益。

用于后续 SOA 管理的 SOUP

SOUP 方法可以用于那些使用已经推出的 SOA 的项目。在这种情况下，SOUP 对 XP 进行了大量的参考。图 3 表明了 SOUP 和 XP 过程彼此重叠。

这种方法主要带来什么样的好处呢？SOA 项目的价值在于，它可提供良好定义的体系结构和严格的技术指南。您获得了一个框架，可以在其中以服务的形式构建应用程序。项目团队的主要任务是构建和使用服务。他们最适合执行这些任务，因为他们具有必要的业务领域知识。但是，他们并不需要考虑技术体系结构或技术的创新，因为这些任务将由 SOA 团队完成。

此类项目将遵循上一部分中列出的相同 SOUP 指南；不过，您将发现，每个阶段的工作量都大幅度地减少了。这一部分的许多交付内容都和前面描述的一样；必要时，我会说明它们与从头构建 SOA 时的项目中的对等项之间的差异。

初始

启动 SOA 并运行后，仍然需要进行一些开发工作。您无疑将希望构建使用现有服务或公开新服务的项目。初始阶段的主要交付内容有：

• 项目远景和范围：这仅包含单个项目的范围，而不包含更大的 SOA 计划的范围。
• 项目策略：描述此具体项目的策略和流程，并说明其如何利用 SOA。
• ROI 分析：项目的详细成本优势分析，这对于帮助进行与实现有关的决策非常关键。

定义

在定义阶段，您将构建与 SOA 项目有关的各项内容，并了解如何利用 SOA。您需要标识 SOA 可以提供的服务和仍然需要构建以满足您的项目目标的服务。

项目生命周期的此阶段的活动包括：

• 收集需求
• 标识服务
• 制定项目计划，其中包括时间安排和项目评估
• 开发测试用例

此阶段的主要交付内容有：

• 功能需求文档：软件项目的典型需求文档。
• 用例和用例实现：涵盖所有正在构建的新业务流程。
• SOA 适用性文档：说明现有 SOA 框架如何应用到此项目。
• 项目计划：详细说明整个项目，包括里程碑和依赖关系。
• 服务策略：标识已经存在并能够使用的服务以及可以公开的新服务。
• 测试计划：其中包括项目的测试用例。

在此阶段，您不需要严格遵循在 SOA 推出期间遵循的正式需求收集标准。相反，可以通过用户案例或类-责任-协作者（Class, Responsibilities, Collaborator，CRC）卡（请参阅参考资料）来简化需求收集。根据 XP 的思想，测试案例是在这种类型的项目的早期构建的。

设计

此阶段可以迅速完成，因为大部分服务都在初始 SOA 推出时已经完成。在设计阶段，只需要关心如何使用这些服务，需要在现有服务的基础上构建什么功能，以及需要构建哪些新服务。

此阶段的主要交付内容有：

• 详细设计文档：说明您的设计如何利用总体 SOA，并建立设计与应用程序编程模型。
• 数据库模型：封装供此特定项目使用的逻辑和物理数据设计。

构造

构造阶段涉及更多的是装配，而不是新部署。随着提供的服务越来越多，每个项目都将有越来越多的可重用服务，而需要构建的新服务也就越来越少。XP 的迭代开发技术是此开发阶段的最佳选择。在 XP 中，理论上的迭代周期设置为两周，当在 SOA 环境中构建小型服务和使用一组服务时，这一时间对于一个开发 Development-QA 周期来说绝对足够了。使用此迭代方法，SOA 可以通过快速软件发布提供有价值的业务灵活性。

项目生命周期的构造阶段的活动包括：

• 迭代开发
• 迭代 QA 和测试
• 用户文档

此阶段的主要交付内容有：

• 新服务：在本阶段结束时，任何将要公开的新服务都会准备就绪。
• 测试结果：执行测试用例所得到的结果应提供给所有相关方。
• 文档：此开发阶段应产生详细的代码文档以及对以前创建的其他文档的所有必要更新。

部署

在此阶段，将启动使用多个服务的应用程序，或启动新服务。由于基础设施是由 SOA 团队进行管理的，因此该流程相对比较简单。

支持

在此阶段，将仅为您的新服务提供支持。在进行此项工作的过程中，请遵循在原始 SOA 项目期间制定的支持指南。单个项目不需要花很多时间制定新的支持指南。

管理 SOA 生命周期

本文向您介绍了 SOUP，这种新的软件方法可用于构建 SOA 并将此体系结构的好处带给各个项目。文中说明了可以如何使用类似于 RUP 的正式方法来对 SOA 进行初始构建，然后转向 XP 样式的灵活流程，以进行后续服务推出工作。通过实现这两个过程的最佳组合，您可以依靠一个统一的开发模式来进行相关工作，此模式可提供足够的灵活性，以便对 SOA 生命周期的不同阶段进行管理。

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

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

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