面向服务的体系结构（Service-OrientedArchitecture，SOA）是一个组件模型，它将应用程式的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联繫起来。SOA技术已存在超过20年的时间，但一直未得到广泛的套用。随着Web服务的出现逐渐被人们接纳，SOA终于迎来了自己的“春天”。对SOA的需要来源于需要使业务IT系统变得更加灵活，以适应业务中的改变。通过允许强定义的关係和依然灵活的特定实现，IT系统既可以利用现有系统的功能，又可以準备在以后做一些改变来满足它们之间互动的需要。就开发体系结构方面而言，SOA是将来的一个发展趋势。SOA将数据和信息作为服务公开的模型使其成为了一个非常强大的概念，与当前的应用程式构建块範例截然不同。

SOA是指为了解决在Internet环境下业务集成的需要，通过连线能完成特定任务的独立功能实体实现的一种软体系统架构。从这个定义中前提有下面两点：1）软体系统架构： SOA不是一种语言，也不是一种具体的技术而是一种软体系统架构，它尝试给出在特定环境下推荐採用的一种架构，从这个角度上来说，它更像一种模式(Pattern)。因此它与很多已有的软体技术比如面向对象技术，是互补的而非互斥的。它们分别面向不同的套用场景，用来满足不同的特定需求。2）SOA的使用範围：需求决定同时也限制功能。SOA并不是包治百病的万灵单，它最主要的套用场合在于解决在Internet环境下的不同商业套用之间的业务集成问题。在下面我们会详细讨论Internet的各种特点是如何决定了SOA的特点，这里我们只需要先简单回顾一下Internet环境区别于Intranet环境的几个特点：a）大量异构系统并存，计算机硬体工作方式不同，作业系统不同、程式语言也不同；b）大量、频繁的数据传输仍然速度缓慢并且不稳定；c）版本升级无法完成，我们根本就无法知道网际网路上有哪些机器直接或者间接的使用某个服务。基于上面的前提，下面就让我们一起看一下SOA的3个基本特徵：

在Internet这样鬆散的使用环境中，任何访问请求都有可能出错，因此任何企图通过Internet进行控制的结构都会面临严重的稳定性问题。SOA非常强调架构中提供服务的功能实体的完全独立自主的能力。传统的组件技术，如.NET Remoting， EJB，COM或者CORBA，都需要有一个宿主(Host或者Server)来存放和管理这些功能实体；当这些宿主运行结束时这些组件的寿命也随之结束。这样当宿主本身或者其它功能部分出现问题的时候，在该宿主上运行的其它套用服务就会受到影响。SOA架构中非常强调实体自我管理和恢复能力。常见的用来进行自我恢复的技术，比如事务处理(Transaction)，讯息伫列(Message Queue)，冗余部署(Redundant Deployment)和集群系统(Cluster)在SOA中都起到至关重要的作用。

对于.NET Remoting，EJB或者XML-RPC这些传统的分散式计算模型而言，他们的服务提供都是通过函式调用的方式进行的，一个功能的完成往往需要通过客户端和伺服器来回很多次函式调用才能完成。在Intranet的环境下，这些调用给系统的回响速度和稳定性带来的影响都可以忽略不计，但是在Internet环境下这些因素往往是决定整个系统是否能正常工作的一个关键决定因素。因此SOA系统推荐採用大数据量的方式一次性进行信息交换。

