本文是面向服务的体系结构(SOA)系列之一，主要通过名为JKHL Enterprises(JKHLE)的虚构公司阐述一个案例研究。本文的案例研究重点是与SOA设计（更具体地说是服务和流的设计）相关的挑战和解决方案。本文描述如何应用“SOA设计场景”的实现和解决方案模式来解决与该案例研究相关的业务和IT挑战。

　　我们在本文中介绍的案例研究包括以下人员和角色：

　　·Sandy Osbourne-Archer，首席技术架构师
　　·Edmund Smythe-Barrett，企业架构师
　　·Ursula DeBarry，软件架构师兼服务设计团队主管
　　·Henry Lee，业务分析人员
　　·Jason Smith，集成开发人员
　　·Willy Sheng Duo Li（也叫Willy Li），应用程序开发人员

　　帐户开立项目的挑战

　　我们在本文中定义的帐户开立项目挑战与“SOA设计场景”相关。该场景的重点包括用于SOA设计（更具体地说是服务和流的设计）的方法、构件和工具。

　　软件架构师兼服务设计团队主管Ursula DeBarry从业之初担任的是J2EE?开发人员，后来成为了软件架构师。

　　她拥有娴熟的设计技能，在应用诸如Rational Unified Process(RUP)和面向服务的建模与体系结构(Service Oriented Modeling and Architecture，SOMA)之类的方法方面非常熟练。除了使用IBM Rational Software Architect之类的工具对她所负责的项目进行应用程序建模和组装以外，她还为同事组织了多个关于方法和工具使用的研讨会，并在其中负责授课。

　　Ursula对专门从事SOA设计方面的工作特别感兴趣。在Ursula之前担任的职位中，她完成了Web服务试验项目的设计和实现。不过，这个试验项目由于政治原因而取消了。

　　她非常渴望寻找新的SOA机会。Ursula从以前的同事——应用程序开发人员Willy Li——那里了解到，JKHL Enterprises正在寻找有经验的软件架构师和服务设计师来实施SOA计划。Ursula前去JKHL Enterprises应聘。

　　首席技术架构师Sandy Osbourne-Archer对Ursula进行了面试，由于她本身具有丰富的经验、娴熟的技能，并且有Willy Li推荐，因此当场就被录用了。Ursula非常高兴能担任软件架构师兼服务设计团队主管。

　　在与Sandy的首次会面中，Ursula了解了帐户开立项目的目标和挑战。Sandy表示，自己对业务和IT之间存在的语义差异和细节差异不甚满意，因为这些差异容易出现不同步或不完全一致的现象（请参见图1）。

　　Sandy强调了保持业务设计和IT解决方案一致的需求，以便保持企业对新业务机会的敏捷性和响应能力。

　　图1当前业务和IT不同步（不一致）
 
　　Sandy列出了帐户开立项目的高级业务目标：

　　·目标1：降低成本：

　　1.1: 降低创建和管理帐户的成本

　　1.1.1: 降低帐户激活的成本

　　1.2: 减少纸质文档的数量

　　1.2.1: 增加电子应用程序的数量

　　·目标2：提高每个客户拥有的产品数量
　　·目标3：提高可用性
　　·目标4：减少不遵从法律法规的风险
　　·目标5：增加客户自助服务
　　·目标6：加快上市时间

　　Sandy总结了高级设计目标和挑战：

　　·业务设计：

　　清楚地定义业务战略和目标
　　以业务驱动的方式对服务需求、设计和实现进行优先排序
　　提高服务重用，以加速上市时间并降低成本

　　·IT解决方案设计：

　　为关键业务活动的服务提供显式的可跟踪性
　　可重复且可扩展的设计方法
　　能实现更好重用的服务组合
　　用于多通道访问的服务绑定策略
　　方便组装、部署和管理的解决方案

　　SOA设计场景的帐户开立计划

　　通过一系列的会议，Ursula和企业架构师Edmund Smythe-Barrett共同制定了SOA设计场景的帐户开立计划。

　　他们与业务分析人员Henry Lee进行了讨论，对为帐户开立项目定义的关键业务需求有了更好的理解。图2描述了帐户开立高级流程，提供了该流程的关键元素的概念视图。

　　图2帐户开立高级流程
 
　　为了提高SOA设计的成熟度和改进帐户开立流程，Ursula计划应用用于服务设计的SOMA并执行用于流程组合的业务服务设计。

