时下，IT界最流行的话题莫过于SOA，而SOA领域里我们用到的最广泛的技术就是WebService。我们热衷于使用WebSerivce来解决企业应用中面临异构系统的应用集成问题，它的问世，天生为集成服务，成为解决异构系统应用集成的首选“良药”。

    但是良药并非“神药”，当我们把它神化之后，错误地以为SOA就必须使用WebService来构建服务，但是在过多地使用WebService后，往往发现“良药服用过量”也会有“不良反应”，使企业的应用又面临严重的性能瓶颈。那么对于它的认识与使用，我们需做何选择呢？

    SOA的理解

    对于SOA架构，并不是说把你的应用或者组件包装成服务就是SOA，而是说，你需要基于一种构架，从而让你的产品能够更适应“业务敏捷性”。SOA的重要特性在于松耦合、可重用、可视化、灵活性，所以只有在这几个环节做到之后才能使企业应用真正置身于SOA的大环境之中。

    SOA方案按照解决对象可分为:面向企业异构系统和面向企业内部业务系统两个方面，前者的角度称为Inter-SOA，后者称之为Intra-SOA。

    而企业在构建SOA时，并非单纯从解决企业异构系统的角度出发，也要考虑到应用的升级、扩展、企业新系统的建设。因此仅以一种修修补补的方式来改造传统技术构建的业务系统，采用Inter-SOA来适应企业的快速变化并非长久之策，它只能作为当前不得已而选择的一种手段。

    WebService的价值观

    WebService很好地解决了基于不同平台，不同语言开发的应用系统间的集成问题，成为解决Inter-SOA最通用最好的技术手段。但是WebService总是被过度乱用，只要谈到SOA，就要用WebService。

    在构建企业的应用或新系统的建设时，都考虑将业务封装成WebService的方式以适应业务的变化，这并非合理的选择。

    儒家文化的一种理念就是“中庸之道，过犹不及”，对待WebService的态度，我们面临的是同样的选择。

    那么有没有一种技术既能适应于外环境的变化，也能适应于内部系统的变化呢？这就需要Intra-SOA和Inter-SOA内外配合，前者从业务的角度来解决业务的需求变化，后者从系统层面解决跨系统间业务与数据的整合。Intra-SOA和Inter-SOA“内外兼修”才能称之为完整的SOA解决方案。

    SOA的正道

    根据笔者经验，能够实现“内外兼修”的SOA解决方案需基于Intra-SOA的ProFrame来构建企业内部的SOA，同时能够提供基于Inter-SOA的ESB产品ProBus来解决接口层异构系统EAI、工作流和多渠道接入的功能。

    而所谓ProFrame，是定义生成实现并重用SOA服务的业务框架的核心解决方案。ProFrame最大化了基于SOA的下一代系统所要求的灵活性、重用性及安全性。

    ProFrame的“Enterprise ModuleBus构架”是运用Gartner提出的“Microflows”概念，实现“Intra-SOA”的核心技术。通过ESB消除了系统与服务间的相互依赖性，提高了服务的可重用性。类似，通过EMB消除了组件或模块间的相互依赖性，从而提高了各模块的重用性。通过组合服务接口、单位模块及通过ESB构建的模块流程，构建了真正的服务组件。

    EMB的优点不仅在于可重用性，而且实现了服务的业务逻辑的可视性。因此用户不懂编程，也可以参与到设计与开发工作当中。

    其中ProFrame的核心就是EMB (Enterprise Module Bus)，它不同于ESB(Enterprise Service Bus)，但却有着异曲同工之妙，它通过把企业的业务逻辑按照Business Module和Service Module的方式，在ProFrame平台上进行开发与定义，通过EMB来统一管理Service Module，通过组合已有的模块产生各种新的服务，构建一个内部的SOA环境。

    构建的这些Business Module和Service Module可以复用和重新组合成新的服务，从而在企业内部形成一个Intra-SOA的松耦合、可重用、高性能的SOA环境。

    ProBus是该Inter-SOA中ESB解决方案，从应用角度而言，是软件提供商对服务、应用、资源以及分散的服务组件进行连接或整合，提供可靠通信的ESB解决方案。它解决系统之间的互联、消息传递、转换、路由、Web服务支持、Flow的控制等。ProBus以高性能的引擎结构保障稳定的服务，可以与BPM、MCI进行连动，灵活支持多种适配器，是真正实现SOA 2.0的ESB解决方案。

    我们声称要构建SOA，于是新建的系统要遵循一系列的标准，要支持WebService，很多原来可以直接以内部模块的方式非常高效的构建系统，现在为了SOA，为了支持异构系统的调用，而把它故意封装成了WebService。孰不知，这正是噩梦的开始。WebService基于SOAP协议来进行通信，它传输数据的格式为XML，而每次调用WebService时都需要传输XML格式的数据，对XML进行解析，这些都是出现性能瓶颈的罪魁祸首。

    Webservice绝非唯一

    当我们需要构建复杂而高效的SOA环境时，确实可以发挥其应用集成的特长，但我们也不能忽视其通讯方式和原有的数据交换格式而引起的性能欠缺，这也许将严重影响企业业务运维。

    不论是基于Inter-SOA还是Intra-SOA，实施SOA的目的是一样的，那就是实现以业务为核心，提高IT系统扩展的灵活性以及IT资产的复用，达到业务灵活组合的状态。而WebService则是作为Inter-SOA中首选的技术，而非解决SOA的唯一途径。

    北京TmaxSoft系统软件有限公司技术总监 黄志伟

    图1. Intra-SOA和Inter-SOA架构

 图2. 基于松耦合架的企业模块总线

图3. 基于Inter-SOA的ESB解决方案
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。