由于Internet中大量异构系统的存在决定了SOA系统必须採用基于文本而非二进制的讯息传递方式。在COM、CORBA这些传统的组件模型中，从伺服器端传往客户端的是一个二进制编码的对象，在客户端通过调用这个对象的方法来完成某些功能；但是在Internet环境下，不同语言，不同平台对数据、甚至是一些基本数据类型定义不同，给不同的服务之间传递对象带来的很大困难。由于基于文本的讯息本身是不包含任何处理逻辑和数据类型的，因此服务间只传递文本，对数据的处理依赖于接收端的方式可以帮忙绕过兼容性这个的大泥坑。此外，对于一个服务来说，Internet与区域网路最大的一个区别就是在Internet上的版本管理极其困难，传统软体採用的升级方式在这种鬆散的分散式环境中几乎无法进行。採用基于文本的讯息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。每一项新技术都是在一些旧的技术基础上发展出来的。正如XML根本思想来自于在60年代就已经出现的早期标记性语言一样，SOA虽然这两年才出现，但是它所表达的观念应该说在网路这种分散式系统结构出现不久就已经广泛套用了。例如我们最熟悉的HTTP协定就是一个非常典型的SOA架构设计。HTTP协定的工作过程简单叙述如下：1）客户端，通常是通过浏览器，向伺服器端以文本的方式传送一个请求，索取一个Web页面；2）伺服器端接收到这个请求之后，根据请求的内容进行处理并且返回一个符合HTML语法的文本；3）客户端接收到伺服器端的回响文本后调用本地的程式，通常还是浏览器，把返回的HTML文本的内容展现出来。下面来看一下HTTP协定如何满足了SOA的特点：独立的功能实体：作为伺服器端的Web伺服器是绝对不会因为客户端的状况变化而改变的，它总是非常稳定的按照自己的内在逻辑运行，回响外部的请求，管理自己的资源和数据。这里一个非常好的例子就是Web伺服器对快取(Cache)的处理，很多Web伺服器为了提高性能都或多或少的对数据进行快取，但是快取数据、刷新数据这些于客户端完全无关的操作完全由伺服器端独立完成，完全不受客户端的影响。 大数据量低频率访问：对于一个HTTP请求来说，客户端与伺服器之间访问的边界非常简单：就是一个请求，一个回响，没有任何其它的信息往返。无论客户端申请的网页上除了文字之外还有什幺信息，对于客户端来说，它发出的请求只是简单的告诉Web伺服器它所需要的网页的位置；至于为了生成这个网页，伺服器端是否需要访问资料库，执行Servlet或者其它的CGI程式对客户端而言，都是完全透明的。 基于文本的讯息传递：迄今为止兼容性最好的系统可能就是HTTP协定支撑的大部分的web套用了，我们可以在Windows平台下用IE查看网际网路上一个Linux+Apache伺服器上的由Perl脚本自动生成的网页。这里的关键就是所有内容都是以格式化的文本方式传递的，不管Perl脚本如何执行，只要它的输出是符合HTML规範的网页，就可以被客户端的浏览器解释。而由于不同的作业系统上对于相同的HTML的解释遵循相同的规範，因此不同作业系统下仍然能够看到一致的用户界面。我们上面基本描述了SOA作为一种软体架构有哪些特点，下面让我们一起看看Web Service与SOA的关係。

Service是就现在而言最适合实现SOA的一些技术的集合，事实上最近SOA的火爆在很大程度上归功于Web Service标準的成熟和套用的普及为广泛的实现SOA架构提供了基础。下面让我们看看Web Service中的各种协定是如何互相工作来满足SOA所需的特点的：独立的功能实体：通过UDDI的目录查找，我们可以动态改变一个服务的提供方而无需影响客户端的应用程式配置。所有的访问都通过SOAP访问进行，只要WSDL接口封装良好，外界客户端是根本没有办法直接访问伺服器端的数据的。大数据量低频率访问：通过使用WSDL和基于文本(Literal)的SOAP请求，我们可以实现能一次性接收大量数据的接口。这里需要着重指出的是SOAP请求分文本方式和远程调用(RPC)两种方式，正如上文已经提到的，採用远程调用方式的SOAP请求并不符合这点要求。但是令人遗憾的是现有的大多数SOAP请求採用的仍然是远程调用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至没有提供文本方式的SOAP支持。 基于文本的讯息传递：Web Service所有的通讯是通过SOAP进行的，而SOAP是基于XML的，不同版本之间可以使用不同的DTD或者XML Schema加以辨别和区分。因此只需要我们为不同的版本提供不同的处理就可以轻鬆实现版本控制的目标。

无论您现在的系统是否牵涉到基于Internet的业务集成，採用SOA推荐的架构都对提高您系统的扩展性有很大帮助，下面是在系统中引入SOA后需要在软体架构方面做出的改变：使用基于文本方式的SOAP调用，摆脱远程调用中出现的函式参数类型等与数据无关的信息，保证所有SOAP传递的都是有意义的商业数据。依赖于Schema，而不是类定义对这些数据进行解释。 传统的三层Web套用将可能变成四层结构：传统意义上的商业逻辑层将被进一步划分为存放每个会话(Session)信息的客户逻辑层和与状态无关Sateless的SOA层。

不同种类的作业系统，套用软体，系统软体和套用基础结构（application infrastructure）相互交织，这便是IT企业的现状。一些现存的应用程式被用来处理当前的业务流程（business processes），因此从头建立一个新的基础环境是不可能的。企业应该能对业务的变化做出快速的反应，利用对现有的应用程式和套用基础结构（application infrastructure）的投资来解决新的业务需求，为客户，商业伙伴以及供应商提供新的互动渠道，并呈现一个可以支持有机业务（organic business）的构架。SOA凭藉其松耦合的特性，使得企业可以按照模组化的方式来添加新服务或更新现有服务，以解决新的业务需要，提供选择从而可以通过不同的渠道提供服务，并可以把企业现有的或已有的套用作为服务， 从而保护了现有的IT基础建设投资。　如图1的例子所示，一个使用SOA的企业，可以使用一组现有的套用来创建一个供应链複合套用（supply chain composite application），这些现有的套用通过标準接口来提供功能。　服务架构　服务架构　为了实现SOA，企业需要一个服务架构，图2显示了一个例子：　图2　在图2中， 服务消费者（service consumer）可以通过传送讯息来调用服务。这些讯息由一个服务汇流排（service bus）转换后传送给适当的服务实现。这种服务架构可以提供一个业务规则引擎（business rules engine），该引擎容许业务规则被合併在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（service management infrastructure），用来管理服务，类似审核，列表（billing），日誌等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（regulatory requirement），例如Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。 SOA基础结构　要运行，管理SOA应用程式，企业需要SOA基础，这是SOA平台的一个部分。SOA基础必须支持所有的相关标準，和需要的运行时容器。图3所示的是一个典型的SOA基础结构。　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 的工作。　SO

