SOA 搜集

from: http://zhidao.baidu.com/question/1555941.html

面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用 中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点，一点是它的灵活性，另一点是，当组 成整个应用程序的每个服务的内部结构和实现逐渐地发生改变时，它能够继续存在。而另一方面，紧耦合意味着应用程序的不同组件之间的接口与其功能和结构是紧 密相连的，因而当需要对部分或整个应用程序进行某种形式的更改时，它们就显得非常脆弱。

对松耦合的系统的需要来源于业务应用程序需要根据业务的需要变得更加灵活，以适应不断变化的环境，比如经常改变的政策、业务级别、业务重点、合作伙伴关 系、行业地位以及其他与业务有关的因素，这些因素甚至会影响业务的性质。我们称能够灵活地适应环境变化的业务为按需（On demand）业务，在按需业务中，一旦需要，就可以对完成或执行任务的方式进行必要的更改。

虽然面向服务的体系结构不是一个新鲜事物，但它却是更传统的面向对象的模型的替代模型，面向对象的模型是紧耦合的，已经存在二十多年了。虽然基于 SOA 的系统并不排除使用面向对象的设计来构建单个服务，但是其整体设计却是面向服务的。由于它考虑到了系统内的对象，所以虽然 SOA 是基于对象的，但是作为一个整体，它却不是面向对象的。不同之处在于接口本身。SOA 系统原型的一个典型例子是通用对象请求代理体系结构（Common Object Request Broker Architecture，CORBA），它已经出现很长时间了，其定义的概念与 SOA 相似。

然而，现在的 SOA 已经有所不同了，因为它依赖于一些更新的进展，这些进展是以可扩展标记语言（eXtensible Markup Language，XML）为基础的。通过使用基于 XML 的语言（称为 Web 服务描述语言（Web Services Definition Language，WSDL））来描述接口，服务已经转到更动态且更灵活的接口系统中，非以前 CORBA 中的接口描述语言（Interface Definition Language，IDL）可比了。

Web 服务并不是实现 SOA 的惟一方式。前面刚讲的 CORBA 是另一种方式，这样就有了面向消息的中间件（Message-Oriented Middleware）系统，比如 IBM 的 MQseries。但是为了建立体系结构模型，您所需要的并不只是服务描述。您需要定义整个应用程序如何在服务之间执行其工作流。您尤其需要找到业务的操 作和业务中所使用的软件的操作之间的转换点。因此，SOA 应该能够将业务的商业流程与它们的技术流程联系起来，并且映射这两者之间的关系。例如，给供应商付款的操作是商业流程，而更新您的零件数据库，以包括进新 供应的货物却是技术流程。因而，工作流还可以在 SOA 的设计中扮演重要的角色。

此外，动态业务的工作流不仅可以包括部门之间的操作，甚至还可以包括与不为您控制的外部合作伙伴进行的操作。因此，为了提高效率，您需要定义应该如何得知服务之间的关系的策略，这种策略常常采用服务级协定和操作策略的形式。

最后，所有这些都必须处于一个信任和可靠的环境之中，以同预期的一样根据约定的条款来执行流程。因此，安全、信任和可靠的消息传递应该在任何 SOA 中都起着重要的作用。

我可以用面向服务的体系结构做什么？

对 SOA 的需要来源于需要使业务 IT 系统变得更加灵活，以适应业务中的改变。通过允许强定义的关系和依然灵活的特定实现，IT 系统既可以利用现有系统的功能，又可以准备在以后做一些改变来满足它们之间交互的需要。

下面举一个具体的例子。一个服装零售组织拥有 500 家国际连锁店，它们常常需要更改设计来赶上时尚的潮流。这可能意味着不仅需要更改样式和颜色，甚至还可能需要更换布料、制造商和可交付的产品。如果零售商 和制造商之间的系统不兼容，那么从一个供应商到另一个供应商的更换可能就是一个非常复杂的软件流程。通过利用 WSDL 接口在操作方面的灵活性，每个公司都可以将它们的现有系统保持现状，而仅仅匹配 WSDL 接口并制订新的服务级协定，这样就不必完全重构它们的软件系统了。这是业务的水平改变，也就是说，它们改变的是合作伙伴，而所有的业务操作基本上都保持不 变。这里，业务接口可以作少许改变，而内部操作却不需要改变，之所以这样做，仅仅是为了能够与外部合作伙伴一起工作。

