评论专栏: Andre Tost：您是 SOA 专家吗

不在 SOA 中迷失方向

我最近开始着手与人合作撰写一本书，讨论如何使用 Java™ 创建面向服务的体系结构（Service-Oriented Architecture，SOA）解决方案。关注这方面的东西时（即使很短时间），就会明显地发现，在 SOA 中扮演着重要角色的来自 IBM® 和其他厂商的各种产品正在不断增多——而这甚至还不包括正在进行的各个开源项目。最终我们了解到，如果没有恰当的方法、流程和组织，企业级别的 SOA 项目就不可能完全成功。这就导致了我不得不从高层的细节跳到很低层的细节，然后又回到高层细节，每天如此往复数次！我知道我的很多同行和同事都经历着相同的事情。

因此，我决定通过本文为您提供一个挑战和机会，将在其中简单地讨论今天的 SOA 专家要知道的“事项”的范围。这并不是要吓您——您可能已经觉得快被这个领域涉及的范围及发展的速度吞没了。相反，本文的目的是让您知道您并不是孤军奋战，并帮助您确保获得持续成功所需的工具和技巧。

回页首

流程与方法：“如何”与“什么”的问题

在 SOA 发展的早期，大部分讨论都是与技术相关的，此类技术主要集中在 Web 服务上：SOAP、WSDL、XML 模式等等。不过，SOA 背后的核心目标之一是，提高业务与 IT 之间的一致性，因此相关讨论开始越来越多地向这方面发展。哪些服务是我的业务所需的？这些服务是否对实际业务难点进行了处理？为了尽可能进行重用和支持进行快速变更来适应市场变化，我的服务的粒度应该如何？这个讨论非常重要（仍然将持续很长时间），其重点是其背后的核心问题的概念：什么是服务？

让这个问题（以及所有从其派生的问题）回答起来更为简单的方法是，转而研究“如何”方面。我如何标识我的业务需要哪些服务？如何将服务集组合为新解决方案？如何在服务设计中包含业务视图？以及我如何确保在 IT 中实现的服务真的是业务方面所需的服务？

您会注意到，我在此上下文中大量使用了术语“业务”。传统方法关注软件的体系结构设计与设计的 IT 方面的内容。SOA 带来一个全新的视角，而这需要在我们的流程和方法中加以反映。我所合作过的大部分公司或多或少都具有针对独立应用程序开发的流程。要建立支持创建面向服务的体系结构的环境，通常需要对这些流程进行调整，以包含跨企业的服务设计概念，而且更重要的是，要确保采用了从业务级别开始的恰当的“自顶向下”分析和设计。

我要在此处指出的两种方法是：

• 面向服务的建模和架构（Service Oriented Modeling and Architecture，SOMA）描述了一种方法，从标识相应的服务到对其加以实现，从而对服务进行建模和体系结构设计。

• Rational® Unified Process (RUP)，按照 Wikipedia 的定义，这种方法是一个迭代软件开发流程框架（不是单个具体的规定性流程，而是一种可采用的流程框架）旨在供开发组织和软件项目团队进行定制，将选择适合其需求的流程元素。这对此方法进行了很好的说明，显然它可以作为基于 SOA 的开发流程等的框架。而事实上，SOMA 方法已经包含到了 RUP 中了。可以获得用于 Rational Method Composer 的插件，可帮助您实现这个 RUP4SOMA 扩展。

底线是，SOA 专家必须知道如何定义和应用用于创建面向服务的体系结构的正确方法。采用 SOMA 之类的现有方法并使用 RUP 作为总体框架，可帮助引导讨论。

回页首

治理：避免服务混乱

与前一主题紧密相关的是治理。我已经提到，服务是为了跨企业重用而构建的，因此，软件显式地设计为独立于特定业务领域。大部分 IT 组织的结构都不对此提供支持，包括所使用的资金与 ROI 模型。必须建立服务所有关系定义。如果服务是作为订单管理项目的一部分构建，如果让其在整个企业内重用存在的额外成本，如何计算这个额外的成本呢？如果稍后另一个业务部门产生了保证持续更新服务的新需求，谁负责进行此工作，谁为此提供资金支持？

但组织仅是治理的一个方面。事实上，我们对此术语的定义非常宽泛。作为技术人员，我最关心 IT 治理，我上面所提到的所有关于流程和方法的东西当然也属于这一范畴。但还有更多的东西。除了讨论如何创建 SOA 解决方案之外，治理还讨论如何对其进行操作（随便提一下，可以参考 观点与展望，第 5 部分: 什么是 IT 管理，为什么应该对其加以注意？，其中提供了对 IT 治理的一种很不错的看法，同时也说明了这个主题内容的多样性）。IT 运行时管理也属于其中，我经常听到人们将信息技术服务管理（Information Technology Service Management，ITSM）称为一个关键规程，而将信息技术基础设施库（Information Technology Infrastructure Library，ITIL）看作实现此规程的重要框架。

