自 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
评论