面向服务的体系架构 SOA企业应用SOAPWebIT厂商
面向服务的体系架构(Service Oriented Architecture, SOA)就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或者其他服务。如今，企业级应用的开发都采用面向服务的体系架构来满足灵活多变，可重用性高的需求。
在经典软件工程理论中，不管是瀑布方法还是原型方法，都是从需求分析做起，一步一步构建起形形色色的软件系统。但是，需求变更像一个挥之不去的阴影，时刻伴随着系统左右。每一个实际应用系统的开发者都饱尝了在系统进入开发阶段、测试阶段，甚至上线阶段遭遇应接不暇的需求变更的极端痛苦。如何解决这一问题？能否来一场软件开发和架构的革命？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）设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。
由于Web服务与SOA有着很多相同的技术特点，如：基于XML语言，符合SOAP、WSDL和UDDI标准等，很多人都认为下一代Web服务就是SOA。 Web服务可以用来实现SOA，但是如果没有Web服务，企业照样也可以很好地实现SOA。反之，即便是利用Web服务技术，也不一定能保证SOA的效果就更好。
Web服务与SOA关系如图1所示。
Web服务是一套技术体系，可以用来建立应用解决方案，解决特定的消息通信和应用集成问题。随着时间的推移，我们发现，这些技术在不断发展、不断成熟，也会更好地帮助你实现SOA。SOA是一种软件架构，而不局限于某个技术的组合(例如Web服务)，它超越了技术范畴。在一个商业环境中，纯粹的SOA是一种应用软件架构，其中所有的功能都是相互独立的服务模块，通过完备定义的接口相互联系起来。只要按照一定的顺序来请求这些功能模块所提供的服务，就可以形成完整的业务流程。正如IBM SOA技术和策略总监Mark Colan先生强调的那样："Web服务的确是实现SOA一条最好的路，但不等同于SOA。"
SOA的灵活性将给企业带来巨大的好处。如果把企业的IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客（可能在公司内部，也可能是公司的某个业务伙伴）就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。
但是，要得到这种灵活性，需要有一系列实现架构的新方法，这是一项艰巨的任务。企业架构设计师必须要变成"面向服务的架构设计师"，不仅要理解SOA，还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙，也非常关键。那么目前SOA的实现技术究竟有哪些呢?
正如我们前面所讲的，服务是整个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描述包含必要的细节,以便服务请求者能够使用特定服务：- 请求消息格式
- 响应消息格式
- 向何处发送消息。
- 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是服务发现的一个好的解决方案。
3.2 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 提供与企业需要保持一致的基础架构，从而提供合适的服务级别和可管理性、以及异构环境中的操作。图2显示了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强调松散耦合，强调跨平台集成，这与模型驱动的架构和开发不谋而合。模型驱动的架构和开发(Model Driven Architecture, MDA以及Model Driven Development, MDD)并没有把业务模型和平台无关模型分开来，而是把平台无关模型做为起点。
MDA由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use cases，根据系统搭建的平台，架构设计师可以由这个平台无关的模型得到平台相关的模型，这些平台相关模型足够详细，以至于可以用来直接生成需要的代码。
基于MDA的思想，利用MDD方式，我们可以对SOA进行建模，在此基础上，实现各种形式的模型转换或扩展实现SOA.