IBM 认证 SOA 解决方案设计师认证考试准备: 第 1 部分，SOA 最佳实践(2)

IBM 认证 SOA 解决方案设计师认证考试准备: 第 1 部分，SOA 最佳实践

第 2 页，共 6 页
对本教程的评价

帮助我们改进这些内容
SOA 最佳实践
SOA 周围环绕着很多光环。而每个光环背后都存在让人疑惑的东西。我们将使用各种术语，但会为其提供清楚的解释和相关关系，以便了解其用途和含义。
不久前，软件开发界开始出现支持模型驱动的开发（Model-Driven Development，MDD）的产品。而 SOA 无疑通过业务驱动的开发（Business-Driven Development，BDD）向这个方向迈进了一步（请参见参考资料部分中列出的 Mitra 的文章）。请参见图 1。

MDD 从最初以软件建模为中心转向了以软件架构师角色为中心。BDD 则更进一步，上升到了以业务建模和业务分析人员（business Analyst，BA）角色为中心。
由于 SOA 在软件开发领域仍然相对较新，其最佳实践仍然在不断出现和发展。因此，我们目前有时候会将其称为“指导方针”。
在深入了解 SOA 最佳实践的细节前，我们需要确保具有共同认可的语言和定义。因此，让我们首先简单了解一下 XML、Web 服务和 SOA。
简单说来，XML 是最低级的通用语言。它是一种可扩展标记语言，不同的平台和语言都能理解它。很多 Web 服务标准中都使用了 XML。标记的内容将由定义语法的模式进行验证或解析。

有关 XML 的更多信息，请参考 developerWorks 上的XML 技术教程。
Web 服务是能够进行重用的功能构建块。必须由提供者系统使用标准协议和语义对其进行发布、查找（发现）和调用。这是使用具有不同语法和相关结构的 XML 进行的，例如以下 XML：
WSDL UDDI SOAP
图 2 显示了这些标准间的关系。

由于 Web 服务是基于标准的，因此提供了较高级别的第二个通用语言。
Web 服务描述语言（Web Services Description Language，WSDL）是一个 XML 实例文档，符合用于服务请求方和服务提供者之间的通信的 W3C 标准 XML 语法。它描述 Web 服务如何工作。正是由于 WSDL 文件，Web 服务才被称为“自描述”，因为可以从 WSDL 文件生成 SOAP 消息。事实上，很多工具都可以从 WSDL 文件创建客户机代码。
WSDL 文件包含以下元素：
Type：使用某种语法（如 XML 模式）的数据类型定义（string、int） Message：要传递的数据 Part：消息参数 Operation：服务支持的操作的抽象描述 Port Type / Interface：一个或多个端点支持的操作的抽象集。此名称已更改，因此可能会遇到两者中的任何一个。 Binding：特定端口类型的具体协议和数据格式规范 Port / Endpoint：绑定和网络地址的组合。此名称也已更改，因此可能会遇到两者中的任何一个。 Service：相关端点的集合，包括其关联的接口、操作、消息等。
图 3 显示了 Thomas Erl 给出的 WSDL 结构（有关更多信息，请参见参考资料）。

