使用OSGi，SCA，BPEL和Spring增强可管理性

自OpenSOA最初发布名为“ 优势整合，SCA，OSGi和Spring”的白皮书以来，这三种技术的整合产生了一些有趣的事情。甚至有一个这种基础设施的 商业实现。 Spring动态模块早已合并了Spring和OSGi，同时Spring Bean可以被作为一个 SCA的组件实现使用。最近，Tuscany的Java实现被构建在了Apache的OSGi框架 Felix之上。

如果William Vambenepe愿意承认这种新型基础设施所声称的：

• “灵活性” （感谢OSGi）

• “可测试性”（感谢Spring）

• “可重用性” （感谢SCA）

那么他不太同意白皮书作者的观点，表现在：

• “简单性”……除非你是一少部分对所有三种工具都有涉猎的人之一。

• “可管理性”，让我们称之为“可管理潜力”，并保持友好。
  

可管理性是SOA的一个重要方面。在一次私人通信中，Brian Cowan，一个位于西雅图的大型保险公司的首席商业架构师指出：

SOA似乎正将一些单块（monolithic）应用模型的复杂性推给了管理和运营。这是你得以实现、部署、伸缩或者保护你解决方案的每个独立部分所必须付出的代价。

William在他更早的一篇文章里对SCA在可管理性上的影响做了评论：

我看到了SCA的另一个优势：它是机器可读的组合应用的逻辑的描述，并位于一个对应用和服务管理有用的粒度层次。

与SCA[类似]，BPEL不是针对可管理性而设计的。它更多定位于提高生产力、可移植性以及灵活性。[……] 它还提供了对应用管理非常有用的元数据。无论是从突显应用流程（通过活动），还是从阐明依赖和关联策略（通过伙伴链接）的方面来说。

SCA，OSGi 和 Spring 还有助于填补那个空白。它们提供额外的应用元数据，这些元数据可以被应用管理工具用来给管理任务提供更多的应用上下文。

在这篇对OSGi进行了广泛介绍的白皮书里，作者指出：

OSGi服务平台是专为那些能够无人值守操作或者在一个平台操作员的控制下操作的设备而设计的。这些就是需要远程管理的设备。

远程管理设备需要一个协议。选择一个适当的协议很困难，因为有太多的选择，包括SNMP、CMISE、CIM、OMA DM或者其它协议。

OSGi联盟决定不优先选择其中一个协议而否定其它的，因为没有一种协议能够适合各种情况。因此OSGi联盟选择了一个体系结构，其提供了一个能够被一个经过授权的Bundle使用的管理API。这时，这个经过授权的Bundle就能够扮演一个管理Bundle，在这里Bundle将一个协议映射到API调用上。

事实上，西班牙的马德里综合技术大学（Universidad Politécnica de Madrid）的电讯工程系（Departamento de Ingeniería Telemática）已经为OSGi服务平台开发出了一个叫做JMood的基于JMX的管理代理。

结尾，William提出了一些注意事项：

虽然这一切很令人兴奋，不过我们中的一些人还想知道，这样冒着风险将这些规范过于紧密的衔接到一起是不是太早了。我见过太多这种“标准框架”的powerpoint幻灯片，来展示一系列开发中的规范能够如何如何准确地协同工作来满足世界的所有需求。

查看原文：Enhanced Manageability with OSGi, SCA, BPEL and Spring