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.
真正讓OSGI引起關(guān)注的是Eclipse,我覺(jué)得很多人對(duì)OSGI的認(rèn)識(shí)還只是停留在這個(gè)層次 － Eclipse平臺(tái)是一個(gè)OSGI的實(shí)現(xiàn)，并且下載和安裝的每一個(gè)Eclipse plug實(shí)際上都使用了OSGI。
不過(guò)我想說(shuō)這些認(rèn)識(shí)是不夠的 － OSGI有一個(gè)簡(jiǎn)單的服務(wù)編程模塊，這個(gè)模塊適應(yīng)了當(dāng)前面向服務(wù)編程的趨勢(shì)，并且支持動(dòng)態(tài)部署，這些功能在企業(yè)級(jí)IT環(huán)境中會(huì)越來(lái)越被人們重視。

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?

ML：有人認(rèn)為Sun應(yīng)該選擇OSGI做為JEE7(java 7.0)的容器，你對(duì)此有何看法？

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是否接受OSGI甚至發(fā)展到與之對(duì)立，如果是這樣，那么這個(gè)沖突將會(huì)給java帶來(lái)什么？這是一個(gè)值得思考的問(wèn)題。就我自己對(duì)OSGI的認(rèn)識(shí)看來(lái)，OSGI會(huì)對(duì)JAVA帶來(lái)很多進(jìn)步，例如模塊化，版本控制和類加載等。

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.