本文是五篇系列文章中的开篇之作，本系列文章是有关基于面向服务的架构（SOA）的软件开发。它介绍了如何使用 IBM? Software Service Profile 扩展的 UML 模型设计同业务需求相连接的 SOA 解决方案，而它至今仍然是独立于解决方案的执行的。作者首先描述了业务目标以及满足这些目标所要执行的业务过程，然后解释了如何使用该过程识别那些完成他们所提需求所必须的业务相关的服务。

　　建模是如何改进 SOA 的

　　SOA 的强大功能在于它具备将业务敏捷贯穿业务过程综合和复用的能力。SOA 通过一下两种方式实现这一功能：方式之一是通过鼓励解决方案被组织在可复用的服务周围，这些服务对从执行中分离出来的功能进行压缩；方式之二是为管理功能之间的耦合提供工具。建模能够被用来消除业务需求和一个已经被配置的基于服务的解决方案之间的缺口。模型驱动的开发方法能够被用来生成 SOA 执行，通过使用诸如 Java? 2 Platform, Enterprise Edition (J2EE) 或者 IBM? CICS? 这些在业务敏捷有效的同时满足业务功能性和非功能性目标的平台。

　　面向服务的架构（SOA）具有许多含义。从业者通常使用 SOA 来定义一个架构风格，以及描述一种使用该架构风格进行操作的 IT 基础构造。这些是很有用的聚焦拓扑结构的透视图，但是仅有这些还不够。

　　要实现其潜能，基于 SOA 的 IT 基础构造（此后简称为 SOA 需要同业务相关，从而由业务驱动并且用来对业务加以支持。我们需要一种设计 SOA 解决方案的方法，该方案同它们需要实现的业务需求相连接。如果所给出的业务需求仅仅是一个需求条目的列表，并且 SOA 的抽象级别是从描述 Web 服务集合的若干 XML 文档中得到的话，那么找到这种解决方案是很困难的。

　　我们所需要的是一种形式化业务需求并且提高抽象级别以便 SOA 能够更加类似业务服务，以及那些服务是如何满足业务目标的方法。这这种方法将被配置的解决方案同其业务价值紧紧联系在一起。与此同时，我们需要一种从支持它们的展开的 SOA 平台中隔离业务关系的方法。

　　建模和模型驱动开发（MDD）能够帮助我们实现这些目标。建模允许我们将执行细节抽象出来，并且关注于那些驱动架构决定的问题。从某种意义上说，这一方法将描述如何将 SOA 的基本原理之一应用到 SOA 解决方案的开发中：分离关系和松耦合。这里，我们将业务分析师的任务和责任从那些 IT 成员中明确分离出来。

　　通常的，业务分析师将关注业务组织和操作要求，这些都是满足业务目标所必须的。他们往往并不关注（也没有能力处理）IT 关系，例如复用、内聚性和耦合性、分发、安全性、持续性、数据完整性、并发性、错误恢复等等。进一步，业务过程建模工具通常并不具备处理这些关系的能力。假如它们具备了这些能力，那么它们也许就不再是一款有效的业务分析工具了。

　　关于建模 SOA 的本系列文章

　　本系列文章展示了如何使用扩展了 IBM? Software Service Profile 的 UML 模型来设计一个同业务需求相联系的 SOA 解决方案，该方案目前尚独立于解决方案的执行。通常来讲，通过一个具体的、典型的、和完整的例子能够更容易的理解概念。本文也将采用这一方法。我们不会花费大量的时间处理 UML 的细节，但是我们会关注如何通过使用 UML 来帮助您进行设计和开发。

　　虽然本系列文章是关于来自 SOA 模型的 Web 服务解决方案的，但是我们首先来关注我们所努力实现的业务目标，从而使得我们的解决方案能够实现业务中的某些有价值的部分。然后，我们探索业务过程，该过程需要在业务中被完成以实现那些目标。这将提供 SOA 解决方案必须满足的业务功能性需求。接着，我们使用业务过程来那些在创建 SOA 解决方案中有用的识别服务。

　　在本系列的后面几篇文章中，我们将利用具备未来复用和业务敏捷的架构，创建服务规范和执行来实现那些需求。最终，我们将使用 MDD 生成一个能够被配置和执行的 Web 服务解决方案。

　　为了使例子更加真实，我们将使用已经存在的 IBM? Rational? 和 IBM? WebSphere? 工具来建造解决方案，并且将它们链接在一起，从而我们能够验证该解决方案并且更加有效的管理变化。表1提供了一个开发例子及其所使用工具的全面过程的概要。