　　应用SOMA进行服务设计

　　Ursula指出，IBM Global Services的架构师和专家开发的SOMA方法基于从客户合作项目中获得的知识。Ursula希望能够利用经过验证的SOMA方法进行帐户开立服务设计。

　　IBM提供了两种应用SOMA进行服务设计的方法：

　　·用于服务设计的SOMA

　　在此方法中，客户通过服务约定雇用IBM，让他们的架构师和专家来应用SOA方法和IBM工具来代表客户进行服务设计。

　　Ursula和Edmund一致同意，对于该帐户开立项目，他们将参加与IBM的服务合作项目，以便在使用“用于服务设计的SOMA方法”来创建服务设计方面获得帮助。服务设计团队和IBM将应用SOMA方法来确定服务，指定服务和流，并实现该服务设计。与IBM的合作将帮助服务设计团队为将来的项目获得SOAM的实际应用知识。

　　·业务转换分析(BTA)和服务设计

　　在此方法中，客户通过应用IBM Rational Method Composer中包含的RUP SOMA方法直接创建服务设计。BTA和服务设计的重点是通过应用自动化的设计工具和流程，以改进设计一致性和加速上市时间，从而提供正式的说明性服务设计方法。或者，客户可以雇请IBM Services代表他们应用BTA和服务设计。

　　在旨在使将来的SOA变得更加自给自足的工作中，Ursula领导的服务设计团队将开始培训BTA和服务设计的使用。

　　用于流程组合的业务服务设计

　　Ursula将领导帐户开立项目的用于流程组合的业务服务设计。

　　将SOA场景模式应用于该案例研究

　　SOA设计场景的重点是通过使用经过证明的IBM方法和工具，从而使业务设计与IT解决方案设计保持一致。诸如组件业务模型（Component Business Model，CBM）、SOMA和RUP for SOMA等方法提供了概念框架，用于定义建模的方方面面以使业务与IT设计保持一致。使用IBM工具来支持设计方法，以对可跟踪性建模并创建整个生命周期中的设计构件。SOA设计场景可应用于每个基本SOA场景。

　　SOA设计场景模型的基本构造包括流、服务和组件（请参见图3）。

　　·流或流程表示完成某个业务流程所需要的活动流。流是旨在实现业务目标的相关和集成服务的组合。
　　·服务是代表性的可重复业务任务。通过提供定义良好并且与实现无关的接口，从而将服务用于封装应用程序的功能单元。服务可由其他服务或客户端应用程序调用（使用）。
　　·组件表示服务向服务使用者公开的功能，以及由实现服务的服务提供者提供的服务质量 (QoS)。

　　图3服务提供业务与IT之间的一致性
 
　　注意：SOA设计场景的关键元素是服务设计。

　　服务设计以及最终的服务通过在业务流和目标与IT组件之间提供桥梁，从而提供一致性能力（如图3所示）。

　　以下几个部分将详细描述该案例研究解决方案元素，这些元素映射到SOA设计场景实现：

　　·用于服务设计的SOMA
　　·业务转换分析和服务设计
　　·用于流程组合的业务服务设计
　　·用于服务设计的SOMA

　　注意：用于服务设计的SOMA实现特别利用了SOMA标识、规范和实现阶段来交付所需的SOA设计成果。

　　Ursula和IBM Services合作项目团队开始通过应用用于服务设计的SOMA方法来处理帐户开立服务设计。该团队集中于服务设计的以下方面：

　　·服务标识
　　·服务规范
　　·服务实现

　　SOMA方法是用于SOA设计和构造以支持目标业务流程的分析和设计方法。SOMA通过服务、组件和流的标识、规范和实现来完成此任务。SOMA v3.1扩展了SOMA，以提供同时还包括实现、测试、部署、监视和管理活动的端到端方法，如图4所示。

　　图4 SOMA方法
 
　　SOMA方法提供了用于SOA设计的描述性指导，并且是SOA解决方案设计模式的基础（请参见图5）。

　　图5用于SOA参考体系结构分层解决方案的SOMA指导
 
　　服务标识

　　服务标识的目标是创建候选服务及其对业务有意义的关联操作的初始集合。服务标识主要由软件架构师来完成，并且通常包括业务分析人员以支持角色形式的参与。

