OSGi Bundle Communication Options
DZone's Guide to
OSGi Bundle Communication Options
Join the DZone community and get the full member experience.
Join For FreeThe State of API Integration 2018: Get Cloud Elements’ report for the most comprehensive breakdown of the API integration industry’s past, present, and future.
There are various approaches to communicating between bundles...each having its own benefits/tradeoffs. Here are my (in progress) notes on evaluating the options with regards to Fuse ESB 4.2...
OSGi Service Registry
This is the most common (and well documented) approach from a pure OSGi perspective. Simple XML can be used to both register APIs as services and access other bundle's services. The service registry then provides an abstraction layer and an event framework to support dynamic binding, reacting to service lifecycle changes, etc. The whiteboard pattern can also help better manage this interaction in more complex/demanding scenarios.
OSGi Import-Package/Export-Package
This approach is more direct and relies on OSGi bundle manifests to tell the classloader which classes to export (make available to other bundles) or import (find classes in other bundles). This has the effect of making any imported classes look like any other class in a bundle.
However, this tends to tightly couple bundles together and can cause various classloader/versioning issues when bundles get out of sync.
JMS
An ActiveMQ broker is provided with Fuse ESB and is easily setup/configured. JMS endpoints can then easily be setup using Camel to wrap access to POJO Java code, etc. This can easily serve as a bridge between bundles or even VMs/machines entirely. This approach povides the standard JMS benefits (guaranteed messaging, loose coupling, high performance, failover/load balancing, etc).
Some initial performance concerns usually arise when considering use of persistent XML messaging. Most performance concerns can be mitigated by varying the JMS QoS or even using serialized object messages instead of XML, etc.
HTTP (SOAP, REST)
Another classic approach is to provide HTTP endpoints to interact with a bundle. This provides a loosely coupled strategy bound to either a SOAP WSDL or REST request/response format. Camel components can be used to setup these endpoints and wrap requests to POJO Java code, etc.
Unfortunately, these endpoints aren't the easiest to configure/test and often impose a significant overhead in terms of marshaling request/response data around.
NMR
Though its roots were in JBI/XML based messaging, it has evolved to provide a more generic/configurable approach to bundle communication. It can be configured to be to be synchronous or asynchronous. Also, the camel-nmr component makes it easy to define NMR endpoints to route data between bundles without the need to use JMS brokers or more complex HTTP definitions.
See this post from Adrian Trenaman for more details on the new NMR...
VM
VM uses asynchronous SEDA to send messages between entities in the same virtual machine. This has the benefit of using a seperate thread for a producer and consumer.
More to come on this...I'm still working out the differences between VM and NMR in OSGi.
Distributed OSGi (DOSGi)
This implements the remove services functionality using SOAP web services. Its very new and I'm still coming up to speed on it...(thanks Ashwin for pointing this out)
More to come on this...see these page for now.
http://cxf.apache.org/distributed-osgi.html
http://osgithoughts.blogspot.com/2010/07/cxf-distributed-osgi-12-is-out.html
summary
This is clearly still a work in progress. There are a lot of options and I'm still trying to get my head around the trade-offs of each approach (hence this page). As time permits, I'll try to expand on these more...
If anyone has had good/bad experiences with these techniques or others, let me know...
OSGi Service Registry
This is the most common (and well documented) approach from a pure OSGi perspective. Simple XML can be used to both register APIs as services and access other bundle's services. The service registry then provides an abstraction layer and an event framework to support dynamic binding, reacting to service lifecycle changes, etc. The whiteboard pattern can also help better manage this interaction in more complex/demanding scenarios.
OSGi Import-Package/Export-Package
This approach is more direct and relies on OSGi bundle manifests to tell the classloader which classes to export (make available to other bundles) or import (find classes in other bundles). This has the effect of making any imported classes look like any other class in a bundle.
However, this tends to tightly couple bundles together and can cause various classloader/versioning issues when bundles get out of sync.
JMS
An ActiveMQ broker is provided with Fuse ESB and is easily setup/configured. JMS endpoints can then easily be setup using Camel to wrap access to POJO Java code, etc. This can easily serve as a bridge between bundles or even VMs/machines entirely. This approach povides the standard JMS benefits (guaranteed messaging, loose coupling, high performance, failover/load balancing, etc).
Some initial performance concerns usually arise when considering use of persistent XML messaging. Most performance concerns can be mitigated by varying the JMS QoS or even using serialized object messages instead of XML, etc.
HTTP (SOAP, REST)
Another classic approach is to provide HTTP endpoints to interact with a bundle. This provides a loosely coupled strategy bound to either a SOAP WSDL or REST request/response format. Camel components can be used to setup these endpoints and wrap requests to POJO Java code, etc.
Unfortunately, these endpoints aren't the easiest to configure/test and often impose a significant overhead in terms of marshaling request/response data around.
NMR
Though its roots were in JBI/XML based messaging, it has evolved to provide a more generic/configurable approach to bundle communication. It can be configured to be to be synchronous or asynchronous. Also, the camel-nmr component makes it easy to define NMR endpoints to route data between bundles without the need to use JMS brokers or more complex HTTP definitions.
See this post from Adrian Trenaman for more details on the new NMR...
VM
VM uses asynchronous SEDA to send messages between entities in the same virtual machine. This has the benefit of using a seperate thread for a producer and consumer.
More to come on this...I'm still working out the differences between VM and NMR in OSGi.
Distributed OSGi (DOSGi)
This implements the remove services functionality using SOAP web services. Its very new and I'm still coming up to speed on it...(thanks Ashwin for pointing this out)
More to come on this...see these page for now.
http://cxf.apache.org/distributed-osgi.html
http://osgithoughts.blogspot.com/2010/07/cxf-distributed-osgi-12-is-out.html
summary
This is clearly still a work in progress. There are a lot of options and I'm still trying to get my head around the trade-offs of each approach (hence this page). As time permits, I'll try to expand on these more...
If anyone has had good/bad experiences with these techniques or others, let me know...
Your API is not enough. Learn why (and how) leading SaaS providers are turning their products into platforms with API integration in the ebook, Build Platforms, Not Products from Cloud Elements.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Ben O'Day , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}