另一种形式是内部改变，在这种改变中，零售组织现在决定它还将把连锁零售商店内的一些地方出租给专卖流行衣服的小商店，这可以看作是采用店中店 （store-in-store）的业务模型。这里，虽然公司的大多数业务操作都保持不变，但是它们现在需要新的内部软件来处理这样的出租安排。尽管在内 部软件系统可以承受全面的检修，但是它们需要在这样做的同时不会对与现有的供应商系统的交互产生大的影响。在这种情况下，SOA 模型保持原封不动，而内部实现却发生了变化。虽然可以将新的方面添加到 SOA 模型中来加入新的出租安排的职责，但是正常的零售管理系统继续如往常一样。

为了延续内部改变的观念，IT 经理可能会发现，软件的新配置还可以以另外的一种方式加以使用，比如出租粘贴海报的地方以供广告之用。这里，新的业务提议是通过在新的设计中重用灵活的 SOA 模型得出的。这是来自 SOA 模型的新成果，并且还是一个新的机会，而这样的新机会在以前可能是不会有的。

垂直改变也是可能的，在这种改变中，零售商从销售他们自己的服装完全转变到专门通过店中店模型出租地方。如果垂直改变完全从最底层开始的话，就会带来 SOA 模型结构的显著改变，与之一起改变的还可能有新的系统、软件、流程以及关系。在这种情况下，SOA 模型的好处是它从业务操作和流程的角度考虑问题而不是从应用程序和程序的角度考虑问题，这使得业务管理可以根据业务的操作清楚地确定什么需要添加、修改或 删除。然后可以将软件系统构造为适合业务处理的方式，而不是在许多现有的软件平台上常常看到的其他方式。

正如您可以看到的，在这里，改变和 SOA 系统适应改变的能力是最重要的部分。对于开发人员来说，这样的改变无论是在他们工作的范围之内还是在他们工作的范围之外都有可能发生，这取决于是否有改变 需要知道接口是如何定义的以及它们相互之间如何进行交互。与开发人员不同的是，架构师的作用就是引起对 SOA 模型大的改变。这种分工，就是让开发人员集中精力于创建作为服务定义的功能单元，而让架构师和建模人员集中精力于如何将这些单元适当地组织在一起，它已经 有十多年的历史了，通常用统一建模语言（Universal Modeling Language，UML），并且描述成模型驱动的体系结构（Model-Driven Architecture，MDA）。

from: 面向构件与SOA社区

from: http://www.yourblog.org/Data/20071/498032.html

什么是SOA

最近半年以来，在企业级应用开发领域，谈论最多的一个词，恐怕非SOA(Service-Oriented Architecture，面向服务架构)莫属。那么SOA究竟拥有什么样的魔力，能够让众多的软件厂商对他趋之若骛，掀起新的一轮企业架构浪潮。让我们 在本文中一探SOA的究竟。

那么什么是SOA，让我们先从基本概念开始讲起。

什么是SOA?

SOA是一种架构模型，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA的关键是“服务”的概念，W3C将服务定义为：“服务提供者完成一组工作，为服务使用者交付所需的最终结果。最终结果通常会使使用者的状态发生变化，但也可能使提供者的状态改变，或者双方都产生变化”。

Service-architecture.com将SOA定义为：“本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能 是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

Looselycoupled.com将SOA定义为：“按需连接资源的系统。在SOA中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA规定了资源间更为灵活的松散耦合关系。”

Gartner则将SOA描述为：“客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”

Gartner相信BPM和SOA的结合对所有类型的应用集成都大有助益??“SOA极大的得益于BPM技术和方法论，但是SOA面临的真正问题是确立正确的企业意识，即：强化战略化的SOA计划（针对供应和使用）并鼓励重用。”

