转：信息系统，用户主导的时代来临了(一)

http://soa.ctocio.com.cn/xwpl/208/9038708.shtml

本文是上海道仑软件公司熊军民撰写的信息上“路”三部曲的第一部。道仑公司开发以业务为中心的信息系统平台取名为ROAD。以业务为中心，这正是ROAD平台的指导思想。

没有“银弹”

　　没有任何一种单纯的技术或管理上的进步，能够独立地承诺在十年内大幅度地提高软件的生产率、可靠性和简洁性。

　　——弗雷德里克·布鲁克斯

　　这是布鲁克斯在1986年发表的经典文章《没有银弹》中的断言。该文一发表，在业界引起轩然大波，遭到许多软件专家的讨论与质疑。

　　在反对布鲁克斯观点的专家中，库克斯和布鲁克斯的论战最引人瞩目，库克斯认为“重用和交互的构件开发是解决软件根本困难的一种方法”，但布鲁克斯认为库克斯在两点上误解了他的本意。

　　首先，库克斯断定软件困难来自“编程人员缺乏构建当今软件的技术”。而布鲁克斯则认为根本困难是固有的概念复杂性，作为本质上的困难，构思软件概念性的结构本身就有复杂性、一致性、可变性及不可见性的特点。无论是任何时间，使用任何方法设计和实现软件的功能，它都存在。

　　二十年以来，尽管软件专家们努力研究新方法来解决软件的困难，但是布鲁克斯认为这些方法，包括高阶语言、OOP 、AI等皆舍本逐末，只解决了一些概念的表达技巧而已，无法解决根本性的概念结构问题。 由于没办法解决这种根本性的困难，使得原本单纯可爱的软件，逐渐演变为进度落后、成本暴涨、错误丛生问题的集合体，像恶梦中的狼群般蜂踊而至，于是哀号而希望有种“银弹”能即刻平息它们。然而布鲁克斯认为:“不仅眼前找不到‘银弹’，由于软件的本质使然，未来也不太可能找得到。”

　　二十年来是否存在“银弹”的争论一直没有结束过，各种观点相继出现，直到今天也没有得出一个最终的结论。

面向构件开发是“银弹”吗?

　　面向构件开发是九十年代提出的一种软件开发新范型，它是在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。由于以分布式对象为基础的构件实现技术日趋成熟，它已经成为现今软件复用实践的研究热点，被认为是最具潜力的软件工程发展方向之一，是解决软件问题的“银弹”。

　　面向构件开发概念的提出虽然有一段时间了，却很难实现产业化。如果仔细思考一下，事情恐怕没有想象中的那么乐观。

　　首先，面向构件开发并不能解决软件开发的根本困难：

　　1. 软件系统的主要难度就在于概念和整体结构的合理性，先要有整体结构的设计，才有构件，构件是由整体结构决定的，而不是反过来。其次，构件丝毫没有减少概念和整体设计的难度，反而可能会增加难度。

　　2. 由于企业的需求不断变化，软件的结构也需要跟着改变;由于变化的粒度有大有小，构件本身也很可能需要改变，一个构件的改变很可能导致其它与之相关的构件的改变;而构件的开发、组装和调试都是需要时间的，所以很难跟上快速的变化。

　　3. 开发一个软件系统时，在用户需求与软件实现(构件)之间存在着一个很大的鸿沟。用户需求的准确表达和组织，以及如何正确地转化成软件的功能实现，都存在很大的困难。构件开发并不能解决这个问题。

　　4. 用户希望复用的是业务，而不是构件，这一点构件化的方法做不到。

　　其次，关于构件的产业化，我们认为，作为信息时代的软件生产，自有其自身的特点，把它与工业时代的大规模生产方式简单类比，认为软件产业也会复制工业时代的生产方式是不切实际的，理由是：

　　1. 标准化问题，现在软件产业的标准基本都是底层技术级别的标准，如通信、组件、数据库访问等，高级应用层的构件标准能否制定出来，由谁来制定，是个很大的问题。目前关于软件构件的标准远未出台，如果各构件平台厂商推出的构件互不兼容，不能够实现复用，将又造成资源浪费。

　　2. 可靠性问题，机器(如汽车)的性能是由少数几个主要零部件(如发动机)决定的，而软件系统则要复杂得多，将很多符合“标准”的构件组装起来，是否就能组成整体上满足要求的软件系统，实在是个问题。

　　3. 经济问题，构件组装的可靠性问题即使能找到解决办法，其耗费的时间和成本必定是惊人的，很可能得不偿失，完全有违当初构件产业化的初衷。

