Category Archives: OSGi

Maybe IBM wants control of Java

The hot topic of debate today is the breaking news story that IBM is in talks to acquire Sun. Dana Gardner doubts this, and a bunch of myFB and Twitter friends ask the obvious questions in their status updates: Why the heck would IBM want to do this?  

I haven’t seen anyone yet bring up the Java question.  As co-chair of the OSGi EEG and formerly 9-year employee of a Java vendor, I have seen the battles between Sun and IBM over the control of the Java langauge up close.  It has never been a pretty picture.

Recently I was asked about Jonathan Schwartz’s blog entries about Sun’s future direction and corporate strategy. The content of these entries has been subject to the usual praise and criticism, but I haven’t seen anyone talk about what’s so obviously and painfully missing – at least for someone active in the Java community and trying to push the ball forward (e.g. enterprise OSGi). Where is the talk about leading the Java community? Where is the talk about collaboration with IBM, Oracle, Progress, Tibco, and others? Where is the description of how helpful Sun is toward Apache’s Java projects (especially Harmony)?

IBM has ported many products onto the OSGi framework during the past several years, including flagship products such as WebSphere Application Server and Lotus Notes. Never mind the fragmentation in the Java community caused by the disagreement over SCA.  What about Sun’s recent announcement that they were going to reinvent Java modularity in the Open JDK project, all on their own, without input, without regard to what happens to OSGi?  What kind of potential change cost does that represent to IBM and all the other Java vendors who have ported products onto OSGi?

The potential acquisition of Sun has been debated so far mostly in terms of the business value Sun has – that is, in the context of where it is still making money, as if that were the main or only reason for an acquisition. But I say again, what about the unrealized potential for collaborative leadership in the Java community? Sun obviously isn’t paying attention to this, but  IBM might be.

Advertisements

Perspective on OSGi for the Enterprise

I once heard an OSGi guy from BEA (now Oracle) say that everyone thinks about OSGi for its deployment capabilities, but the real power is in its service model.

I have mentioned this controversy before, i.e. whether or not the OSGi programming model is likely to become widely adopted in the enterprise. To a large extent this may well depend on how well the EEG does its job. This is one topic I’m hoping to explore during next week’s meeting, i.e., which scenarios the release is good for, and which it isn’t.

I have also mentioned before that one of the current work items for the OSGi enterprise expert group is adapting various Java EE components to the OSGi Framework. The first priority is to ensure that the components work as they did before, i.e. as if the OSGi Framework were irrelevant. This is the deployment capability, where the OSGi Framework (and by this I mean one of the various implementations of the current specification) is used only to host the application. Such an application could equally be deployed on Tomcat, or a Java EE compliant application server. For this scenario, the EEG work is pretty straightforward. We just have to make sure nothing is broken.

To enable the service model, however the work to map the Java EE components is quite different. For example, perhaps you want to create an OSGi service that uses a Web app as a service, or a JTA-managed transaction as a service. Let’s say you want to use JNDI to discover an OSGi service, etc. This will take some effort, and we are running short on time. A critical evaluation point for the enterprise release therefore is whether or not the Java EE components we’re mapping are sufficient and/or appropriate.

A recent EEG vote approved four of the design documents in progress (early drafts) to move to the specification (and final) stage: the Blueprint model (based on Spring dm), Distributed OSGi (which I’ve written about before), JTA, and JMX. Is this enough? Well, perhaps it is for some applications – and probably not for others. What else is needed? JNDI? JPA? JDBC? Web apps?

One great thing about the OSGi standardization process is that it starts by gathering requirements – in fact the initial requirements gathering exercise is what led to the OSGi Board’s decision to charter the EEG in the first place. And for any work item pulled from the initial requirements list, the first job was to refine and document the requirements in sufficient detail to create move to the design stage.