同样要记住，与服务交互所需的所有细节都位于其 WSDL 文件中。
UDDI 定义如何查找 Web 服务（及其 WSDL 文件）。UDDI 并不像 WSDL 和 SOAP 一样深入人心，因为很多时候，使用者知道 Web 服务的位置（通常位于公司的企业内部网中）。
UDDI 列表保存在 UDDI 注册中心。每个列表可以包含以下内容：
白页：地址、联系人和已知标识符 黄页：基于标准分类法的行业类别 绿页：有关业务公开的服务的技术信息
绿页即所需的全部内容。它们可提供对服务的 WSDL 信息的访问。
SOAP 是用于在网络上交换基于 XML 的消息的协议。通常，使用 HTTP 作为传输协议，但也可以使用其他协议，如 SMTP 等。
SOAP 消息包含以下元素：
Envelope：必需的元素，用于将文档标识为 SOAP 消息 Header：包含应用程序特定的信息 Body：必需的元素，定义调用和响应信息 Fault：包含有关出现的错误的信息
正如我们前面提到的，SOAP 内容可由 WSDL 文件确定。
SOA 的主要目标是创建和维护业务和 IT 之间更紧密的协作——从而能更方便地通过与 IT 组织协作来即时获得所需功能。SOA 就是根据业务流程将 Web 服务构建块连接在一起，以便从头至尾提供所需功能。SOA 是最高级别（企业及企业之外）的框架。
您可能会想，“为什么要使用 SOA 呢？”简单说来，因为通过它可以更为灵活和迅速地构建系统。被提到最多的 SOA 好处是“让业务分析人员不再受到 IT 部门的束缚”。但 Mansurov 给出了对 SOA 感兴趣的另一个原因，如图 4 中所示（有关更多信息，请参见参考资料部分）。

此研究表明，由于 SOA 将更多的精力和时间放在了开发的早期阶段，因此可以节约 30% 到 50% 的成本。这项研究还表明，36% 的缺陷都是由于需求收集时的错误导致的。这同样也适用于 SOA。
接下来让我们正式开始本教程的学习。我们将讨论指导方针的各种类别，首先是通用 SOA 指导方针。




回页首
我们将使用“WS-*”指代完整的 Web 服务标准集。这些标准和其他 SOA 相关标准是必要的基础。如果偏离了标准，任何人都无法重用您的服务，以后也不会再考虑这样做了。所有标准都非常重要，但我们仅讨论一些对 SOA 极为重要的标准：
WS-I：您使用的协议应与 Web 服务互操作性（Web Services Interoperability，WS-I）标准兼容。HTTP、SOAP 和 JMS 都是此类兼容消息传递基础协议。 WS-BPEL：您的业务流程应该通过 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，WS-BPEL）定义。其名称很长，但此标准对于以跨产品的方式记录您的流程非常必要。 WSDL：正如上面所说的，WSDL 定义 Web 服务如何工作。 UDDI：使用 UDDI 时，它将对 Web 服务进行注册，以便使用者能够查找服务。 SOAP： SOAP 是用于按照其 WSDL 文件的定义在网上进行基于 XML 的消息传递的协议。 WS-*：还有很多我们在此处没有讨论的标准，包括 WS-Coordination、WS-Notification、WS-Policy、WS-Reliability、WS-Resource、WS-Security、WS-Transaction 等等。
为了获得真正的 SOA，您至少必须遵循这些标准。

顾名思义，企业服务总线（Enterprise Service Bus，ESB）是集成组织的各个系统的企业级通信机制。它支持请求方与提供者之间跨网络进行事件驱动的消息传递，同时提供了身份验证和事务管理等服务。服务可以采用 .NET 框架或 J2EE 平台；协议可以为 HTTP 或 JMS；平台可以是 UNIX 或 Windows。
有必要讨论一下 SOA 所基于的主要原则：
松散耦合：服务必须注意到彼此的存在，但位置、版本和实现的更改应该为透明的。Spring 之类的框架就是松散耦合的，基于声明性配置文件的连接和面向方面的交织，但 SOA 使得松散耦合达到了另一个境界。在 SOA 中，ESP 之类的机制可以在不涉及客户机逻辑的情况下适应更改。而 WebSphere® Integration Developer 之类的工具则使得连接工作变得非常简单。 契约接口：WSDL 是定义 Web 服务的接口的标准方法，应该用于描述所有 Web 服务。 可重用服务：可重用性具有多个特征，包括抽象和耦合。服务应该定义为尽可能小，但同时仍然能为完整业务功能提供支持。如果您添加更多的功能，服务的可重用性就会减弱，因为能够与其协同工作的其他服务的数量就会减少。请考虑定义原子服务。 自描述服务：为了进行重用，必须能够找到组件。尽可能使用业务分析人员能够理解的术语。提供丰富的描述。使用全面描述 Web 服务的 WSDL 文件。 无状态性：服务不应在调用之间保持状态。应该设计为重入，从而避免在处理并发请求时出现问题。Artus 对服务为何需要无状态的相关问题进行了讨论（请参见参考资料部分列出的 Artus 的文章）。基本原因是什么呢？有状态服务的可重用性低。