　　4. 应对变化的问题，一个构件的改变很可能导致其它与之相关的构件的改变，如果由于需求的变化而需要新的构件，是向构件的供应商求助，还是自己解决?时间来得及吗?

　　5. 商业模式问题，对于构件的生产者来说，构件的开发成本基本是由第一个合格的版本决定的，后面的复制基本不需要成本，所以，最大的风险在于，花费巨大成本开发的构件能卖多少份拷贝?如果只能卖少数几份拷贝，则肯定亏本，而这是事前很难预计的。对于构件的购买者来说，也面对类似的问题，即购买多少份同样的构件?如果购买大量的拷贝，这比自己开发更合算吗?所以，无论是构件的生产者，还是构件的消费者，都面临很多不确定的问题，很难下决心走上这一条路。

　　在可以想象的将来，这些问题尚看不到解决的希望，构件的产业化不太可能成为现实。

　　这种基于“标准化构件”开发软件的思想，实际上是照般工业时代大规模工业化生产的思想，把软件当作机器生产。然而一台机器执行的是设计好的简单任务，一旦出厂后不需要什么变化，而现在企业应用软件面对的是快速变化的环境，需要的是随需应变。在当代企业面对高度不确定性的环境情况下，“标准化构件”开发已很难适用。

当前的信息系统架构

　　当今典型的信息系统架构如下图：

　　Middleware,ESB,SCA…

　　.

　　CRM

　　ERP

　　SCM

　　HRM

　　PM

　　WfMS

　　图1当前信息系统架构

　　我们看到，当前信息系统架构的特点是：

　　l 各个应用单独开发，各自为政，其数据库也单独设计，形成一个个信息孤岛。

　　l 开发各个应用所采用的理念、方法、技术不一样，没有考虑应用间流程的集成和交互，没有统一的接口。

　　l 每个应用都有自己的用户管理和安全控制机制，没有统一的门户 。

　　l 缺少全面的管理控制功能。

　　l 应用的业务逻辑大都是硬编码程序，应变能力差。

　　基于以上架构的信息系统必然存在以下缺陷：

　　l 每个应用各自为政，形成一个个信息孤岛，应用和业务流程的无缝集成很难实现。

　　l 系统结构和功能僵化，应变能力差，无法快速应对变化，需要不断投入人力物力进行系统改造和升级，甚至推倒重来。

　　l 缺少帮助业务人员进行业务创新和管理创新的技术手段。

　　l 缺乏统一的系统门户，业务人员疲于应付，工作效率低下。

　　l 随着应用的增多，管理的复杂度增加，管理和安全存在失控的危险。

　　为什么会出现这么多各自为政的应用系统呢?这是历史原因造成的，当初人们开发应用系统时，受到用户需求、开发理念、方法和技术等方面的限制。

　　首先，需求方面，当初企业的信息化要求远不如现在的高，企业一般只对少数关键的应用提出了信息化的要求。

　　其次，开发理念方面，因为用户的需求不高，所以软件提供商实现每个应用时也只考虑其本身，而没有考虑与别的应用的集成，更没有思考整个企业的信息化如何实现。

　　最后，技术方面的限制，当时的应用系统业务逻辑都是用硬编码实现的，这使我们不可能同时考虑和实现所有的业务应用，那太复杂了，只能一个一个的实现。

　　软件技术发展到今天，已经经历了半个多世纪。从程序语言和技术发展看，经历了从汇编语言，到过程语言，到面向对象语言和动态语言，再到现在的面向构件的开发。从软件架构的发展看，经历了从主机终端架构，到客户机服务器架构，到以中间件为基础的三层和多层架构，再到现在的面向服务的体系架构(SOA)。软件的复杂度与日俱增，但在软件开发的效率和满足快速变化的需求方面却还是显得力不从心。

　　对现在的企业用户来说，他们迫切需要用最好的方法，把这些不同的应用、技术、端点进行集成，从而为企业的业务提供最高效的支持。

　　由于目前的应用系统是由不同的IT供应商在不同的时期、用不同的理念和技术开发的，编程语言可能采用C、RPG、COBOL、C++、VB、JAVA、C#等，服务器端可能采用Java EE、.NET、CORBA等，中间件还可能包括BEA的Tuxedo、IBM的WebSphere，甚至还要在大型机上安装包括SAP、Oracle在内的套装软件解决方案。这样复杂的IT系统分布在企业IT系统的不同角落。这些应用就象人类社会早期分布在各地的一个个不同的民族国家，语言不同，文化不同，价值观不同，社会制度不同，法律不同，货币不同，度量衡也不同，它们之间的交往必定会遇到许许多多的障碍，交易成本会很高，而效率极低。显然，要在这些应用之间实现无缝集成，不是一件容易的事情!

