【IT168 技术文档】

　　概述

　　面向服务的体系架构（service Oriented Architecture，SOA）就是在分布式的环境中，将各种功能都以服务的形式提供给最终用户或者其他服务。如今，企业级应用的开发都采用面向服务的体系架构来满足灵活多变，可重用性高的需求。

　面向服务的体系架构 - SOA

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

　　什么是SOA

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

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

　　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）设计。要想真正实现业务与服务的分离。就必须使得服务的设计和部署对用户来说是完全透明的。也就是说，用户完全不必知道响应自己需求的服务的位置，甚至不必知道具体是哪个服务参与了响应。

　　SOA不等于web 服务

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

　　Web服务是一套技术体系，可以用来建立应用解决方案，解决特定的消息通信和应用集成问题。随着时间的推移，我们发现，这些技术在不断发展、不断成熟，也会更好地帮助你实现SOA。SOA是一种软件架构，而不局限于某个技术的组合（例如Web服务），它超越了技术范畴。在一个商业环境中，纯粹的SOA是一种应用软件架构，其中所有的功能都是相互独立的服务模块，通过完备定义的接口相互联系起来。只要按照一定的顺序来请求这些功能模块所提供的服务，就可以形成完整的业务流程。正如IBM SOA技术和策略总监Mark Colan先生强调的那样：“Web服务的确是实现SOA一条最好的路，但不等同于SOA。”

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

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