JAX London April 2011

JAX London was a great conference. The venue was better than before and they have refined the speaker selection to suit the target London audience. There were many good talks, these were the highlights:

Dan North, keynote talk on the Agile day was totally absorbing. I think we are at the stage where 'Agile' is the norm for good development teams; when IBM's RTC has good support for Agile that means it's mainstream :-).  So, it's time to look beyond Agile - Dan talked about patterns that he observed in 'insanely productive' teams. I particularly liked 'Fits in my Head' - keeping design small or modular enough so that you can reason about the whole thing. I also liked his observation that OSGi done well is 'fantastic in this space'.

In the past I always wanted to go to Ted Neward's talks but somehow they always seemed to conflict with something else I had to do. So this time I went to the 'Busy Developers Guide to Scala' and the 'Busy Developers Guide to Gamification'. The Scala talk was perfect for me as I know nothing about Scala, the gamification one was a mystery. The thesis was that you can make work more fun by making it like playing games somehow. It may work if you like game playing but as a game-hating manual-reader it made no sense to me. However - looking round the room I think I may have been the only person that wasn't buying the idea.

Holly and Valentin (from the Apache Aries project) did a good review of the range of freely available OSGi tooling - the PAX stuff is particularly interesting. I also enjoyed Richard Nicholson's (Paremus) talk - 'Modularity meets the Cloud'.  Paremus are doing really interesting leading edge work, leading edge in the sense that they are getting to and solving problems before most of us realise they are problems.  Well worth having a look at their products if you are serious about OSGi. Neil Bartlett's OSGi live coding challenge was great too - a bit scary in places - but absolutely the best one of these that I've seen done for OSGi.

Chris Aniszczyk gave a beautifully constructed talk and demonstrated seamless integration of Git, Mylyn, Eclipse and Hudson (Jenkins or whatever).

Finally - Martijn Verburg gave the only talk on Java at JAX. Nice introduction to Java 7  - there are some pretty compelling new features, not headline stuff, but things that will make Java code smaller and tidier. For example being able to have strings in case, separate long numbers with underscores, better file IO features. Not exciting maybe but so important. Great to see the Java language catching up with PHP in terms of usability :-).


I hope JAX maintain this standard, I talked to many attendees in the breaks and everyone I spoke was both enjoying the conference and deriving value from it. Well done to the JAX team - keep it up!

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.

Oracle meet IBM at the LJCOpenConference

The LJC Open Conference last Saturday was the best! We had 75 people and a packed agenda with talks ranging from the "Java Roadmap" through to "The Diabolical Developer". Martijn Verburg, captured below, was the diabolical developer:

And he was, in fact, awesome...and very diabolical.

Steve Elliot from Oracle and Steve Poole IBM answered questions on their future together in Java:

It's still early days and the LJC organisers clearly thought it was prudent to separate the Steves with Martijn and Ben - although I'm not sure if they were worried about them getting too friendly or the reverse. Nice touch to have coordinated the names though - if you want become a contribute to the OpenJDK being called 'Steve' looks like a good first step.

Igor - have you watered the brains today, Igor?

In his keynote at ApacheCon 2010, Dana Blankenhorn noticed 'middle aged men dressed like college students' and then went on to liken us to the Knights of the Round Table.

I won't dispute the Camelot analogy - but I do want to take issue with  'middle aged men'. Middled aged is probably justifiable on average but it ignores the fact that there were a reasonable percentage of both old and young - and - no kidding - some of us are even female.

The youth were brought in by a wonderful organisation that I knew little about till earlier year - the Apache TAC . The TAC enables great programmers early in their career who are  unlikely to be able to get employers to sponsor their travel and even more unlikely to be able to pay for themselves get a chance to come along and participate. This is great for them but it's also very necessary for the future of the ASF a good dose of wild youth counters the tendency of these organisations to turn crumbly and nostalgic.

After the conference a few of us (including Igor of the blog title)  had to hang out in Atlanta for the weekend and ended up in Blind Willies, Atlanta's finest blues bar. We, Igor and I, danced till the early hours to the music of House Rocker Johnson. So in future I would like to suggest another question on the TAC form:

• Are you prepared to dance like nobody is watching?

Anyone who can't commit (without a reasonable excuse) should be consigned to the 'encroaching middle age bucket' and discarded.

By the way - for those of you who are almost certainly too young to recognise it - the title quote is a reference to 'The Monster Mash' from the 1969 Bonzo Dog album 'Tadpoles'.  I like the idea that younger delegates might inject a bit of life into the proceedings and don't intend to extend the analogy any further than that :-)

ApacheCon Atlanta

So that was my first ApacheCon - if you don't count the one in Dublin at which I drank far too much Guiness and decided on a career change which took me on a slightly circuitous route through  PHP  and back to Apache again.

It was a pretty amazing conference all round - great to meet Lin Sun, Jarek Gawor, Kevan Miller and others from IBM. Also great to meet new Apache people  - and catch up with the ones I already knew.

AWESOME that IBM is a gold sponsor of the ASF - well done whoever made that happen!

As usual I learned a lot about technology - Kevan had a nice slide explaining which other Apache projects are used in Geronimo - I had no idea.  I do like this philosophy - no need to re-invent wheels when there are Apache projects which provide spokes, hubs, rims and tyres.

Send your developers to JAX!

Last month I, and a number of developers from IBM's Hursley labs, went to JAX London; I'm delighted to say that we were a gold sponsor this year. I was going to write about the conference before but sadly I didn't get to see (m)any of the sessions because I was responsible for  the IBM demo area and spent most of my time talking to people about what IBM does with OSGi.

In between talking to people, my view of the conference was mainly looking at the other sponsor's stands. So, here are some observations based on what I saw:

1. This is a great UK conference to sponsor if you want to reach Java developers.
2. The busiest stands were the ones that had tools demos and/or were able to sell interesting stories about  work that they were involved in - or they were hiring :-)

If you are going to sponsor a developer conference, which I strongly recommend,  send your developers to run the stand....or at least your tech sales people. Don't send the salesmen. Seriously, no-one will walk away from this conference with a bunch of orders - you won't close a sale here. The aim is inspire people with a vision of how working with you and your products will make their life easier, more profitable and more fun (in a tech sort of way) - that message will get back to the people with hard cash. Trust me.

Here's my favourite image  from the conference - taken at about 19:00 by a slightly wobbly photographer - I have appropriated the Microsft stand - which was looking a little lonely.

By the way, I am a recovering Windows user - I've been free for nearly three years now, so it took me several beers to get this close....

Testing bundles with PAX Exam

For integration testing OSGi bundles there is pretty much only one option - it's PAX Exam.  This week, as part of preparing a talk for ApacheCon I decided I wanted to have a simple 'HelloWorld' test showing the use of PAX Exam. It was all pretty straightforward - except for one thing that took hours to resolve - I thought the one thing might be worth mentioning.

I use Maven to build with, the application I was trying to write a test for was a stand alone version of this OSGi Blueprint Hello World sample. The application is pretty trivial and so is the test case. I used Craig Walls' tutorial to get me started.


So, what was the problem? This was what happened when I ran 'mvn install' in my test project in an attempt to run my test case:

I had no idea why anything was looking for com/sun/jdmk/jmxtools/1.2.1/jmxtools-1.2.1.jar, it certainly wasn't something I'd specified as a dependency in the project pom. Eventually, after much searching around, I looked at the Apache Aries default-parent pom and noted that some 'exclusions' had been added to the pax-logging section. I copied the same exclusions into my test project's pom and everything just worked.  The relevant sections of the pom are highlighted below:

Hope this helps - apart from that small problem I really like PAX Exam :-)