BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Eric Newcomer on the future of OSGi

Eric Newcomer on the future of OSGi

This item in japanese

Bookmarks

Eric Newcomer is the CTO of IONA Technologies. He's had a long and distinguished career, spanning time at DEC, writing one of the Distributed Transaction "bibles", several best selling books on Web Services and participating in many of the important Web Services specifications and standards, such as WS-CAF and WS-TX. Eric is now co-chair of the OSGi Enterprise Expert Working Group and agreed to talk to us about OSGi, Java and ESB."

Mark Little (ML): Hi Eric. Can you give us a bit of background about yourself and your relationship to OSGi?

Eric Newcomer (EN): We had looked into OSGi a couple of years ago as a potential solution for delivering applications to mobile devices, but didn't really do anything with it.

Last summer I received an invitation for IONA to attend the OSGi Enterprise Workshop on September 11, 2006. I believe I actually tried to find someone else to attend since it was the Monday following my vacation, and couldn't, so I ended up attending. One thing led to another – I recommended that IONA join OSGi to participate in the Enterprise Expert Group and I volunteered to co-chair it.

It seemed like an enterprise edition of OSGi had the potential to be really important to the industry, given the requirements presented at the Workshop, and I felt IONA could make a strong contribution to it.

ML: OSGi has been around for quite a while, but it's only recently that it seems to have received a lot of attention. Why do you think that is the case?

EN: What really got OSGi into the spotlight was Eclipse. And I think that's still probably how most people would know about OSGi – the Eclipse platform is an implementation of OSGi, and every Eclipse plug in that you download and install uses OSGi behind the scenes.

But I would say it's been more than that – OSGi has a simple service programming model that fits with the current trend toward service orientation, and supports dynamic deployment, something that is growing increasingly attractive in enterprise IT environments.

ML: What's IONAs interest in OSGi?

EN: We are looking at OSGi the same way many other vendors are looking at it, as an enabling technology for dividing up a large software project and deploying the results.

But we are also interested in the potential of the OSGi programming model for meeting basic enterprise IT requirements. We think of it as a deployment platform, programming model, and runtime with significant potential for improving SOA based applications, and the potential to create an important vendor eco-system around runtimes the way the Eclipse platform has created an eco-system around tools.

It seems clear that the industry is ready for a lightweight alternative to JEE, and we are already seeing significant interest in the marriage of Spring and OSGi in this area for example.

The infrastructure requirements for SOA are different than the requirements that drove the creation of infrastructure products such as JEE application servers and EAI brokers – SOA needs something more lightweight, something that represents more of an improvement or refinement than something entirely new. OSGi seemed to have a lot of potential in this area.

ML: ESBs have been evolving for a number of years and yet all of a sudden most of the popular implementations have started to look at OSGi in one way or another. Do you think OSGi and ESB are a good match?

EN: Absolutely. First of all there's the development and deployment aspect of OSGi, in which ESBs can be developed, deployed, and enhanced using OSGi services and bundles. This should help speed time to market for new ESB features and functions, and improve manageability of ESB deployments. Second there's the OSGi programming model, which has the potential to create a standard interface for accessing ESB functionality from a Java container. Ultimately I believe we are looking at the possibility of OSGi enabling a ‘best of breed' style approach to the ESB market, in which OSGi becomes the "platform" for the ESB and vendors develop OSGi bundles to plug in. In fact I'd go farther and say OSGi is a good match for SOA infrastructure in general, and we are seeing this come up in places such as JBI V2 and the proposal for the Eclipse SOA runtime project.

ML: How is the work within the OSGi committee progressing?

EN: At the June 28 meeting in Munich we passed from the initial requirements phase into the design phase, which I keep saying means the fun will really begin.

As anyone who's worked in multiple organizations knows, each one has its own unique approach and process. The OSGi process starts with a formalization of requirements into RFPs (Request for Proposal) and then once some number of RFPs are approved by the Requirements Committee, the Expert Group members can start creating RFCs (Request for Comment), which are the design documents identifying proposed solutions to the requirements. After that (or perhaps concurrently) EG members can develop a reference implementation and then someone (preferably not the same people as those coding the RI) develop the conformance test. A specification is only complete once there's an RI and a conformance test. So we are still relatively at the beginning of the process, but making good progress.