　　本系列文章关注的是如何捕获业务需求，建立满足其需要的服务模型，并且创建和配置实现这一设计的解决方案。我们还将重点强调支持工具。目前，这些工具由表1中所列出的 IBM 工具提供，它们将表现 SOA 建模性能的最小集，并且能够在任何架构层中被用来对消费者的请求和提供者的服务进行建模。这些工具并没有将过多的注意力放在用于发现需求的方法或者技术上、用于分析和评估服务解决方案的方法上、或者将服务划分到不同的架构层的方法上。要获得关于那些重要主题的更多相关信息，请参见 面向 SOA 的 IBM? Rational Unified Process? (RUP?) 和面向 SOMA 的 RUP （请参见 Resources 中提供的链接）。这些 IBM? Rational? Method Composer 插件程序提供了开发过程、指导、工具指导、和文章，解释了使用这些工具来开发完成的服务模型和解决方案的额外的方法。

　　Purchase Order Process 的例子

　　这个例子是基于 Purchase Order Process 例子的。而 Purchase Order Process 来自面向 Services (UPMS) RFP 的 OMG UML Profile 和 Metamodel，它基于 BPEL 1.1 规范中的一个例子 （请参见 Resources）。由于业务之间的相互关系没有被定义、业务数据不完全、以及不具备错误处理或者补偿机制，所以 BPEL 1.1 规范只包含了一个局部解决方案。这个例子的该版本包括若干出于完全性考虑而制造的数据——特别是相关性所需要的数据。

　　这个例子首先使用 IBM? Rational? RequisitePro? 描述建立业务目标的业务动机。接着，使用表达满足业务目标所必须的业务组织和操作需求的 IBM? WebSphere? Business Modeler 捕获一个高层的业务过程。这些动机和过程模型为识别同业务需求相联接的服务建立了上下文环境。

　　在我们理解了业务需求之后，我们能够继续进行满足这些需求的服务的开发工作。在一个 SOA 解决方案中，第一步就是识别服务。为了实现这一点，我们将业务过程视为一个 Service Requirements 契约。然后，在关注软件架构的同时，服务规范和服务提供者以一种满足业务需求的方式被设计和连接在一起。

　　这一从业务模型中识别候选服务的过程即为大家熟知的 域分解。IBM? Rational Unified Process? (RUP?) SOMA 描述了域分解和其他一些方法，当它们被共同使用时，为业务所需要的识别所有服务提供了更高的保证。

　　业务需求

　　场景：几家公司决定共同生产一个可复用的服务来处理订购单。该项目的目标是：

　　建立一个处理订购单的普通方法
　　确保订货单被及时的处理，并且交付要求的货物
　　有助于最小化库存和相应的维持开销
　　最小化生产和货运的成本

　　图1显示了从 RequisitePro 中得到的需求。请注意该 Process Purchase Order 业务用例满足了我们所有的业务目标。

　　图1. RequisitePro 中展现的业务需求
 
　　我们同样为目标2创建了一个关键的执行指示器（KPI）：时需处理（请参见图2）。

　　图2. 关键的性能指示器
 
　　该 KPI 将成为我们想要在实现业务用例的业务过程模型中观察的对象，它将成为我们 SOA 解决方案的一个约束，并且将成为我们配置的 Web 服务中所监控的对象。这将允许该服务被监控和管理，从而确保业务目标真正得到满足。

　　业务组织过程

　　来自成员公司的业务分析师分析了需求，并且决定遵守 IBM? WebSphere? Business Modeler 业务过程来满足业务目标以及业务操作约束条件。该过程意在充分的完成和详细的处理，它能够被用作各方之间正式的服务层次一致性（SLA）的基础因此，我们的满足这些业务需求的 SOA 解决方案应该严格遵守这些业务需求，请参见图3。

　　图3. Purchase Order Process 业务过程模型
 
　　Purchase Order Process 开启了三个并行的活动：一个用作管理生产和运送时序安排，另一个用作价格计算和货品计价，第三个用作运送订购的产品。过程首先启动一个基于产品订购的价格计算。然而，由于全部的货品计价取决于产品是在哪里生产的及其运送的费用，所以这一价格并没有计算完全。与此同时，订购已被发送到生产，用来决定产品何时被提供以及来自哪个位置。与之并行进行的是，该过程请求运送，然后等待发自生产时序安排提供者的运送时间表。当生产时间表被制定出来之后，货品计价就能够被完整的计算出来，并且返回给消费者。