总的说来，SOA 专家可以描述 SOA 治理的所有方面，包括方法（如前面所讨论的）、与 SOA 相关的组织挑战以及如何处理它们，另外还包括具体的 IT 治理技术和概念（如 ITSM 和 ITIL）。

回页首

体系结构：什么使其面向服务？

我们所进行的大量工作都是创建、描述或检查体系结构。这些体系结构对服务及其基础组件、这些服务间的关系进行描述。对系统的体系结构可使用很多透视图：例如，软件组件视图、上下文视图或操作视图。

通常，我们尝试通过正式的模型表示系统的体系结构，而此模型通常采用 UML 进行说明，使用工具来创建上面提到的各种透视图。Rational Software Architect 就是这样的工具。通过逐步的细化，我可以从模型派生出更为详细的细节，然后可以从其中生成具体的实现。模型最初是独立于平台的模型（Platform-Independent Model，PIM），后来逐渐转换为平台特定的模型（Platform-Specific Model，PSM）。（请注意，一定要不仅关注服务及其间的关系，还要对这些服务所在的环境进行描述。）

有了目标解决方案的正式表示形式，还让我能够应用通用设计模式，实际上就是重用各种用于表示组件及其交互的得到认可和验证的方法。通过这样，我可以轻松地应用企业服务总线之类的各种熟知概念（另请参见 IBM Patterns for e-business）。

对于 SOA 专家，这意味着他或她必须能够创建良好的体系结构，其中应用了面向服务的原则和大家熟知的 SOA 设计模式。体系结构采用 UML 表述为正式的模型，要使用 Rational Software Architect 之类的工具创建此模型。

回页首

标准：WS-* 迷宫

作为创建面向服务的体系结构和设计的一部分，标准的问题总是会出现——这毫不意外，因为利用基于标准的接口和消息模型是 SOA 的主要好处之一。标准可以是特定于行业的（例如，用于保险行业的 ACORD 或用于医疗保健行业的 HL7）或特定于技术的。对于 SOA（特别是 Web 服务），已经建立了大量的标准——实际上，我们应该将其全部均称为“规范”，因为其中很多尚未实际成为正式标准。其中一些已经得到了相关供应商的大力支持，一些还没有得到大家的认可，其中一些甚至彼此重叠和相互竞争。

为了更为简单一些，我们开始使用“概要”的概念。概要——大部分都是由 WS-I 组织定义，归其所有——是处理特定场景的规范和标准包。例如，WS-I 基本概要 (WS-I Basic Profile) 包括支持可互操作的基本 Web 服务交互的所有核心 Web 服务标准（SOAP、WSDL、XML 等）。而可靠安全概要 (Reliable Secure Profile) 则是更为高级的概要的例子，其中包括 WS-ReliableMessaging 和 WS-SecureConversation 等内容，用于支持构建能够可靠而安全地交换消息的解决方案。

作为 SOA 专家，您需要知道所有相关 WS-* 标准和规范，能够确定各自的位置，知道其状态以及如何将其应用到给定的解决方案体系结构。而且，您还需要知道哪个产品支持哪个版本的标准——而这就是我们下一个主题将讨论的内容。

回页首

产品

这很可能成为本文中最长的部分。我们 IBM 总是积极地推出各种软件产品，而最后介绍的这些产品也推动着我们所进行的工作，包括从建模到开发，再到运行时以及 IT 解决方案的部署与管理。

没有任何两个客户是完全相同的。事实上，当我认为已经“完全了解”的时候，我遇到了之前从来没有遇到过的新挑战。当然，这其中的部分原因是因为软件技术的极高创新速度。有些组织拥有存在多年的系统，而且他们对此相当满意，而其他组织则喜欢尽可能让自己站在技术的前沿位置。大多数企业都处于两者之间，拥有非常多样化的异类平台和应用程序。

考虑到这个多样性，向 SOA 进发的过程中会涉及到大量技术和产品。例如，您可能会通过将业务流程表示为符合 BPEL 标准的流来对其进行建模，并随后将其在 WebSphere® Process Server 上部署和实现。或者，您可能会希望建立企业服务总线（Enterprise Service Bus，ESB），以使用 WebSphere ESB 跨多个不同的网络协议和数据格式集成现有功能。可以使用 Tivoli® 提供的 ITCAM 系列产品来建立 SOA 管理。将基于门户的用户界面环境（基于 WebSphere Portal Server）插入到在大型机上的 CICS® 中运行的一组服务中。这个列表非常长。

并非到这里就完了。作为专家，我们有时候会遇到有关特定产品和平台的非常细节的问题。我下面将给出一些例子，所有这些问题都是我在过去数周中碰到的问题：

1. 我如何在 WebSphere Process Server 中的 BPEL 流程内跨多个合作伙伴链接调用保留 SOAP Header 字段？
2. 用于记录给定服务的请求方的名称的 WebSphere ESB 自定义中介元素是什么样？
3. 如果协议为 HTTP、JMS、MQ，我如何将响应消息相关到 Message Broker 流中的相应请求节点？
4. WebSphere Application Server 是否支持 WS-Policy 标准？
5. 如何将现有 C++ 应用程序的基于 CORBA 的接口替换为使用 IBM 产品的 Web 服务？
6. SIBus 功能提供用于检索总线名称、目的地名称和类型等信息的 JMX 接口是什么？
7. 在 iSeries 上运行的 RPG 应用程序连接到 DataPower 应用程序的最佳方式是什么？
8. 为了利用面向 SOA 的 ITCAM 产品，我需要哪个版本的 IBM Tivoli Monitoring？

这个列表会非常长，在大多数情况下，并不能给出简单的回答（有时候也很简单）。但我甚至还没有提出一个我最看重的问题：所有这些与您的竞争者的产品比较起来如何？（到底为什么会有人问这个问题呢？）

能帮助我们通过这个迷宫的是 IBM SOA Foundation 的概念以及相关的 SOA 参考体系结构，其中提供了结构设计方法，帮助确定相关功能组的结构，随后可使用这些功能组定位与之相关的产品。

既然这样，SOA 专家应该知道 IBM SOA Foundation 中的基本产品集以及整个 SOA 软件市场中的相关产品。这包括有关这些产品彼此如何集成（以及如何与现有系统集成）和如何优化在其上运行的解决方案的技能。

回页首

Java 技术：Annotations，有人知道吗？

正如我提到的，我现在正在撰写一本关于 SOA 和 Java 的书。由于书籍出版前需要一段时间，因此它应该基于书籍推出时可用的最新 Java 技术。目前最新的技术是 Java 5，具体来说是 Java Enterprise Edition (Java EE™) V5。对于 Web 服务而言，Java 内的重要标准是 JAXB V2.0 和 JAX-WS V2.0。

所有这些技术都相对较新，通常在商业中间件产品中尚不可用（但这种情况会很快发生变化）。目前作为开源项目提供了参考实现；例如 Glassfish 项目构建了一个 Java EE 5 应用服务器，其中包括对 JAXB 和 JAX-WS 的支持。由于该书应该是独立于供应商的，因此我们使用了 Eclipse 工具平台来开发示例（Eclipse 实际上是所有 IBM 工具产品的基础）。

因此，我在本书的撰写各章节时，了解了关于这些新标准和编程模型的大量信息，我相信这些标准和模型将很快在我们的客户项目中得到越来越多的应用。我们现在也已经在 WebSphere 产品系列中看到了对此的支持。

与我们在目前 J2EE™ 中（J2EE 中的“2”在 Java V5 中消失了）构建 Web 服务的方式的一个重大差别是使用了 Annotation。简单说来，我们用于定义不断增长的部署描述符的很多元素都归结于 Java 源代码，即带“@”前缀的关键字。将随后在源代码中自动处理这些关键字，以便使所有信息都位于一个地方，而不是分布在多个不同的文件中。我个人必须承认，我对 Annotation 并不十分感冒。乍看之下，这些似乎使一切变得简单了（所有东西都在一个地方，在代码中我需要的地方），但这也使得建立良好的关注分离（业务逻辑编码与进行部署决策）和实现更为声明化的编程风格变得很难。

另一个大的变化是“通用对象”。这稍微有些偏题，您可以参考相关的教程；另外还要指出的是，我非常喜欢这些东西，特别是其应用到 JAX-WS 提供者编程模型的方式。

不过，无论喜欢与否，SOA 专家都必须了解一系列标准 Java API 并能够对其加以应用（特别是影响 Web 服务和 XML 的 Java API），并能够说明这些 API 的不同版本间的差别。

回页首

特殊专业技能

如果阅读了这些内容，仍然认为自己是符合上面所述要求的 SOA 专家，您一定是个天才，请立即与我们联系，因为 IBM 可能会希望能够聘请您到我们的企业来！

但严肃点说，面向服务的计算领域是一个涉及面复杂的相当大的领域，仍然在迅速地扩展，正逐渐地成为构建软件系统的一个主要方式。要彻底地了解它的每个方面并不可能，因此我们所能做的就是专注于它的某个特定部分，并同时保持对整体情况的足够认识。