在理解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以藉助现有的套用来组合产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程式和业务流程。

A. 平衡最初的旧系统投资(Leverage initial investment)：　组织过去所投资的系统、软硬体，如果能再利用等于赋予其新的价值，这也替组织降低成本并增加竞争力。　B. 基础建设的便利性(Infrastructure Commoditization)：　让所有的套用程式能相互沟通(互通性)。　C. 快速的接近市场(Faster time-to-market)：　服务的重複使用(再利用)，来缩短过去的组织流程，更快速的提供服务来接近市场。　D. 减少支出(Reduce Cost)：　服务的重複使用，可降低开发成本。因为开发新系统的成本，大部份比更新旧有系统来的花费大。　E. 减低风险(Risk mitigation)：　开发新系统的风险远大于更新旧系统。　F. 持续改善商业流程的循环(Continuous improvement cycle for business process)　G. 中心流程处理(Process-centric processing)

有5点： 　一，SOA可通过网际网路伺服器发布，从而突破企业区域网路的限制，实现与供应链上下游伙伴业务的紧密结合。通过SOA架构，企业可以与其业务伙伴直接建立新渠道，建立新伙伴的成本得以降低。 　二，SOA与平台无关，减少了业务套用实现的限制。要将企业的业务伙伴整合到企业的“大”业务系统中，对其业务伙伴具体採用什幺技术没有限制。 　三， SOA具有低耦合性特点，增加和减少业务伙伴对整个业务系统的影响较低。在企业与各业务伙伴关係不断发生变化的情况下，节省的费用会越来越多。 　四， SOA具有可按模组分阶段进行实施的优势。可以成功一步再做下一步，将实施对企业的冲击减少到最小。 　五， SOA的实施可能并不具有成本显着性。这要分三种情况加以讨论： 　 当企业从零开始构建业务系统时，採用SOA架构与不採用SOA架构成本可看做是相同的。 　 当企业业务发展或发生企业重组等变化而原有系统不能满足需要，而需要重构业务系统时，採用SOA架构与不採用SOA架构成本可看做是相同的。 　 当企业业务发生缓慢变化并可预见到将来需要重构业务系统时，由于可以按模组分阶段逐步实施SOA以适应变化的需要，这样企业不需一下投入一大笔经费进行系统改造，而是根据企业业务发展情况和资金情况逐步投入，缓解了信息投入的压力。 　另指 半导体光放大器 (Semiconductor Optical Amplifer）　一般有行波放大和谐振放大两种，行波SOA的材料和一般半导体雷射器相同，光纤通讯领域多为InP材料，放大波段1550nm附近，毅力简单的理解为一个没有反馈腔的雷射器，一般端面反射率小于千分之五。

书 名: SOA&Web2.0:新商业语言

作　者：(美)卡特

出版社： 清华大学

出版时间： 2007

ISBN: 9787302155850

开本： 16

定价: 29.80 元

★IBM资深副总裁,顶级SOA战略大师SandyCarter力作!

一本正在寻求企业IT成功之道的中国CIO乃至CEO们值得一读的书！

--用友软体股份有限公司董事长、总裁：王文京

SandyCarter引述了IBM近年来帮助企业开发SOA的案例，这对刚刚起步的企业有很大的借鉴意义。此外，这本书与其说是在传播实现SOA的具体技术，不如说是为企业介绍一些关键的基本理念，为其提供实现SOA所需的正确思想，全书并不涉及如何进行SOA或Web服务套用的实际开发，所以您会发现本书很少有原始码或API讲解。

现在，在机构的灵活性和业务表现之间存在一种直接的、可查证的联繫。为了将灵活性最最佳化，企业必须对其内部、外部的关键流程与基础架构实现前所未有的整合与自动化。同时，企业必须学会以更具动态性和反应性的方式来管理流程。

总而言之，企业必须实现灵活应对。

直到最近，技术都一直阻碍着这些目标的实现。正是由于面向服务架构(SOA)、Web2．0和开放标準的出现，才促成企业实现了这些目标。在本书中，IBM的顶级SOA策略家展示了业务经理该如何利用技术创新来推动动态流程的发展，以应对当今世界越来越快的变化。

在本书中，SandyCalter示範了将企业解构为“组件化”业务模式的方法，然后用相互连线的、可重複的并且能快速、轻鬆、经济地适应各种变化的IT服务来支持该模式。这些技术将帮助IT专家和业务经理达到崭新的运营水平，以开展着眼于市场的创新，这才是最重要的。

第Ⅰ部分从起点开始－－业务

第1章创新迫在眉睫3

1.1专注于增长4

1.1.1增长的议程4

1.1.2灵活性：一项核心的技能5

……