Implementations based on the current version of the OSGi specifications seems to gaining momentum: in addition to the several hundred IBM products (I have heard from different IBM sources that the number is between 200 and 300) currently deployed on OSGi, and the plans of all application server vendors to support OSGi based deployments, open source ESBs such as ServiceMix4, OpenESB (BTW this pointer was harder to find than I expected, I am wondering whether pre Project Jigsaw they had more top level info on OSGi?), Carbon, and Mule also support OSGi, or plan to (actually among these it seems Mule is alone in not yet supporting OSGi). And perhaps more interestingly, the Spring dm Server and ServiceMix4 support developers interested in using the OSGi programming model.

Mainly, I think that the enterprise release of OSGi should be about creating enterprise Java applications as a collection of OSGi services. But is the industry really ready to move past the deployment only stage?

Early indications point in the right direction, but I suppose we will have to wait for next year to really find out for sure.

Sun and OSGi: Cooperation through competition

Last week I attended my last OSGi Board meeting, which was hosted by SAP near Heidelberg. Although I’ll remain EEG co-chair, Gordon is replacing me on the board.

As you might imagine, one of the hot discussion items was Sun’s recent announcement of Project Jigsaw, their latest modularity initiative. Hal, Mirko, Peter, and Neil have already recorded their thoughts in their blogs, and I don’t want to repeat what they’ve already said.

One way I like to sum it up is that it wasn’t the breakthrough we were hoping for. After Sun rejoined the OSGi Alliance last year, and announced they were using OSGi in Glassfish, OpenESB, and ProjectFuji – not to mention hiring the Apache Felix project lead – many of us started thinking Sun might finally bury the hatchet. But no, Sun has apparently decided to cooperate with us by competing with us.

We knew, of course, that Sun is kind of schizo about OSGi. I did my best to encourage them to participate in the EEG, and after Sun hired Richard, I guess you could say that sort of happened. But he still is primarily focused on Felix, which is understandable. We have not seen or heard anything from Mark Reinhold and his colleagues, however.

And now we have to worry about the confusion Sun’s announcement creates. I can’t see the customer or the industry benefit in having to choose between two modularity systems. Do we really expect all the vendors that are currently shipping hundreds of products on the OSGi Framework, to invest in supporting an additional modularity framework for their products, just because Sun proposes it? Yet it is certain to raise questions and generate debate, just as the end is in sight for the OSGi enterprise release.

We have released an updated draft (warning: this is a pdf link) of the current design documents. Several of these have been submitted to expert group vote so that the final phase can begin – writing the specifications. (BTW it’s not too late for comments and feedback on the updated drafts.)

You may know that the OSGi Alliance is unique (at least among standards consortia I’ve worked with) in hiring someone to write all the specifications (Peter Kriens, of course). I think this is one of the reasons the OSGi specifications are so good – and because Peter has been with OSGi since the beginning, he can ensure continuity and consistency.

With any luck, we will be more or less done by March, 2009. I am not exactly sure what the bits and pieces of designs we have add up to yet – I think one of the major work items (in significance if not effort) is to check the current designs against the original requirements, and against several scenarios people are likely to want to use OSGi technology for in the enterprise – such as building web applications, distributing an application’s processing work, or managing persistent data.

I want to be sure the release adds up to something, and that it will have the best chance at being adopted. This was, of course, another important discussion item during last week’s Board meeting: getting the enterprise release out and ensuring its success.

For me one of the big factors has always been, and still is, whether or not enterprise developers will adopt the OSGi programming model. I am optimistic.

OSGi for the Enterprise Gets a Bit Closer & LinkedIn Too

Last week at IBM Montpellier the upcoming OSGi 4.2 release got a bit closer, and Yan Pujante presented LinkedIn’s requirements.

Peter can’t believe what Yan is saying… !

In the now usual pattern for a two-day expert group face to face, the first day was given to the core platform expert group (CPEG) and the second day to the enterprise expert group (EEG).

Neither can the rest of us…!

The work to produce the enterprise edition of the OSGi specifications is roughly divided between these two groups, based on whether a particular work item changes the core platform framework itself (CPEG), or to extends the core platform with new features (EEG).

