Eclipse Equinox - Fulfilling the Promise of Write Once Run Anywhere
The major announcement this week at EclipseCon surrounds Equinox becoming a top level project. Just before the conference I caught up with two of the leading people in the Eclipse community to discuss this announcement and what it means.
Ian Skerrett is Director of Marketing for the Eclipse Foundation, and a regular contributor to Eclipse Zone. Jeff McAffer is Equinox Project Lead, leads the RCP project and is one of the original architects of Eclipse.
The timing of the announcement is interesting – a buzz has been slowly building around OSGi. At the end of December and early January, JavaLobby, InfoQ and developer forums have been talking about Equinox and OSGi. It’s a good indication that people are starting to do this now, and that they see this as a better way of programming.
You can find out more about Equinox and OSGi right now at the newly launched portal.
James: What is the main message that Eclipse want to send out with this announcement?
Ian: The key thing is that Eclipse is serious about runtimes, but we find that lots of people are still stuck on thinking Eclipse is a Java IDE, or a developer toolset. Specifically, Eclipse has progressed well beyond being developer tools. This initiative proves how much Eclipse has evolved as a platform enabling runtime technology.
To organise ourselves and get some momentum around this, a top level project has been created with a broad base community involvment behind the project. We're going to launch a community effort to drive the adoption of the Equinox runtime.
James: What is the problem that Equinox is trying to solve? What are the issues that need to be addressed?
Ian: Building applications these days requires a new approach. Right now, there's really no one component model that allows a consistent approach across tiers and platforms.
Microsoft have a component model consistent across tiers, once the platform defined is a Microsoft platform.
In Java we have SE (Standard Edition) and ME (Micro Edition) and EE (Enterprise Edition). These all require different models. It's portable, but not properly consistent. Infrastructure technology needs to be a lot more adaptable.
From a business view, companies are starting to become much more agile, and want to get new things out the door faster. The whole point here is one of integration. In many ways Eclipse from a tools development platform solved the integration of developer tools.
The same type of problem exists in the general software market, where companies want to integrate their third party customers into their platforms but to do so they need an integration mechanism. People are reinventing their own ways of doing this and as a result we miss out on cross pollination between platforms. Driving for a consistent integration mechanism for third party integration is important.
James: Do Microsoft have anything equivalent to the Equinox approach?
Jeff: Microsoft have done a good job of defining a consistent programming model for Windows Mobile, Vista and the Microsoft server environment. But it doesn't go to other platforms like Linux, Symbian or other operating systems.
James: Is there anything "in competition" with Equinox in the Java space?
Jeff: From a JCP perspective, JSR 291 defines a dynamic component model, which is basically the OSGi specification. There's also JSR 277, the Java Module System, which develops a component model for Java, being lead by Sun.
Sun has aspirations to do something in this space, but have a way to go to make it a reality.. There's nothing produced yet for public consumption.
Equinox is the reference implementation of JSR 291, and one of Equinox co-leads, Tom Watson, is the spec lead for JSR 291. JSR 291 is a good thing as it covers OSGi in JavaSE. There's also JSR232 for OSGi in ME space. The reason for different JSRs is that in the JCP even if the technology is the same, there needs to be a different JSR for each of SE,ME and EE.
JSR 232 has been around for a long time, with IBM and Nokia leading. IBM leads JSR 291 and that has been finalized and voted on. So we are very much in favour of 291,very much supportive of it, and did a lot of work on making it happen and revising the OSGi spec to make it suitable to make it work in JavaSE.
James: Would it be true to say Equinox is OSGi for Java?
Jeff: It would be unfair, as there are 3 or 4 open source implementations for OSGi. If you went to OSGi.org, got Release 4, and requested the reference implementation for R4, you'd be pointed to Equinox. There's also Apache Felix, and Knopplerfish and then there's Concierge which is just an R3 implementation. Knopplerfish passes the R4 compliance tests, while Felix doesn't pass these tests. Equinox is far and away the commercial choice for industrial applications and enterprises.
But it would be unfair if people characterised Equinox as OSGi.
Ian: OSGi is a standard and specification, and Equinox is the best implementation of that standard. It's the most widely deployed and used implementation of OSGi.
James: Do you think that after seeing the extra visibility that Equinox gets that other implementors from Felix, and Knopplerfish will join Equinox to make one great implementation?
Jeff: When Felix started we had this conversation about why are we having 3 OSGi OS communities, why don't we all work together. At that time, it was decided that Felix would continue, as diversity is a good thing. It does fragment the efforts a little bit, but the change in poisiton for Equinox won't cause anyone to abandon another community.
Ian: There's good relationships and technical respect for the different groups
Jeff: Sure. The guy who leads Felix, Richard Hall, and some of the Equinox leadership Tom Watson, and myself, participate in the OSGi spec setting. We’re also involved in the expert groups in OSGi, and talk about the tech problems and implement solutions and designs to the different issues. We end up with a better specificiation as a result.
James: So how does Equinox help the developer?
Ian: At an abstract level we really see there's a new way of building software - we call it Component Oriented Development and Assembly. The idea is that there are multiple component providers, anyone can create a component be it an open source component at Eclipse, or enterprises building components. Individuals and organisations can take these components and specialise them for their own use. When you're assembling your application and your runtime - if you don't want a heavyweight runtime, you can strip down your runtime now based on what is required for your solution. This flexibility is unique in terms of component models out there.
The underpinnings of this approach is Equinox and OSGi and the ability to use this model across different platforms and tiers.
James: How can I actually take Equinox for use in my own application?
Ian: There's a few modes of using this. You can take Equinox in solo mode and run it on a JVM and Operating System. Lots of organisations have extensive investment made in JEE application servers. The scalability and reliability in an appserver environment is important. You can take Equinox and run it in that environment and take advantage of these type of applications in the appserver environment.
The RCP platform can be seen as another Equinox runtime mode, where RCP runs on Equinox on the desktop.
James: Is the ability to run Equinox on an application server new?
Jeff: The Equinox WAR allows the WAR to start an Equinox framework to run in the appserver, and allow bundles to plug together to create an application. This has been in place for the last year, the technology is called the Servlet Bridge. The key interesting piece of this is that you can write a set of bundles with data models, or utilities, and these same bundles can now be integrated into a web app, allowing full reuse.
Ian: I was talking to NASA, a big user of Equinox. They actually build a platform for when they send up a Mars Rover, and all the Command and Control systems - how the receive data back, do analysis - are built on top of RCP. A year ago they made the decision that the data analysis was too intensive to do on a desktop, so they took the Data Analysis component, essentially an RCP plug-in, and moved it to run on a Linux server running on Equinox. At development time they don't need to decide where it's running until it goes to the deployment step. They use embedded Jetty support in the IDE so they can debug it right inside the IDE.
James: It sounds to me that Equinox really helps Java live up to the “write once run anywhere” promise.
Jeff: To wake people up at talks I give, I say that we've been living a lie with this Write Once Run Anywhere concept, because the programming and deployment models are all different between SE, ME and EE.
Code that you write for ME doesn’t stand much of a chance on EE, but OSGi and Equinox helps components run anywhere you want.
James: What companies are using Equinox at the moment?
Ian: In July 2007 BEA released a new server product called the Event Server. A number of their customers were building event driven applications. If you can imagine a financial institution that needs to do analysis of stock prices - as stock prices change they need to do real-time analysis. So they're a whole bunch of events coming at them that they need to quickly process. In that type of environment latency is very important - so they needed a lightweight container and lightweight deployment model to go forward with.
They choose Equinox as the container and runtime platform, and built up a specialised server for event processing.
It's interesting to see they took this approach, for a stripped down specialised server for doing this type of application. It's why you want to do something like Equinox and CODA.
Another good example is IBM Lotus - so they have Sametime, Notes and Symphony all based on Equinox - the core runtime platform is Equinox. One of the things I've observed is that Sametime messaging client/collaboration suite, where integration with other communication partners is important. They've been able to quickly integration third parties like Cisco and 3Com into Sametime. And the nice thing is integration is very tight from a UI perspective.
James: How does it fit into the Eclipse project structure?
Jeff: There are now 11 top level projects at Eclipse. Each project has a project management committee, a group of leaders within that domain who understand the technology and help set the direction of the open source community. They also help manage the projects that are underneath the top level project. So it's a two level structure of top level projects, and subprojects.
What we're doing here with the Runtime top level project is creating a place where runtime-related technology has a first class home in Eclipse. To date, there are many bits of runtime technology at Eclipse in strange places, like the Technology project, which is seen as an incubator so people are less likely to go there for enterprise quality technology, although there is a lot of industrial grade stuff in there.
There's also the eRCP project, embedded Rich Client Platform project, is very weighed down in DSDP project - Device Software Development Platform. Here the runtime is embedded in the tooling project. We have a series of these mismatches where runtime technology from a producer point of view doesn't have a good home.
If you look at the community for people who look to adopt the Eclipse runtime, when they go to the Eclipse site they get pointed off in all directions. So if you go to your CTO to say "we should be using Equinox because it's the coolest runtime, and has all this flexibility". You give him a url and he looks at the Equinox project and see's that it is currently under the Eclipse top level project. Then you see that the sibling projects are things like JDT (Java Development Tooling), PDE (Plugin Development Environment) and Platform - the tooling RCP. The CTO sees that this is all tooling and doesn't understand what Equinox is.
James: How are you helping the community to get started with Equinox?
Ian: We've created a portal that is being launched today. The feeling is that this is still very new technology, and we need to do a lot to help people understand how to use it, capabilities and what's possible.
We'll be focused on articles, tutorials, webinars and documentation to help people get aware of it.
Getting Started with the Equinox Community
The Eclipse Foundation has launched an initiative to help organizations adopt Equinox, OSGi, and CODA into their software infrastructure. A new top-level project, called the Eclipse Runtime (RT) project has been created to help foster and grow this community. Eclipse RT is a significant supplier of runtime oriented technology that organizations can use to build their unique software solutions. Eclipse RT will include open source projects that provide Ajax support (Eclipse RAP), a SOA Runtime (Swordfish), a persistence service (EclipseLink), technology to allow deployment to embedded devices (Embedded RCP) and more to come in the future. The wider Equinox and Eclipse community also includes runtime technology, based on Equinox, for enterprise reporting (BIRT), modeling (EMF), and data access.
To get started and better understand the concepts in this white paper, we suggest that you take advantages of the following resources:
1. Demo of Equinox in Action
2. Two Webinars: Getting Started with OSGi and Introduction to Eclipse Equinox and OSGi
3. Complete the Introduction to Equinox Tutorial