　　在服务标识期间，将创建服务模型工作产品，并移交给负责服务规范的软件架构师。服务标识与产生服务模型的分析级别同义，而服务规范则是设计级别。

　　服务标识的关键输入包括：

　　·业务分析和建模

　　用于定义业务体系结构。CRM通常用于业务分析，以帮助客户了解其业务和能力，并确定能力差距。也可以使用其他方法来进行业务分析。

　　·服务注册中心和存储库

　　现有的服务和有关它们的信息通常存储在服务注册中心和存储库中。该帐户开立项目是第一次采用SOA；因此不存在现有的服务。

　　让我们进一步了解三种用于确定候选服务的补充技术：

　　·目标-服务建模
　　·领域分解
　　·现有资产分析

　　目标-服务建模

　　目标-服务建模的关键目标是证明服务的可跟踪性和与业务目标的一致性。目标-服务模型是一种由内向外(middle-out)的方法，在相应输出可用时迭代地用于验证通过领域分解和现有资产分析技术确定的候选服务列表的完整性。

　　在开发目标-服务模型时，您通常与业务主管、业务分析人员和主题专家紧密合作，以确定范围内的业务目标和项目的阶段。对于每个目标和子目标，您将确定可用于评估业务性能的关键性能指标(KPI)和度量。

　　JKHLE销售管理业务组件中的服务标识重点目标是确定支持该业务组件的服务。表1提供了一个业务目标的摘要和支持KPI，以说明目标-服务模型。

　　表 1 目标-服务模型的业务目标和KPI

　　领域分解

　　对于领域分解，我们采用自顶向下的方式工作，将业务领域分解为主要的功能区域和子系统。在下一个级别，我们进一步将功能区域分解为流程、子流程和高级业务用例。

　　注意：高级业务用例通常是作为服务公开的理想候选者，并且可以提供初始的设计范围。

　　领域分解使用并增强领域分析和领域工程方法的子集，包括：

　　·功能区域分析

　　将领域分解为功能区域可以为IT子系统及其实现服务的对应服务组件的设计提供业务边界。如果没有提供CBM，则为SOMA合作项目执行领域分析。

　　·流程分解

　　执行业务流程建模以将流程分解为子流程和任务。对于初始的候选服务列表，三个级别的分解通常就足够了（请参见图6）。

　　·面向变化的分析

　　全面观察流程、规则、策略和结构（数据），以确定候选共性。下一步，分离出流程、规则和结构的变化。

　　图6流程分解
 
　　分解集中于“帐户开立”流程以及“帐户激活”和“验证”功能区域，如图7所示。

　　图7帐户开立流程和功能区域的领域分解输出
 
　　现有资产分析

　　现有资产分析的主要目标是最大限度地重用现有的应用程序事务、现有系统中的模块和打包的应用程序。在执行现有资产分析时，我们采用自底向上的方法以确定候选服务。可能会确定一些新服务，并且在其他情况下，该技术将确认前一项技术的标识结果。

　　观察图7，Ursula与Edmund使用自底向上的方法，共同确定JKHLE环境中的现有应用程序和事务，以最大限度地实现重用。Edmund让Ursula知道许多现有的中间件和后端应用程序，例如CICS、IMS、SAP和Siebel。Ursula评估每个现有的应用程序，以确定应该将哪些应用程序作为帐户开立流程应用程序的服务公开。他们可以使用IBM WebSphere Studio Asset Analyzer来扫描IBM System z（大型机）和分布式软件，以确定并在存储库中存储相关的应用程序信息，其目的是促进和了解哪些资产可以成为可重用组件并作为服务公开。

　　现有资产分析并不只是将现有的应用程序接口作为Web服务公开。需要周密考虑以确定现有应用程序的接口是否允许良好的服务设计（请参见图8）。

　　图8将现有应用程序作为服务公开的选项
 
　　如图8所示，存在几种公开现有应用程序的选项：

　　·将现有应用程序包装为服务

　　将功能保留原样，但是使用工具或中间件将现有功能作为服务公开。例如，将CICS应用程序作为SOAP Web服务公开（也称为直接公开）。

　　·将现有功能包装并替换为服务

　　按上述方式包装功能，但是在以后使用最终的服务规范来重新开发服务。然后，替换原始服务，并将客户端重定向到新的实现。