The goal is to complete work on R4.2 in time to deliver compliant software in the Eclipse Ganymede release, scheduled for June 2009. This is because the Eclipse platform, Equinox, is currently the reference implementation of OSGi. However, we have had good participation in the meetings from the other platform providers, including Apache Felix, Prosyst, and sometimes Makewave. It is looking tight, but do-able. And we made some good progress Wed-Thurs last week.

Since I’m EEG co-chair I’ll concentrate on that from here on. During Thursday’s meeting we pretty much closed out the major design documents: Blueprint Component Model (Spring-“inspired”) and Distributed OSGi. The Blueprint, aka Spring/DM (see discussion here) and is nearly complete, just working on the final collection of bugs, most of which have been submitted by Rick McGuire of the Apache Geronimo team, who’s developing the conformance test suite (TCK). SpringSource is providing the reference implementation, which has been available for some time in the Spring-DM project.

Needless to say, the Spring mapping document, aka RFC 124 (see Adrian’s excellent summary for what it means) is probably the most important work item for the EEG.

Next is probably the Distributed OSGi document, aka RFC 119, which defines extensions for configuring OSGi services to communicate remotely using existing distributed software systems. The RI we recently demo’d for this is hosted at Apache CXF, and David Bosschaert recently posted a Spring-DM update for it. Tibco is working on the TCK, so we are in pretty good shape overall now.

During the afternoon, Yan presented LinkedIn’s view of OSGi, including information about their requirements for using it in their next-generation platform. Jan drew pictures on the whiteboard, and used bits of this slideshow. Their major interests are improving the modularity of their applications, and updating them more easily and dynamically. It’s great to have a user company participate in the meetings – we could actually use more and I hope more will consider joining.

LinkedIn’s Distributed OSGi design

After Yan’s presentation we focused on the Java EE mapping work, which has progressed intermittently throughout the past couple of years. It was always a goal of enterprise OSGi to include components of Java EE, but it was not always easy getting everyone to focus on the work and agree on a direction. At the Board meeting in June however, the Java EE work was identified as a priority for the release, and since then we we have been more focused on it and are starting to get somewhere, although significant work remains.

After discussing the topic with others, I believe the priorities are improving the support for Web applications, and for mapping JNDI, JPA, and JDBC. The design docs are in pretty good shape for JTA and JMX, so those are ok. It will be tight, but it looks like we have the right people assigned from Oracle, IBM, and SpringSource to make it happen. Maybe security is also needed…?

Of course, it’s easy for me to say the design docs are in pretty good shape now, and that several from CPEG and a few from EEG are ready to move into the formal specification phase, but Peter Kriens actually has to write the specs now, and we will have to see how he gets along…