回页首
服务的使用者是业务分析人员。因此，服务的名称应该使用他们的术语，应该对他们有意义。例如，应该使用 Transfer Funds between Accounts（而不是 ProcessTransferTransaction）作为服务名。
可以在此领域中使用很多面向对象的系统开发中的建模技术。例如，利用领域专家建模会话、经过调整的 CRC 卡、活动 Swimlanes、状态转换图以及其他技术都可以在 SOA 项目中用于发现业务服务。事实上，Artus 给出了一个示例，说明如何使用状态转换来发现业务服务（请参见参考资料部分中列出的 Artus 的文章）。
在组织内建立标准命名规则。访问一些公共 UDDI 注册中心，以了解其他公司如何对其服务进行命名：
BindingPointXMethods
通常，服务操作应该为动词短语，而服务本身应该为一个名词。这个建议是通过多年面向对象的系统开发经验得到的。
并非任何东西都应该是服务。标识服务时，请确保进行以下工作：
从现有系统中挖掘候选服务。 将重点放在业务价值上。 平衡粗粒度和细粒度。
Ali Arsanjani 指出，“使用目标-服务建模，实际是通过考虑多个部分的方法来减少可能已经标识的候选服务的实际数量。更为明智的方法是，首先进行自顶向下开发，然后进行目标-服务建模，最后进行对现有资产的自底向上遗留分析”（请参见参考资料部分中列出的 Arsanjani 的文章）。他将目标-服务建模定义为主要使用业务的目标来标识满足这些目标所需的服务。
注意粒度和增值。例如，如果要通过一系列服务提供遗留系统，则在紧密耦合的情况下最好将较大的功能块保持在一起。将重点放在不依赖于其他服务工作的完整功能上。
细粒度服务的重用性更高，但需要进行更多的协调工作。服务越多，则意味着使用者需要进行更多的工作来连接业务流程。另一方面，粗粒度服务的重用性可能更低，但提供的功能会更多（因此协调工作较少）。那么架构师要怎样做呢？答案并不令人满意，“根据您自己的判断，具体情况具体分析”。不过以下给出了一些经验总结：
当发现候选服务的某些部分能为使用者提供单独的价值时，则请进行进一步划分。由于并非所有使用者都希望使用所提供的所有功能，让这些部分保持在一起将会降低总体服务的可重用性。 当遇到高度耦合（有时称为“内聚”）而进一步划分会分离高度耦合的功能时，停止进行更细的划分工作。进一步划分将不会为使用者提供完整的解决方案。
最后请记住，粒度增加意味着消息传递工作更多（可能会在整个网络中进行），而这当然会有性能影响。

尽管其名称如此，但却与舞蹈无关。通过将 Web 服务的接口连接到一起来支持业务流程，从而将其编排 为组合应用程序。流程将业务规则作为其定义的一部分。协调 与编排类似，但编排跨多个相关方，而协调仅关注一个参与者。
SOA 相对较新，但已经有了一些建议方法。这些方法经常是其他现有方法的组合和扩展。这样很好——重要的是有流程和技术可遵循。我们将向您介绍一些建议的 SOA 方法。
服务体系结构方法 (Methodology for Service Architectures)：（Jones，2005 年）重点在服务发现上，提供了此方法的概念。此方法的重点在最早期的 SOA 开发活动上。图 5 显示了此方法中使用的一项技术。可以将此方法作为补充方法，但并不具有整个 SOA 项目的全部步骤。

