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