虽然不同厂商或个人对SOA有着不同的理解，但是我们仍然可以从上述的定义中看到SOA的几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

需着重注意的是，SOA并不是新生事物??大型IT组织成功构建和部署SOA应用已有多年的历史??这要比现有的XML和Web服务长很多。IBM CICS和BEA TUXEDO就是过去被用于构建SOA应用的两种技术范例。

重点说明的是SOA并不是一种现成的技术，而是一种架构和组织IT基础结构及业务功能的方法。SOA是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）的模型。这一定义阐明了SOA的范围。

SOA要求开发人员将应用设计为服务的集合。SOA要求开发人员跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重 用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。

但是，SOA并不仅仅是一种开发方法??它还具有管理上的优点。例如，现在管理员可直接管理开发人员所构建的相同服务，这远胜于以往管理单个应用的 方式。通过分析服务间的交互，SOA可以帮助企业了解何时以及为什么业务逻辑被切实执行了，这使管理员或分析师能够有针对性的优化业务流程。

SOA的基本特征

SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征：

q 可从企业外部访问

q 随时可用

q 粗粒度的服务接口

q 分级

q 松散耦合

q 可重用的服务

q 服务接口设计管理

q 标准化的服务接口

q 支持各种消息模式

q 精确定义的服务契约

我们现在开始依次讨论以上概念。

1 可从企业外部访问

通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。业务伙伴采用先进的B2B协议（ebXML或RosettaNet）相互合 作。当业务伙伴基于业务目的交换业务信息时，他们就参与了一次会话。会话是业务伙伴间一系列的一条或多条业务信息的交换。会话类型（会话复杂或简单、长或 短等）取决于业务目的。

除了B2B协议外，外部用户还可以访问以Web服务方式提供的企业服务。

2 随时可用

当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。同步应用对于其所使用的服务具有很强的依赖性。

许多同步应用通常部署在前台，其最终用户很容易受到服务提供者短缺的影响。很多情况下，同步应用利用分布式服务提供者，这样可以响应更多的用户请求。但是，随着提供特定服务功能的服务器数量的增长，出现短缺的可能性也呈指数级上升。

相比之下，异步应用要更为稳健，因为其采用队列请求设计，因此可以容许出现服务提供者短缺或迟滞的情况。异步应用大多数情况下部署在后台，用户通常不会觉 察到短暂的短缺。大部分情况下异步应用能够稳健应对短时间短缺，但是长时间短缺则会引发严重问题。在服务短缺解决、队列引擎将罕见的大量工作推到共享的应 用资源中时，可能会出现队列溢出甚至服务死锁。

服务使用者要求提供同步服务时，通常是基于其自身理解或使用习惯。在多数情况下，采用异步模型可以达到同样的效果，但更能够体现SOA的最佳特性。

当然，并不是所有情况下都应当采用异步设计模式。但大多数情况下，异步消息可以确保系统在不同负荷下的伸缩性，在接口响应时间不是很短时尤其如此。

3 粗粒度服务接口

粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。举个例说明最为清楚??向计费系统中添加一个客户是典型的粗粒度服务，而你可以使用几个细粒度服务实现同一功能，如：将客户名加入到计费系统中，添加详细的客户联系方式、添加计费信息等等。

采用粗粒度服务接口的优点在于使用者和服务层之间不必再进行多次的往复，一次往复就足够。Internet环境中有保障的TCP/IP会话已不再占据主导、建立连接的成本也过高，因此在该环境中进行应用开发时粗粒度服务接口的优点更为明显。

除去基本的往复效率，事务稳定性问题也很重要。在一个单独事务中包含的多段细粒度请求可能使事务处理时间过长、导致后台服务超时，从而中止。与此相反，从事务的角度来看，向后台服务请求大块数据可能是获取反馈的唯一途径。

4 分级