面向服务的建模体系结构（Service-Oriented Modeling Architecture，SOMA）：根据 Ali Arsanjani（有关 Arsanjani 的链接，请参见参考资料部分）的说法，“面向服务的建模方法提供了用于定义 SOA 基础的建模、分析、设计技术和活动。它可帮助在每个 SOA 层次定义元素和进行每个级别的关键体系结构决策。为了达到此目的，它结合使用了自顶向下、业务驱动的服务标识和通过利用现有资产和系统进行服务标识的工作流。” 面向服务的分析和设计（Service-oriented analysis and design，SOAD）：Zimmermann 这样描述 SOAD 方法：“该 SOA 方法强调了已确立的通用软件体系结构原则，如信息隐藏、模块化以及关注点分离，同时还添加了其他主题，如服务编排、服务存储库以及服务总线中间件模式，这些问题显然需要在建模期间加以注意”（请参见参考资料部分列出的 Zimmerman 的文章）。此方法包含业务流程建模（Business Process Modeling，BPM）和面向对象的分析与设计（Object-Oriented Analysis and Design，OOAD），对其进行了扩展，以标识服务和同步 BPM 与 OOAD 构件。此方法处理了 WS-BPEL 和 WSDL 之间的划分，还讨论了其他主题，如提供高服务质量（Quality of Service，QoS）等。作为一名老 OO 建模人员，我非常熟悉 OOAD 技术，包括 UML。SOAD 认为 OOAD 对 SOA 而言紧密耦合程度仍然太高，太过于细粒度，因此将其作为更为细粒度的层次使用（请参见图 6）。

SOAD 主要关注业务级别的高级问题，如业务流程等。由于开发工作变得更为详细，因此使用了现有的面向对象的技术。SOAD 包括 SOA 特定的主题，如：
服务类别和聚合 策略与方面 中间相遇流程 语义代理 服务收集和知识代理
面向服务的建模 (Service-oriented modeling)：Mark Endrei 则从业务分解入手；业务分解的任务是标识用例和流程（请参见参考资料部分列出的 Endrei 的文章）。当用例和流程进入设计阶段后，将使用系统用例和子系统来支持所标识的流程。随后将使用业务用例来标识服务。
下一部分是标识业务目标并将其划分为子目标（请参见图 7）。子目标将随后把之前标识的服务映射到目标，从而发现是否存在任何未涵盖的领域。这样做的目的是为了标识业务组件，因此下一步是在子系统内的流程进行分析。

Ali Arsanjani 对 SOMA 方法进行了详细说明（请参见参考资料部分列出的 Arsanjani 的文章），分析了用于发现服务的各种技术。他将自顶向下流程称为“域分解”，通过此流程可得到业务用例。他将自底向上流程称为“现有系统分析”，通过此流程将得到可转换为组件的候选功能。最后，他将中间相遇流程称为“目标-服务建模”，通过将重点放在业务目标和性能度量上来标识潜在服务。此方法是一种文档丰富的 SOA 方法，因为其中包含构件的格式，因此可以作为一个不错的入手点。 敏捷性面向服务建模 (Agile service-oriented modeling)：Pal Krogdahl 的重点在于建模业务服务以及将业务流程连接到服务（请参见图 8）。他的方法是以 Zimmermann 和 Arsanjani 的成果为基础（请参见参考资料中列出的 Krogdahl 的文章）。他增加了将敏捷性方法应用到 SOA 的讨论。

尚没有得到整个行业明确认可的 SOA 方法。在整个行业就此达成一致前，请选择一个方法，并根据您的组织的情况对其进行调整。历史证明，一些建议方法的出现和混合将最终成为事实标准。




