OSGI关于Glassfish的捆绑软件间通信

Question

I am trying to move from some custom OSGI platform to Glassfish for ease of maintenance and implementing new bundles quicker.

I came up with a problem while migrating. So I have BundleA and BundleB, which are supposed to communicate via Service References. The interface for the reference is on BundleC, which is the main bundle on the custom platform. Without BundleC nothing will start, including the platform itself. So I have put the interface on BundleC. BundleB has the class implementing the interface and registering it as a service while it is starting up, and BundleA uses that service.

While moving to Glassfish, as it already provides a proper OSGI platform, I dont need my old BundleC. So after removing BundleC, how to provide a proper inter bundle communication, other than exporting and importing classes or including one bundle for start up? I want BundleA and BundleB to be "nearly" independent, not coupled.

Are there any solutions for this case? or I will still need that BundleC as some kinda middle-ware?

Answer 1

Assuming you have the following setup:

                     Service    
  +-------+                                +-------+
  |   A   |---get------|>---register-------|   B   |
  +-------+             .                  +-------+
      !                 .                     !
      !         [service package]             !
      !                 .                     !
      !             +-------+                 !
      \----import-->|   C   |<---import-------/
                    +-------+

This means there are 2 life cycles. First A and B must be resolved against C. C's purpose is to decouple A and B from each other since it contains the only shared part, the interface. So from a pure coupling problem this is not at all bad in general and many people recommend it.

However, the problem with this model is that you get lots of puny little bundles only containing the interface (though calling it middleware seems a stretch).

I therefore general pick one of the bundles and make it export the service package. The picked bundle must be the provider of the service. This is in general the implementer of your service interface (but does not have to be, read the OSGi Semantic Versioning Whitepaper for details). The provider is the bundle that fulfills the service contract as defined by the service interface's package. The provider of the service is likely bundle B.

Bundle B would then export the service interface's package. Bundle A imports this package. This gives a very nice dependency model: Bundle A depends on the service interface's package but NOT on Bundle B. Any other provider of the interface's package will work as well. At the same, time, bundle A does not get started until there is at least one provider exporting the package. So you have a very nice dependency managed solution and need only 2 bundles instead of 3.

  +-------+                                +-------+
  |   A   |---get------|>---register-------|   B   |
  +-------+             .                  +-------+
      !                 .                     ^
      !         [service package]             !
      !                 .                     !
      \----import-----------------------------/

In bnd(tools) this is trivial, just add the service package to your Export-Package header, bnd will then copy the package from the class path into bundle B. Make sure you mark the provide checkbox for the package to use the right version range for imports.

Answer 2

If I understand your architecture properly I think you're doing the right thing, except that because you're now using Glassfish as your OSGI container, you shouldn't need anything in bundle C except for the definition of your service interface.

bundle C - should only define the service interface (not provide an implementation). bundle B - implements the service interface defined by bundle C and registers itself with the OSGI container as a service provider of that interface.

bundle A - depends on the service interface defined in bundle C.