SOA 建模: 第 1 部分 服务识别
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 关系，例如复用、内聚性和耦合性、分发、安全性、持续性、数据完整性、并发性、错误恢复等等。进一步，业务过程建模工具通常并不具备处理这些关系的能力。假如它们具备了这些能力，那么它们也许就不再是一款有效的业务分析工具了。
本系列文章展示了如何使用扩展了 IBM® Software Service Profile 的 UML 模型来设计一个同业务需求相联系的 SOA 解决方案，该方案目前尚独立于解决方案的执行。通常来讲，通过一个具体的、典型的、和完整的例子能够更容易的理解概念。本文也将采用这一方法。我们不会花费大量的时间处理 UML 的细节，但是我们会关注如何通过使用 UML 来帮助您进行设计和开发。
虽然本系列文章是关于来自 SOA 模型的 Web 服务解决方案的，但是我们首先来关注我们所努力实现的业务目标，从而使得我们的解决方案能够实现业务中的某些有价值的部分。然后，我们探索业务过程，该过程需要在业务中被完成以实现那些目标。这将提供 SOA 解决方案必须满足的业务功能性需求。接着，我们使用业务过程来那些在创建 SOA 解决方案中有用的识别服务。
在本系列的后面几篇文章中，我们将利用具备未来复用和业务敏捷的架构，创建服务规范和执行来实现那些需求。最终，我们将使用 MDD 生成一个能够被配置和执行的 Web 服务解决方案。
为了使例子更加真实，我们将使用已经存在的 IBM® Rational® 和 IBM® WebSphere® 工具来建造解决方案，并且将它们链接在一起，从而我们能够验证该解决方案并且更加有效的管理变化。表1提供了一个开发例子及其所使用工具的全面过程的概要。
| 角色 | 任务 | 工具 |
|---|---|---|
| 业务执行官 | 传达业务目标 | Rational RequisitePro |
| 业务分析师 | 分析业务需求 | WebSphere Business Modeler |
| 软件架构师 | 设计解决方案的架构 | Rational Software Architect |
| Web 服务开发人员 | 执行该解决方案 | IBM® Rational® Application Developer 和 IBM® WebSphere® Integration Developer |
本系列文章关注的是如何捕获业务需求，建立满足其需要的服务模型，并且创建和配置实现这一设计的解决方案。我们还将重点强调支持工具。目前，这些工具由表1 中所列出的 IBM 工具提供，它们将表现 SOA 建模性能的最小集，并且能够在任何架构层中被用来对消费者的请求和提供者的服务进行建模。这些工具并没有将过多的注意力放在用于发现需求的方法或者技术上、用于分析和评估服务解决方案的方法上、或者将服务划分到不同的架构层的方法上。要获得关于那些重要主题的更多相关信息，请参见 面向 SOA 的 IBM® Rational Unified Process® (RUP®) 和面向 SOMA 的 RUP （请参见 Resources 中提供的链接）。这些 IBM® Rational® Method Composer 插件程序提供了开发过程、指导、工具指导、和文章，解释了使用这些工具来开发完成的服务模型和解决方案的额外的方法。
这个例子是基于 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 业务用例满足了我们所有的业务目标。
我们同样为目标2创建了一个关键的执行指示器（KPI）：时需处理（请参见图2）。
该 KPI 将成为我们想要在实现业务用例的业务过程模型中观察的对象，它将成为我们 SOA 解决方案的一个约束，并且将成为我们配置的 Web 服务中所监控的对象。这将允许该服务被监控和管理，从而确保业务目标真正得到满足。
来自成员公司的业务分析师分析了需求，并且决定遵守 IBM® WebSphere® Business Modeler 业务过程来满足业务目标以及业务操作约束条件。该过程意在充分的完成和详细的处理，它能够被用作各方之间正式的服务层次一致性（SLA）的基础因此，我们的满足这些业务需求的 SOA 解决方案应该严格遵守这些业务需求，请参见图3。
图3. Purchase Order Process 业务过程模型
Purchase Order Process 开启了三个并行的活动：一个用作管理生产和运送时序安排，另一个用作价格计算和货品计价，第三个用作运送订购的产品。过程首先启动一个基于产品订购的价格计算。然而，由于全部的货品计价取决于产品是在哪里生产的及其运送的费用，所以这一价格并没有计算完全。与此同时，订购已被发送到生产，用来决定产品何时被提供以及来自哪个位置。
推荐文章 |