一个关于粗粒度服务的争论是此类服务比细粒度服务的重用性差，因为粗粒度服务倾向于解决专门的业务问题，因此通用性差、重用性设计困难。解决该争论 的方法之一就是允许采用不同的粗粒度等级来创建服务。这种服务分级包含了粒度较细、重用性较高的服务，也包含粒度较粗、重用性较差的服务。

在服务分级方面，须注意服务层的公开服务通常由后台系统（BES’s）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。

5 松散耦合

SOA具有“松散耦合”组件服务，这一点区别于大多数其他的组件架构。该方法旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。

服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。

大多数松散耦合方法都依靠基于服务接口的消息。基于消息的接口能够兼容多种传输方式（如HTTP、JMS、TCP/IP、MOM等）。基于消息的接口可以采用同步和异步协议实现，Web服务对于SOA服务接口来讲是一个重要的标准。

当使用者调用一个Web服务时，被调用的对象可以是CICS事务、DCOM或CORBA对象、J2EE EJB或TUXEDO服务等，但这与服务使用者无关。底层实现并不重要。

消息类Web服务通常是松散耦合和文档驱动的，这要优于与服务特定接口的连接。当客户调用消息类Web服务时，客户通常会发送的是一个完整的文档（如采购 订单），而非一组离散的参数。Web服务接收整个文档、进行处理、而后可能或者不会返回结果信息。由于客户和Web服务间不存在紧密耦合请求响应，消息类 Web服务在客户和服务器间提供了更为松散的耦合。

6 可重用的服务及服务接口设计管理

如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。设计 可重用服务是与数据库设计或通用数据建模类似的最有价值的工作。由于服务设计是成功的关键因此，因此SOA实施者应当寻找一种适当的方法进行服务设计过程 管理。

服务设计管理根本上讲是服务设计问题，服务设计需要在两点间折衷??走捷径的项目战术与企业构建可重用通用服务的长期目标。

超越项目短期目标进行服务接口的开发和评估是迈向精确定义服务接口的重要一步，同时还需要为接口文档、服务实现文档及所有重要的非功能性特征设立标准。

在大型组织中实现重用的一个先决条件是建立通用（设计阶段）服务库和开发流程，以保证重用的正确性和通用性。此外，对记述服务设计和开发的服务文档进行评估也是成功利用服务库的关键。

简言之，不按规则编写服务将无法保证可提供重用性的SOA的成功实施。在执行规则的过程中会产生财务费用，需要在制定SOA实施计划时加以考虑。

7 标准化的接口

近年来出现的两个重要标准XML和Web服务增加了全新的重要功能，将SOA推向更高的层面，并大大提升了SOA的价值。尽管以往的SOA产品都是 专有的、并且要求IT部门在其特定环境中开发所有应用，但XML和Web服务标准化的开放性使企业能够在所部署的所有技术和应用中采用SOA。这具有巨大 的意义！

Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。例如，开 发人员可以采用最适于门户开发的工具轻松创建一个新的门户应用，并可以重用ERP系统和定制化J2EE应用中的现有服务，而完全无须了解这些应用的内部工 作原理。采用XML，门户开发人员无须了解特定的数据表示格式，便能够在这些应用间轻松地交换数据。

你也可以不采用Web服务或XML来创建SOA应用，但是这两种标准的重要性日益增加、应用日趋普遍。尽管目前只有几种服务使用者支持该标准，但未来大多数的服务使用者都会将其作为企业的服务访问方法。

8 支持各种消息模式

SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。

q 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。

q 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服 务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。

q 等幂消息。向软件代理发送多次重复消息的效果和发送单条消息相同。这一限定使提供者和消费者能够在出现故障时简单的复制消息，从而改进服务可靠性。

9 精确定义的服务接口

服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。

META将SOA定义为：“一种以通用为目的、可扩展、具有联合协作性的架构，所有流程都被定义为服务，服务通过基于类封装的服务接口委托给服务提供者，服务接口根据可扩展标识符、格式和协议单独描述。”该定义的最后部分表明在服务接口和其实现之间有明确的分界。

SOA的优点

