SOA的实现技术

　　实现SOA的核心技术 - Web 服务

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

XML

　　XML（可扩展标记语言，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是服务发现的一个好的解决方案。

　　SOA 基础架构的关键组件 -企业服务总线（Enterprise Service Bus，ESB）

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

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

　　SOA的原则可以描述如下：

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

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

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

　　ESB需要某种形式的服务路由目录（Service Routing Directory）来路由服务请求。然而，SOA 可能还有单独的业务服务目录（Business Service Directory），其最基本的形式可能是设计时服务目录，用于在组织的整个开发活动中实现服务的重用。Web 服务远景在业务服务目录和服务路由目录的角色中都放置了一个 UDDI 目录，因而使得可以动态发现和调用服务。这样的目录可以视为 ESB 的一部分；然而，在这样的解决方案变得普遍之前，业务服务目录可能与 ESB 是分离的。

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

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

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

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

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

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