部署开源SOA需要专业人才与技术的支援

 　　相对商业SOA动辄需要投入6到7位数的成本，开源SOA产品的一大卖点就是低廉的价格。然而，这些低成本、功能丰富的平台通常都是并非针对商业用户所开发的企业服务总线(ESB)，需要更多的技术专业人员去进行调整。

　　在开源ESB中，Apache ServiceMix、Iona Fuse ESB、JBoss ESB、MuleESB，以及WSO2ESB都是目前的主流，但在进行选择前，必须先考虑到其功能配置是否能对你公司SOA实施有所帮助，还是平添障碍。

　　ESB是一种基于标准的SOA中枢，它能够通过服务界面连接应用。通过信息合并、Web服务、XML以及数据传输和管理，ESB能可靠连接、调整并控制服务之间的通讯与互动。

　　涉及到技术集成方面，开源ESB提供了与其它商业应用相类似的成效。开源ESB不仅经过完善的测试，在网上建立正式的资料文档，同时也针对JDBC、SOAP、FTP、HTTP、POP3、TCP、UDP，甚至AS/400等遗留系统带有一系列的配适器。

　 　然而，在阶段性实施SOA的过程中，将商业需求与IT基础架构相结合尤为重要，而这正是开源ESB所无法提供的(至少从目前来看)。虽然IT人员能够适 应XML和Java，但商业人员在开源环境下工作总会面临着各种困难。商业分析师往往都要视觉化查看流程状态，对流程运行进行实时变更，或调整服务等级协 议，并替换低效的服务。在这方面，商业产品所具备的灵活性带来了即插即用的架构和对现有服务的再使用。

　　只有当用户有足够的XML和 Java专业经验来使用它们时，开源ESB才能提供直观的成效。比如某公司需要一套系统来接受、验证和处理网上订单。在MuleESB里，终端、连接器和 路由器都是由XML所定义。在Spring和Mule中，要创建JavaBean和两个配置文件来接受订单信息，但文件内容与XML之间的对话，以及验证 订单数量的正确性，都需要进行额外的Java编码。然后通过XML来配置Web服务适配器，去处理订单。

　　因此在某种情况下，商业ESB是最理想的选择，因为商业分析师能够在无需额外编码的前提下，视觉化查看流程状态。而对于开源产品来说，额外的编程要求和技术专家的支持明显带来了不少障碍。

　 　测试是一种从开源产品中获得经验的有效途径。只要Web服务被创建，开发人员就能建立小规模用户群去进行测试，在早期活动(比如SOA试运行阶段)中尤 其如此。在这方面，Jmeter和SoapUI都提供了相仿的功能，匹配大多数的商业产品，足以完整测试SOA试运行项目。

　　治理上的欠缺

　 　相比其它部署模型，SOA要求更多的制度规范，否则公司内的复合应用和Web服务就会过剩，从而降低服务应有的效率。虽然在ESB上的开源产品不在少 数，但在SOA治理方面，市场上目前只有MuleGalaxy一种开源产品。不过这并非坏事，因为整个开源社区都会专注于开发并调验这一个平台，满足与其 它商业产品相匹配的要求。

　　MuleGalaxy提供了Web管理控制台工具，如XML、XSD和WSDL文件可以被添加到注册表中。 IT团队可以运用并加强策略，而用户也可以管理生命周期和关联性，并运行报表。该平台支持自动发现服务，提交到Atom发布界面。此外，它也有类似于商业 产品的功能，因此在选择治理工具时，MuleGalaxy也是一个理想考虑对象。

　　MuleESB特别提供了额外的工具，以订阅付费的模式来监控、管理、使用和操作。对于那些需要高可用性、高绩效和技术支持的公司，可以考虑这一优势。另外，几乎所有的开源项目都能获得开源社区的支持，虽然对企业来说这种方式可能较为低效。

　 　与SOA相关的大部分开源产品的成本都会随着时间、技术等因素的演化而逐步降低。为了有效实施开源ESB，IT团队必须要准备好去学习框架、组件模型、 XML脚本模型，并在Spring和Java上有一定的工作经验。对于具备专业人才和充裕时间的公司而言，良好的治理和测试功能，灵活的可升级性与可扩展 性，让开源产品成为高成本的商业产品之外的又一选择。