Ronald Schmelzer ，ZapThink 的高级分析师，再次讨论了关于开源的 SOA 解决方案对于企业的适用性方面的常见的误解与偏见，并且提出问题“为什么有那么多的 IT 组织过早的放弃了开源软件 (OSS) 作为他们的 SOA 实现？”
必须要明确的一点是，ZapThink 并不是提倡你丢掉所有供应商的解决方案而转投 OSS，然而，我们相信当前的经济和技术环境使得 OSS 解决方案更加可靠，可行，更具成本效益，并且随着业界的成熟更加有效。
他首先根据维基百科定义了开源软件，小心地指出了自由软件与开源软件之间的微妙区别。
开源这个术语，就算不是始终都会，也是经常与自由软件的概念一起被使用。在这一术语中，自由有时候意味着获取许可证不需要任何花费，但这并不是自由软件基金会 (FSF) 的准确定义。FSF 定义自由和开源软件 (F/OSS 或 OSS) 为可以自由的拷贝和重用的软件 […] 这意味着 FOSS 许可证给予了用户拷贝，修改，分享，发布，以及对技术进步作出贡献的权利，但这并非意味着对总的花费作出了任何暗示。
除此之外，开源软件还可以有商用 (COSS)，这种方式下“社区在一定层面上拥有修改，分享，增强软件的权利而其它的部分由公司保留”；这造成了对于采纳开源解决方案伴随着害怕，不确定和怀疑 (FUD)，因此必须要在众多可获得的开源许可证中查找法律术语。
先让我们来看看不确定性。从 SOA 的角度来看，OSS 的不确定性很大程度上是由于两方面的问题：是否有足够的 OSS 供应能够覆盖我们 SOA 实现范围内的整个需要，还有这些 OSS 项目对于我们的需求而言，质量是否过关？
他接下来试图回答这一问题:
个人和公司对于这些 [OSS] 工具倾注了成千上万小时的开发和维护时间。[…] 许多构建开源工具的经验是来自于那些曾经使用商业版本的用户，他们的目标是模仿或者提升这些解决方案的功能和表现。
此外他还指出，由于许多供应商工具是并购带来的结果，还些还是经历了一系列的并购；所以通常会发现商业 / 供应商的解决方案在路线图以及与产品组合的其它产品集成方面，定义不完善。接下来他分类列出了在整个解决方案空间的不同部分可用到的各种各样的方案…
对于 […] 企业服务总线 (ESB) 功能而言，开源解决方案比比皆是。许多公司都成功地实现了 Mule ESB ， Apache Axis2 ， Apache Synapse 以及 Apache ServiceMix 。
对 SOA 开发而言，有广泛可选择的 OSS 方案，[…] 比如 Swordfish SOA 框架以及 Equinox OSGi 打包框架。
对于开源的 SOA 注册与管理解决方案有 Mule Galaxy ， SOPERA ， WSO2 的开源注册 产品，以及 Membrane SOA 管理工具。
OSS 的业务流程管理 (BPM) 以及 BPEL 运行时引擎包括 ActiveBPEL ， Apache ODE ， Orchestra ，以及其它很多。
他声称害怕 OSS 解决方案不被支持这种说法是没有根据的，大部分 OSS 项目都有商业公司提供需收费的支持。
尽管许多优秀的 OSS 解决方案真的需要收费的支持来达到所必需的响应时间和关照，但我们也可以说这钱花得值。通过商业公司来对 OSS 产品提供支持你可以从中得到这方面的好处：以低成本或无成本进行社区开发，测试，改进，而获得专业级的支持，时间和价值都保证一定的质量。就算是选择一个商业厂家，你一样需要支付支持的费用。
…另外，他还建议到，OSS 可以减轻因为并购，消减成本或者合并，而对 IT 业界的产品或产品线所带来的退市下线的风险.
OSS 意味着更少的风险，因为代码对于社区是公开的，谁都可以利用。从 SOA 的角度看，你希望对于基础设施或者单一厂商的解决方案依赖越少越好，因此，对于大多数而言，OSS 有着极大的意义。
他继续给出了 BlueStar Energy 在整体地基于 OSS 解决方案通过 5 年的 SOA 实现，节省了 2400 万美元。
如果你阅读了这个安全分析，你可以发现其设计原则有着决定性的非厂商倾向。他们想要控制他们的环境，这意味着要创建一个中立于实现的规范。[…] 他们的业务集成套件由开源的分布式，可伸缩可依赖的组件组成，比如企业服务总线，业务流程管理系统以及消息系统结构。
他鼓励架构师用一直实现未知 / 厂商中立的方式来设计架构，并权衡侯选解决方案的适用性；不管是开源的还是厂商的。他在文章的总结中看好 OSS 在企业 SOA 实现中的前景。
自省一下你自己的 FUD。保证你不会因为在你的 SOA 基础设施混搭中过早地抛弃了 OSS 而失去相应的优势。
评论