Monday 13 December 2010

Remote services

Recently I experimented with OSGi remote services using Apache Aries (blueprint services) with either Apache Tuscany or Apache CXF to provide the remoting capability.

I was trying to find the simplest and most flexible way to do this:


There are two OSGi runtimes (R1 and R2),  a bundle in R1 is using a service supplied by a bundle in R2.

For those of you who don't want to do a lot of reading the short summary is:
  • The simplest way to do this is Apache CXF
  • The most flexible way to do this is to use Apache Tuscany
Let's start with a few words about CXF. The part you need to do this is Distributed OSGi . There are very good samples with the project and I only encountered two issues with achieving what I wanted to. The first of these is that the multi-bundle distribution doesn't run on Equinox so you have to use the single bundle distribution or use Felix. I elected to use the single bundle distribution on Equinox.
The second issue was that I had a web bundle in one framework and had some problems with conflicts on http port which I didn't properly resolve. I found that I could work around them by configuring the http port to anything except 8080, for example:

org.osgi.service.http.port=6969

in the Equinox config.ini file. If you are trying to debug an application which uses CXF it is also worth understanding that the consumer runtime (R1)  registers a proxy service based on the WSDL produced from the provider (R2) runtime - this proxy service is not registered until something in R1 tries to use it.

Apache Tuscany  provides the same functionality as CXF and a lot more besides. I wanted to use Tuscany because I want to get onto the other things I can do with it later, for example Tuscany supports other component models (eg EJB) and other bindings (JMS, JCA, json-rpc and so on).  I used a sample banking application (developed by Graham Charters et al. for the 2010 OSGi Community Event), the code for the application and all of the SCA configuration is checked in here. The application had already been run on IBM's WebSphere Application Server so all I had to do was figure out how to do it on a pure open source stack. How hard could it be?
The application itself and the SCA configuration are both very simple. The picture below shows the relationships between  bundles and how the bundles are distributed between OSGi runtimes. The API bundle is, of course, installed in both runtimes.



As usual with Apache Aries samples,  I have tried to make it as simple as possible to run. If you want to run this sample you will currently (it is not released) need to check out and build Aries, then from the ~/samples-sandbox/bank directory just use 'mvn clean install' to build the sample.


To run the sample, change directory to bank-assembly/target and run:

sh runclient.sh - to start the client runtime (Runtime 1)
sh runserver.sh - to start the server runtime (Runtime 2)

(apologies - I don't have equivalent .bat files)

You can check that the server is producing WSDL by navigating to:


http://localhost:8081/creditcheck?wsdl
http://localhost:8081/lineofcredit?wsdl
http://localhost:8081/chequing?wsdl


And that the client is running navigating to:

http://127.0.0.1:9090/bank/index.html

That all looks wonderfully simple - and it is. So why did I imply this was hard?

Tuscany is a big project and I just wanted to use a bit of it - all of the difficulties I had were connected with putting together an OSGi Tuscany runtime that had what I needed. Of course, if I had used a commercial application server (like IBM's WAS) someone would have done all this for me and there would have been no pain at all.

If you look at the bank-assembly/pom.xml you will see that I am actually downloading an entire Tuscany distro, unpacking it and then using the Equinox config file to pull in the bundles that I need for the OSGi runtime.
Finding the correct bundles would have been very difficult without the help of the Tuscany team - they told me what I'd need.

This solution is far from ideal. A slightly better solution would be to specify the list of bundles that I need in the pom.xml and have Maven get them for me as we do in all the other Aries samples. The reason that I can't do this is that Tuscany found that many of the OSGi bundles they wanted didn't exist or were badly put together - so they have fixed them - which is great! But they have fixed them in the Tuscany distro only - which is slightly less great from the point of view of a consumer. It would have been nice if they had followed the ServiceMix model and simply made the fixed bundles available.

The best solution (which we don't have at all yet) would be to have a proper bundle repository somewhere and use a resolver to go to it and get the OSGi bundles I needed - whatever they might be. One day there will be such a repository - but it's going to take some effort to build :-) Until then hacking-it-up is the only way.

The other thing that I hope will happen sometime soon is for Apache Tuscany to be able to work with the recently implemented Aries Application model. As it stands, I don't use the Aries Application model in the Bank sample, it is just a set of OSGi bundles. 

In summary, I like Tuscany and I'll go on to try and use other bindings with OSGi applications. The fact that it wasn't easy to pull together the right OSGi platform says more about where we are with OSGi today than about Tuscany. For wide scale enterprise OSGi adoption to happen we need a bundle repository. Tuscany have implemented a workaround (which I don't like), ServiceMix have implemented a work around which is much better - but the right answer is a bundle repository and as soon as possible, yesterday even.