　　我们使用 WebSphere Business Modeler 来创建一个被称作 Order processing time limit 业务度量标准，来满足来自业务需求的 Order Processing Time Limit KPI。该业务度量标准监控 Purchase Order Process 处理时间，并且当处理时间大于五天时发出一个警报，请参见图4。

　　图4. 对 KPI 进行业务测量
 
　　业务分析师可能使用 WebSphere Business Modeler 来仿真业务过程。这样做将会达到以下这些重要的目的：

　　首先，它可以被用来制定业务过程想象它将如何工作。这将使业务分析师能够和不同的利益攸关方一起验证操作。消费者往往在您向他们展示那些不正确的东西之前，并不知道它们到底想要的是什么。在仿真模型中运行一个业务过程，对于避免投入到错误的解决方案之中，尽早验证业务过程来说是一个很重要的方法。通过仿真想象业务过程还将帮助您发现新的改进和提炼的机会，这是仅仅靠阅读进程所很难做到的。

　　仿真的第二个作用就是决定执行一个过程将会花费多少代价和多长时间——这是做出业务决定时需要考虑的关键问题。业务分析师能够将资源和时间分配给过程中的每一项任务。这些资源包括可用性、花费和位置信息等。此外，WebSphere Business Modeler 仿真能够被用来评估一个过程将会花费多长时间，花费什么东西，以及哪里可能会成为资源的瓶颈。业务过程中的变化会导致不同的仿真运行结果，可以用它们容易的比较出某一项改变是否会达到我们想要达到的效果。

　　最后，方针运行的结果能够被用来获得业务 KPI 的早期评估，来确保业务过程满足目标。这将为开发团队带来信心，使他们确信自己在正确的时间，采用正确的解决方案，处理正确的问题。

　　我们还在 RequisitePro 中把 WebSphere Business Modeler Purchase Order Process 链接到 BUC1 Purchase Order Process 业务用例上，来指出实现该用例的过程。“Realization” 是用例建模中的一个术语。您能够看到该业务用例在 WebSphere Business Modeler 的 Requirement Explorer 视图中通过一个 BUC 图标中的小箭头被链接到一个过程上，请参见图5。

　　图5. 将业务过程链接到他们所实现的业务用例
 
　　您能够在 WebSphere Business Modeler 中使用 Requirements 透视图在业务过程及其在 WebSphere Business Modeler 的 Requirement Explorer 视图、RequisitePro 客户端、或者 Microsoft? Word? 中的需求中实现的业务用例之间进行定位。

　　下一小节将业务过程作为一个 Requirements 契约进行处理，并且显示如何在一个业务操作需求的 SOA 解决方案中识别服务。

　　服务识别

　　一些业务过程能够在 IBM? WebSphere? Process Server 等平台上直接运行。但是存在这种情况，业务过程没有充分的关注 IT，并且可能为更好的复用而忙于非功能性的需求，例如性能、可量测性、和安全等。在这种情况下，业务过程可能被视作 SOA 解决方案必须处理的需求的规范。

　　服务需求

　　对于 Purchase Order Process 的需求能够从 WebSphere Business Modeler 业务过程中得到。这些需求被视作一个服务契约，指出参与到业务过程中的角色，希望它们这行的任务，以及它们之间相互作用的规则。该服务契约是一个正式的、架构中立的规范，它们由相互作用的服务消费者和提供者执行，并不关注任何 IT 架构或者执行的内容。在这种情况下，该服务契约包括同原始业务过程相同的信息；它就是通过使用 IBM? Rational? Software Modeler 或者 IBM? Rational? Software Architect 打开 WebSphere Business Modeler 模型所创建的业务过程的一个视图。

　　业务分析师通常使用 WebSphere Business Modeler；相反，IT 架构师则使用 Rational Software Architect。这两种工具一般不可能一起被使用，它们被用来访问相同的用户工作区。为了使 IT 架构师能够从业务分析师的工作中受益，Rational Software Architect 能以被用来将 WebSphere Business Modeler 业务模型导入到一个 Rational Software Architect 工作区中，在那里，IT 架构师能够打开并看到被译成 UML 的业务分析师的内容。图6显示了在 Rational Software Architect 中我们的 WebSphere 模型被译成 UML 的节选。

　　图6. 服务需求契约
 
　　下面我们利用一些时间来理解该图，因为我们将在开发 SOA 解决方案时看到类似的图。

　　 Process Purchase Order 协作符合 Process Purchase Order 业务过程。

　　请注意：

　　协作通过归类符号（一个被划分的长方形）来展示，而不是通过虚线椭圆形符号被展示。UML 2 对于这两者都许可。由于长方形符号能够为角色提供更多的空间，所以本例子采用长方形符号。

