业务敏捷性取决于企业信息的自由流动、服务和业务流程。而且这也要求IT系统必须能够满足业务的变更：远洋航运集团规划未来几年内把集装箱的吞吐量提高4倍，集团组织构架向多组织化发展……遇到这样的变更，如果你告诉客户：你们仓储系统需要重新构建，组织构架需要重新建模，人力资源系统需要重新编写，财务系统需要重新编写……那将会是一件多么可怕的事情？

　　事实上，满足IT系统的敏捷性，必须逾越几个最基本的障碍：

　　（1）能够统一描述出各种业务，或者说业务对象与业务模型。这些业务对象和业务模型需要很容易被组合或重组。因为企业业务并非随意创建，而是由基本规则在支撑。尽管我们不断宣称需要灵活、敏捷，但这样灵活性的变更发展也必须有一定的原则。这如同企业市场开拓，从一个区域向另一个区域拓展，而绝非游击队的模式： 打一枪换一个地方。

　　（2）企业IT系统一般会由多平台（IBM、BEA、Microsoft、SAP、Oracle等）和多技术（J2EE、.NET、遗留技术等）构成。大企业的异构性会更复杂。某项业务可能涉及到企业内部系统、外部环境、供应商、分销商和客户等等。这就使得业务的变更牵涉到众多合作伙伴。所以必须有更好的互联技术来满足不同系统之间的信息交互，这种信息互联必须基于统一的标准和构架，而且能够很容易定位与获取。

　　SOA为支撑业务敏捷性提供了新的思路和方法

　　上个世纪九十年代所诞生的了BPR（业务过程再造），除了吸引了很多眼球之外，没有形成实实在在的应用，直到如今逐渐成熟起来的BPM Suites（业务过程管理套件），才让BPR再次走入了人们的视线。这就像是一个迟来的热潮，用户最终发现并发掘了那些概念的价值。

　　SOA也是一个迟来的热潮。1996年，Garnter就预见到了服务构架的重要性，并提出了SOA概念。但那个时候并没有合适的技术能够满足这种构架。多年以后，伴随着互联网浪潮，越来越多的企业将业务转移到互联网领域，带动了电子商务的蓬勃发展。为了能够将公司的业务打包成独立的、具有很强伸缩性的基于互联网的服务，人们提出了Web Service概念。

　　Web Service开始流行以后，互联网迅速出现了大量基于不同平台和语言开发的WS组件。为了能够有效地对这些为数众多的组件进行管理，人们迫切需要找到一种新的面向服务的分布式架构。该架构要能够使这些由不同组织开发的Web服务相互学习和交互，保障安全以及兼顾复用性和可管理性。由此，人们重新找回面向服务的架构（SOA），并赋予其时代的特征。在经过IBM、BEA、SAP、Oracle、TIBCO、IONA、SUN、Microsoft等企业的推动下，一批标准的不断补充，参考构架的不断完善，这才使SOA逐渐“从空中降落到地面”。

　　但是，SOA不是业务敏捷性的最终解决方案。它只是为客户构建IT系统时，提供了一个从“服务”视角解决问题思路和方法。当然任何方法都必须有一套可参考的通用语义和多种实现构架来支持，这就是为什么我们常说的“SOA不是一种架构”的原因之一。

　　去年10月份由OASIS组织发布的SOA参考模型（Reference Model）深刻阐述了SOA语义层面的概念，特别是对Service的抽象描述：

　　A service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description。

　　很明显，对Service的描述在这个定义当中并没有限定具体的介质和规范。只是在现有的技术体系下，大家发现采用Web Service来实现Service是个不错的选择。

　　但SOA参考模型没有提出一套参考架构，其更多的是围绕Service来诠释一些基本概念，比如服务描述（Service Description）、交互（Interaction）、契约和策略（Contract&Policy）等等。这为不同厂商之间的实现留有了发散空间，但也为人们理解SOA增加了难度。

　　目前，SOA构架大致与下面图有些类似。但具体实现层面，不同厂商之间是不同的。

　　图3 ：一个SOA参考架构图

　　主要是围绕：消费者（Consumer）、业务过程（Business Process）、服务（Service）、服务组件（Service Component）和应用（Application）来诠释和分层的。

　　中国离SOA还有多远

　　当IBM、BEA这些厂商在经过多年“系统集成应用实施”之后，发现了传统消息集成的很多弊端（集成性方面需要定制化、旧有系统的需要一定的改造等），在这样的不断演进和探索的基础上，似乎找到了SOA的一套方法，以及实现的构架。尽管SOA不仅只是用来解决集成问题，但解决集成问题肯定是SOA的重要方面之一。

　　可以想象，一个有过很多阅历的成年人，对一个涉世未深的孩子说：“你应该走这条路，这是我的经验之谈，不然你未来会有很多麻烦而又头疼的事情。”孩子多数时候会用充满迷惑、好奇的眼神回答：“真的吗？”

　　为了让孩子更容易理解未来道路的选择，IDC发布了《SOA中国路线图》。有观点认为，这是“国际研究机构首次基于中国IT背景，针对中国企业实施SOA路线所做的特定解读”。下面是这个路线图的一些简单摘要：

　　中美SOA定位对比：

　　这个《SOA中国路线图》是有一定可取之处的。

　　可取之处之一，是其点出了中美IT系统所面临的根本性问题不同：现阶段，国内主要是以“构建支撑某一业务的应用系统”为主，其中伴随着一部分企业内部应用系统之间的整合。如果用前面的“三个阶段”来做以下匹配，可能更多还处于第一阶段，即使第二阶段的应用也处于起步状态。

　　可取之处之二，是为国内大型集团化企业指明了如何解决系统集成和系统构建的融合性问题，基于SOA方式下的解决方案。

　　但这个《SOA中国路线图》最大的缺陷，就是忽略了国内的中小型企业用户，忽视了国内软件厂商普遍技术实施薄弱的现状，忽视了绝大多数应用开发平台扩展度、模型度较低的现状。而另外，这个线路图有很有明显的国际化软件公司主导意味，同时，这与普元“构件之路”的口号也有一定雷同之处。

　　不清楚这样的《SOA中国路线图》到底能够被国内多少企业所接受，但是针对SOA这个浪潮，国内软件企业应该抓住这次机遇，结合国内客户的业务与IT需求现状，逐渐寻找出一条适合自己的构架。

　　我们应该跳出SOA那种虚晃而又模糊的“服务”概念，看到“服务”背后的本质：客户期望IT系统更灵活，期望IT系统更容易随业务而变更，期望IT系统之间更容易通讯和协作。开发商需要不断提炼产品的组件度、模型度来应对业务系统的共性问题和差异问题，同时也满足快速构建企业IT系统的需求。