既然说sOA是拯救eai的“天使”，那么就让我们来看看sOA这个“天使”究竟是什么样子? 也许是失败的案例太多了，eai(企业应用集成)作为一类典型的it项目，常常被人们称为“死神之吻”。在集成软件的发展历史上，ibm公司的saa和sql关系数据库曾经给人们留下深刻印象。

corba技术在这个领域很风光。而在中间件成为一种流行的集成方法的今天，许多集成工具采用专用而非开放标准的技术，以hub(交换中心)的架构为基础把应用、消息系统和数据源连通起来。不管怎样，上述所有这些技术和产品都在向着一个目标——实现eai的标准化而努力。

sOA能够改变这一切!

在过去的40年间，软件架构师总是在与同一个“魔鬼”交战，这就是软件的复杂度，而交战的结果总是不断印证着那句不变的咒语:道高一尺，魔高一丈。特别是随着硬件系统、操作系统平台的不断增加以及企业网络的飞速蔓延，如何把这些不同的信息系统集成起来，也就是实现eai(企业应用集成)，更是令许多企业的it人员不堪重负。

到目前为止，传统的编程技术所形成的软件系统都是刚性的。也就是说，一旦开发完成并投入运行，就是固定不变的，不能在使用过程中进行调整和改变。在业务流程中，软件系统严格按照预先设定的目标，各功能模块按照确定的顺序执行。如果数据结构或者业务逻辑发生改变，就必须对所有相关的软件模块、数据源和消息逐个进行修改。就算是有了eai中间件，这种情况也并没有得到根本性的改变。

今天，sOA改变了这种现状。sOA采用服务请求(service request)的方式，使软件系统向“柔性化”迈进了一大步。与传统的软件系统不同，sOA只限定服务所需的信息并提出服务请求，但是不限定提供服务的模块。

由于不限定提供服务的模块，这样就完全可以在服务请求模块不知不觉的情况下，由新的数据源来满足这个服务请求。另一方面，新的数据源也可以去响应其他服务请求者提出的类似请求。在这样的系统中，只需要根据新的情况修改服务的执行者，而不需要修改服务的请求者。所以，基于sOA的企业应用系统可以随着企业业务的变化而逐渐演变。

web服务催生sOA

既然说sOA是拯救eai的“天使”，那么就让我们来看看sOA这个“天使”究竟是什么样子？

sOA支持服务型软件的设计。也就是说，在这样的环境中可以设计出为其他应用提供服务的软件模块。另一方面，所有有服务需求的应用模块都会把自己接受服务的接口公布出来。这样一来，网络环境就可以变成这些服务的交易场所和交易机制。这与当今盛行的web服务的思路可谓异曲同工。实际上，web服务将会催生sOA的实现。

当我们利用web服务来实现sOA的时候，就等于获得了一种建立各种应用并实现eai的编程工具和方法，应用系统的开发、集成和维护的成本和风险都会大大降低。实际上，sOA既是一种架构模式，又是一种编程模式，它同时也是一种关于软件的全新思维方式。

sOA不仅可以得益于web服务的成熟与发展，而且可以从其他许多技术领域获得帮助，其中，网格计算将会是第一个对它有帮助。网格计算不仅仅可以把许多cpu的计算能力整合起来，而且可以提供一种框架，用来完成软件服务模块的动态定位、分配、均衡与管理工作，从而保证不管发出服务请求还是提供服务的模块处在任何地方，都可以保证系统可以安全有效地运行。

值得注意的是，sOA并不能等同于web服务。web服务是一套技术体系，包括xml、sOAp、 wsdl和uddi，可以用来建立应用解决方案，解决特定的消息通信和应用集成问题。随着时间的推移，我们发现这些技术在不断发展、不断成熟，也会更好地帮助你实现sOA。但是，web服务不是sOA。sOA是一种软件架构，而不局限于某个技术的组合(例如web服务)。它超越了技术范畴。在一个商业环境中，纯粹的sOA是一种应用软件架构，其中所有的功能都是相互独立的服务模块，通过完备定义的接口相互联系起来。只要按照一定的顺序来请求这些功能模块所提供的服务，就可以形成完整的业务流程。

web服务的出现，为sOA的应用提供了一种标准。到目前为止，业界已经形成了一些基本的标准模块。sOAp用于服务请求的建立;wsdl用于服务请求的发布;uddi用于服务请求的目录列表;另外还有一些关于安全和数字签名的标准。但是，在业务逻辑的层面上，比如业务流程的开发与管理方面，各家软件厂商总是存在着分歧与争议。

如果sOA理想得以实现，也许会使集成变得更加容易。但要让sOA尽善尽美地走到这一步本身并非易事。首先，必须实现原有系统的标准化，即便如此，仍然需要根据特定的业务流程进行适量的开发工作。在实施sap,sap,sap,sapsap项目方面有经验的人都有体会，任何业务都有其独特的流程和数据结构，其中许多内容无论如何都无法用标准的软件模块来实现。在企业应用集成方面，情况同样如此。尽管已经有了许多进行虚拟数据映射和遗留业务逻辑自动分析的工具，但是其中总有一些特殊的程序和数据结构无法自动处理。

可以预见，sOA并不会完全取代传统的刚性应用软件，但是将会给他们套上标准化的“外壳”，让他们更加易于与别的应用系统实现集成。另外，我们不能把sOA与web服务以及xml混为一谈。web服务可以用来实现sOA，但是如果没有web服务，你也可以很好地实现sOA。反之，即便是利用web服务技术，也不一定能保证sOA的效果就更好。

从长远观点来看，基于xml的web服务将会成为实现sOA的主要工具。但要达到那一步，也许还需要3～5年的时间。目前，我们对sOA还需要有更加深入的认识，也许还会走很多弯路。例如，采用传统的方法，即便是利用sOAp消息来实现现有软件的集成，其结果仍然是一个刚性的点对点通信系统。只不过由于很多厂商都支持sOAp，因此实现过程会比较容易而已。由此形成的集成系统，维护复杂程度并不会降低多少。