　　·使用更适合于服务调用的适配器

　　在某些情况下，无法包装某个功能并将其作为服务公开。

　　但是，能够以更容易集成的形式包装该功能，例如消息队列接口或Java连接器体系结构（Java Connector Architecture，JCA），从而允许新服务就地访问该功能（也称为间接公开）。

　　·将功能集成到服务中

　　在某些情况下，只需将现有的功能用作服务实现中的一个逻辑组件，即可让新服务就地访问该功能。

　　在执行每一项标识技术之后，将确定一个修订后的候选服务组合，这样就为制定规范做好了准备。

　　服务规范

　　服务规范定义依赖关系、组合、公开决策、消息、服务质量约束以及与服务状态管理相关的决策。服务规范任务的目标是详细描述服务模型。

　　服务规范包括以下子任务：

　　·应用Service Litmus Test以做出公开决策
　　·确定服务依赖关系
　　·确定服务组合和流
　　·确定非功能性需求
　　·指定服务消息
　　·编写状态管理决策文档

　　应用Service Litmus Test以做出公开决策

　　使用Service Litmus Test以做出服务公开决策。图9突出显示了需要公开的JKHLE候选服务。

　　图9要公开的服务
 
　　确定服务依赖关系

　　详细的服务检查可以揭示对用于实现服务功能的其他服务或应用程序的服务依赖关系。

　　存在两种需要考虑的依赖关系类型：

　　·功能依赖关系是这样的服务之间的依赖关系，即这些服务彼此依赖以交付所需交付的服务。例如，AccountActivation组合服务具有对ARSetup、AccountSetup和createAccount服务的依赖关系。
　　·流程依赖关系是这样的服务之间的依赖关系，即这些服务编排在一起以构成业务流程。例如，帐户开立流程依赖“确定资格”前提条件和“创建帐户”流程依赖关系。

　　确定服务组合和流

　　检查功能区域和业务流程可以帮助详细描述服务及其流的组合。服务流规范描述服务之间的编排。例如，帐户激活组合服务是一个长时间运行的可中断流程宏流。“帐户查询”是一个短时间运行的不可中断流程（微流）。

　　确定非功能性需求

　　服务模型必须考虑用于指定服务质量(QoS)的非功能性需求。例如，“帐户查询”服务可用性需求为99.999%，帐户激活服务的帐户激活性能需求为在四天内激活。

　　指定服务消息

　　服务模型中的数据流通常以在服务之间流动的消息的形式表示。在确定服务规范的过程中，存在数据模型未完成的情况。要考虑有关将实现的服务的详细信息在此时间点不足够的情况。虽然如此，仍然需要考虑用于服务输入和输出的数据和消息。例如，表2指定了AccountInquiry服务的服务消息。

　　表2指定服务消息

　　编写状态管理决策文档

　　在某些情况下，服务组合需要编写状态管理文档，例如有状态、无状态、带有缓存状态的状态等等。

　　例如，存在流程的某些部分的状态管理可能由组合服务或其他元素控制的情况。

　　服务组件规范

　　服务规范任务的最后一部分是组件规范。孤立地执行此任务通常是非常困难的，因此实现任务通常并行地执行并且是迭代的。服务组件规范包括以下子任务：

　　·确定组件属性
　　·确定事件和消息
　　·确定组件内部流
　　·创建组件类关系图
　　·面向变化的设计

　　可以使用IBM Rational Software Architect，以UML的形式为服务组件规范任务创建若干工作产品。

　　服务实现

　　在确定并指定服务以后，需要做出有关每个组件如何实现功能的关键体系结构决策。

　　服务分配

　　在整个生命周期中以迭代的方式将服务分配到组件，以执行用于将服务分配到企业组件的服务分配。例如，帐户查询服务被分配到客户CICS后端系统（请参见第12页上的图7）。

　　技术可行性探索

　　需要确定并评估技术约束，以确保公开候选服务在技术上是可行的，对于在现有系统分析期间确定的服务尤其是如此。通常使用技术原型来探索技术可行性。

　　将组件分配到各层

　　将组件分配到应用程序体系结构中的各个SOA参考体系结构层是在指定组件并编写实现决策文档之后执行的（请参见第12页上的图7）。

　　表3提供了关键的服务实现决策的摘要

　　表3服务实现决策

　　SOMA建模环境