回页首
我们已经给出了 SOA 的主要原则，您的设计应该支持这些原则。接下来我们将给出一些特定于设计的建议。
这可能非常明显，但值得进行一下强调：SOA 的一个主要目标是让业务分析人员和技术人员 (IT) 能更为密切地合作。在过去，分析人员受到 IT 人员告知的“可能性”的约束。正如将用例用于驱动 IT 工作一样，业务用例也能在 SOA 中提供这种方向指导。
有些 SOA 方法使用业务目标来驱动活动和开发构件。当然，这意味着您理解您的业务活动。如果不理解业务活动，则采用其他方法；如果答案是肯定的，则利用其通过业务分析人员和 IT 人员的合作来发现服务。
IBM Rational Application Developer (RAD) 之类的集成开发环境（Integrated Development Environments，IDE）将从 WSDL 文件生成 Web 服务代码。完全没有必要手动键入此信息。
SOAP 内容是 XML。正如您所知道的，XML 具有描述性，但通常由于标记的量而显得比较大。如果您遇到了性能问题，请考虑使用消息传输优化机制（Message Transmission Optimization Mechanism，MTOM）；该机制构建于 XML 二进制优化打包（XML-binary Optimized Packaging，XOP）之上。XOP 可通过使用 MIME 编码提供更高效的 XML 序列化。MTOM 使用 XOP 来编码 SOAP 消息，而同时仍然向 SOAP 应用程序提供 XML 信息集。
另一个比较新的备选方案是使用 XFire。XFire 是一个与标准兼容的开放源代码 SOAP 框架，使用了最新的技术（包括 StAX 解析器）来提高 SOA 消息传递性能。
同样，除非您的性能无法接受，否则使用常规 XML SOAP 消息就应足够了。不过，如果您要向大量客户机提供服务，则可能需要使用其中一个备选方案来提高性能。

StAX 是一个解析器 API，是介于树导航 DOM 和基于 push 事件的 SAX 接口之间的 API。它和 SAX 一样在 XML 文档上按照串行方式工作，但允许应用程序对标记进行 pull 操作。有关更多信息，请参见参考资料部分 (Ryan)。
尝试尽可能发送原子服务请求。服务请求应该独立，以便在需要回滚时能够独立于其他服务进行此操作。
例如，如果有一个银行业务应用程序，且需要提供资金转帐服务，请使用单个 transferFunds(fromAccount,toAccount,amount) 服务进行此操作。如果仅提供转帐操作组件部分，如 deposit(anAmount) 和 withdraw(anAmount)，那您就是自找麻烦了。不仅使用此服务的应用程序需要进行更多的工作，而且可能会在 withdrawal 正常工作但 deposit 出现问题（反之亦然）时出现问题。原子服务将包含单个事务中的所有步骤，确保对相关步骤运用 All-or-Nothing 处理方法。
当考虑 fromAccount 和 toAccount 可能属于不同金融公司时，这就变得尤为有意义了。那么，（逻辑）事务如何跨公司工作呢？Jon Maron 提供了此问题在分布式服务领域中的一个更为复杂（也更真实）的示例，并提出了一个解决方案（请参见参考资料部分中列出的 Maron 的文章）。正如您可能猜到的，此解决方案需要进行更多的工作，但却能够满足事务需求，如图 9 中所示。

可以采用增量的方式逐步提供各个服务。没有必要同时将所有内容都变成服务。首先从能体现主要好处的领域着手。例如，在我目前的工作中，我们系统的中心部分是一个遗留系统；简单说来，这个遗留系统很难处理。因此，我们首先处理这个问题，因为这个领域是非常适合为整个企业中不同组创建服务的最佳位置。
在编排期间，请求方流程、Web 服务和系统将会连接到提供者服务中。就其本质而言，这就是耦合。区别在于 ESB 机制可以路由到经过更新的服务、处理格式之间的转换以及其他必要的细节。这是松散耦合，仍然可以对可用服务进行重用。在组织外部重用服务时，松散耦合尤为重要。
Dave Artus 列出了服务使用者和提供者之间以下的这些依赖关系（请参见参考资料部分列出的 Artus 的文章）：
平台：Web 服务提供平台独立性 位置：SOA ESB 在运行时提供动态路由 可用性：SOA ESB 支持异步调用 版本：SOA ESB 可对格式更改进行协调
如果您的服务均按照相同的方式工作，业务分析人员编排业务流程的工作就会变得更为简单。此外，如果您使它们都能异步工作，就消除了对服务可用性的依赖。
简洁性与 Brad Cox 所说的“表面区域”相关：将参数归入单个结构中，使得使用者仅需要提供映射结构即可，从而能够方便地将值安全发送到服务。如果服务发生更改，仍然可以支持相同的结构，因为它仍然是映射。这将允许您弃用之前的参数集，但同时仍然为其提供支持，而不会影响服务的当前使用者。
这可能很明显，但 SOA 应该反应迅速且十分灵活，因此需要在 SOA 工作中能够使用的各种工具。您可以使用 IBM 的 SOA 工具集，包括 WebSphere Business Modeler、Rational Application Developer (RAD) 和 WebSphere Integration Developer (WID) 产品。通过这些工具，可以采用交互方式开发业务流程和 Web 服务，并随后将其连接到一起形成可部署的 SOA 应用程序。您将需要注册中心和存储库。IBM 的 WebSphere Service Registry and Repository (WSRR) 可作为这样的解决方案。
如果没有针对 SOA 开发进行了调整的工具，您会发现很难成功。请记住，SOA 远远不止 Web 服务。




