ApacheCon Europe 2006 is being held in Dublin this week. I couldn’t attend the whole week, but I did get to go to a half-day OSGi tutorial given by longtime OSGi evangelist Peter Kriens. Peter, who is the current editor of the OSGi specification, says:

“OSGi is kind of SOA”

“OSGi is kind of a Java Operating System” or at least a “mini-kernel”

OSGi is “the Dynamic Modularity Layer for Java”

OSGi is a Java framework for developing remotely deployed service applications. OSGi started life in 1998 with the original use case of home automation. OSGi applications can run on different software and hardware architectures. There is a lot of buzz around it right now, particularily in the enterprise space, partially because of Eclipse Equinox, which is OSGi R4 based and the technology underlying Eclipse bundles (actually Equinox goes beyond pure OSGi). But there are a bunch of other implementations, including the Apache Felix project. The specification is freely available and royalty free.

OSGi applications adhere to a basic SOA, the contract between client and service is based on a Java interface and discovering and binding available implementations is done through the framework. Client and service are softly coupled. So it provides an in-VM service model. Declarative services, introduced in R4, are akin to having dependency injected components. Applications declare their service dependencies in an XML file, and are notified by the framework at runtime as services becomes available and go away. The last is an important point: services can go away at runtime, just as they can be dynamically discovered. The next major release of Spring is adding support for OSGi. One of the tutorial attendees made the point that OSGi is a generic event notification framework.

OSGi applications are packaged as bundles, handled by the OSGi Module Layer. The Module Layer addresses packaging, class loading modularization, protection and versioning (multiple versions of the same package) – things Java does not do well, or at all, by itself. In addition, OSGi provides basic Life Cycle Management. An API for managing bundles allows them to be installed, resolve their dependencies, started, stopped, refreshed, updated and uninstalled. So basically, bundles register one or more services with the framework service directory, and other bundles can use those services. Service contracts are just Java interfaces, so service implementations are just POJOs and no special classes need be extended nor interfaces implemented.

Its a pity OSGi wasn’t somehow used as the basis of JBI, there are so many similarities.

Its also a pity that there are currently two rival JSRs attempting to establish a dynamic modularity layer for Java SE. JSR-291 is the OSGi Alliance backed one that aims to “define a dynamic component framework including component lifecycle for existing Java SE platforms”. Peter is on the expert group. JSR-277 aims to do more or less the same thing, expect not as well according to Peter – who is is not on the expert group despite his best efforts! Richard Hall was at the tutorial, he is on both groups. According to Richard he is trying to steer the 277 folks in the right direction. It will be interesting to see what happens. Richard was giving a couple of OSGi related talks in Dublin, I wish I had been able to attend them.

And I think the Eclipse Rich Server Platform proposal deserves some serious attention. There is so much happening in the module/component/service packaging, assembling and deployment space (the McSPAD space) (ok, I guess thats several kind of overlapping spaces). We’ve got JBI, SCA (though don’t hold your breath) and now (yes it has been around for quite some time) OSGi. What we really need to do is get everyone in an aircraft hanger (big enough?), seal the doors and tell them they are not getting out until there is only one. One McSPAD to rule them all.


The Advanced Message Queuing Protocol (AMQP) 0.8 spec has been released. AMQ is an open specification for queued messaging that was born at JPMorgan Chase under the direction of John O’Hara. JPMorgan have formed the AMQP Working Group, together with a bunch of companies including Red Hat, Cisco and Iona. They aim to create an alternative to expensive proprietary messaging middleware like IBMs MQSeries. IBM aren’t the only vendor selling an overpriced queuing system, I reckon TIBCO fall into that category too. I understand this has been brewing behind the scenes for a while, but a lot of folks weren’t sure it would ever see the light of day. As Brian McCallister puts it this is a space badly in need of an open standard, but has concerns about whether it will be properly opened up. According to InfoQ JPMorgan have an implementation in production now. I’ve worked on a number of messaging systems for investment bank trading floors (and beyond) over the years, going back to NetBIOS days, reliable broadcast with UDP/IP, point-to-point based systems with TCP/IP, including HTTP tunneling based Internet trading infrastructure. Back in those days the messaging systems were the product. These days they should just be part of the woodwork, and hopefully AMQP, OpenWire and implementations like ActiveMQ can bring scalable, performant and reliable asychronous messaging to all enterprises.

Maven 2

June 20, 2006