了解了SOA的定义和基本特征，最后我们再来看看SOA潜在的优点：

编码灵活性

可基于模块化的低层服务、采用不同组合方式创建高层服务，从而实现重用，这些都体现了编码的灵活性。此外，由于服务使用者不直接访问服务提供者，这种服务实现方式本身也可以灵活使用。

明确开发人员角色

例如，熟悉BES的开发人员可以集中精力在重用访问层，协调层开发人员则无须特别了解BES的实现，而将精力放在解决高价值的业务问题上。

支持多种客户类型

借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。

更易维护

服务提供者和服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。

更好的伸缩性

依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。

更高的可用性

该特性在服务提供者和服务使用者的松散耦合关系上得以体现。使用者无须了解提供者的实现细节，这样服务提供者就可以在WebLogic集群环境中灵活部署，使用者可以被转接到可用的例程上。

SOA可以看作是B/S模型、XML/Web Service技术之后的自然延伸。SOA将能够帮助我们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅 速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

   

出处：作者：崔晓波 BEA系统（中国）有限公司资深技术顾问  日期：2005-08-04   

from: http://blog.csdn.net/leomz_t/archive/2006/10/13/1333532.aspx

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，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服务和相关标准。

from: http://blog.sina.com.cn/u/4a877c31010008vt

什么是SOA ？

越来越多的客户在问，如何通过采取财务上无可非议的渐进步骤，打造当今随需应变业务环境所需的敏捷 IT 基础设施，从而提高业务流程的灵活性。通过采用面向服务架构（SOA），公司具备实现业务灵活性所需的技能、软件和经验。

SOA（Service-Oriented Architecture)既服务导向架构，是指为了解决在inernet环境下业务集成的需要，通过连接能完成特定任务的独立功能实现的一种软件系统架 构。该定义的学术味道较浓，但其核心思想并不难理解：让应用不受限于技术，让企业轻松应对商业服务变化和发展的需要。目前，SOA的实现手段主要包括： Web　Serice（网络服务）、CORBA和JINI等。

据Gartner　Group预测，到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将很可能结束传统的整体软件体系架构长达40 年的统治地位，届时将有70%的企业在进行IT建设时会转向SOA。因此Gartner建议，主流企业现在就应该在理解和应用SOA开发技能方面进行投 资，但实际情况又如何呢？到目前为止，绝大部分企业客户还处于计划或早期实施阶段，它们仍在等待从厂商那里获得更多的Web服务工具和平台。

为何需要 SOA？

面向服务架构（SOA）是一种应用框架，它着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。SOA 使用户可以构建、部署和整合这些服务，且无需依赖应用程序及其运行计算平台，从而提高业务流程的灵活性。这种业务灵活性可使企业加快发展速度，降低总体拥 有成本，改善对及时、准确信息的访问。SOA 有助于实现更多的资产重用、更轻松的管理和更快的开发与部署。在当今的业务环境中，变化是毫无疑问的，因此快速响应客户需求、市场机遇和外部威胁的敏捷性 比以往任何时候都更显重要。

各种企业都认识到组件化、模块化、互操作和可伸缩基础设施的价值：

组件化：利用标准化的应用程序和资源服务接口

互操作：实现应用程序和/或资源之间的轻松信息交换

模块化：混合搭配、添加删除、业务流程与基础设施

可伸缩：从现有资源起步，随需添加其他资源

为何选择 IBM？

虽然"SOA"一词是在 20 世纪 90 年代中期出现的，但在该词诞生以前，华罗庚软件基地早已在帮助客户向面向服务的方法转型。只有华罗庚软件基地具有在每一层面履行 SOA 承诺的真实经验、产品和服务深度。无论您是新手还是具有多年 SOA 经验的老手，也无论您是喜欢自己动手还是喜欢获得更多帮助，华罗庚软件基地都可帮助您加快 SOA 采用的步伐，提高灵活性，从而使您的企业更具竞争力。您完全可以将我们作为您的 SOA 向导。我们已经帮助了许多公司，我们同样也可以帮助您。

华罗庚软件基地在十年前已实现SOA，它可以帮助您：

了解 SOA 如何帮助实现业务目标

创建一份详细的 SOA 计划

完善和实施该计划

确保您的 SOA 符合业务需求和性能要求

不管您处在 SOA 采用进程中的哪一步，也不管您的未来 SOA 计划可能需要什么，华罗庚软件基地都能帮您一步步地实施 SOA 解决方案，并确保每一步都能带来回报。华罗庚软件基地具有欠经考验的 SOA 经验、实用的软件和服务，并深刻了解您在选择 IT 供应商时想要了解的业务。

SOA 业务整合采用模型

连接：确保不同应用程序和系统之间可靠而灵活的信息流

整合：整合框架支持异构环境中的互操作性--扫除摆在 web 服务和非 web 服务方法所支持的整合架构前的障碍

自动化：编排业务和 IT 流程，使 IT 和业务目标保持一致，增加收入，控制成本

优化：一种整体方法，它通过使战略和运营目标与业务活动保持协调统一以及为 IT 服务提供支持来实现企业转型与管理

SOA 治理框架

SOA 在本质上是一种分布式的架构方法，因此其治理需求比集中式环境更显重要。要获得必需的业务和技术适应能力，企业需要适当的功能、资产和流程。SOA 环境的治理目标就是要确保在这些功能、资产和流程中实现面向服务的战略。

业务驱动的 SOA

许多企业现在都在着手开发面向服务架构，但结果可能是大多数企业的实施都不太尽如人意。大多数企业实际关注的目标范围都比较窄，它们过于关注技术，而对业务服务的关注不足。

业务驱动的 SOA 2--如何管理 SOA 过程

面向服务的业务是一种连续的服务结构--"企业网"。这在任何一个急于求成、好高骛远、挑战性强的大项目中都是绝对不可能实现的，因为它是通过一个连续的中小项目流逐渐实现的。

改变下一代的应用架构

SOA原本三个普普通通的英文字母，但是排列到了一起却是当今IT届红得发烫的“主角”—Service Oriented Architecture（面向服务架构）。

这个早在1996年就由Gartner提出的“预言”，在厂商和媒体的推波助澜下，8年之后突然重生,火爆异常。

但是我们发现，即使在8年之后，这个概念在中国用户当中的认识还是比较模糊的。在一次SOA的技术讲座上，记者身边坐着中国移动管理业务流程的 项目经理孙庆伟，他向笔者抱怨还是听得不太明白，同时他的第一问题就是：在中国有用户了吗？当得知还没有全面实施的用户的时候，失望之情溢于言表。而方正 奥德计算机系统有限公司业务咨询总监纪钟断言SOA在中国还是一个概念……

究竟SOA是什么？是什么样的魔力让各家软件厂商对SOA趋之若骛呢？

打破信息孤岛的根本之道

以前企业是以应用为中心来构建自己的IT系统的。从IT技术的角度来看，任何一个应用都具备三要素，即业务界面（Interface）、业务逻 辑（Logical）、数据（Data）。如果是以应用为中心去开发一个应用，我们只要在这三个层次选择不同的工具和产品就可以了。譬如做一个人事系统， 数据库我们可以选择甲骨文的，界面可以采用Web浏览器等等。通过这种方式，可以构建很多的业务应用系统，譬如人事系统、仓库管理系统、ERP系统等等。 然而我们很快发现，大多数的业务和服务不是在一个应用系统内就可以完成的。譬如下一个订单，很可能是要涉及企业的客户管理系统、仓库管理系统、ERP管理 系统等。而这些应用系统由于开发的时间不同，采用的开发工具不同，一个业务请求很难有效地调用所有的应用系统。用简单的语言来表述，这些已有应用系统是孤 立的，也就是我们常说的“信息孤岛”。

