1.6 扩展模型

组装模型可通过支持新的接口类型、实现类型和绑定类型而扩展。扩展模型基于XML schema substitution组及名称空间联邦之上。

所选择的接口、实现及绑定的元素名称形式要促成以简易的方式进行扩展。因此，相应的元素名为interface.xxx、implementation.xxx和binding.xxx。“xxx”可以采用一个与接口、实现或绑定关注的相关名称。SCA规范定义了一些接口、实现和绑定的基本类型，但是其他的可在支持这些运行时可用的额外之处按照需要进行定义。

注意：规范的未来版本将定义如何贡献SCA模型扩展及其运行时功能。

<element minOccurs="0" maxOccurs="1" ref="sca:binding"/>

<element minOccurs="1" maxOccurs="unbounded" ref="sca:interface"/> </sequence>

<attribute name="name" type="NCName" use="required"/>

</complexType>

…

<element name="binding" type=" sca : Binding"/> <complexType name="Binding"/>

…

</schema>

在以下片段中，我们展示了基本如何扩展以支持WebService绑定。此片段展示了包含在sca-binding-webservice.xsd中的binding.java元素和WebServiceBinding类型定义。

<?xml version="1.0" encoding="UTF-8"?>

<schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.osoa.org/xmlns/sca/0.9" xmlns : sca="http: //www.osoa.org/xmlns/sca/0. 9">

<element name="binding . ws" type=" sca : WebServiceBinding"

substitutionGroup="sca :binding"/>

<complexType name="WebServiceBinding">

<complexContent>

<extension base=" sca : Binding">

<attribute name="port" type="anyURI" use="required"/> </extens ion>

</complexContent>

</complexType>

</schema>

本文大纲如下：

1. SOA时间轴（从XML到Web服务再到SOA）
2. SOA的持续进化（标准组织与贡献厂商）
3. SOA的根源（SOA与过去架构的比较）

这个主题顺序可能有一点奇怪。我们以最近及当前的开发开始，以回顾过去架构平台而结束。简单地选择了这个结构，是因为本文最后环节的信息或许不是每个人都需要阅读。

[注]：本文节译自"Service-Oriented Architecture: Concepts, Technology, and Design"

By Thomas Er

Publisher: Prentice Hall PTR

（未完待续）

3.4. 比较SOA与混合Web服务架构

在前一节中，我们提到最近的分布式互联网架构变化已如何成为混合Web服务。这一主题值得详细说明，因为它已经是（并预期继续是）SOA周围的混乱之源。

首先，传统架构内使用Web服务是完全合理的。由于许多编程语言都支持对Web服务的开发，他们可轻易地将其嵌入老的应用设计。并且，对于那些不支持Web服务定制开发的遗留环境，通常也可用适配器的方法来解决。

注意

尽管我们集中于分布式互联网架构，但并没有限制两层客户-服务器的应用使用Web服务。

Web服务作为构件包装器

Web服务在这个语境中的主要角色已引进了一个包含包装器服务的整合层，促成经由SOAP兼容的集成通道的同步通信（图4.7）。实际上，SOAP规范初始发布和第一代SOAP服务器都被特别设计用来复制使用消息的RPC风格的通信。

这些集成通道主要在集成结构中，被用以促进与其他应用或外部合作伙伴的通信。也被用于促成与其他（更多的面向服务）解决方案通信，还可利用第三方工具提供的Web服务。不管他们在传统架构中的使用或目的，关键是要澄清靠这种方式在分布式互联网架构中纳入Web服务不具备真正的SOA资格。这只是使用Web服务的分布式互联网架构。

并非是反映构件接口和用Web服务建立点对点连接，SOA提供了对于不同通讯模型的强健支持（基于同步和异步的交换）。另外，在SOA内的Web服务受制于特定的设计需求，象由面向服务原则提供的那些。这些和其他的特征都支持对和谐的松散耦合的追求。一旦实现，单个服务不再限于点对点通信；它能够适应任何的现在和未来的请求者。

SOA内部的Web服务

然而SOA在大小和品质方面会有所不同，SOA与其他架构在Web服务的使用方面有切实不同的特征。本书主要专注于探索这些特征。目前已经充分阐明：基本上，SOA构建于一组Web服务，它们被设计用于一个或多个电子商务流程的集体自动化（或者参与自动化的），SOA促进将这些服务组织成抽象企业自动化逻辑特定部分的特定层。