　　为了解决软件开发和应用集成的问题，软件厂商逐渐推出了各种技术和平台。下面简要分析一下当今流行的几类技术及其发展前景。

未来的软件架构—SOA

　　面向服务的架构(Service-Oriented Architecture，SOA)是近年来提出的最新IT架构概念，它是基于标准的、松散耦合的面向服务的架构。

　　当今的企业处于快速变化的环境中，信息系统必须提供必要的技术来满足企业发展、法规遵从等要求，并提供更广泛的服务。但是，在目前的软件架构下，IT团队始终处于被动状态，面临的挑战日益严峻，在满足不断变化的业务需求与不能实现随需应变的IT系统之间，存在着越来越大的差距。

　　企业IT系统当前面临的问题是，没有针对它的一套架构方法，产品孤岛之间的数据使用不一致，无法实现客户的单一视图。渠道集成或“客户接触点”集成可能引起包括高度的复杂性、高昂的成本，缺乏足够的灵活性及可扩展性等诸多问题。

　　就IT而言，SOA是一种分布式计算方法，它能够将复杂、异构的IT系统抽象为复合的、面向业务的服务。这种观点认为，业务应用的根本是“服务交付”，各种应用被描述为细化的服务，以实现模块化并重复利用，以降低IT成本并提高资源效率。

　　基于Web服务的SOA架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准(如XML和SOAP)提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来，交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。

　　SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来，将其功能以粗粒度的服务形式表示出来，每种服务都清晰地表示其业务价值，那么，这些服务的顾客(可能在公司内部，也可能是公司的某个业务伙伴)就可以得到这些服务，而不必考虑其后台实现的具体技术。更进一步，如果顾客能够发现并绑定可用的服务，那么在这些服务背后的IT系统能够提供更大的灵活性。

　　SOA不仅仅局限于技术，SOA的实现过程中还涉及到人员和流程等方面。事实上，SOA，或者更宽泛的概念，服务导向(Service-Oriented, SO)，本身就不仅仅着眼于IT，而是针对整个企业。SOA包括人、流程和技术，它是一种通过把功能描述为服务来管理上述所有企业资源的方法，其中企业用户可以根据业务需求来构建流程。

　　SOA必将成为未来流行的软件架构。

Java EE，力不从心

　　“Java Enterprise Edition” (Java EE)是1990年代由Sun公司提出来的。Java EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。

　　Java EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循Java EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。

　　对于开发人员而言，只需要专注于各种应用系统的商业逻辑与架构设计，至于底层繁琐的程序撰写工作，可搭配不同的开发平台，以让应用系统的开发与部署效率大幅提升。

　　Java EE的核心规范是 Enterprise Java Beans(EJBs)，它是Java EE的核心之一，主要用于服务器端的商业逻辑的实现。EJB规范定义了一个开发和部署分布式商业逻辑的框架，以简化企业级应用的开发，使其较容易地具备可伸缩性、可移植性、分布式事务处理、多用户和安全性等。

　　Java EE将组成一个完整企业级应用的不同部分纳入不同的容器(Container)，每个容器中都包含若干组件(这些组件是需要部署在相应容器中的)，同时各种组件都能使用各种Java EE Service/API。Java EE容器还包括：Web容器，Applet容器，Application Client容器。

　　在Java EE提出后8年的演化中，Java EE发生的最大变化可能就在于它放弃了对“分布式对象模型”的强调。EJB2.0引入的本地接口使得Web层与EJB层可以运行在同一个Java虚拟机中，从而使Web容器与EJB容器的物理分离部署变成一种昂贵的冗余;Java EE 1.4以后版本支持的Web Services兼容性，使得客户端可以通过粗粒度的Web接口调用远程服务——这两次变化事实上都是在论证“分布式对象架构”的无用性。

　　值得注意的是，近年来，还有一股更强劲的离心潮流在深刻地影响着Java EE的演进，它肇始于上文提到的开源软件运动。最初它只在Rickard Oberg的动态代理RMI设计与JBoss服务器的微内核架构中显露过邪恶的一角，但是近两三年来，经过多个项目、各种技术杂志/论坛/Blog的折射和放大，它已经形成一个名为“轻量级容器架构”的完整解决方案，并暴露出完全取代传统EJB架构的野心。