在以前解决企业内部信息系统“信息孤岛”的问题通常是采用EAI（企业应用整合）的方式。为了保证所有的应用能够互通互用，每一个应用都需要一 个EAI Server来对应。打个简单的比方，EAI Server就好像一个“翻译”一样让每两个应用之间可以对话，可以互相调用。但是我们发现这种方式存在很大的问题。由于每两个应用之间必须用EAI来整 合，当一个企业只有两个应用的时候需要一个“翻译”，当企业有三个应用需要互通的时候需要三个“翻译”，当有四个应用的时候就需要六个“翻译”，五个应用 互通就需要十个“翻译”……从逻辑上讲，EAI的整合方式是一个基于点对点的整合方式，企业的应用越多，这种逻辑关系就会成级数上涨。尽管从理论上来说， EAI是能够完成企业应用之间的整合的。然而这样庞大和复杂的逻辑，体现在实施过程中，就会发现EAI的投入比较高，实施周期也比较长。

那么如何从根本上解决所谓的“信息孤岛”的问题呢？SOA就应运而生，它不是从每两个应用之间的互通做起，而是把每个应用看作服务，形成共享。

因此，SOA对于实现企业资源共享，打破“信息孤岛”的步骤就是:

第一步，把应用和资源转换成服务（Service）；

第二步，把这些服务变成标准的服务，形成资源的共享。

从这个意义上讲SOA不仅仅是一个技术，而是一个软件架构。企业的决策者只需要根据企业的策略来制定流程，把应用作为服务“拿来就用”，而无需考虑底层的集成。这样就可以实现IT和企业业务之间同步。

实现弹性IT的必由之路

其实，SOA并不是一个新事物。IT组织已经成功建立并实施SOA应用软件很多年了，BEA、IBM等厂商看到了它的价值，纷纷跟进。SOA的目标在 于让IT变得更有弹性，以便更快地响应业务单位的需求，实现实时企业（Real Time Enterprise，这是Gartner为SOA描述的远景目标）。而BEA的CIO Rhonda早在2001年6月就提出要将BEA的IT基础架构转变为SOA，并且从对整个企业架构的控制能力、提升开发效率、加快开发速度、降低在客户 化和人员技能的投入等方面取得了不错的成绩。

由于SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种规范。这就决定了SOA的广泛性。SOA要求开发者从服务集成的 角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA 鼓励使用可替代的技术和方法（例如:消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整 原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场做出快速的响应。

SOA也不仅仅是一种开发的方法论，它还包含管理。例如，应用SOA后，管理者可以方便地管理这些搭建在服务平台上的企业应用，而不是管理单一 的应用模块。其原理是通过分析服务之间的相互调用，SOA使得公司管理人员方便地拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企 业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。

SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业IT架构环境中单个应用程序 是无法包容业务用户的（各种）需求的，即使是一个大型的ERP解决方案，仍然不能满足这个需求在不断膨胀、变化的缺口，对市场快速做出反应，商业用户只能 通过不断开发新应用、扩展现有应用程序来艰难的支撑其现有的业务需求。通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流 程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的——这是从上向下看的。这种角度 同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚:它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相 反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。

企业流程（Enterprise Process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方 法。例如，会计可能是企业服务系统的一个组件，但是将发票寄给客户却是一个业务流程。服务被定义用来支持业务流程，因而贯穿整个流程始终的是:各种服务组 件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。

传统的应用集成方法，如点对点集成、企业消息总线或EAI、基于业务流程的集成等，都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于 企业现代业务变化不断产生的需求。基于SOA的应用开发和集成可以很好的解决其中的许多问题。SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。

不同于传统的应用集成方法，在 SOA 中，围绕服务的所有模式都是以基于标准的技术实现的。大部分的通信中间件系统，如 RPC、CORBA，也同样如此。可是它们的实现都不是很完美的，在权衡交互性以及标准定制的可接受性方面总是存在问题。SOA 试图排除这些缺陷。因为几乎所有的通信中间件系统都有固定的处理模式，如RPC 的功能、CORBA 的对象等。然而，服务既可以定义为功能，又可同时对外定义为对象、应用等等。这使得SOA可适应于任何现有系统。

