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定位对比：
|
美国 |
中国 |
| 过去的半个多世纪，美国从主机时代、PC时代，到了现在的网络时代，积累了大量的应用系统 |
过去中国近30年的IT建设多为生产型系统，服务型系统普遍未开始建设 |
| 美国实现SOA架构关键任务是：对已有系统中的功能进行提取和包装，形成标准的“服务” |
大量“服务”需要全新构造才是中国SOA的主要任务 |
中国SOA实施策略：
| IT建设领先领域（电信、金融） |
服务型系统还没开始大规模构造领域（政府、电力、国防） |
1. 采用对老系统进行切割和封装的方式，或整个系统包装成一个服务；
2. 未来的新建系统用粒度更小、组合更容易、架构更灵活的面向构件技术构造；
3. 用ESB实现新旧“服务”的注册与管理。 |
1. 首先需要统一标准(SCA/SDO)；
2. 用符合SOA标准的方法——面向构件——构造粒度更小、组合更容易、架构更灵活的“服务”；
3. SOA的流程管理；
4. SOA的软件治理；
5. 多“服务”用ESB实现集成。 |
这个《SOA中国路线图》是有一定可取之处的。
可取之处之一，是其点出了中美IT系统所面临的根本性问题不同：现阶段，国内主要是以“构建支撑某一业务的应用系统”为主，其中伴随着一部分企业内部应用系统之间的整合。如果用前面的“三个阶段”来做以下匹配，可能更多还处于第一阶段，即使第二阶段的应用也处于起步状态。
可取之处之二，是为国内大型集团化企业指明了如何解决系统集成和系统构建的融合性问题，基于SOA方式下的解决方案。
但这个《SOA中国路线图》最大的缺陷，就是忽略了国内的中小型企业用户，忽视了国内软件厂商普遍技术实施薄弱的现状，忽视了绝大多数应用开发平台扩展度、模型度较低的现状。而另外，这个线路图有很有明显的国际化软件公司主导意味，同时，这与普元“构件之路”的口号也有一定雷同之处。
不清楚这样的《SOA中国路线图》到底能够被国内多少企业所接受，但是针对SOA这个浪潮，国内软件企业应该抓住这次机遇，结合国内客户的业务与IT需求现状，逐渐寻找出一条适合自己的构架。
我们应该跳出SOA那种虚晃而又模糊的“服务”概念，看到“服务”背后的本质：客户期望IT系统更灵活，期望IT系统更容易随业务而变更，期望IT系统之间更容易通讯和协作。开发商需要不断提炼产品的组件度、模型度来应对业务系统的共性问题和差异问题，同时也满足快速构建企业IT系统的需求。
查看本文来源
京公网安备 11010802021500号