I used Maven 1.x for several years for organising and building a product I was working on. For me one of its strongest features is the uniform structure it imposes on a project, meaning a developer who has used maven before can quickly understand how a component fits together and is built. Another is its management of the dependencies a project has, and the shared repository it uses for this. Recently I’ve had an opportunity to start using Maven 2 for building some open source projects I’m looking at. Maven 2 improves on both these features. This is a good introductory article to Maven 2. To delve deeper, check out the free book Better Builds with Maven.

I mentioned recently that I was impressed by Omea Reader, the blog and news organiser from JetBrains. I still am, I have all my favorite blogs coralled now, and have been busy circling the blogosphere looking for more targets. But all is not cow-cow in the world of blogsumption. One really annoying feature is the fact that, when there is a reference to another blog in a post, or on a website page, and you right click and subscribe, you have to step through a wizard to complete the subscription. I want a Quick Subscribe, just use the defaults and don’t interrupt what I’m doing. The next is the fact that having subscribed, the reader window opens the feed, when in fact most of the time that is not what I want, I’m just subscribing for later, I want to continue on the blog / page I was on. Then it gets worse. If you’re on a website which you went to from a feed, the back button takes you back to the feed, not to the website. Arrgghh. Are you listening JetBrains? Read my smoke signals. Ok, I have not looked too deeply at the preferences, maybe I can change this behaviour. Another thing though, unlike SharpReader, there is no tray alert when a new post is downloaded. I miss my tray constantly bugging me. I do. Honest.

I really like this post from Steve Northover. I think great engineers are about 70% scruffs and 30% cleans.

CodeGrabbit Plugin

June 11, 2006

There are a lot of blogs out there with a lot of useful stuff – code snippets, hints and tips, mini-tutorials and howtos on this open source component and that tool.

Wouldn’t it be great if, having come across a useful code snippet or component related howto, there was a way to insert the necessary bits directly into the Eclipse project you’re working on. These bits might include Java classes, the latest jars for a component etc. I’m imagining a plugin that could set all these artifacts up in the selected project, including making appropriate changes to the build properties and whatever, and some sort of server side descriptor that describes the artifacts in question and where to get them. So the blog entry would have a link to the descriptor.

The only issue I see with this might be security, I guess some bad folks might put malicious components out there and create tempting blog entries to entice hapless programmers to download, build and run the latest whatever, but then steal their credit card details or something. This could probably be overcome with the usual trust/signing mechanisms – but that might be a bit too expensive/inconvenient for publishers. Not sure what the answer to this is, but I reckon this would be a great help for folks.

So I suppose this is kind of a distributed, expert exchange, remote assist, write my code for me stylie thing 🙂

If you think this is a good idea, let me know, and maybe we can start a project to build this.

By now most folks understand the advantages of running and orchestrating key business processes using SOA principles and Enterprise Service Buses, like the web service standards based Cape Clear ESB. There is a lot of business activity taking place on the ESB, and it’d be great to be able to monitor that, gather the intelligence and analyze what our businesses are telling us. In other words putting the ESB and Business Activity Monitoring (BAM) together.

One of the key issues when considering BAM is being non-invasive. A BAM should be able to collect the data it needs to present a real-time dashboard of business state and Key Performance Indicators (KPIs), without you having to engineer that into your applications. Another key issue is correlation. Lots of bits of data and process state go into creating a holistic picture of a business process. A BAM needs to be able to tie all those bits together. Different systems often use different keys to identify a particular instance of a process. Sometimes the interaction between systems is terse e.g. in a synchronous request/response scenario the response message might not even have a process identifier. This can make it difficult for the BAM to create that holistic view and show you everything you want to see.

Fortunately, both of these issues can be addressed very effectively by the ESB. When business services are exposed on an ESB, the bus is handling all the messages as they flow between services. These messages and their orchestrated flow between services define a large part of the process. The ESB itself can event out these messages to the BAM, there is no need for invasive engineering – so collection is free. The ESB is already doing correlation, internally it knows what process instances it is dealing with, so it can add that information to the messages it sends to the BAM, together with a whole bunch of other useful stuff like timestamps and source and destination services.

Sometimes of course, things happen inside of applications that are invisible to the bus, and may be difficult to collect, but that are important to know. Again the ESB can help by exposing its BAM collection function as just another service that applications can invoke. With the Cape Clear ESB we’re enabling effective BAM. We’re doing a whole bunch of other great stuff to make BAM easier too, I’ll post more on that soon.

In the meantime, how about a new TLA: SAM – SOA Activity Monitoring 🙂