SOA 帮助企业信息系统迁移到“leave-and-layer”架构之上，这意味着在不用对现有的企业系统做修改的前提下，系统可对外提供 Web Services接口，这是因为它们已经被可以提供 Web Services接口的应用层做了一层封装，所以在不用修改现有系统架构的情况下，SOA可以将系统和应用迅速转换为服务。

Gartner预计，到2008年，SOA将成为占有绝对优势的软件工程实践方法，它将结束传统的整体软件体系架构长达40年的统治地位（可能性：70%）。Gartner建议，主流企业现在就应该在理解和应用SOA开发技能方面进行投资。

SOA成功的阻碍

SOA能成功吗？这是很多人包括笔者在内提出的疑问。从厂商得到的信息来看大多数企业还是对SOA采用一种观望的态度。

如果要成功实施SOA还有很多工作要做。

第一是安全问题，由于需要事先灵活的策略，很多情况下需要把服务暴露在外，导致企业的安全需求就凸显出来，特别是那些以Web Services方式构建的SOA应用系统。由于Web Services天生的问题。即使像IBM这样的厂商也意识到这一点。”SOA可大幅改善业务的灵活性和响应时间，但它必须是一个安全的环境。”。

第二是标准的问题。SOA的建立是需要封装的服务具有一个统一的、标准的接口。和基于XML等技术的Web Services所面临的问题一样。如果没有标准接口，实现SOA的理想也就无从谈起。

第三是企业管理的问题。尽管SOA给我们描绘了SOA实施的要求是企业的信息系统相对完善。所有的事情要有严格的流程管理。但是从流程管理来 看，要涉及到企业内部的利益的重新分配。如果说中国的ERP实施的成功率30%,那么整合企业中所有的应用成功的几率有是多大呢？从这个意义上讲，SOA 所面临的企业内部管理、流程才是阻挡在SOA面前最大的问题。

SOA与Web Services之间的关系是怎样的？

Gartner：Web Services并不一定要转向SOA，也并非所有的SOA都要基于Web Services，这两种技术方向之间的关系是非常重要的，并且它们是相互影响的。Web Services将使SOA能够为大型机用户所用；与此同时，SOA的最佳实践架构将有助于使Web Services获得成功。

SOA不是一定需要 Web Services来实现，并且一个基于Web Services开发出来的应用也不代表就是一个基于 SOA 构架应用。Web Services只是服务实现的一个典型，是实现企业 SOA的一个组件（非必需组件）。SOA 为基于服务的分布式系统提供了概念上的设计模式。Web Services则是基于标准的、可经济实惠地实现 SOA的一项技术。

SOA将IT资源透过服务这样一个在业务上有重要涵义的概念来提供、共享，把IT与业务的距离更加拉近了一步。服务在涉及的层次上要比组件、函 数、流程等更高，而且往往在业务上可以找到与之直接对应的概念或实体，例如报价、订单。服务打破了IT系统间的藩篱，就像一家公司的各个部门，平常各自扮 演特定对内或对外服务的角色，但彼此间如果能有效地通过共通的语言及文字，进行良好的沟通，便能协力达成更大、更高的目标。

from: http://blog.csdn.net/leomz_t/archive/2006/10/13/1333532.aspx

对于面向同步和异步应用的，基于请求/响应模式的分布式计算来说，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以借助现有的应用来组合 产生新服务的敏捷方式，提供给企业更好的灵活性来构建应用程序和业务流程。

About the author

Raghu R. Kodali is consulting product manager and SOA evangelist for Oracle Application Server. Kodali leads next-generation SOA initiatives and J2EE feature sets for Oracle Application Server, with particular expertise in EJB, J2EE deployment, Web services, and BPEL. Prior to product management, Kodali held presales and technical marketing positions in Oracle Asia-Pacific, based in Singapore. Prior to Oracle, he worked as software developer with National Computer Systems, Singapore. He holds a master's degree in computer science and is a frequent speaker at technology conferences. Kodali maintains an active blog at Loosely Coupled Corner