徐莉
软件组件化能实现吗？对于这个10年前就有人提出的概念，软件业从未停止过尝试的脚步。从“面向对象”到“面向流程”，再到我们今天关注的“面向服务（SOA）”，归根结底，都可以看作实现软件组件化的一种途径，
-- 只不过，他们之间是螺旋上升的的关系。
按照科诺技术公司CEO汪须忠所言，SOA是在原有组件化和EDI（电子数据交换）的基础上，进一步将可重复利用的软件资源抽象化和标准化，换句话说，就是抽取软件基因，建立互通的管道，达到重复利用和信息流畅的目的，解决业务最头痛的“适应业务变化”和“集成”问题。与过去的组件化模式相比，SOA的新奇之处还在于：它变过去的技术组件为业务组件（又叫服务），强调的是技术无关性，关注的是实现怎样的业务功能——在业务请求与响应之间随时搭建快速通道，同时，变过去的紧耦合为松耦合，既保证系统弹性，又不失系统效率，进而实现重复利用软件资源、快速响应市场需求变化、提高生产力等目标。
将2004年命名为软件SOA年似乎并不为过——IBM、BEA、微软、Oracle四大中间件厂商集体放言，要力推SOA。这让我们相信，SOA将促成软件业新的变革，而良性的市场互动，更让我们看到SOA从理论全面走向实践的可能。
“我们正在基于SOA开发下一代产品”，用友软件股份公司产品总监郑雨林说。
作为一名从业多年的软件人，郑雨林对企业信息孤岛和应用孤岛带来的麻烦深有体会，“SOA将帮助我们消除这些孤岛，在各种应用之间建立自由地互通互联，也正因为这一点，我们相信SOA将是整个软件业未来10年的发展方向。”
像用友一样，越来越多的企业开始参与到SOA相关的开发当中。按照Gartner的预测，到2006年，SOA将改变整个软件的构建方式，80%的软件会是通过打包方式进行销售。
用户的反应同样令人兴奋。Yankee 的调查报告显示：76%的CIO表示他们将在未来投资SOA。“用户的进步是超出想象的”，IBM 左洪说，“4年前，当我们向用户提到Web服务，需要从最基本的概念讲起，但今天，再与用户谈起Web服务和SOA，有些人会说，‘噢，我们已经开展了相关工作’。”
中间件厂商，如BEA、IBM，都在忙碌着为市场提供强有力的、有弹性的SOA平台。一些新公司，如科诺公司，则从提供SOA自动生成工具和集成工具的角度，成为市场上的新生力量。
所有的角色似乎都已准备就绪，就等大戏开演。不过，市场并非全无质疑，有很多人对SOA的概念仍不清楚，不少IT管理人员对SOA在操作上的挑战充满疑虑。但这些并不妨碍SOA带领我们走向下一个10年。
解开两道历史难题
有人选择习惯，有人选择改变，后者才是我们这个世界的原动力。
系统管理员惠明面临的问题很有代表性，他最怕两件事，一是公司进行业务整合，二是公司开展新业务。因为对他来说，两件事都意味一个结果——持续熬夜加班。像惠明一样，大多的IT管理人员都经历过类似的噩梦，有人更将异构系统环境与需求的不断变化，看作多年来应用软件的两大“癌症”，使得软件从业人员长年累月陷入“修修补补、穷于应付”的工作状态，企业也根本无法做到对市场变化作出快速响应。
追本溯源，是因为于当初的软件设计思想和软件架构有问题。过去，应用软件基本上是按照业务流程逐一对应开发的，每一个应用自成体系、自立门户。按照BEA中国首席技术推广人程朝晖的说法，事实上，任何应用都包含最基本的三个内容：界面、业务逻辑和数据展现，应该可以重复利用。但就因为每个应用自成体系，每开发一个新应用，就需要重开发一遍界面与数据展现，重写一遍业务代码，浪费了大量的时间和人力。
而SOA就是力求改变过去纵向开发应用的模式，将软件按照业务需求，定义成大小合适的“组件”，作为企业共享资源，随时调用。“SOA的核心就是找到将软件组织在一起的方法”，IBM软件集团大中华区市场总监左洪说。
SOA带给用户的好处很明显，除了前面提到的可以降低开发成本，提高系统集成度和响应速度等，还能帮助解决因为系统升级带来的烦恼。就像汪须忠所言，传统的软件升级对用户就意味着每三年来一次革命，不仅需耗费大量金钱，还会闹得人仰马翻。现有的ERP等企业软件几乎都是铁板一块，当某一点业务变化时，某一点功能需要调整时，必须全部升级，这不但造成升级TCO成本太高，而且牵一发动全身，质量无法保证。而未来SOA构架下的企业软件就像是一个不断进化的生态过程，某些“服务（业务组件）”不断地局部升级，新的“服务”不断地加入，只有这样的系统才能真正做到RTE实时企业，快速适应业务变化。
过去，用户上一个CRM项目，通常只有两种选择，要么从Siebel这样的公司购买庞大无比的系统，而最终却只应用了其中很少一部分功能；要么从小厂商购买功能不足或不全的产品，结果必然面临系统整合的问题。但如果所有软件都基于SOA架构来开发，一方面，对Siebel而言，也可以将过去一整套CRM软件根据市场需求，进行最优化分解，让用户可以根据自己的需求购买其中部分“服务”；另一方面，用户也可从不同厂商处购买最好的“服务”，因为大家都是基于同样的标准和体系架构，组装到一起将不再是个难题。
对于软件开发群体来说，将促使更细的分工，各有所精，做成产业链，而不是某几个公司来垄断，形成软件业的生态圈，纵向的是不同层的技术，如做“服务”的；组装“服务”的；横向的是不同业务领域的，如人事、采购、财务……。有了SOA，中小ISV们可以集中在不同的专精领域，如考勤、工资、费用管理等，而用户自己可以将每个领域最好的配在一起。而SAP、Siebel这样大的ISV，也可以借助SOA架构，提高自己系统的灵活性，适应更多用户的需求。
换个角度上路
坚持未必总是好事，重要的是原则不变，方法随需应变。
如果说面向对象等模式在组件化的道路上，为我们提供了部分思路，那么SOA则是这个思路具有跳跃性的升级版本。虽然目标一致，但思考的角度却已大不相同。SOA强调的是业务本身，看重的是最终结果，因此对用户来讲，更有现实意义。
汪须忠认为：过去的面向对象、技术组件的概念之所以没有获得大家期望中的成功，主要原因在于其关注点在技术，一个技术组件往往用某单一技术来实现一个技术功能，如一段JAVA SCRIPT实现的日历。对用户的意义不大。另外，技术组件是紧耦合的，组件粒度通常过小，不但组装成本高，而且一个组件的改动对另一组件的影响很大，从而影响质量。但业务组件（基于SOA架构的组件，也叫服务）却将注意力集中在业务功能上，每一个业务功能必须是完整的，至于实现这一个业务功能的技术可能涉及很多，如数据库、JAVA、JSP等。也就是说，在一个业务组件中，可能所有这些技术同时出现，以实现现实生活中所需的业务功能，如财务报销、病历等等。它强调技术无关性，是对业务对象的抽象。同时，“服务”的安装，未来的升级维护等应该被考虑到，而不仅是一堆实现某功能的代码。
另外，在范围上，SOA也要远远大于面向对象模式。面向对象的重用性只能局限于一个项目，一个应用。但在实际应用中，跨部门、组织、行业的应用之间互联互通，是经常发生的情况。就像一个设备销售公司，既要自己的上下游供应商和客户进行业务交流，也须和银行、电信等公司进行业务往来。SOA要解决的正是这个问题。所有的“服务”都采用同样的标准，建立在同样的平台之上，当发出一个业务请求时，系统将自动根据需要调用平台上的“服务”，无论这个“服务”是在上游供应商的网络中，还是业务伙伴、银行的系统内。
除了思路更为成熟，Web服务等标准的日渐成熟，也为SOA架构走向应用创造了条件。SOA架构的前身是CORBA和DCOM，其实就是远程/不同系统之间如何互动。
但CORBA/DCOM都是如何在技术上实现互动（现被SOA中的Web服务所替代）。而SOA不但利用Web服务实现技术上的互动，同时，考虑如何去掉技术相关性，从业务的层次如何降低“耦合”度。Web服务中部分标准已经比较成熟，如用于通信的SOAP（XML消息传递），建立请求者与响应者关系的WSDL（Web服务描述语言），是目前发展比较快的两个标准。
谁的时代
如果你相信SOA是场革命，那么赶快加入吧，说不定你就是新的赢家。
当所有人都向一个方向行进，必然会形成一股潮流。今天的SOA正在逐渐成势成局。所以对于局中人来说，你别无选择，聪明者，必然会利用这个机会做一次跳跃。
SOA首先会给一些中小ISV市场机会。“SOA首先会在大的行业市场、多应用的环境中发挥作用”，程朝晖说。对于面向此领域的ISV来说，集中精力做专做精自己的业务，将是最明智的选择。过去因为人力、财力所限，只能服务于少量用户的ISV，现在则可以通过提供行业内“标准”产品，面向更多的用户。SOA让“小而精”有了更大的生存空间。
大的应用厂商则可以改变过去那种大而全的开发与销售方式，将软件按照用户业务的特征，按照最合理的大小重新打散，提高系统销售弹性，更好地适应用户需求。
软件产业链条的概念将逐渐深入人心。比如说，今天软件Office、Word和Excel功能不同, 用户可以选择某一个, 而不需要另一个, 但同时, 这两者之间的互通又很容易，终端用户自己就可以做。如果大部分软件都可以达到这种状态，才意味着软件业的产业链真正形成。果真如此, 未来应用软件可能还是集中在几个大公司手中。另外一种可能, 就是更多的公司各自提供专精的部分, 有人做Word, 有人做Excel。从业务层次来说, 现在还无法明确“软件订单”这个标准。但即便是汽车行业，丰田的组件也未必可以用在通用的汽车上。但没有人否认产业链的存在。理论上讲，SOA将使得软件业可以像汽车、PC一样，形成产业链条。但它的前提是制定出严格的标准来，这必然有很长的路要走。
新的角色现身SOA市场，譬如科诺公司。作为SOA市场的新生代企业，科诺为业界提供的是工具产品，相当于为业界提供的是两条SOA生产线：一条是组件生产线, 一条是组装生产线。ISV提供“原材料”, 即每个业务组件的需求, 还有业务流程，科诺这类的公司则负责根据“原材料”生成业务组件，同时利用组装生产线按业务流程, 组装出整体应用系统。传统中间件厂商也会提供同样的服务，成为SOA市场的引擎。
从市场格局来看，中间件市场首先会发生改变。程朝晖认为，随着标准化、组件化的深入，中间件厂商的数量会减少。“这是市场发展的必然规律的，任何成熟的市场一般都会由二三家大企业把持。最早时候，中间件厂商有200多家，但现在，也只有四家在盈利。二三年后，还可能会有一家被淘汰出局。”
汪则认为，大的应用厂商可能会收购部分中间件厂商，“这是由规模决定的，很多应用厂商规模都远远大于中间件厂商。”另一种可能性，IBM、微软这样的大厂商也可能会收购一些应用厂商。而对于SAP、Peoplesoft这个层面的应用厂商来说，格局也可能发生改变，重点还是要看谁在SOA上面走得更快更好。有消息说，SAP股东曾就因对SOA反应迟缓问题，向管理层表示过不满。
竞争也好，市场也罢，到底会发生怎样的改变，没有人能够精准预测。但有一点毋庸置疑：变革的时代，你必须随势而动。
落实SOA
宁静致远，很多问题还需要静下心来仔细研究。
SOA到底会演变成什么样子，今天看来还是个未知数。但相关工作可以逐步开展。左洪认为，落实SOA，需要几个层次的工作：第一个层次最简单，只需要创建单独的“服务”；第二个层次，需要将业务功能集成到SOA中，这将涉及多层次的集成；第三个层次是将用户的IT基础设施转换到SOA模型；第四个层次则是集中转换用户的业务模型。
从现有情况看，开展SOA还有很多难点。
首先标准仍不完备。Web服务是实现SOA最好的方式，但Web服务本身还有很多不成熟的方面。除了前面提到的SOAP和WSDL相对成熟外，在可靠消息传递、安全Web服务、Web事务处理等方面的标准还有待完善，无论UDDI、ebXML、UBL等在定义业务方面都还需要走很长的路。作为一种社会科学，在设定标准方面，软件要比硬件难得多。
另外，“服务”大小的问题，也就是所谓“服务”颗粒度粗细的问题，也是眼下需要不断尝试的工作。就SOA架构来说，“服务”颗粒大小问题，在某种程度上决定着整个系统的灵活性和效率，要在灵活和效率之间找到一个平衡点。而平衡点需由实践来检验。
“服务”又是会变的，这一点也是当前软件业面临的又一挑战。光有一个组件化的概念是不够的，还需要自动能够解决“服务”的来源问题，即不仅是如何快速组装, 而且解决如何最快速度地生成这个“服务”或调整这个“服务”。这是一个系统工程, 不是一个点能解决所有的问题。
各家公司都提出了各自的解决方案。如按需生成组件的概念，汪须忠将其称为人类“信息”复制的路线。 标准组件的目的是为了重复利用，节省成本，但由于业务标准的难以制定，业务层次的万能组件难以实现。如果能够充分利用工具，走自动化的路， 按需求自动生成符合技术标准的不同业务组件，即以自动化来解决个性化的成本问题，那么，不但成本会进一步降下来，而且质量还会提上去。但其中的具体细节，还需要进一步完善。
作为一个刚刚步入实践的事物，SOA面临的挑战还有很多。 ■
·资料链接·
过去
面向对象编程（Object-Oriented Programme， OOP）
面向对象程序设计是通过对象，对象间消息传递等语言机制，使软件开发者直接模拟问题空间中的对象及其行为，从而提供了一种直观的、自然的语言支持和方法学指导。面向对象设计的基本操纵单位为对象、对象间通过消息传递机制实现功能调用。使用封装，继承和多态等方法具体实现数据的安全操作，代码复用和方法重载。它是紧耦合的，是以技术为核心制定组建单元的，因此，在系统灵活性等方面无法满足市场的需求。
现在
面向服务架构（Service-Oriented Architecture, SOA）
SOA是一种组件模型，它将应用程序的不同功能组件（服务），通过“服务”之间的良好接口联系起来。（也就是“服务”之间的松耦合。）接口是采用中立方式进行定义的，独立于实现“服务”的硬件平台，操作系统和编成语言。这是构建在各种各样系统中的“服务”可以以一种统一和通用方式进行交互。松耦合的好处是保证系统灵活性，另外，还可以保证“服务”的重复利用。Web服务是目前实现SOA最重要的标准。
未来
面向事件架构（Event-Driven Architecture， EDA）
Event-Driven的数学模型是图灵机（Turine Machine），是技术编程的基础。现有几乎所有的程序模式都是事件驱动式的，但是最近几个月才从技术层次走向业务层次，也就是所谓的EDA。EDA真是要解决异步驱动的问题。通过Agent（代理）来处理事件，然后触发其他相应动作（如向另一业务组件/服务发出请求）。EDA还仅是一个想法而已，没有一个标准或产品。 http://www.ccw.com.cn/news2/look/htm2004/20041118_091JC.asp
