面向服务的体系架构(Service Oriented Architecture, SOA)就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或者其他服务。如今，企业级应用的开发都采用面向服务的体系架构来满足灵活多变，可重用性高的需求。IBM Rational Software Architect(RSA)是一套设计与开发工具，它构建在开放的、可扩展的Eclipse3.0平台之上，实现了多项行业最新标准，提供了灵活的插件扩展机制。借助UML2.0技术，它实现了模型驱动的软件开发模式，可以帮助开发团队创建更加强壮的软件结构。

本文从总体上介绍了SOA实现的相关技术，以及RSA中对这些技术的支持与扩展。

2 面向服务的体系架构 - SOA

在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一步一步构建起形形色色的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段，甚至上线阶段遭遇应接不暇的需求变更的极端痛苦。如何解决这一问题?能否来一场软件开发和架构的革命?SOA的提出，就是被人看成这样的一场革命。其实质就是要将系统模型与系统实现分割开来。

2.1 什么是SOA

2.1.1 定义

SOA并不是一个新概念，有人就将CORBA和DCOM等组件模型看成SOA架构的前身。早在1996年，Gartner Group就已经提出了SOA的预言，不过那个时候仅仅是一个"预言"，当时的软件发展水平和信息化程度还不足以支撑这样的概念走进实质性应用阶段。到了近一两年，SOA的技术实现手段渐渐成熟了，在BEA、IBM等软件巨头的极力推动下，才得以慢慢风行起来。

关于SOA，一般认为:SOA，面向服务的架构是一个组件模型，它将应用程序的不同功能单元----服务(service)，通过服务间定义良好的接口和契约(contract)联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合。

2.1.2 SOA中的特征

从SOA的定义中，我们看到两点:

软件系统架构: SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构，从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。

服务(service)是整个SOA实现的核心。SOA架构的基本元素是服务，SOA 指定一组实体(服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约)，这些实体详细说明了如何提供和消费服务。遵循 SOA 观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。

基于上面讨论，我们给出SOA的下面一些特征:

服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。

服务的重用(reuse)。服务的可重用性设计显著地降低了成本。为了实现可重用性，服务只工作在特定处理过程的上下文(context)中，独立于底层实现和客户需求的变更。

服务的互操作(interoperability)。互操作并不是一个新概念。在CORBA、DCOM、web service中就已经采用互操作技术了。在SOA中，通过服务之间既定的通信协议进行互操作。主要有同步和异步两种通信机制。SOA提供服务的互操作特性更利于其在多个场合被重用。

服务是自治的(Autonomous)功能实体。服务是由组件组成的组合模块，是自包含和模块化的。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体;当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，消息队列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

服务之间的松耦合度(Loosly Coupled)。服务请求者到服务提供者的绑定与服务之间应该是松耦合的。这就意味着，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台，等等。服务请求者往往通过消息调用操作，请求消息和响应，而不是通过使用 API 和文件格式。这个松耦合使会话一端的软件可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前基于遗留代码(例如，COBOL)的实现完全用基于 Java 语言的新代码取代，同时又不对服务请求者造成任何影响。这种情况是真实的，只要新代码支持相同的通信协议。

服务是位置透明的(location transparency)。服务是针对业务需求设计的。需要反应需求的变化，即所谓敏捷(agility)设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。

2.2 SOA不等于web 服务

由于Web服务与SOA有着很多相同的技术特点，如:基于XML语言，符合SOAP、WSDL和UDDI标准等，很多人都认为下一代Web服务就是SOA。 Web服务可以用来实现SOA，但是如果没有Web服务，企业照样也可以很好地实现SOA。反之，即便是利用Web服务技术，也不一定能保证SOA的效果就更好。

Web服务与SOA关系如图1所示。

