《程序员》2007第6期作品：SOA与业务敏捷

本文发表于《程序员》杂志2007年第6期，转载请注明相关信息，谢谢。

  

SOA 与业务敏捷

作者：TIBCO中国研发中心 胡长城（银狐999）

  

在阅读这篇文章之前，我要强调一个观点： SOA不仅仅只是一套构架，其更像是一套设计思想、方法。为解决客户所面临的业务敏捷性问题提供了一套新的解决方法。

 

On Demand 反映客户对业务敏捷性的需求

其实业务的敏捷性是众多传统企业与IT企业一直在探讨的话题。几年前，大家都或多或少看过IBM非常具有创意的“e-Business on Demand”广告。那时候，这个专有名词在中文当中被称之为“随需应变”。“e-Business on Demand”是IBM在2001年提出的概念和口号，以替代早先（1990年代中后期）的“e-Business”策略，它的主题思想是： 使 IT 应用以服务形式出现，用户可以像使用其他公共设施那样，在任何时间和任何地点安全地、稳定地、高效地获得有偿信息和服务。

 

再回想一下就能发现，现在众多技术人员熟知的 Web Service 正是诞生在那个时期。当然，现在探讨的 SOA 要远比 Web Service 以及 Service on Demand 要复杂得多。

 

首先让我们来看看什么是业务敏捷性（Business Agility）。 企业发展来自于市场不断开拓、战略不断调整、经营方针不断完善、管理水平不断提高。但是在今天，要实现上述所有的工作，都必须依赖于IT系统的有效支持。因为按照传统的方式，已经无法满足企业发展与竞争的需求。

 

《世界是平的》的作者托马斯·弗里德曼在他的作品中讲了两个很有趣的故事：

 

作者本人给位于德克萨斯州的奥斯汀的Dell 管理部门写了一封信，询问他自己的Dell 笔记本的各个部件来自哪些国家。得到的答复是：美国因特尔公司设在菲律宾、哥斯达黎加、马来西亚或中国的工厂生产的处理器；韩国、日本、中国台湾或德国生产的内存；中国内地或中国台湾生产的显卡……

 

某天早上10 点，Dell 发现很多客户订购的笔记本电脑都要求配备40G 的硬盘，如果这样的话，两个小时后，供给链将出现断货信号，并自动地发送给Dell 销售部门、公司网站以及所有的订购电话接线员。如果你正好10 点半向Dell 发出订单，公司的销售代表会对你说：“您现在只需要在40G 硬盘价格的基础上多支付10 美元，就可以得到60G 的硬盘的配置。”利用这种促销手段，在一两个小时内，Dell 可以根据全球供应链的情况重新塑造顾客对产品的需求结构。

 

上述两个故事都在讲述一件事，那就是怎样让企业的业务变得更加灵活，或者说更加敏捷。不难想象，Dell公司已经具备了比较完善的供应链管理系统、财务系统、客户关系系统等IT基础设施，这也说明Dell的企业经营管理已经依赖于IT系统的支撑。今天，绝大多数企业都具备了类似特征。不否认存在一些企业的经营管理还依赖于传统的电话沟通、面对面的洽谈会，但这已经是少数，而且会越来越少。

 

如今一个企业是否能够让CEO的决策、企业战略的调整、市场方向的重定位等等一系列问题快速变更与执行，几乎都依赖于信息化建设的完善。然而，这种完善程度不仅意味着信息系统在企业内部的覆盖面，更依赖于这些系统之间的协作性与敏捷性。

 

让我们在此用简短的一句话来为业务敏捷性下个定义：

 

业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。

 

IT 系统一直在不断演变和发展，寻求对业务敏捷性的更好支持

在美国、欧洲三四十年的IT系统建设中，基本经历 了三个应用阶段：

 

第一阶段信息发布，即传统的Information Management System，在这个阶段最主要的任务是把某一个业务下的信息数据管理起来，比如早期的财务系统、人力资源系统 ；

 

第二阶段是企业系统的内部整合，当企业内部绝大多数信息系统都已经建立之后，是否能够有效地进行协作和资源整合，成为主要解决的问题；

 

第三个阶段，是企业内部的信息系统需要与外部环境，包括供应商、分销商和客户进行整合。

 

当然不是所有的企业都经历的这些阶段，也不是所有的企业都已经进入第三阶段，这只是一个整体性的发展路线，或者说趋势。

 

图 1 ：企业信息系统发展过程

 

图2：信息系统技术标准发展过程

 

上面两张图分别显示了不同视角下，IT系统和技术标准的发展。第一张图显示了人们为追求业务过程自动化而做出的努力；第二张图则显示了SOA在发展历程中，所经历的阶段（图中主要显示了一些相关标准）。事实上我们还可以绘制的更多：从面向对象（OO）到组件（Component），再到服务（Service）；把ARIS、Enterprise Architecture、五视图方法、SOA Reference Model等等也绘制到另一张图中；把“应用+服务模型（Service Model）+服务组件（Service Components）+中间件”这种类似的多层构架的演变历程绘制在另一张图上。

 

这一张张的演进图表达了什么？它们代表了IT系统在为企业经营管理（业务）提供支撑的发展历程，包括体系结构、系统模型、标准、语言等等。这些历程正伴随着上述 三个应用阶段而不断演进。

 

然而，人们构造这些 IT 系统是为了什么？仅仅是卖给客户几个“漂亮的概念”吗？当然不是，这是软件提供商在不断满足客户在业务系统的应用性、敏捷性上的需求而做出的努力。

 

业务敏捷性取决于企业信息的自由流动、服务和业务流程。而且这也要求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定位对比：

美国	中国
过去的半个多世纪，美国从主机时代、 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系统的需求。