Last Friday’s flight back to Boston ended a crazy string of travel – a different European city each week of June. I will post some photos soon. I am really glad that’s over!
Last week’s OSGi Enterprise Expert Group (EEG) meeting in Munich went very well, making a fitting end to the crazy travel period, and giving me some idea that it was all worthwhile… Certainly last week’s trip was.
The EEG meeting was held the day after the OSGi Community Event, which illustrated pretty well the growing interest in OSGi. Lots of great presentations, good information, and very interesting people in attendance.
(Here’s a good summary, from someone with a home automation perspective – which was actually the original purpose of OSGi. You can see the top of my head behind Peter Kriens in the third photo .
During my presentation on the EEG I summarized where we are in the process, listed the RFPs we’ve received, and tried to highlight some of the discussion points. More about that in a moment.
First, I am very glad to say that during the EEG meeting we successfully passed from the requirements phase into the design phase, with the recommended approval of seven of the 11 RFPs under discussion (two of the 13 mentioned in the presentation have been referred to the management EG).
So now the real fun can begin! We can debate whether or not mapping existing enterprise technologies onto OSGi is sufficient. We can, in the words of a community event participant, ascertain whether or not any of the current “failed” distributed computing models should be adopted, or whether anything new may be needed.
In general, it looks like the EEG will be spending a lot of time on mapping existing technologies to OSGi, and drawing requirements from those mappings to potentially extend and enhance Release 4. These include Spring, lot of parts of JEE, SCA, and some existing enterprise technologies (CORBA, Tuxedo, Tibco, WebSphere MQ, Web services, etc.), at least for interworking, and probably JBI as well (some interest already expressed here – may need to be formalized). Many, if not all, of the original requirements coming out of the initial workshop and refined in subsequent meetings, may be met this way.
However, OSGi already has a well-documented and widely used programming model based around services. Peter Kriens and BJ Hargrave gave a great “best practices” presentation — they said they also gave it at Java One — that illustrates the benefits of this programming model pretty well.
Some are suggesting – including me – that the OSGi programming model can be very simply and minimally extended to meet some of the very basic enterprise requirements, such as access to a remote OSGi service (deployed in a remote JVM), or interworking with existing enterprise technologies. OSGi developers should not have to learn another API and/or programming model in order to accomplish some simple, but important, enterprise tasks.
To be very clear, this is a point of current discussion within the EEG. Nothing has been decided. We are just starting the design stage. As co-chairs it will be our responsibility to bring these discussions to closure through consensus (hopefully!) or vote (if necessary) in the upcoming meetings.
One very interesting point is raised in one of the RFPs (for security enhancements), which already recognizes in its requiements statements the need for vendor supplied and user developed code to co-exist in the same OSGi deployment (and to maintain security of course). If you accept this view – and this does seem likely – the cat is already out of the bag (i.e. people are already using the OSGi programming model and will want to continue).
Imagine a situation sometime in the future in which an enterprise developer can develop basic services using OSGi by itself, and, as required, configures in parts of other technologies such as JEE (security, transactions, JNDI, JCA?), SCA (components, composites, wires, policies?), JBI (deployment container for BPEL?), Spring (well, this actually may not be the same kind of thing since the Spring RFP basically marries OSGi and Spring configuration), and external systems (CORBA/IIOP, WebSphere MQ, Tuxedo?). This could create an envioronment in which developers do not have to choose upfront among these various “competing” enterprise technologies and programming models, but instead can think about using them when and as necessary in a kind of continuum.
By the way, whenever anyone mentions the idea that OSGi might be extended for distributed computing, some number of people seem to automatically jump to the conclusion that we mean “doing everything” and if we “do anything we’ll be forced to do everything” i.e. define an entirely new distributed computing approach, new communication protocol, new data serialization format, etc.
I can assure you that this is not at all the case. The EEG has progressed carefully and cautiously from the beginning, focusing on gathering and refining requirements. And we will continue to progress carefully during the design phase, evaluating proposed solutions against those requirements. Let the fun begin!