　　SOMA建模环境（Modeling Environment，ME）提供模型、方法、IBM工具和内容的内聚联系，以支持对用于IBM客户服务合作项目的SOA解决方案进行基于资产的开发。

　　业务转换分析和服务设计

　　注意：业务转换分析（Business Transformation Analysis，BTA）和服务设计实现使用RUP SOMA业务转换分析方法。

　　服务设计使用IBM Rational Method Composer包括的RUP SOMA方法中捕获的过程。IBM Rational Software Architect用于创作和重用服务设计模式和最佳实践，包括数据和部署建模以及服务组装。

　　Ursula和服务设计团队成员开始进行有关如何使用BTA和服务设计的培训。该团队计划使用此方法为将来的SOA项目创建服务设计。

　　在“用于服务设计的SOMA”中，我们在“帐户开立项目”的上下文中描述了SOMA的核心元素。在本部分，我们将重点介绍业务转换分析(BTA)和服务设计实现的关键元素，这些元素利用了IBM Rational Method Composer中包括的RUP SOMA方法。BTA和服务设计实现通过应用自动化的设计工具和流程，以改进设计一致性和缩短上市时间，从而提供正式的说明性SOA设计方法。

　　图10显示了核心RUP SOMA用例和参与者。RUP SOMA利用了“应用基于模式的工程方法”的概念。

　　请注意，参与者将带模式的BTA和服务设计应用于执行业务转换分析用例，以及包括标识、指定和实现服务的核心SOMA用例。

　　图10 核心RUP SOMA用例
 
　　图11显示了用于BTA和服务设计的扩展流程。RUP SOMA流程步骤显示得非常粗略。更详细的信息在IBM Rational Method Composer包括的RUP SOMA方法中。

　　请注意数据建模、集成服务和部署建模的连锁流程。在此例中，RUP SOMA流程使用数据建模的结果。集成服务和部署建模主要是RUP SOMA的后续流程。管理可重用资产是扩充所有其他流程的基础结构流程。

　　IBM推出的重用管理解决方案基于IBM Rational Asset Manager，后者用于管理和治理对任何角色和规则有利的几乎任何资产的重用。Rational Asset Manager可以与IBM WebSphere集成在一起。服务注册中心和存储库支持在组织的标准资产重用流程上下文中重用和治理与服务相关的运行时资产。

　　图11 BTA和服务设计扩展流程关系图
 
　　图12显示了RUP SOMA中定义的主要活动：

　　·执行业务转换分析：生成用作服务设计输入的业务和业务流程模型。
　　·标识服务：发现候选服务并将其组织为层次结构以便于理解。
　　·指定服务：指定服务的外部视图，并充实服务传递的消息。
　　·实现服务：做出有关服务实现的决策。

　　RUP SOMA流程没有充分强调可靠的需求管理在整个SOA设计生命周期中的作用。因此，添加了管理需求流程元素。如图12所示，整个生命周期中非常协调地使用了IBM WebSphere Business Modeler、IBM Rational RequisitePro和IBM Rational Software Architect。

　　图12用于BTA和服务设计的核心RUP SOMA流程
 
　　在下面的几个部分中，我们将重点介绍核心BTA和服务设计用例的重要参与者、方法与模式、工具和工作产品。

　　执行BTA

　　图13显示了执行BTA流程中的主要活动。BTA的结果是创建了描述以下内容的工作产品：

　　·业务的静态结构

　　创建业务分析模型并执行功能区域分析的活动。

　　·业务的动态特性

　　创建业务用例模型，并通过WebSphere Business Modeler业务流程实现业务用例。

　　BTA活动可以产生业务体系结构的完整描述。BTA活动还可以提供与业务相关并且是服务设计的必需输入的模型。服务设计还使用业务规则和业务目标作为服务发现的输入。BTA还包括集中于那些构件的活动。

　　图13 RUP SOMA——执行BTA
 
　　标识服务

　　图14显示了用于标识服务的RUP SOMA流程。该流程依赖并行执行的子任务，这些任务用于标识候选服务。同时使用不同的方法可以极大地提高发现完整候选服务集的机会。

　　图14 RUP SOMA——标识服务
 
　　指定服务