同样通过跨企业的标准SOA，出现了天然的协同性，超越了专有的应用平台。这考虑到先前不同的环境组成，以支持新的和进化的业务自动化过程。

SOA结构模型在企业信息整合中的应用

作者: 叶健辉, 　出处:赛迪网,　责任编辑: 叶江, 2007-04-29 08:10

　　SOA提供了一种方法, 通过这种方法在构建分布式系统时, 可以将应用程序功能作为服务提供给终端用户应用程序或其他服务……

　　一、传统方法进行企业信息整合的分析

　　企业应用集成(EAI：Enterp rise Application Integration) 是指对企业中完成不同业务功能的应用系统进行集成, 在它们之间建立起可供数据交流和应用沟通的纽带, 进而使他们之间的信息交互成为可能。通过这种方式使用户可以访问企业的整体信息, 而不必考虑这些具体信息到底是属于哪一个应用系统的, 即各个不同应用系统对用户来说是透明的。

　　传统的企业应用集成的层次主要有数据级集成、应用接口级集成、业务逻辑级集成等; 数据级集成属于面向信息的集成方式, 该方式可能会导致损坏数据, 打开数据库的安全缺口等; 应用接口级集成属于面向接口的集成方式, 采用该方式对AP I接口进行修改时, 将增加大量的工作量, 也可能会增加现有应用系统的不稳定性。而业务逻辑级集成属于面向过程的集成方式。该集成方式不仅暴露了应用程序的业务逻辑, 而且由于业务逻辑的交叉, 导致了各个集成系统之间的紧耦合性, 降低了应用系统的灵活性, 增加了整个系统维护的难度。

　　上述3种方式都属于紧耦合的应用系统集成方式。这种紧耦合的集成方式将影响系统的灵活性和扩展性, 阻碍业务的流程调整和优化, 不利于企业业务发展。为解决上述问题, 需要一种面向功能层的企业系统集成方式。该方式不仅能保证原有系统的数据安全性和逻辑安全性, 而且还能实现各系统之间的松耦合, 方便系统流程的重组和优化。SOA的出现，为这一问题提供了一个比较完美的解决方案。

　　二、面向服务的体系结构(SOA)：

　　2.1 面向服务体系结构简介

　　SOA(service-oriented Architecture，也叫面向服务的体系结构或面向服务架构)是指为了解决在Internet环境下业务集成的需要，通过连接能完成特定任务的独立功能实体实现的一种软件系统架构。SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是 采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

　　传统的Web(HTML/HTTP)技术有效的解决了人与信息系统的交互和沟通问题，极大的促进了B2C模式的发展。WEB服务 (XML/SOAP/WSDL)技术则是要有效的解决信息系统之间的交互和沟通问题，促进B2B/EAI/CB2C的发展。SOA(面向服务的体系)则是 采用面向服务的商业建模技术和WEB服务技术，实现系统之间的松耦合，实现系统之间的整合与协同。WEB服务和SOA的本质思路在于使得信息系统个体在能 够沟通的基础上形成协同工作。

　　2.2　SOA结构模型

　　SOA提供了一种方法, 通过这种方法在构建分布式系统时, 可以将应用程序功能作为服务提供给终端用户应用程序或其他服务。在发现新的商机或危机的预期下, SOA 体系结构形式旨在提供企业业务解决方案, 这些业务解决方案可以按需扩展或改变。SOA 解决方案由可重用的服务组成, 带有定义良好且符合标准的已发布接口。SOA 提供了一种机制, 通过这种机制, 可以将原有系统资源封装成服务后集成到新开发的分布式系统, 而不管它们的平台或语言。SOA中的服务通过服务描述和传输实现了相互之间的交互, 如图1所示。

　　其中, 服务描述是一种经过协商的模式, 用于描述服务是什么、应该如何调用服务以及成功地调用服务需要什么数据等。传输是一种机制, 用于将来自服务使用者的服务请求传送给服务提供者, 并且将来自服务提供者的响应传送给服务使用。

2.3　SOA中的工作角色

　　在SOA服务模型图(图2)中面向服务的体系结构中主要有三种角色：

　　(1) 服务消费者是需要使用服务的应用程序或其它的服务。通过对注册中心的服务进行查询后, 根据接口说明信息并使用某种传输协议与服务绑定并执行服务功能。

　　(2) 服务提供者是创建服务的实体。可以从服务消费者处接受请求并可以远程执行所请求服务。通过向注册中心发布服务接口信息以供服务消费者发现和访问服务。

　　(3) 服务注册中心处于中心位置提供了展示服务的功能。服务消费者通过查询存储有服务信息库的注册中心以找到感兴趣服务的接口信息。

　　2.4　SOA三大基本特征

　　一、 独立的功能实体 ：在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上的版本管理极其困难，传统软件采用的升级方式在这种 松散的分布式环境中几乎无法进行。采用基于文本的消息传递方式，数据处理端可以只选择性的处理自己理解的那部分数据，而忽略其它的数据，从而得到的非常理想的兼容性。

　　从SOA的几个重要特征可以看出，SOA之所以被用于信息资源整合，是因为其具备了标准化、可操作、可组装的特性。SOA提供了一个通用的、可 互操作的和有弹性的行业标准架构，可以在软件基础架构中建立一系列支持商业模型的可重复利用的服务，这些服务由不同应用系统的组件构成，能够帮助企业实现适应商业流程变化的需求。

三、采用SOA进行企业信息系统集成

　　3.1采用SOA进行企业现有信息系统集成的步骤：

• 　　1) 提取各个应用系统中需要对外暴露的功能模块。这些功能模块通常都是一些能够清晰完整地表现其业务价值的软件实体, 该软件实体包含了它所能提供的所有服务。
• 　　2) 将这些功能模块表现为服务组件的形式。定义服务的描述信息、服务的接口以及调用服务所需要的定位信息等。将软件实体的概念模型转换成实际的服务模型。
• 　　3) 将已实现的服务发布到服务注册器,供其他服务调用者进行查找和绑定。这个步骤可以视企业集成的具体情况选择使用。
• 　　4) 绑定和调用服务, 将各个应用系统集成起来, 实现企业应用在功能层面的集成(见图3) 。

　　3.2实施建议

　　“整合是分阶段、循序渐进、逐步实现的。如果把企业的所有经营活动看作是一个个服务，那么整合就是要将企业内外部的各种服务有机地联结起来。首先可以只需创建单独的服务;接下来不仅可以创建服务，而且可以开始将业务功能集成到SOA中;第三步涉及将企业IT基础设施转换到SOA模型;最后则集中 于转换业务模型，以使之成为适应需求变化的模型。

　　对具体的整合对象，按照建模、装配、部署、管理四个阶段实现整合。在建模阶段，可以定义业务模型或流程、软件模型和SOA模型。之后就可以创建 一组服务，这组服务可以与已发布的通用接口一起重用;在部署阶段，开发人员可以提取创建的服务，并把它们放在一个可执行、可管理的环境之中;在使用阶段， 根据软件模型来装配应用程序，并且测试其软件质量以及非功能性需求，比如性能、可伸缩性等等;最后的管理阶段是一个长期的过程，在这个阶段中，可以监控并 管理安全性和使用，以及在许多与可能已经为SOA制订好的服务级协定或策略相对应的方面比较其性能。

　　这样由小及大，逐渐在企业业务中进行整合扩散，并形成整个企业的IT转型，最终通过全面整合实现随需应变的企业IT架构。

3.3 基于Web服务体系结构的SOA企业信息系统整合

　　作为一种概念，SOA已经成熟。比较来说，现在Web服务是实现SOA最好的方式。Web服务是由URL (Uniform Resource Locator) 确定的软件应用, 其接口和绑定能够以XML(ExtensibleMarkup Language) 的形式定义、描述和发现, 并且支持借助Internet协议, 如SOAP ( Simple　ObjectAccess Protocol) 。采用XML 格式消息的方式与其他软件应用交互 。Web 服务采用[ 6 ]WSDL(Web ServicesDescrip tion Language) 作为其服务接口描述语言、通过UDD I (Universal Descrip tion, Discovery and Integration) 协议规范进行Web服务的网上注册和服务查找定位, 并使用SOAP传输协议在网络间进行XML格式的信息交互。

　　XML是一种扩展标记语言。Web服务的描述语言就是用XML形式描述的 , Web服务的数据也是以XML格式进行交换的。可以说XML是定义Web服务协议规范的基石。

　　WSDL服务描述语言采用XML Schema定义。WSDL能对各种语言实现的服务进行描述, 具有语言无关性。

　　DD I是通用描述、发现和集成协议。UDD I使得全球统一定位、发现服务成为可能。

　　3.4　Web服务集成实现模型

　　要运行，管理SOA应用程序，企业需要SOA集成模型，这是SOA平台的一个部分。SOA集成模型必须支持所有的相关标准，和需要的运行时容器。图4所示的是一个典型的SOA集成模型。下面分别介绍这些层。

　　SOAP， WSDL， UDDI ：WSDL，UDDI和SOAP是SOA基础的基础部件。WSDL用来描述服务;UDDI用来注册和查找服务;而SOAP，作为传输层，用来在消费者和服务提供者之间传送消息。SOAP是Web服务的默认机制，其他的技术为可以服务实现其他类型的绑定。一个消费者可以在UDDI注册表(registry) 查找服务，取得服务的WSDL描述，然后通过SOAP来调用服务。

　　WS-I Basic Profile：S-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提供了标准化的架构，一个应用对应的服务也能适用于其它应用，企业开发新应用的速度将得到大大提高，同时对旧有系统也可以包装成服务，服务之间为了满足新业务的需求可以进行组合，从而实现信息系统资源的整合。

3. SOA的根源 (SOA与过去架构的比较)

我们现在实际地跳回时间轴看一看过去架构与SOA的差别。这是一项有趣的研究， 我们能够看出SOA许多当代特征的起源。

1.4<span style="7pt

1 SOA时间轴（从XML到Web服务再到SOA）

我们从讲述形成当前SOA平台的关键工业开发入手来建立时间轴。然后我们看一看SOA在它的权限范围内，如何作为当代架构的平台而改变了XML与Web服务技术的角色。

1.1. XML简史

如同HTML，扩展标记语言（XML）系W3C所创建，源自流行的标准通用标记语言（SGML），它在60年代后期就已存在。这是广泛使用的元语言，允许组织增加原始文档数据。

XML在90年代后期的电子商务运动中声名鹊起，服务器端脚本语言可以经由互联网而处理业务。通过XML的使用，开发者能够给任何片段附加上意义和上下文，再跨越互联网协议传输。

XML不仅被用于以标准化的方式来表达数据，其语言自身还被用作一系列的附加规范的基础。XML Schema定义语言（XSD）与XSL转换语言（XSLT）都以XML表达。这些规范，事实上已成为关键核心XML技术集的关键部分。

XML表达架构代表了SOA的基础层。在其内部，XML建立了在服务各处流动的消息格式与结构。XSD schemas保持消息数据的完整与有效性，而且XSLT使得不同的数据表达间通过schema映射而能够互相通信。换句话说，没有XML你在SOA内寸步难行。

1.2. Web服务简史

在2000年，W3C接受了一项关于简单对象访问协议（SOAP）规范的提案。这个规范本来设计用于（并在一些案例替代）专有RPC通信。想法是对于在构件间传输参数数据可以序列化成XML传送，然后支序列化成其原生格式。

很快，公司及软件厂商开始看到，对于推进通过构建于专有-免费的互联网通信框架之上的电子商务技术，存在日益巨大的潜力。这最后导致了创建一个纯粹的、基于Web的分布式技术能充分利用概念标准化的通信框架，来桥接组织之间和组织内部所存在的巨大差异。这个概念被称为Web服务。

Web服务最重要的部分是其公共接口。它是分配服务识别并使其激活的核心信息块。因此，首先支持Web服务的是Web服务描述（WSDL）。W3C第一份WSDL评议提案是在2001年，此后还在不断地修订这一规范。

为了进一步的开放协同性的愿景，Web服务需要一个互联网友好的、XML兼容的通信格式，以便能够建立一个标准化的通讯框架。尽管有别的选择，譬如可以考虑XML-RPC，但SOAP因为工业界的偏好而胜出，并且保留了最初的通讯标准用于Web服务。

为支持SOAP的新角色，W3C随之发布了更新版本的规范，同时考虑了RPC风格的与文档风格的消息类型。而后者在SOA里面更为常用。最终，“SOAP”一词不再代表“简单对象访问协议”的首字母缩写。到了规范的1.2版，它变成了一个独立的术语。

完成第一代Web服务标准家族的是UDDI规范，它原本由UDDI.org所开发，被递交到OASIS之后，它继续与UDDI.org一起合作开发。这个规范考虑在组织内部及组织边界之外来创建标准化的服务描述的注册。UDDI提供了潜在的对Web服务在一个集中的位置注册，在此处能够被服务请求者所发现。WSDL与SOAP不同，UDDI尚未被工业界所普遍接受，并且保留了一个可选的SOA扩展。

开发定制的Web服务可适应变化的业务需求，并且第三方市场出现了促进各种实用服务的销售或租赁。现存的通讯平台，譬如面向消息的中间件（MOM）产品，结合Web服务可支持SOAP之外的其他消息协议。一些组织可迅速合并Web服务，以促进B2B数据交换经常要转变为EDI（电子数据交换）替代品的需求。

1.3. SOA简史

不久前组织才开始意识到只需要缓和地替代现存的分布式应用，Web服务可成为独立的架构平台---可使用Web服务技术集的效益来实现企业中服务概念的平台。这样，面向服务架构开始进入IT的主流。

在这一点SOA频繁地以不同的方式被分类，经常依赖于构建服务所用的实现技术。早期的模型，主要从Web服务标准初始系列中得到灵感，将SOA定义为一个围绕三个基本的构件的架构模型：服务请求者，服务服务提供者与服务注册（图1）。

图1. SOA的早期形态

第一代Web服务标准实现此模型的以下方面：

• WSDL描述服务。
• SOAP提供了用于服务及其请求者的通讯格式。
• UDDI提供了标准化的服务注册格式。

从物理架构的角度，基于Web服务的SOA第一次变异实际上超越了原始SOA模型。你或许能回忆起原始SOA不需要使用服务注册。作为替代，发现被归类为当代SOA的一个特征，通过面向服务原则在服务层面被提倡。

我们的原始SOA模型在今天可轻易获得，因为它已被所有主要厂商的开发及运行平台所支持。这些相同厂商都有关于SOA的远大计划，其中许多现在已经能够自我证明。当代SOA的诸多特征，大都是过分主动的开发与协作的结果，已经产生了一系列第一代Web服务平台的扩展。知名的“第二代”或“WS-*”规范，这些扩展处理特殊的功能区域，Web服务技术平台全面提升至企业水平。

补充WS-*领域对于将面向服务概念引入业务分析的世界也很重要。通过面向服务，业务逻辑能够清晰地被封装，并从根本的自动化技术中抽象。这个愿景藉由业务流程定义语言的提升而得到进一步支持，最知名的是WS-BPEL。这不仅考虑到将传统的业务流程管理（BPM）模型解决成一系列的服务，更进一步提供具体的和可执行的格式充分表达业务逻辑的语言能力，填补了分析与实现间的空隙。

这些及其他工业影响已经扩大了SOA的潜在范围。如同更多的当代特征被增加，也很可能今天我们所归类的当代SOA，会形成未来原始SOA的基础。

SOA是一个真正的进化。今天的结果明显是被不同的相关标准组织和软件厂商主动驱动的结果。通过受协作与竞争的混合刺激的不稳定环境，扩展被作为战略定位，每个都定义了我们称为当代SOA技术平台一个特定部分。在第2节，我们近距离看看标准的开发过程。

1.4. SOA如何改造XML与Web服务

如同任何架构，SOA引入了边界和规则。尽管当代SOA可能由XML及Web服务技术平台所构成，但这些平台需要经历大量的变化，以便其各自的技术被适当定位并在面向服务架构范围内加以利用。

使用XML或Web服务的传统分布式应用环境因此肯定有一些重新实现，面向服务的设计原则需要在技术与心态方面都进行改变。以下是当你必须对现存实现翻工时，你可能面对的一些潜在问题示例。

• SOA现在需要数据表达与服务建模标准表达保持一致。这个相当含糊的需求有许多含意，并主要促进内在协同性。
• SOA依赖于负责所有服务间通信的SOAP通讯。结果，所有需要XML的地方，一般也会有SOAP消息，以照顾传输、临时处理与路由及最终交付。XML文档与关联的XSD schema现在经常需要有意地与SOAP通讯一起建模。
• SOA使用标准化的文档风格的通讯。从RPC风格迁移到文档风格的消息给服务描述的设计强加了变化。特别地，接口特征需要以更普通的术语表示，并全面增加操作粒度。
• 由于强调文档风格的SOAP消息，SOA促进内容及高智能模型。这个支持服务的无状态及自治，并使消息传输的频度最小化。然而先前的RPC风格的方法支持带有目标数据的小颗粒XML文档传输，在SOA内的XML文档经常需要代表不止一个数据语境的绑定数据。
• 直到WS-*扩展的高阶信息能力普遍流行，许多应用都将需要配备SOAP报头来实现临时解决方案以管理复杂的消息交换。一些更急迫需求包括管理与关联。这些临时的设计有效地建立了转变模型，需要时可轻易地迁移到工业标准的实现。

要点总结

• 核心XML技术集已成为分布式互联网架构的通用部分。现在也提供基础数据表达及SOA数据管理层。
• 第一代Web服务架构来自关键标准开发：WSDL、SOAP与UDDI。然而UDDI对于多数据环境而言仍旧是一个可选的发现机制，WSDL与SOAP已经成为构建在XML层之上定义SOA基本通信框架的核心技术。
• SOA充分利用XML与Web服务率先铺设的道路。它将久经考验的概念与先进技术的结合，已经被IT社团所充分接受。
• 尽管当代SOA已经形成并有了对XML与Web服务的工业级接受度，SOA的到来对于已有XML及Web服务的传统应用还是带来了改变。

l name – 模块名称，必须在一个SCA系统内唯一。模块名称的形式也有限制以便必须不包含“/”或者“#”，因为它们能够在系统级被用作元素间的分隔符。

注意：Eclipse对于插件（plugin）的命名规范提供了一个实现唯一名称的好方式，例如com.mycompany.myvaluemodule。这种格式被推荐但并非标准。

模块包含零个或多个入口点、构件、外部服务及连线。这些工件在下面几节详细描述。构件包含模块的业务逻辑。连线描述连接到或连接自构件的服务。入口点定义由模块所提供的公共服务，能够自模块外部访问。外部服务代表模块在模块外部的别处所提供的服务。

1.3.1 构件

构件（component）被实现（implementation）的实例（instance）配置。构件提供并消费服务。多于一个构件可使用并配置相同的实现，在此每一构件配置的实现不同。例如每一构件可能配置对于消费不同服务的相同相同实现的引用。

实现定义了以一种构件类型形式的构件的可配置方面。SCA考虑了多种不同的实现技术，诸如Java^TM、业务流程执行语言[7] （BPEL）、C++。SCA定义了一个可扩展机制，思考新的实现类型。当前的规范不要求一个SCA运行时对实现技术进行支持，厂商可能选择一种对共重要的技术进行支持。

构件被定义在一个sca.module文件中。构件被作为module元素子节点的component元素所成代表。一个模块内可以有零个或多个构件元素。以下片段展示了带有component子元素schema的module schema。

<module xmlns="http://www.osoa.org/xmlns/sca/0.9" xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9" name="xs:NCName">

…

<component name="xs:NCName">*

<implementation.implementation-type/>

<properties>?

<v:property-name override="no or may or must" modulePropertyName="xs:NCName">value

v:property-name>+

properties>

<references>?

<v:reference-name>wire-target-URIv:reference-name>+

references>

component>

…

module>

component元素有以下属性：

l name – 构件的名称。此名称必须：

1.5 绑定

绑定（binding）被外部服务和入口点所使用。外部服务使用绑定来描述用于调用一个外部服务（可以是一个由其他SCA模块所提供的服务）的访问机制。入口点使用绑定来描述对于必须使用入口点所发布的服务的客户（可以是来自其他SCA模块的客户）的访问机制。

SCA支持使用绑定的多个不同类型。示例包括SCA服务、Web服务、无状态会话EJB、数据库存储过程、EIS服务。SCA运行时必须提供对SCA服务和Web服务绑定类型的支持。SCA提供了一个扩展机制，借此SCA运行时可对额外的绑定类型进行支持。有关如何定义附加的绑定类型，参见扩展模型一节（Extension Model）。

绑定由binding元素所定义，它是在模块文件或子系统文件中外部服务或入口点元素的子元素。以下片段展示了具有binding元素schema的模块schema。

version="1.0" encoding="ASCII"?>

xmlns=http://www.osoa.org/xmlns/sca/0.9 xmlns:v="http://www.osoa.org/xmlns/sca/values/0.9"

name="xs:NCName" >

name="xs:NCName" >*

.interface-type/>

uri="xs :anyURI"/>+ wire-target-URI< /reference>

…

name="xs :NCName" override="sca:OverrideOptions”>* .interface-type/>

uri="xs:anyURI"/>*

binding元素的名称是有架构的；其自身之中是限定名称。首个限定符总是名为“binding”，第二个限定符是各自的绑定类型（binding-type）（例如：binding.sca、binding.ws、binding.ejb、binding.eis）。

binding元素有一个具有以下语义的可选uri属性。

l 对于外部服务而言，URI属性定义了外部服务的wire-target URI。在模块内定义外部服务是可选的，但是需要在子系统内定义外部服务。一个模块的外部服务的URI 属性可被模块构件使用模块配置。一些绑定类型可能不只需要简单URI的目标地址（类似WS-Addressing入口点引用）。在这些情形中，绑定类型将定义识别服务所必须的附加属性或子元素。

l 对于入口点而言，URI属性定义了相对于模块构件的URI。此URI的缺省值是入口点的名字。

当一个入口点存在多个绑定时，意味着此服务可用于任何规定的绑定。系统用于在可用绑定中进行选择的技巧被疏于实施，并可能包括额外的（非标准）配置。无论如何，用到的技巧都应当被文档化。

入口点能够总是在子系统级有其绑定覆盖。仅当外部引用有may或者must的覆盖属性时，外部引用才是可覆盖的。详情参见覆盖部分。

以下部分详细描述SCA和Web服务绑定类型。

1.5.1 部署绑定的URI形式

用于绑定的组成联合uri属性的有效URI如下：scheme的基本系统URI / 子系统URI / 模块构件URI / 绑定URI。

对基本URI在“http://acme.com”的入口点，子系统名是“equitiesSubsystem”，模块构件名为“stocksComponent”，入口点绑定为“getQuote”的相对URI，URI看起来会象这样：http ://acme .com/equitiesSubsystem/stocksComponent/getQuote

在每个级别指定的URI可能是绝对的或是相对的。路径被缩短到只包括指定绝对URI的最低级（最右边）以及跟随它的所有相对URI。这样，如果在前一例子中的模块构件有“http://acme.com”的绝对URI，而不是“stocksComponent”的相对URI，那么有效的URI会仅以http ://acme.com/getQuote结尾。

系统可能为任何支持层级URI的URI scheme指定一个的基本URI。URI只为有基本URI的系统构造。

对于任何同时有一个名字和和一个uri属性的SCA元素，uri缺省与名称相同。如果binding元素不指定一个uri属性，URI缺省赋给作为入口点部分的名字。因此，如果没有uri属性被指定，绑定的缺省URI将是：基本系统URI/子系统名/模块构件名/入口点名。

允许指定一个不同于子系统名称的相对URI，模块构件或者入口点名称允许入口点URI层级独立于系统组织而设计。

将URI层级设计成独立于系统组织一种是好的实践，但当系统初始创建时可能有时会使用缺省URI层级。在此情况下，系统组织会被改变，同时依靠给选定元素的uri属性赋以适当的值维护着URI层级形式。这时是一对改变组织的同时维护现存URI的示例：

l 要将单个moduleComponent（说是“foo”）转变成两个moduleComponents，新的包含用在“foo”中的moduleComponent其uri属性值应当是：“. ./foo”。

l 要将两个moduleComponents融到一个moduleComponent（将“foo”和“bar”只融到“foo”中），用在“bar”模块中的绑定应当有一个“. ./bar/myEntryProint”的uri属性。

URI属性也可能被用来为一些入口点创建更短的URI，此处子系统或者模块构件根本不可能在URI中出现。例如，如果一个模块构件有一个“.”的uri属性，那么此模块构件的名称将不会出现在URI中。

1.5.2 SCA绑定

SCA binding元素由以下schema定义。

SCA绑定可被用于客户端与包含在不同SCA模块间服务间的服务交互。在此种方式中，绑定类型的实现在SCA规范中没有定义，它还可以由不同的SCA运行时以不同的方式实现。唯一的需求是要求服务质量必须为SCA绑定类型实现。SCA绑定类型不会有意是一个互操作的绑定类型。对有互操作性，类似问题Web服务绑定这样的互操作绑定类型应当被使用。

如果外部服务经由其uri属性指定了一个URI，那么就提供了连到由另一个模块构件提供的服务的连线。URI值必须如下：