　　按照这一运动信徒们的说法，Java EE的发展史上只出现过一个错误——不幸的是，这个错误名叫EJB。与EJB提供的重量级架构不同，借助AOP和IoC机制，轻量级容器能够最大程度地降低代码对于专用接口的依赖性，以简短、轻便、专注、可移植的方式实现业务对象。

　　从“轻量级容器架构”这个词被发明出来的那一刻起，人们对Java EE远景的考虑就发生了根本性的分裂：Sun和大部分主流厂商更多地关注于“Web Services”和“快速开发工具”这些利润增长点，而一部分离经叛道的独立专家和开发者则认为，如果不把轻量级容器纳入规划，Java EE的发展蓝图就注定无足称道。

　　其实，双方争执的关键是传统意义上的“应用服务器”的存亡——如果所有企业级服务都可以通过AOP机制提供给普通Java对象，如果管理业务对象生命周期的可以是一个最微不足道的“微内核”，那么深盔重铠的应用服务器还有什么存在理由?

　　而如果失去了应用服务器的这个产品类型，那些靠这项销售起家的厂商又将何以自处?正是在这里，两个阵营之间存在着最深刻的利益分歧;而这场争执的结局当然也将决定Java EE(乃至Java企业开发)的最终走向。

　　07年7月初，SUN公司宣布加入SCA/SDO国际构件标准组织，标志着Java EE将在未来五年内逐渐退出‘解决客户关键问题的主流技术’的地位。也随着SUN加入SCA/SDO组织的这一刻，Java EE的客户价值领导地位大势已去，Java EE应用服务器将进入低价值和同质化的时代。SUN公司加入这一组织，正说明了两点：一就是在激烈的思想斗争中，加入代表了承认领导地位的失去;二就是将逐步放弃自己的JBI。

　　由于Java EE在市场上的努力有了一段时间，在新一代(SCA/SDO/BPEL)技术还没有成型前，他们还在扮演着‘解决客户关键问题的主流技术’的角色，可是近几年来越来越显出力不从心。直接导致一大堆五花八门技术的出现来弥补其不足：Spring, Struts, Hibernate, AOP......。这些属于2.5G的技术在一段时间内解决了一些问题，不过也在带来更多的问题(彼此的集成，开源的问题等等)。将来Java EE也许会成为一个企业运营需要的同质化的平台，解决分布式计算的问题，也是一个成熟的平台，就像PC机、操作系统一样，发展缓慢。

　SCA，前景难料

　　虽然面向构件开发的概念提出很多年了，但进展缓慢。于是人们认为，除了构件标准化的问题外，另一个主要原因是，缺乏一个高效、实用的构件平台，即一个以构件为核心的生态系统，包括了构件运行环境、开发环境、应用管理环境、基础性的公共构件库、以及面向构件的方法学和经验论。

　　于是SCA(Service Component Architecture)被提出来了，SCA即服务组件框架。它是由BEA、IBM、Oracle等知名中间件厂商联合制定的一套符合SOA思想的规范。SCA规范给出了如何创建组件和如何将这些组件装配成一个完整的应用程序的定义。SCA的目的是使用户在构建企业应用时有一个不再直接面对具体的技术细节的层次，而是通过服务组件的方式来构建应用。它使开发人员可以将注意力集中在业务逻辑的编写上。

　　对于企业应用，SCA还提供了关键的一些基础设施，象安全性、事务、可靠调用等，这对于企业应用的开发而言就变得很方便了。SCA是第一项承诺提供一个组合模型以启用服务网络并支持构建下一代面向服务应用程序的技术。

　　SCA的好处有：

　　l 使用组件和组合简化SOA实现

　　l 使用松耦合的组件和参考来支持敏捷特性

　　l 通过一个综合的调用模型支持事件驱动的行为

　　l 将开发和集合分开，允许技术不可知的组合

　　虽然SCA声称它使开发人员可以将注意力集中在业务逻辑的编写上，但SCA是基于组件的，它关注的是如何描述按照各种编程模型和协议编写的组件所组成的程序集。然而，我们不要忘了，组件是属于技术层面的东西，不能把组件等同于业务，用户真正关心的是业务，而不是组件。另外，SCA对组件关系的建模也过于简单，有的实现甚至让组件自动寻找调用关系，这根本无法构建复杂的业务逻辑。在SCA这里，业务与技术之间的鸿沟依然没有被跨越，这显然无法满足用户复杂多变的业务需求。

