JBI研究－OSGi迁移

JBI包含甚么东东？三部分：组件（Components），组件之间的交互控制（NMR[Normal Message Router]）和JBI管理

JBI提供了一个标准的容器，符合该标准的容器可以载入JBI环境中，与其他组件交互处理数据，组件之间的交互通过NMR来完成，NMR定义了WSDL2.0规范 8种数据处理模型中的4种（In-Only、Robust In-Only、In-Out、In Optional-Out）。JBI提供了组件的安装、卸载和管理接口，用JMX实现。

数据的处理流程是：DataA——组件——NMR——组件——NMR——组件——DataB。

由NMR控制数据的路由，QoS等。而组件规模本身可大可小，大到是一个Web容器，小到是一个数据输出（System.out），总之，你要对数据进行处理来完成一项业务。

有没有其他的想法？用OSGi怎么样？将JBI的功能架构分散到OSGi中。当然，OSGi和JBI关注的不是一个方向。

可以设想，OSGi运行环境等同于JBI环境；JBI组件等同于OSGi的Bundle和Service；JBI的NMR怎么处理？可以用一个Bundle来实现NMR的功能；JBI的管理呢？简单，OSGi的Bundle管理比JBI的Bundle管理更强大。

能不能迁移？技术上应该没有多大的问题吧，我想。

JBI的新意在哪里呢？我一直在想。其实，这种结构在很多开源项目里已经实现了，比如OpenAdapter。只不过OpenAdapter关注的问题只在其系统架构的层次而没有从全局和规范化考量，或许这就是不同之处吧。