At the Enterprise Workshop last September ( announcement: http://www.osgi.org/news_events/osgi_workshop_091106.asp, results: http://www2.osgi.org/EnterpriseWorkshop/HomePage) initial requirements were gathered and prioritized (http://www2.osgi.org/EnterpriseWorkshop/Requirements). The EEG was created in December by the OSGi Board, and held its initial meeting at the end of January in Dublin, Ireland. At that time several "workstreams" were identified. Leaders were assigned to the various workstreams and from that the 13 or so current RFPs were created. A couple of weeks ago the EEG voted to submit seven of the RFPs for approval, so with that we are effectively starting on the design stage.

Based on the RFPs submitted we will be spending a lot of time figuring out how to map existing enterprise technologies onto OSGi, such as Spring, SCA, JEE, JBI, Web services, and perhaps others.

ML: What fundamental changes can we expect to see around OSGi in the next year or so?

EN: I don't think we'll see any fundamental changes. I think what we are looking at is a range of potential extensions to existing capabilities in order to meet enterprise requirements. Anyone familiar with OSGi knows that it has its origins in the embedded space, first for home automation and then for automotive automation and mobile phone application management. So the question naturally comes up, when evaluating requirements for an enterprise edition of OSGi, whether it can be the same OSGi as the embedded edition or whether something else is needed. This always brings up the comparison with J2ME, J2SE, and J2EE (I guess these are all just JME, JSE, and JEE now since we are well past Java 2). But so far the answer is that we are definitely not going to be doing this with OSGi. The native OSGi mechanisms will be used to extend and enhance OSGi to meet the new requirements for use in enterprise IT environments, but the core OSGi will not change.

The extensions that we'll be looking at are based on the RFPs that have been submitted, such as a better mapping of JEE components such as JNDI, JDBC, and RMI, including object serialization, improved Web application support, improved security to support deploying user code and vendor supplied code in the same JVM, how to access external systems from within OSGi (and vice versa), and how to discover services that might be deployed in a remote OSGi environment.

ML: Some people have said that Sun should adopt OSGi as the container of choice for EE7. What do you think?

EN: Absolutely, would make all the sense in the world. The bigger question is around the future of Java, and whether or not Sun will embrace OSGi or continue to fight it, and if they do continue to fight OSGi what impact that will have on Java. From my recent and somewhat limited experience with OSGi it seems that it significantly improves Java in many ways – modularity, versioning, improved class loading.

Sun voted against JSR 291, which passed anyway, making OSGi officially part of JSE. But that gives some indication of Sun's view. Sun has also proposed JSR 277, for Java modularity, which appears to significantly overlap with OSGi. Sun has a great opportunity to embrace OSGi and base Java 7 on it, but even though there is no official statement it seems that they are leaning in the direction of overlapping rather than embracing OSGi.

I hope Sun comes to their senses about OSGi sooner rather than later. On the other hand, perhaps it would be better if Sun continues to oppose OSGi, since things have gone well for OSGi so far.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • What is it with OSGi advocates

    by William Smith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Sun and the members of the JCP are making a huge effort to ensure that it is compatible with OSGi, OSGi will support 277 (after all, 277 has 2 OSGi people on it). But it would be quite wrong for Sun to favour one vednor solution (OSGi) over all the others (Maven, Ivy, etc).

    JSR-277 is a good thing for OSGi. It makes life easier from a JDK perspective for it and the other competing solutions. Bundles/modules become first class citizens on the JVM level. Beyond that, it’s up to the framework (OSGi or whatever else) to provide any value-add stuff they want to. 277 does not limit that. OSGi will offer proprietary extensions on top of the basic spec just like everything else in vendor land. So why do the OSGi people jump up and down all the time.

    It would be rather like if the JBOSS folks were constantly attacking JPA because it didn't solely support hibernate.

  • Re: What is it with OSGi advocates

    by Andrew Perepelytsya,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    They attack JSR 277 not because it's coming from a JCP, but rather because the spec group blatantly ignored an 8-year experience OSGi brought us, and naively approached the problem with a "don't tell us how to do it, we know better" approach.

    Isn't it the core idea of JCP to embrace industry experience and not reinvent a squared wheel?

  • Re: What is it with OSGi advocates

    by William Smith,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I still don't get what the issue is.

    Members of the JSR-277 expert group include two .NET experts, two OSGi experts who co-authored the R4 modularity spec, Maven's creator and Ivy's creator. Sonds like "embracing industry experience" to me, and exactly what the JCP is supposed to do.

  • Re: What is it with OSGi advocates

    by Neil Bartlett,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    William,

    Take a look at the expert group mailing list for JSR 277, which is now open to the public (albeit read-only). Having done so, it's really hard to see that the two OSGi experts (Glyn Normington and Richard Hall) are being listened to. It's certainly not from a lack of effort on their behalf. There are numerous areas in the JSR 277 draft spec and the current strawman which are irreconcilable with OSGi: Sun is willfully refusing to learn any lessons from the experiences of OSGi/JSR 291.

    OSGi people are not simply complaining because our favourite module system has not been chosen. That would be childish. The principle reason that we are making so much noise is that JSR 277 is heading towards failure as a module system! It will be hugely damaging to the entire Java community to have a broken module system baked into the JVM.

    I would really like JSR 277 to be a success, but I believe that it should build on OSGi rather than compete with it. Competing APIs are great in some areas (e.g. GUI libraries or XML parsers) but the module system of the platform is not one of those areas. Can you think any other language or platform that has multiple competing module systems?

    Neil.

  • Re: What is it with OSGi advocates

    by Eric Newcomer,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    By this logic OSGi should be encouraged to recruit JEE experts and define a better alternative to EJB.

  • Re: What is it with OSGi advocates

    by Mark Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Plus it's wrong to say that "... t would be quite wrong for Sun to favour one vednor solution ..." Have you looked at who's involved with OSGi? Last time I looked it was more than a single vendor! With the exception of Sun, I think all of the usual major JEE suspects are there.

  • Re: What is it with OSGi advocates

    by Gerard Janssen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    That's right! Without wanting to oversimplify the issue here. It seems like yet another round of Sun playing the "not invented here" game. Ever since I got acquainted with OSGi it seemed to me like it had solved so many questions of component models, component dependency checking, deployment and upgradeability that most appserver vendors have not yet solved properly and that the official jee standards are not even touching at all.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT