Service orientation within applications

Many IT projects at large companies aim to make the company “SOA-proof”. What really concerns me is that time after time software architects tend to treat “XML Web Services” as a synonym for “Service”. In this article, I want to show that SOA may also exist within a single application.

Often, a perfectly homogenous application is split up in several components that have a great deal of interaction and even share a common domain model. The general idea behind this separation in components is reuse. However, the intended reuse is often not achieved, as other applications often tend to have just a slightly different need.

Furthermore, separation of an application into XML Web Service components comes at a very large price. Precious processing time is lost in (un)marshalling object trees to XML and back. A common way of reasoning is that adding a few more servers or caching requests and responses would solve the problem. Neither of these solutions, however, is quite elegant and should be kept as a last resort.

There is a more elegant solution to achieve loose coupling between components, without the (un)marshalling loss, while still maintaining the possibility to provide your “services” to any other external component. This solution is OSGi.

I will not get into too much detail about OSGi in this article, as there are many articles to be found about that, but here are some key features of OSGi:

• The OSGi specification is defined by the OSGi Alliance [www.osgi.org];
• A bundle (the OSGi application building block) is a black box for other bundles, except for the resources that have been explicitly exposed;
• OSGi bundles can be installed, started, stopped and uninstalled at runtime;
• Each bundle, when started, can provide one or more services. These services may come and go at runtime;
• Bundles can use services without knowledge of their implementation. They can contain metadata that may be used to search a specific service;
• Bundles are versioned. Multiple bundles may provide different versions of the same resources. The OSGi framework will resolve the dependencies perfectly;
• An OSGi application runs completely inside the same JVM, making it very fast (comparing to Web Services or JMS).

The strict visibility rules of the OSGi framework ensure that the loose coupling between components is maintained at all times. OSGi’s advanced class loading allows for several versions of the same bundle to be active at the same time. This makes it quite easy to make modifications in an application, while maintaining backwards compatibility. In fact, OSGi allows for an easy solution of the Web Service Versioning dilemma.

OSGi bundles run inside a single JVM, meaning that OSGi services are not exposed to external applications. However, since an OSGi service just provides an interface to an external user, it is easy to create another bundle that provides this OSGi service (when available) to the outside world as a Web Service. Or maybe as a JMS service. Or one for each. This means that we don’t loose processing time on unnecessary marshalling, but still keep the possibility to simply expose any service to the outside world, if the need comes along (and not by default as is the case with an XML WS).

To recap, besides just being a technologically interesting framework, OSGi offers interesting capabilities to be used in a SOA environment. One of these capabilities is the separation of an application in components that provide each other services. Although these services are not available outside the OSGi context, it is easy to create a bundle that exposes these OSGi services as e.g. Web Services or via JMS.