ESB zone

真的需要 Distributed OSGi?

读完《Why Do We Need Distributed OSGi?》一文，就想“真的需要分布式OSGI吗？”。

瞧瞧OSGI的用户:工具开发者，平台开发者，应用开发者（文中提及的进入企业）。A:对于工具开发者来说，对这个需求不是很强烈，例如要访问SVN、BUG等服务器，都是专有通信协议，直接分布进来还不如自己用个代理模式搞定之；如果对方也是基于OSGI平台，似乎有可能，可这样的应用不是很好找，而且对方也未必相同的分布机制呀。B:平台开发者，稳定的平台，一定要高内聚，低依赖，例如开发一个应用服务器，其中的某个关键组件是依赖外部的一个服务组件，这稳定性保证起来就比较麻烦，何苦哪。C:应用开发者，直接把OSGI作为应用开发容器（下面支一个JBOSS之类的应用服务器），这样的用户到也有，对于规模较大的系统，分布式计算的需求也是存在的，这种情况下，这个容器的作用与EJB是类似的，与CORBA在业务目标上不是很相似；如果想基于RMI之类的重分布式技术，那么还不如直接用EJB哪，如果想用SOAP之类的轻分布式技术，那么只需要把服务通过一个渠道发布出去即可（现在很多人也是这么搞的），例如JBOSS（假如基于JBOSS搭建环境）提供的HTTP通道，稳定又可靠。

看看如何分布？简单的用个CXF，好像不行唉。分布的需求千奇百怪，看看SCA规范中关于分布绑定一节，再看看JBI规范中关于分布绑定的内容，在OSGI规范中加上老长老长的一段相似的东西；如果再考虑安全体系，请求模式，注册/寻址模式，服务质量等，这可好玩了，刚好和IBM的websphere匹配上了（还以为是给IBM定制的规范哪？），全线支持SOA，看起来很美很妙呀。

瞅瞅一个变态而常用的需求，如果想在分布的服务请求之间，增加些规则或逻辑，例如：数据格式转换，多路发送等，不知道这规范还支持不？如果不支持，还是得把ESB搞进来，既然把ESB搞进来了，还要OSGI的分布做啥？从模式角度来说，组合只是一种基本的分布模式，上面讲的这些需求就属于其它分布模式的范畴，可以参考这篇文章《SOA模式》，所实在的，不搞SOA，闲着没事搞啥分布呀。

每种技术都有其作用域，垮了域就不再是强项了，很容易成鸡肋。OSGI常常用组件动态能力，扩展能力说事，我看就扩展能力最具有使用价值，再就是组件之间的隔离能力，真正复杂大型应用中，动态能力反而加强了系统复杂性，目前好似还没有人搞过成本/收益的测试。从职责分离的角度，把分布的复杂需求（应用层的分布需求，比系统层要复杂）封装在独立的组件里（例如：ESB产品，JBI产品等），比OSGI框架层来实现效果会更好一些。从实践经验来看，OSGI + Spring + ESB搭建的应用平台(实在不行，就用SpirngDM)，能够更好的把三种技术的强项聚焦起来，满足企业应用的需要。妄图一个规范打遍天下，还不如加强自有优势，强强联合，用成熟、低廉、可靠的技术来满足企业级市场的需要。

真的不是很需要Distributed OSGi!!!!!!!!