　　图15显示了用于指定服务的RUP SOMA流程。该流程用于定义服务的外部视图，以及用于实现服务的子系统和组件的外部视图的设计。在每个抽象级别，描述了接口、接口签名、接口协议和消息。此外，将在总体流程的此部分期间处理更细粒度的元素（例如原子服务）的编排，以实现更抽象的元素（例如组合服务的接口操作）。

　　在此级别的设计完成之后，可以使用产品化的Rational Software Architect转换来创建可供IBM WebSphere Integration Developer使用的项目和内容，包括描述服务接口的WSDL文件和描述元素（这些元素用于实现服务）执行的BPEL。内容为集成开发人员提供了起点，此起点基于解决非功能性以及功能性需求的已架构IT解决方案，从而给集成开发人员带来好处。

　　图15 RUP SOMA——指定服务
 
　　实现服务

　　图16显示了用于实现服务的RUP SOMA流程。做出有关使用哪些现有资产来实现服务的决策。

　　在使用新组件以实现服务的情况下，将做出有关在总体系统体系结构中的何处使用那些组件的决策。

　　图16 RUP SOMA——实现服务
 
　　用于流程组合的业务服务设计

　　注意：用于流程组合的业务服务设计实现演示了使关键业务度量与业务目标保持一致的流程建模和模拟。

　　Ursula从业务分析人员那里了解到需要对帐户验证流程进行流程改进。Ursula使用IBM WebSphere Business Modeler来模拟现有的流程，然后在通过关键度量模拟来实现的流程优化基础上创建了建议的流程。

　　当前帐户验证流程

　　下面，我们将描述当前帐户验证流程（如第26页上的图17所示）。帐户协调人员检查客户申请，并研究有关多个不同系统的信息，以确定是否需要信用报告。

　　如果不需要信用报告，则客户申请将跳过该流程的大部分内容。如果需要信用报告，则帐户协调人员将向信用调查机构打电话或发送传真，以请求信用报告。由于通信方法（传真或电话）问题，信用调查机构没有为JKHLE提供针对其服务的优惠定价。获得多个信用报告非常昂贵并且耗时。

　　JKHLE无法区分高风险和中等风险的客户，从而导致远高于行业平均水平的大量拒绝受理请求。最后，帐户协调人员发出了批准。批准的定价是通过参考一组复杂的纸质手册来确定的。

　　当前流程中存在多处流程改进余地。

　　·缺乏单一客户视图和信用流程业务规则导致我们定购了超过需要的信用报告。
　　·手动的信用报告检索流程高度不一致、代价昂贵并且非常耗时。
　　·太多的客户请求被拒绝，导致潜在客户不愉快并导致销售代表不满。
　　·虽然定价和帐户规则相当简单，但是其值更改得非常频繁。由于该过程是手动的，很难实现快速更改。

　　图17帐户验证（现有）
 
　　预期的帐户验证流程

　　Ursula在WebSphere Business Modeler中修改了模拟的帐户验证流程来处理上述流程改进，以创建如图18所示的基准。接下来，Ursula可以通过更改流程中的关键度量或值，从而试着优化该业务流程。这称为流程优化（请参见图19）。

　　优化后的流程具有以下改进：

　　·自动化的完整客户视图减少了需要信用报告的客户数量。
　　·自动化的信用报告显著降低了成本并更加快速。
　　·批准更大比例的客户请求。
　　·基于规则的动态定价，可在业务需求的基础上根据需要进行更改。
　　·平均持续时间变化百分比：加速97.6%
　　·加权平均利润：增加84.7%

　　图18帐户验证（预期）

 
　　图19帐户验证——用于优化的流程模拟
 
　　集成开发人员Jason Smith根据前面的实现中描述的方法，使用指定的服务和实现的组件组装并组合了该业务流程。

　　总结

　　了解到Ursula已完成了帐户开立项目的设计，Sandy非常高兴。通过与IBM的合作，Ursula能够将用于服务设计的SOMA方法应用于帐户开立服务设计。此外，服务团队学会了如何使用RUP SOMA方法来为将来的SOA采用创建服务设计。

　　帐户开立服务的设计和开发团队发现，用于SOA设计场景的IBM工具集成良好并且很容易使用。诸如IBM Rational RequisitePro、Rational Method Composer和Rational Software Architect等工具提供了功能丰富的工具环境，可用于加速创建应用IBM方法的服务设计。使用IBM WebSphere Business Modeler对于业务服务设计和流程组合非常有帮助。