Place de la Comedie, Montpellier (Peter’s home town 😉

ps on the drive back to the airport, I took a brief detour to Arles, and toured the old Roman town, including the collesium, which is still used, apparently for bullfights (not Christians and lions anymore..)

Find your seat

No bulls today

Inside the collesium walls

Early Draft OSGi V4.2 Docs Available

As of this week you can download an early release draft document containing 11 design documents we’ve been working on for the past year or so as the result of the OSGi enterprise initiative.

This is important because according to OSGi Alliance rules, only members are allowed access to working drafts of documents. This is the first time we’ve released any of these drafts publicly. As a board member and EEG co-chair, I’m very pleased to see this happen because (a) I often get asked about what’s going on and why we can’t (in this age of open source) release details of what we’re doing and (b) I’m very interested in feedback from the broader OSGi community.

The enterprise edition activity started in January, 2007 with a review of requirements gathered at the enterprise workshop event. Following the OSGi Alliance process, the newly formed enterprise expert group members began writing Request for Proposal (RFP) documents. After an RFP on a particular topic is formally accepted, members can begin writing the Request for Comments (RFC) documents to design solutions to one or more of the RFPs. The early draft contains some of the RFCs that are far enough along to be released – in fact this represents a majority of current work items.

One major work item that is not far enough along, BTW, is the Java EE mapping to OSGi. (Not that I’m trying to put any pressure on any of the members of the group to hurry up and finish their work or anything 😉

The draft is divided into two major sections, like the work: Core and Enterprise (reflecting requirements taken on by the CPEG and EEG, respectively), pretty much (but not strictly) depending on whether the RFC affects the core, or something mapped to the core.

From here, the RFPs (which I call the design docs) are fed into the formal specification drafting process. So it is a great time to submit your comments (please be sure review the feedback form before you do – this basically defines the IP protections and rights involved).

Of course I am particularly interested in any feedback you may have on the distibuted OSGi document (RFC 119), but you may also be interested in:

  • the Spring-DM inspired component model design (RFC 124)
  • or some of the proposed security enhancements (RFC 120)
  • the new command line capability (RFC 132)
  • the new service registry hooks (RFC 126)
  • the bundle tracker (RFCs 121 and 125)
  • transaction support (RFC 98)
  • or the DS updates (RFC 134)

It’s almost 300 pages, but there’s some good stuff there, and 18 months into the task, I think we have a pretty good handle on some things. But then again, maybe not…

The big new areas of course are the distributed OSGi and the “Spring-inspired” component model. And of course, as always, I am very interested in any comments or feedback about the suitability of the OSGi programming model for the enterprise, especially given some of these proposed enhancements.

First Ever Demo of Distributed OSGi

Yesterday David Bosschaert and I gave the first demo of the new design for distributed OSGi, based on the current draft of the Enterprise Expert Group’s RFC 119, at the OSGi Community Event in Berlin.

Download PDF of Demo Overview

OSGiBerlin0001.JPG

“Demo Dolly” David Explains Distributed OSGi Demo

The goal of distributed OSGi is to extend the OSGi framework for distributed computing capabilities by configuring an existing distributed computing software system (such as Web services, CORBA, or Eclipse ECF) behind an OSGi service. The demo showed a Web services solution using Apache CXF as the distribution software, but the design should work with any distributed computing system.

The demo used Apache Felix for the OSGi framework and shows the configuration and publication of a remote OSGi service and uses CXF facilities to generate a WSDL file and consumer and provider proxies for the service.

The goal of distributed OSGi is to allow a service running in one OSGi framework to invoke a service running in another, potentially remote, OSGi framework (meaning a framework in a JVM). Today the OSGi standard defines how services talk to each other only within a single JVM. Extensions are needed to allow services to talk with each other across multiple JVMs – thus the requirements for distributed OSGi on which the design is based.

We did not want to invent a new distributed computing system, since so many already exist. (In fact we had pretty strong feedback on that point!) The design introduces some new OSGi properties to identify a service as remote and a discovery service through which a local service can find a remote service and obtain the metadata necessary to interact with that remote service. The design is intended to support any communication protocol and data format (with some constraints of course, having to do with the use of Java request/response interfaces as the service contract). Another goal of the design is to allow services in an OSGi framework to interact with services external to OSGi, both as client and server.

The design uses SCA intents to express a service’s capabilities, and a requester can use these intents as a filter to help discover services with the required capabilities (e.g. security or reliability).

Overall we recieved good feedback, and a lot of questions pertaining to work that still needs to be done. We hope to be able to publish the code to Apache and publish a draft of the design doc this summer, perhaps in August, after we have a chance to formally review the initial implementation with the EEG membership, and get their blessing (no doubt there will be some changes as well since this is just the start).

OSGi Community Event June 11-12

I’m sorry to post this so late, but hopefully it’s not too late to join the fun, especially if you’re in Europe.

The OSGi Community Event is next week, June 11-12, hosted by Deutsche Telekom in Berlin.

There are a lot of interesting topics and speakers on the program, running the gamut from enterprise application servers and databases, to distributed computing, to converting legacy code to OSGi, home automation, trains, telecommunications, embedded applications for mobile devices, etc.

David Bosscheart and I will be giving a demonstration of the first prototype of the RI for distributed OSGi (I have previously blogged about this part of the EEG activity), which together with Spring Dynamic Modules represents one of the big features for the upcoming Enterprise Edition.

Hope to see you there!