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 作为总体框架，可帮助引导讨论。

　　SOA专家需了解的事情越来越多。本文给出一清单，帮助您洞悉相关内容……

　　治理：避免服务混乱

　　与前一主题紧密相关的是治理。我已经提到，服务是为了跨企业重用而构建的，因此，软件显式地设计为独立于特定业务领域。大部分 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-* 标准和规范，能够确定各自的位置，知道其状态以及如何将其应用到给定的解决方案体系结构。而且，您还需要知道哪个产品支持哪个版本的标准——而这就是我们下一个主题将讨论的内容。

……