　　此外，不同厂商的SCA实现也会有很大的差异，不能直接实现互操作。

　　另外一个无法回避的至关重要的问题是，如果面向构件开发的前景本身不甚明朗，SCA又能有多大作为呢?

ESB，没有解决主要问题

　　伴随着应用集成的迫切要求和SOA架构的日益流行，ESB逐渐成为人们谈论的热点。ESB是企业服务总线(Enterprise Service Bus)的简称，是传统中间件技术与XML、Web服务等技术结合的产物。ESB采用了“总线”这样一种模式来管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础来支持应用之间在消息、事件和服务的级别上动态的互连互通。

　　ESB定义：ESB是一种在松散耦合的服务和应用之间标准的集成方式。它可以作用于：

　　· 面向服务的架构 -分布式的应用由可重用的服务组成

　　· 面向消息的架构 - 应用之间通过ESB发送和接受消息

　　· 事件驱动的架构 - 应用之间异步地产生和接收消息

　　用一句较通俗的话来描述它：ESB就是在SOA架构中实现服务间智能化集成与管理的中介。

　　ESB与SOA的关系：ESB是逻辑上与SOA 所遵循的基本原则保持一致的服务集成基础架构，它提供了服务管理的方法和在分布式异构环境中进行服务交互的功能。

　　目前，ESB被认为是解决企业应用集成问题和实现SOA架构的最好方式。

　　在一些大的IT厂商对ESB的宣传中，认为现在很多大企业里面各部门已经有了非常好的信息系统，但是由于缺乏这些系统之间的沟通，使得这个企业没有办法灵活应变。按照他们的说法，如果用了采ESB，就解决了部门应用的集成问题。

　　事实真是这样的吗?答案恐怕是否定的。

　　实际上，现有的应用功能的颗粒度对于处于这样一个快速变化时代的企业来说还是太大了，不足以让部门级应用跟上业务变化。事实上，当今企业中经常发生的信息系统推倒重建事件，很多就是由于应用系统本身不能满足业务需求而导致的。

　　很显然，各应用系统本身也需要随需应变，也需要SOA化。它们之间的集成也需要更小的颗粒度。

　　另外，当企业采用ESB进行应用集成时，解决的是应用孤岛的问题，而数据孤岛的问题却依然存在。

　　所以，ESB虽然在一定程度上解决了应用的集成问题，但没有解决数据孤岛和应用本身的问题。

WfMS，难当大任

　　在OA方面，由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和应用，而是需要综合的、集成化的解决方案。工作流管理系统(WfMS)作为一种对常规性事务进行管理、集成的技术出现了。

　　WfMS是一个软件系统，它完成工作流的定义和管理，并按照在系统中预先定义好的工作流逻辑进行工作流实例的执行。

　　使用WfMS的目的之一是作为企业应用系统集成(EAI)的平台。在当前大部分企业级IT架构中，各种各样的异构(heterogeneous)应用和数据库运行在企业内网中。EAI就是通过使用多个专门应用满足新需求的方法。有时，这只需要在两个应用之间提供数据通讯的通道。专门应用将很多业务流程硬编码在软件中。而工作流管理系统是不必事先知道问题域的相关信息的。工作流系统将业务流程描述作为输入并管理流程实例的执行，这使得它比专门应用更灵活(当然你也要花精力编写业务流程的规格化描述)。这就是为什么说工作流系统和专门系统是相互补充的。工作流系统可以用来管理全局的业务流程。

　　WfMS能够发挥很大价值的第二个使用方式是：协助涉及多人相关任务工作流软件的开发。为了达到这个目的，大部分工作流系统都有一个方便的机制，来生成执行任务的表单。不用将过程用文字的形式写在纸上，工作流系统使你通过流程定义建模实现过程的自动化(如使用基于Web的应用)。

　　工作流系统的第三种使用方式是：将工作流引擎嵌入到其他应用中。在这里，工作流引擎只是作为一个软件组件，对于应用的最终用户是不可见的。将工作流引擎嵌入到应用中的主要原因是为了重用(不重复发明轮子)和应用软件的可维护性。

　　与以往已经被采用的企业 IT 应用系统，例如 MRPII 或 ERP 相比，WfMS是一个相当重要的里程碑。

　　在传统的软件产品中，系统的设计通常是基于功能分割的，作业项目之间是分裂的。面向对象的技术并不能直接解决这个的问题。从操作上，典型地，我们必须不断地在层次结构的功能表(比如下拉菜单)或对象之间“进进退退”，或者在“神出鬼没”的对象以及相关菜单中捉迷藏。

