作者:Raghu R. Kodali tetsu(作者的Blog:http://blog.matrix.org.cn/page/tetsu)
原文:http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html
中文:http://www.matrix.org.cn/resource/article/44/44070_SOA.html
关键字:SOA
摘要
在最近的软件发展中，面向服务架构（SOA, service-oriented architecture）成为了时下的热门话题。这篇文章将向大家介绍SOA，讨论企业为什么需要SOA，什么是SOA，从核心，平台，服务品质3个层面来解释SOA的基础构成。
By Raghu R. Kodali
对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，SOA是一场革命。一个应用程序的业务逻辑（business logic）或某些单独的功能被模块化并作为服务呈现给消费者或客户端。这些服务的关键是他们的松耦合特性。例如，服务的接口和实现相独立。应用开发人员或者系统集成者可以通过组合一个或多个服务来构建应用，而无须理解服务的底层实现。举例来说，一个服务可以用.NET或J2EE来实现，而使用该服务的应用程序可以在不同的平台之上，使用的语言也可以不同。
SOA有以下特性
SOA服务具有平台独立的自我描述XML文档。Web服务描述语言（WSDL, Web Services Description Language）是用于描述服务的标准语言。
SOA 服务用消息进行通信，该消息通常使用XML Schema来定义（也叫做XSD, XML Schema Definition）。消费者和提供者或消费者和服务之间的通信多见于不知道提供者的环境中。服务间的通讯也可以看作企业内部处理的关键商业文档。
在一个企业内部，SOA服务通过一个扮演目录列表（directory listing）角色的登记处(Registry)来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。统一描述，定义和集成 (UDDI, Universal Description, Definition, and Integration)是服务登记的标准。
每项SOA服务都有一个与之相关的服务品质（QoS, quality of service）。QoS的一些关键元素有安全需求（例如认证和授权），可靠通信（译注：可靠消息是指，确保消息“仅且仅仅”发送一次，从而过滤重复信息。），以及谁能调用服务的策略。
为什么选择SOA？
不 同种类的操作系统，应用软件，系统软件和应用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程序被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程序和应用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的应用作为服务，从而保护了现有的IT基础建设投资。
如图1的例子所示，一个使用SOA的企业，可以使用一组现有的应用来创建一个供应链复合应用（supply chain composite application），这些现有的应用通过标准接口来提供功能。
Figure 1. Supply chain application. Click on thumbnail to view full-sized image.
服务架构
为了实现SOA，企业需要一个服务架构，图2显示了一个例子：
Figure 2. A sample service architecture. Click on thumbnail to view full-sized image.
在 图2中， 服务消费者（service consumer）可以通过发送消息来调用服务。这些消息由一个服务总线（service bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。
SOA基础结构
要运行，管理SOA应用程序，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标准，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。接下来的章节将逐一讨论该结构的每个部分。
Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized image.
SOAP, WSDL, UDDI
WSDL， UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务；UDDI用来注册和查找服务；而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表（registry）查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。
WS-I Basic Profile
WS-I Basic Profile，由Web服务互用性组织（Web Services Interoperability Organization）提供，是SOA服务测试与互用性所需要的核心构件。服务提供者可以使用Basic Profile测试程序来测试服务在不同平台和技术上的互用性。
J2EE 和 .Net
尽管J2EE和.NET平台是开发SOA应用程序常用的平台，但SOA不仅限于此。像J2EE这类平台，不仅为开发者自然而然地参与到SOA中来提供了一个平台，还通过他们内在的特性，将可扩展性，可靠性，可用性以及性能引入了SOA世界。新的规范，例如 JAXB（Java API for XML Binding），用于将XML文档定位到Java类；JAXR（Java API for XML Registry）用来规范对UDDI注册表（registry）的操作；XML-RPC（Java API for XML-based Remote Procedure Call）在J2EE1.4中用来调用远程服务，这使得开发和部署可移植于标准J2EE容器的Web服务变得容易，与此同时，实现了跨平台（如.NET）的服务互用。
服务品质
在企业中，关键任务系统（mission-critical system，译注：关键任务系统是指如果一个系统的可靠性对于一个组织是至关重要的，那么该系统就是该企业的关键任务系统。比如，电话系统对于一个电话促销企业来说就是关键任务系统，而文字处理系统就不那么关键了。）用来解决高级需求，例如安全性，可靠性，事物。当一个企业开始采用服务架构作为工具来进行开发和部署应用的时候，基本的Web服务规范，像WSDL，SOAP，以及UDDI就不能满足这些高级需求。正如前面所提到的，这些需求也称作服务品质（QoS，quality of services）。与QoS相关的众多规范已经由一些标准化组织（standards bodies）提出，像W3C（World Wide Web Consortium）和OASIS（the Organization for the Advancement of Structured Information Standards）。下面的部分将会讨论一些QoS服务和相关标准。
安全
Web服务安全规范用来保证消息的安全 性。该规范主要包括认证交换，消息完整性和消息保密。该规范吸引人的地方在于它借助现有的安全标准，例如，SAML（as Security Assertion Markup Language）来实现web服务消息的安全。OASIS正致力于Web服务安全规范的制定。
可靠
在 典型的SOA 环境中，服务消费者和服务提供者之间会有几种不同的文档在进行交换。具有诸如“仅且仅仅传送一次”（ once-and-only-once delivery），“最多传送一次”（ at-most-once delivery），“重复消息过滤”（duplicate message elimination），“保证消息传送”（guaranteed message delivery）等特性消息的发送和确认，在关键任务系统（mission-critical systems）中变得十分重要。WS-Reliability 和 WS-ReliableMessaging是两个用来解决此类问题的标准。这些标准现在都由OASIS负责。
策略
服务提供者有时候会要求服务消费者与某种策略通信。比如，服务提供商可能会要求消费者提供Kerberos安全标示，才能取得某项服务。这些要求被定义为策略断言（policy assertions）。一项策略可能会包含多个断言。WS-Policy用来标准化服务消费者和服务提供者之间的策略通信。
控制
当 企业着手于服务架构时，服务可以用来整合数据仓库（silos of data），应用程序，以及组件。整合应用意味着例如异步通信，并行处理，数据转换，以及校正等进程请求必须被标准化。在SOA中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。WSBPEL目前也由OASIS负责。
管理
随着企业服务的增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有运行在多相环境下的服务的管理系统就显得尤为重要。WSDM（Web Services for Distributed Management）规定了任何根据WSDM实现的服务都可以由一个WSDM适应（WSDM-compliant）的管理方案来管理。
其它的qos特性，比如合作方之間的溝通和通訊，多個服務之間的事務處理，都在WS-Coordination 和 WS-Transaction 標準中描述， 這些都是OASIS 的工作.
SOA 不是Web服务
在理解SOA和Web服务的关系上，经常发生混淆。根据2003年4月的Gartner报道，Yefim V. Natis就这个问题是这样解释的：“Web服务是技术规范，而SOA是设计原则。特别是Web服务中的WSDL，是一个SOA配套的接口定义标准：这是 Web服务和SOA的根本联系。”从本质上来说，SOA是一种架构模式，而Web服务是利用一组标准实现的服务。Web服务是实现SOA的方式之一。用 Web服务来实现SOA的好处是你可以实现一个中立平台，来获得服务，而且随着越来越多的软件商支持越来越多的Web服务规范，你会取得更好的通用性。
SOA的优势
SOA 的概念并非什么新东西，SOA不同于现有的分布式技术之处在于大多数软件商接受它并有可以实现SOA的平台或应用程序。SOA伴随着无处不在的标准，为企业的现有资产或投资带来了更好的重用性。SOA能够在最新的和现有的应用之上创建应用；SOA能够使客户或服务消费者免予服务实现的改变所带来的影响； SOA能够升级单个服务或服务消费者而无需重写整个应用，也无需保留已经不再适用于新需求的现有系统。总而言之，SOA以借助现有的应用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。
什么是SOA
介绍
"事情可以变的尽可能的简单,但不可能更加简单"
--爱因斯坦
概述
爱因斯坦在数十年前做了上述的著名论断,时至今日,这句话依然与大型软件系统的构建息息相关.不幸的是,任何一个在IT业待了足够长时间的人都能够指出,有太多的软件系统已经在爱因斯坦的这句话上失败了.一些系统做的太简单,以至于无法胜任其应当承担的责任;而另一些则做的过于复杂,使的开发和维护的成本急剧上升,并且没有注意到可能会出现的系统整合需求.看上去要达到"简要"这个程度更像是一个不实际的梦想而已.我们到底错在哪?
松耦合
问题其实就在我们身边.当我们构建了越来越多的软件系统后,出现了许多相似的场景和模式.很自然的,比起把它们全部除去,我们更希望能重复利用这些现有系统的功能.我们先给出一个名词的定义.真实依赖:这是一种事件的状态,它代表了一个系统依赖另一个系统提供的功能这种状态.如果这个世界只存在真实依赖,爱因斯坦的试验也许在多年以前已经实现的很好了.问题就在于,在真实依赖之间我们同样创建了许多的虚假依赖.
如果你去海外出差,你知道你必须随身带着电源适配器,否则你的生活将一塌糊涂.真实依赖是,你需要电力,而虚假依赖是你的插头必须插到当地的插座去.看看那些不同国家的各色的插头,你会注意到,他们有些又小又紧凑,还有些则又大又粗.
这里面给我们的教训就是,虚假依赖是不可以移除的,但是我们可以削弱它.如果我们能够理想的把系统间的依赖降到最低,那我们就已经达到了松耦合的目的,我们可以把那句明言重新加工一下:"虚假依赖应该降到最低而真实依赖是不可改变的."
SOA的定义和解释
现在,我们可以给面向服务架构一个定义了.SOA是个旨在使相互作用的软件业务达到松耦合效果的架构.服务是一个由服务提供者提供的,实现服务消费者的请求的业务单元.提供者和消费者都是软件代理为了各自的利益而产生的角色.
这听起来似乎有些太抽象了,但SOA实际上无所不在.让我们来看个在我们生活中随处可见的有关SOA的例子吧.拿CD做例子.如果你想播放CD,你会把CD插到一个CD播放器里面来播放.CD播放器提供了播放CD的服务.令人高兴的是,你可以更换不同的CD播放器.你可以用一个随身的播放器或是你的昂贵的立体声系统来播放同一张CD.他们都给您提供了播放CD的服务,但是服务质量是不同的.
SOA的思想与面向对象思想有着许多意味深长的差异.在面向对象编程中,数据和行为被强烈的建议绑定在一起.因此,在面向对象的设计中,每个CD应该伴随它自己的播放器,并且不应该被分开.这听起来有些奇怪,但这确实是我们构建许多软件系统的方法.
服务的结果通常可以改变消费者的状态同样也可能改变服务提供商的状态也可能都改变.在你用你的CD播放器听完音乐后,你的心情发生了变化,从"沮丧"变成了"高兴".如果你想要一个涉及到双方状态改变的例子,那么在饭店吃饭将是个很好的例子.
我们想找人帮忙做某项工作通常是因为那个人是那个方向的专家.而消费一个服务通常要比我们自己干来的更便宜和高效.我们大部分的人都能意识到我们不可能成为每个领域的专家.这个道理同样适用于构建软件系统.我们称之为"关注分离",这已经被认为是软件工程的一条基本原理.
SOA如果来达到使交互的软件代理松耦合的目的呢?它通过满足以下两条约束来实现:
1.参与的软件代理的简单并且普遍存在的接口的小集合.只有通用的语义会在这些接口里编码.这些接口对所有的提供者和消费者都是全局可用的.
2.接口间传递的消息必须是可描述的并通过扩展方式传递.没有,或者只有极少量的系统行为被消息订阅.样式约束了消息的词汇和结构.扩展的样式允许新版的服务在旧有的服务存在的情况下被使用.
正如在上面的电源适配器的例子上所说的,接口非常的重要.如果接口不工作,那么整个系统也将瘫痪.在分布式系统中,接口则是即昂贵又易于出错的.接口需要指示系统的行为,而在不同的平台与语言之间要实现接口是非常困难的.远程接口同样也是在大部分的分布式系统中最慢的一种.与为每个应用程序都创建新的接口相比,为所有的应用程序创建一些可重用的接口则要有意义的多.
因为我们只拥有很少的一部分可用的通用接口,我们必须在消息中表示应用程序特定的语义.我们可以通过我们的接口发送任何消息,但是在我们宣称某个架构是面向服务的之前,我们必须遵循一些规则.
首先,这个消息必须是可描述的,因为服务提供者有责任解决问题.这就好比你来到一个饭馆,告诉侍者你要点的菜单,但是你不会手把手的告诉他们的厨师怎么来做你要吃的鱼.
第二,如果你的消息没有按照一定的格式,结构来书写,服务提供者将不能理解你的请求.限制了词汇和结构的消息对于任何一次高效的交流都是必须的.消息受限的地方越多,则这个消息将越容易被理解.虽然这需要通过牺牲扩展性来达到目的.
第三,扩展性非常的重要.要理解这一点并不难.这个世界是个在不断变化的世界,这个道理同样存在于软件系统所处的各个环境.这些变化要求软件系统进行相应的变化,包括服务消费者,提供者,还有他们相互交流的消息.如果消息是不可扩展的,消费者和提供者将都受限于某个特定的服务版本.尽管扩展性如此的重要,不过在以往的情况,依然容易被忽略.最好的情况也只是,它(扩展性)被简单的认为是种好的模式而不是基础.约束和扩展性是一对深深的矛盾体.两者你都需要,你提升了任何一方都将削弱另一方.最好能够寻找到一个正确的平衡点.
第四,一个SOA必须拥有一个机制,它能使的消费者在其寻找到的一个服务的上下文环境下发现一个服务提供者.这个机制应当非常的可变,并且不是必须拥有一个中央注册处.
额外的约束
在SOA中,有几项额外的约束用于提供其可测性,性能,和可靠性.
无状态服务
每个消费者发送给提供者的消息必须包含所有提供者处理该请求所需要的信息.这个约束使的提供者更加的可测,因为提供者不需要在请求之间保存信息.自从每个请求都被通用的对待后,这有效的形成了"服务的批量生产".同样可以宣称这个约束提高了可见度,因为任何一个监控软件都可以监控单个的请求并指出其目的.由于不需要担心中间状态,因此从部分的失败中恢复也是简单的.这使的服务更加的可靠.
有状态服务
有状态的服务在许多场景下难于避免.其中一个便是在消费者和提供者间建立一个会话.会话是典型的为了性能而建立的.例如,为每个请求发送安全证书对消费者和提供者都是相当沉重的负担.如果把证书替换成消费者和提供者之间的一种共享的标记,则会快上许多.另一个场景是给消费者提供服务.
有状态的服务要求消费者和提供者都共享同一特定消费者的上下文,它可能被提供者和消费者间的交互的消息所包含或引用.这个约束的缺点是,它可能全面降低服务提供者的可测性,因为提供者可能需要为每个消费者记忆共享的上下文.它同样还增多了服务提供者与消费者间的耦合关系,使的服务的筛选变的更加的困难.
幂数请求
被一个软件代理接受到的重复请求与单个的请求拥有相同的效果.这个约束允许提供者和消费者通过简单的进行"如果请求失败则重复执行"来全面提高服务的可靠性.
源自SOA的WEB服务
每个人都大概的了解,什么是"WEB服务",但是并没有一个可被广泛接受的定义.WEB服务的定义同时也被W3C WEB服务框架工作组激烈的讨论.尽管定义一个WEB服务是如此的困难,但是大致说来满足下列约束的WEB服务就是一个SOA:
1,接口必须基于互联网协议,例如HTTP,FTP和SMTP
2,除非是二进制附件,消息必须是XML格式
有两个最重要的WEB服务格式,分别是:SOAP的WEB服务和REST的WEB服务.