　　当建模服务需求或者从业务过程中驱动服务需求的时候，协作将回答这些问题：

　　该需求想要达到的效果是什么？如果改协作是从一个业务过程中获得的，这就是同该业务过程相对应的是协作的名字。这些名字通常是动词词组，它们指出协作的角色所要完成的是什么。

　　谁参与并且完成它？协作角色指出谁参与到协作之中。这些角色可能同业务过程中的泳道相对应。

　　角色的职责是什么？（请注意：服务提供者将会扮演这些角色，不一定必须是人。）协作角色的类型通常是接口。角色的职责表达为接口的操作。我们的服务解决方案中的任何扮演角色都必须能够履行这些职责。也就是说，它们必须执行那些操作。在一个业务过程中，角色负责其泳道中的任务。这些接口能够通过创建业务过程中被分配给角色的任务的列表来得到。

　　角色之间相互作用如何？即哪一个角色必须同其他角色相通信？这在角色之间建立起依赖关系。这一相互作用通过协作中的角色之间的连接器来展示。这些连接器指出有一些控制或者数据在业务过程中的泳道间穿流。

　　角色之间相互作用的规则是什么？这是协作所拥有的行为。这种行为可以是活动、相互作用、状态机、或者不透明的行为（例如代码）。当角色的责任被要求时执行这个行为，并且它可能指出角色之间的信息交换。该活动同业务过程中的 UML 视图相对应。

　　我们如何评估需求是否被满足？协作可能具有一些约束，它们为需求指定必须满足的条件。这些约束同业务过程中的 KPI 业务量度标准相对应。

　　Purchase Order 是一个具有四个角色的服务协作，其中一个角色由过程自身来扮演。这些角色通过检查指派给业务过程泳道中角色的任务，从业务过程中获得。WebSphere Business Modeler 使用业务需求的一个以过程为中心的视图，而服务契约采用以角色为中心的视图。这提供了一个更加面向服务的业务契约视图，在过程需求和面向服务解决方案的架构之间的隔阂上架起了一座桥梁。

　　该服务契约可能包含从业务动机模型中的方法中得到的约束。这些约束指出服务契约要完成的是什么，以及如何衡量是否成功。

　　该服务协作也实现了从关键的外部利益攸关方或者参与者的透视图中，为获得业务过程所需要的额外的关于高层功能性和非功能性需求信息的用例。这些用例可以在 Rational Software Architect 中的用例图中被查看，并且它们被链接到 RequisitePro 中的业务用例上。它保持了服务需求契约、业务过程、业务用例、和业务目标之间的链接。

　　图6中所示的服务协作契约，可以是 WebSphere Business Modeler 业务过程模型的一个视图，或者可以被直接配置在 Rational Software Architect 中。使用哪种方法取决于使用该模型的人的偏好，以及是否仿真被用来验证业务过程。无论是哪一种情况，都将维持全面的追踪。当然，来自 WebSphere Business Modeler 业务模型的服务协作契约的质量将依赖于那些过程中的细节水平。关于业务过程建模和服务建模之间的关系的更加完全的讨论，请参见 developerWorks 中的文章：业务服务建模。

　　服务项目组织

　　我们现在已经准备好对一个服务进行建模以满足这些需求。我们的解决方案将实现这些需求，但是并不必须被它们所约束。当我们设计 SOA 解决方案的时候，我们需要识别服务，设计它们的接口，并且决定它们将如何被执行：哪一个服务提供者提供什么样的服务以及如何提供。这建立起服务消费者和提供者之间的依赖关系，并且在系统中建立耦合。管理这一耦合是设计基于 SOA 的服务的一个主要部分。通过将这些业务需求从服务中分离出来，我们具备了设计既满足业务需求也满足 IT 系统需求的 SOA 的灵活性。这将使得业务需求摆脱 SOA 解决方案的过度约束，而这种约束将会导致较差的复用性和业务敏捷性。

　　首先，我们创建了一个被称作 PurchaseOrderProcessModel 的 Rational Software Architect 服务建模项目。该项目包含了一个叫做 PurchaseOrderProcess 的服务模型。该模型包含一个用于服务、服务数据、被提供和被要求的接口的规范的信息模型，和提供被要求的服务的成分。但是，到现在为止，我们主要关注服务识别。

　　如图7所示，在 PurchaseOrderProcess 模型中有五个主要的包：

　　org::ordermanagement 包含同定购管理相关的元素。
　　org::crm 包含数据模型和普通接口，它们被用于服务消费者和服务提供者就开发共享服务所达成一致的想象的 Customer Relationship Management 标准。
　　com::acme::credit 包含同货品计价和支付管理相关的元素。
　　com::acme::productions 包含同生产和时序安排相关的元素。
　　com::acme::shipping 包含同运送相关的元素。

　　这些包将问题域划分为不同的功能区域。这将有助于管理复杂性、建立需求名字空间、使复用变得容易、并且保持不同包之间的独立性，请参见图7。

　　图7. 包依赖图
 
　　该组织将被称作服务模型的域组织。可能使用划分来为组织相同模型的元素证明其他的分类。

　　服务拓扑结构

　　服务模型首先是识别处理定购单所涉及到的服务。关于这一点，我们不再讨论关于服务做什么和如何交互的细节。我们只是勾画出一个草图，描述服务是什么以及它们可能进行交互的高层概念。

　　图8是 Rational Software Architect 中的一个简单的类图（或者自由形态的图），它表现前面所描述的业务功能区域和我们将在那些包中定义的关键服务。此处，仅有的关于服务的信息就是它的名称。

　　图中的使用依赖是要表现这些服务如何彼此相关。关于这一点，我们既没有完全的服务规范，也不知道服务参与者将会提供什么或者需要什么服务。我们也没有这些服务的任何建模信息。因此，对于这些使用依赖的方式来说，尚没有形式化的东西。它们仅仅是一种指示，指出当我们完成服务规范和执行时，预期的执行可能或者不可能为真。然而，这些依赖关系在这一高层上是很有价值的，因为它们开始识别需要被小心管理的系统之间的效用和耦合。

　　图8. 服务拓扑结构图
 
　　请注意：

　　如何发现和设计这一服务的拓扑结构已经超出了本文的范围。面向 SOMA 的 IBM RUP （请参见 参考资源）为如何从业务功能区域中发现服务提供了过程、方法和指导。

　　一种发现需求服务的简单的方法是，查看那些被识别为服务协作的业务需求，并且思考哪些服务提供者将会被要求在该协作中扮演角色。这也正是本例子中所使用的技术。我们能够通过创建一个图来实现形式化，这个图展示了如何使用服务规范完成 Service Collaboration 契约。

　　图9显示了一个抽象的成分，它为处理定购单对上下文进行建模。它具有前面所讨论的服务规范类型中的若干部分。该图显示了在特定的上下文环境中每一个服务规范的潜在使用。我们仍然不知道哪些服务参与者提供或者使用了这些服务。这些部分同样也是抽象的，这是因为它们是服务规范的实例，而不是提供这些服务的服务提供者的实例。

　　图9. 满足服务需求契约
 
　　然而，该图所显示的是这些服务如何完成了 Service Collaboration 需求契约。该契约是一个协作使用，是 Process Purchase Order 服务协作的一个实例。Processing Purchase Orders 的成分同它们在契约中所扮演的角色限制在一起。这提供了一个指向业务需求的链接，并且显示了我们打算指定和执行的每一个服务接口的业务相关性。Process Purchase Order 服务协作的行为指定了这些服务部分如何在服务执行中相互作用。我们将在指定和执行该服务时对其进行第二次访问，以确保解决方案满足契约的需要。

　　下一步工作展望

　　在本文中，我们对一种识别同业务需求相联系的服务的技术进行了概述。首先，我们获得实现业务使命所必须的业务目标。然后，我们对满足该目标所必须的业务操作和过程进行建模。接着，我们将业务过程视作反映 Business Services Requirements 契约的一个服务协作，该契约必须通过我们最终的解决方案来完成。然后，我们使用该需求契约来识别所要求的服务以及它们之间的潜在关系。对于辨别同它们将要完成的业务目标相链接的业务相关的服务来说，它提供了一种正式的方法。

　　本系列的下一篇文章 “建模 SOA 第二部分 服务规范” 将会对每一个服务的规范进行详细的建模。那些规范将会指示被提供的和被要求的接口，哪些接口在服务规范中所扮演的角色，以及那些角色在提供服务中进行交互的规则和协议是什么。

　　关于作者

　　Jim Amsden 是一名 IBM 的高级技术人员，在应用程序设计和开发以及软件开发行业工具方面有二十多年的经验。他持有波士顿大学的计算机科学硕士学位。他的兴趣点包括基于契约的开发，代理编程，业务驱动开发，J2EE UML，以及面向服务架构方面。他也是 “Enterprise Java Programming with IBM WebSphere” 一书的合著者。他目前关注于如何集成工具以更好地支持敏捷开发过程。