　　工作流管理系统是一个真正的“人-机”系统，用户是系统中的基本角色，是直接的任务分派对象，他或她可以直接看到电脑针对自己列出的“任务清单”，跟踪每一项任务的状态，或继续一项任务，而不必从一个模块退出，进入另一个模块，搜索相应任务的线索。前者是面向功能或对象的，而后者是直接面向用户的。这样，用户的任务分派和任务的完成状态，可以被最大程度地电脑化和受到控制。

　　使用WfMS能带来以下好处：

　　1.改进和优化业务流程，提高业务工作效率;

　　2.实现更好的业务过程控制，提高顾客服务质量;

　　3.提高业务流程的柔性等。

　　但目前的工作流管理系统还存在许多的不足：

　　1.规范还没有成熟，没有标准被大范围采用。各个工作流厂家都声称自己的产品符合WfMC标准，但他们的实现几乎没有共通性。

　　2.虽然相对于传统的应用软件，工作流的业务建模技术有了很大的提高，但还无法实现复杂的业务流程，只能作为应用系统的补充。

　　3.现在的业务建模还离不开技术，不懂软件技术的一般用户无法定义，因此项目的实施离不开技术人员，有时需要做大量的客户化编程工作。

　　4.相对于SOA和Web服务的发展和用户对应用集成的迫切要求，工作流技术的发展相对缓慢，这直接导致了BPEL等补充技术的出现。

　　我们看到，目前工作流管理在企业中应用的地方还很有限，大多用在非关键业务(如OA)领域。这不应该是它应有的地位。

　　近年来提出的协同软件和BPM(Business Process Management)工具，基本是工作流软件的别称或提升，谈不上有本质的进步，也很难进入企业的主流应用。

　　因此，工作流管理系统如不迅速提升自己的能力，将一直在企业信息系统中担当尴尬的配角。

笨重的IT架构

　　为了迎合当今的SOA潮流，各软件厂商各显神通，包装推出了各自的SOA平台和产品。

　　下面是目前占主流地位的面向SOA的IT架构，其它的实现也与之差不多：

　　图2 当前面向SOA的IT架构

　　这有点象在建造高楼。

　　且不论这样的“高楼”是否真能适应迅速变化的环境，光是建造和维护这样的“高楼”，用户的时间、人员和资金投入将是巨大的。

　　有几个用户能承受这样的代价?

　　并且，我们看到，在维持各个应用各自为政现状下的应用集成，并没有解决数据孤岛的问题。同时，它还可能引发两个新问题。其一是，IT管理者认为系统最终是可以被整合的，从而无所顾忌地增加新系统。系统数量的增加，意味着整个系统管理复杂程度的提升。另一个问题则是，在增加新系统的过程中，企业在IT方面的投入增大了，而且这种增大是一种“动态”的增大。

　　所谓“动态”的增大就是指企业针对新系统的投入不是一次性地投入。只要系统存在，人员工资、机房房租、电力费用、软件更新以及硬件维护费用就需要不断地投入。这些成本再加上新建系统给整个系统带来的管理复杂性，就会把企业拖入“IT黑洞”之中。

　　我们认为，以上的IT架构只是一种治标的方法，SOA的目标是解决应用集成和数据孤岛问题，而现在的做法却是在原有的IT基础上修修补补。对企业来讲，表面上看，“修修补补”似乎保护了原有IT的投资、节约了建设成本，但深入分析，你会发现它可能是得不偿失的做法，并且会将企业引进IT黑洞。因此，从系统思维上来讲，除非因为特殊原因必须保留原有系统，否则，采用这样的方法对企业内部应用系统进行整合，很可能造成弊多利少的后果。

　　前面提到的SCA、ESB、WfMS、BPM、BPEL等技术和标准，很难说它们的提出是从整体上深思熟虑的结果，一些只是为了应付新出现的问题而提出的，这些标准之间出现了不少混淆、重叠甚至相互竞争的地方。用户要用好这些产品和技术实在是一个巨大的挑战，是一件几乎完成不了的任务。

　　事实上，SOA概念炒作的成分要大于实际推广。与厂商们情绪高涨相对应，SOA的一些实施案例并没有取得预期的效果，用户对SOA的认可度并不是很高。

　　SOA确实是好东西，但我们在通往SOA的路上，是否选择了错误的路径?

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/67003/viewspace-631464/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/67003/viewspace-631464/