回页首
您必须遵循各项标准，因为您要努力保持服务间的一致性。按照 Thomas Erl 的观点（请参见参考资料部分中列出的 Erl 的文章），接口设计人员负责创建 Web 服务的 WSDL 文件以及相关 SOAP 消息的格式。
Erl 进一步指出，此接口设计人员应该具备组件设计和业务分析能力——需要有人专门负责此角色。




回页首
监视是 SOA 中的一项挑战，因为资产可能会分布在整个网络中，包括组织外部。传统监视工具在了解单地址空间或服务器的性能 QoS 方面很在行，但在监视跨多个服务器（甚至可能跨多个公司）的 Web 服务方面并不能提供太多帮助。这些组合应用程序在 SOA 中非常常见。
监视是称为 SOA 治理的控制与反馈机制的一部分。对组合应用程序的监视具有独特的端到端管理问题（请参见参考资料部分列出的 Cappelli 的文章）。此类复杂问题的一个例子就是我们前面讨论的 SOA 中的事务。
仅在 UI 级监视 QoS 并不会发现任何问题（如性能下降）的根本原因。IBM Tivoli Composite Application Manager for SOA 支持进行 SOA 监视。

治理 一词在 SOA 中使用非常广泛。正如我们所知的，治理讨论的是对某事或某人的控制或权威。在讨论 SOA 时，它表示应该以标准的方式对服务使用和注册进行管理和监视。这一直是交付可重用服务时的一个不足之处。
治理涉及到决策过程中的所有涉众。所有涉众（而不仅是 IT 人员）对主要系统都负有责任。
IBM 的 WebSphere Service Registry and Repository (WSRR) 产品就是支持 SOA 治理的一个具体示例。它定义了一个已知的位置来保存和访问有关 Web 服务的信息。
服务驻留在注册中心或存储库中。这些机制需要非常可靠，否则注册中心服务的使用者就会对其丧失信心。除了处理可用性产品注册中心外，该管理员还要监视使用情况和错误，并处理任何其他问题。
注册中心管理员需要熟练使用服务监视工具，如 IBM 的 WebSphere Business Monitor。这些工具可收集关键性能指标（Key Performance Indicator，KPI），且能帮助检测正在运行的 SOA 中的反常情况。
IBM 还提供了一个名为 IBM WebSphere Services Registry and Repository 的工具，允许在您的 ESB 上发布和查找服务。有关更多信息，请参见参考资料。




回页首
Web 服务必须考虑来自多个用例的需求。传统上，开发人员以需求为基础进行开发。为了提高其有用性（即可重用性），构建组件时要考虑未来需求和替代需求。
Eric Pulier 建议在此过程中添加一个步骤：“自由讨论替代用例并与潜在涉众进行讨论”。团队可以随后调整其后续工作，以考虑扩展后的需求和未来需求（请参见参考资料部分列出的 Pulier 的文章）。