SOA的灵活性将给企业带来巨大的好处。如果把企业的IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客(可能在公司内部，也可能是公司的某个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。

但是，要得到这种灵活性，需要有一系列实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成"面向服务的架构设计师"，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。那么目前SOA的实现技术究竟有哪些呢?

3.1 实现SOA的核心技术 - web 服务

正如我们前面所讲的，服务是整个SOA实现的核心，web服务相关技术自然成为实现SOA的首选。

XML

XML 1.0 (可扩展标记语言，Extensible Markup Language) 标准是一个基于文本的 World Wide Web 组织 (W3C) 规范的标记语言。与 HTML 使用标签来描述外观和数据不同，XML 严格地定义了可移植的结构化数据。它可以作为定义数据描述语言的语言，如标记语法或词汇、交换格式和通信协议。

SOAP

简单对象访问协议 (Simple Object Access Protocol) 是一个基于XML的，用于在分布式环境下交换信息的轻量级协议。SOAP 在请求者和提供者对象之间定义了一个通信协议，这样，在面向对象编程流行的环境中，该请求对象可以在提供的对象上执行远程方法调用。因为SOAP是平台无关和厂商无关的标准，因此尽管SOA并不必须使用SOAP，但在带有单独 IT基础架构的合作伙伴之间的松耦合互操作中，SOAP仍然是支持服务调用的最好方法。

W3C SOAP 1.2规范在服务请求者和服务提供者之间定义使用XML格式的消息进行通信。将应用程序请求(在XML中)放入 SOAP 信封中(也是 XML )，并从请求者到提供者发送应用程序请求，提供者发回的响应也采用相同的形式。最近 SOAP 被称为面向服务的架构协议 (Services-Oriented Architecture Protocol)。 SOAP的优点在于它完全和厂商无关，相对于平台、操作系统、目标模型和编程语言可以独立实现。另外，传输和语言绑定以及数据编码的参数选择都是由实现决定的。

WSDL

Web服务描述语言 WSDL (Web Services Description Language) 是一个提供描述服务IDL标准方法的XML词汇。Web 服务描述语言(WSDL)规范定义了一个 XML词汇表，该词汇表依照请求和响应消息，在服务请求者和服务提供者之间定义了一种契约。我们能够将Web服务定义为软件，这个软件通过描述SOAP消息接口的 WSDL文档来提供可重用的应用程序功能，并使用标准的传输协议来进行传递。

WSDL描述包含必要的细节,以便服务请求者能够使用特定服务:

请求消息格式
　响应消息格式
　向何处发送消息。

WSDL 是基于 XML 的，因此 WSDL 文档是计算机可读的(machine-readable)。这样开发环境使用WSDL将集成服务的流程自动处理到请求者应用程序。例如 WebSphere Studio产生一个Java的代理对象，它能够像本地对象一样实现服务，但是实际上代理对象仅仅处理请求的创建和响应消息的解析。不管服务是否用Java、C#或者其他的语言实现，生成的Java代理对象都能够从WSDL描述中调用任何的Web服务。实际上，WSDL不能像编程语言那样描述实现细节。

UDDI

统一描述、发现和集成 (Universal Description, Discovery and Integration) 规范提供了一组公用的 SOAP API，使得服务代理得以实现。UDDI为发布服务的可用性和发现所需服务定义了一个标准接口(基于 SOAP 消息)。UDDI 实现将发布和发现服务的 SOAP 请求解释为用于基本数据存储的数据管理功能调用。

为了发布和发现其他SOA服务，UDDI 通过定义标准的 SOAP 消息来实现服务注册(Service Registry)。注册是一种服务代理，它是在 UDDI 上需要发现服务的请求者和发布服务的提供者之间的中介。一旦请求者决定使用特定的服务，开发者通常借助于开发工具(如Microsoft Visual Studio .NET)并通过创建以发送请求并处理响应的方式访问服务的代码来绑定服务。

SOA不需要使用UDDI，但由于 UDDI 是建立在SOA上来完成自身工作的，所以UDDI是服务发现的一个好的解决方案。

企业服务总线ESB(Enterprise Service Bus)是SOA架构的一个支柱技术。 作为一种消息代理架构它提供消息队列系统，使用诸如SOAP或JMS (Java Message Service)等标准技术来实现。 有人把ESB描述成一种开放的、基于标准的消息机制，通过简单的标准适配器和接口，来完成粗粒度应用(比如服务)和其他组件之间的互操作。

ESB的主要功能有:通信和消息处理、服务交互和安全性控制、服务质量和服务级别管理、建模、管理和自治、基础架构智能等。ESB由中间件技术实现并作为支持 SOA 的一组基础架构，支持异构环境中的服务、消息，以及基于事件的交互，并且具有适当的服务级别和可管理性。

SOA的原则可以描述如下:

　利用显式的与实现无关的接口来定义服务。
　利用强调位置透明性和可互操作性的通信协议。
　封装可重用业务功能的服务的定义。

为了实现 SOA，应用程序和基础架构都必须支持 SOA 原则。启用 SOA 应用程序涉及到创建服务接口，服务接口可以直接也可以间接地通过使用适配器用于现有的或新的功能。从最基本的级别来看，启用该基础架构涉及到规划功能来将服务请求路由和传递给正确的服务提供者。然而，基础架构支持在不影响服务的客户端的情况下由另一个服务实现替代原有的服务实现也是至关重要的。这不仅需要根据 SOA 原则指定服务接口，而且需要基础架构允许客户端代码以独立于所涉及的服务位置和通信协议的方式来调用服务。这样的服务路由和替代是 ESB 的许多功能中的一部分。

ESB 支持这些服务交互功能，并提供集成的通信、消息传递以及事件基础架构来支持这些功能。因此，它将当今正在使用的主要企业集成模式组合成一个实体。ESB 为 SOA 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。图2显示了ESB为SOA提供的基础架构:

Business Service Choreographer 的作用是通过若干业务服务来组合业务流程;因此，它将通过 ESB 调用服务，然后再次通过 ESB 将业务流程公开为客户端可用的其他服务。然而，Business Service Choreographer 在编排业务流程和服务中所扮演的角色确定了这种业务工作流技术是一种与基础架构技术 ESB 分离的技术。

　最后，B2B Gateway 组件的作用是使两个或多个组织的服务在受控且安全的方式下对彼此可用。这有助于查看这些连接到 ESB 的组件，但它们并不是 ESB 的一部分。虽然有一些网关技术可以提供适合于实现 B2B Gateway 组件和 ESB 的功能，但是 B2B Gateway 组件的用途是将其与 ESB 分离。事实上，这种用途可能需要附加的功能(如合作伙伴关系管理)，这些功能不是 ESB 的一部分，并且不一定受到 ESB 技术的支持。

　3.3 实现SOA的方法学 - 模型驱动的开发

SOA强调松散耦合，强调跨平台集成，这与模型驱动的架构和开发不谋而合。模型驱动的架构和开发(Model Driven Architecture, MDA以及Model Driven Development, MDD)并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。

MDA由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。

基于MDA的思想，利用MDD方式，我们可以对SOA进行建模，在此基础上，实现各种形式的模型转换或扩展实现SOA.

4 RSA对SOA实现技术的支持

IBM 软件开发平台提供了对SOA 应用程序开发的最好支持。IBM 软件开发平台包含 Rational 产品家族、向导、模板、及构建应用程序的指南，Rational 开发工具是基于成功的并且非常受欢迎的 Eclipse 平台，它不仅易用、灵活，而且在每一个开发进程中都可以使用外部开发环境。图3显示了基于 Eclipse 的 IBM Rational 产品体系。

Rational Software Architect, RSA涵盖了RAD以及RSM的全部功能，提供了对基于模型的开发以及web应用开发的最好的支持。

4.1 对web服务开发的支持

RSA中包含了构建 Web 服务的专门工具，可以通过自顶向下，自底向上，为web服务建模等不同角度进行web服务的开发，提供了代码编写和完成应用程序的开发环境。还可以使用一些额外的工具(比如 IBM Rational Functional Tester)，对应用程序进行测试，然后把它部署到 WebSphere 服务器平台中。

首先，RSA提供了XML的编辑器，可以对XML进行图形化的显示和编辑，图4显示了对XML的图形编辑界面及其对应的源代码。

RSA内嵌了WebSphere Application Server 6.0的运行环境，WAS 6.0中的SI-BUS实现了ESB，因此我们可以用RSA进行SOA、ESB的部署和测试。如图10所示，可以在RSA上创建WAS 6.0的服务实例，并在此服务上部署ESB。

除了对web服务开发的支持，RSA还提供对UML2.0规范以及可重用资产规范(Reusable Asset Specification, RAS )的支持。这就使得基于模型的开发(Model Based Development, MDA) 和基于资产的开发(Asset Based Development, ABD)成为RSA最有优势的两大特征。这里我们只作简单介绍。

4.2.1 支持UML2.0的MDA平台

UML是实现MDA技术的一把钥匙，它使得用MDA技术创建的所有应用程序都基于标准化的、平台独立的UML模型。通过将这一通用的、被普遍接受的建模标准作为杠杆，MDA使得开发人员可以创建能被轻便地访问、天生具有良好的互操作性的应用程序。我们在前面提到，利用RSA可以对web服务建模，通过模型转换生成web服务。

基于Eclipse平台的RSA，提供各种模式(Pattern)，模板(Template)插件的开发，通过这些高可重用度的模式及模板，用户只需要简单的参数配置，就可以得到相应的模型，代码及其他资源。图11显示了应用RSA模式生成新的模型，再基于新模型生成可部署的项目及代码。

　4.2.2 Recipe - 基于资产的开发(Asset Based Development)

RSA中的解决方案指导(Solution Guide)插件基于可重用资产规范对资产的创建，打包，发布，到重用提供了全方位的支持。可以将各种模式，模型及其他可重用资源作为资产导出，存入本地或远程资产库以便重用及共享，资产在资产库中按照一定的方法进行分类，在RSA中使用资产库浏览器对资产进行查找时一目了然。图12是在可重用资产视图中，浏览资产库。

　5 总结

在本文中，我们讨论了面向服务体系架构的基本概念以及实现技术，并列出了IBM Rational产品RSA对实现SOA的技术的支持，在后续的文章中，我们将对本文中涉及的各项具体技术实现细节作详细介绍。