On last yearâ€™s fifth anniversary of Eclipse, we speculated about whether Eclipse was in danger of suffering the fate of the JCP in spreading its mission too thin. Expanding from its relatively humble IDE origins, today, Eclipse has placed its stake in the sand with runtime, not to mention embedded devices, rich clients, modeling, and application lifecycle management and other areas. We noted some data points, such as JBossâ€™s unilateral move for hosting its own Eclipse development efforts apart from the Eclipse.org main portal, as evidence of Eclipseâ€™s spreading the wings is not gaining universal support. We received a spirited rebuttal from ZDNetâ€™s Dana Gardner who provided an excellent history explaining that other not-so-trivial factors â€“- mostly Sunâ€™s insistence at remaining first among equals -â€“ was actually responsible for the schism.
On year 6, Eclipse is making its expanded mission more formal than ever. With announcement of Equinox as the next top-level project (with everything in Eclipse termed a project, being top level is pretty important), Eclipse is firmly spreading its footprint from design time to run time. Equinox so far has gained support from five Eclipse projects, ranging from frameworks that invoke different communications protocols (e.g., what if your app were to speak IM and support file sharing, etc.); database persistence (the project that catapulted Oracle to Eclipseâ€™s executive board); plus the run times for server-based Ajax, SOA, and even traditional client/server.
And JBoss is still protesting, witness an exchange in CTO Sacha Laboureyâ€™s blog last fall between him and Eclipse executive director Mike Milinkovich.
As Milinkovich pointed out to Labourey, Eclipse has been involved with runtime since the beginnings of the Rich Client Project (RCP) three years ago, whose aim was to offer a fat client alternative to the web deployment that had been the basis of early Eclipse plug-ins. The RCP has helped Eclipse stretch its reach considerably, with everything from debuggers to CRM apps.
Clearly, the engine behind all this is the OSGi framework, something that Eclipse stumbled upon four years ago when its original component model was running out of gas. What makes OSGi pretty swift is that it is quite scalable, and more importantly, allows components to be hot-swapped or provisioned on the fly. So Eclipse had a component framework where plug-ins could be dynamically swapped at run time, which at that point, meant developers could marshal up whichever Eclipse plug-ins (thatâ€™s Eclipse terminology for components, or individual tooling) you needed while crafting a Java app.
With Equinox planting Eclipseâ€™s feet into run time, the potential of OSGi could become pretty huge. Taken literally, it could provide a new model for application integration, or in the words of RedMonkâ€™s James Governor, a â€œstackless stack.â€ Governor provides a detailed listing of early offerings that are supporting the OSGi model of dynamic composition of applications.
If you take the idea of stackless stacks to its logical conclusion, that means the end of monolithic middleware stacks as we know them.
OK, lets take a deep breath and slow down. First, just because you have different tools or applications with the same hot pluggable component model does not necessarily mean you can integrate them. Secondly, weâ€™d be surprised at the death of the stack. Remember when ESBs were supposed to make appserver obsolete? Or SOA or BPM decomposing monolithic application stacks into bunches of configurable, interoperable services or business processes? Heck, this whole take goes back to the days of CASE, when we though that generating components off of an enterprise data model would provide the all-purpose solvent.
Going forward, vendors are likely to support elements of Equinox, or more precisely, Eclipseâ€™s OSGi component engine, highly selectively. Governor pointed out some excellent examples, like BEAâ€™s microService Architecture (mSA), which it used to build WebLogic Event Server, or IBMâ€™s Lotus Expeditor. (Of course, who knows whatâ€™s going to happen with BEAâ€™s products â€“ or at least the newer ones that lack an installed base?)
Oracle is likely to embrace elements of Equinox to help shortcut the magic that its Fusion middleware will have to pull off to bridge its increasingly diverse applications portfolio. IBM will embrace it because it provides a wonderful way for its services folks to help you integrate things. On the other hand, weâ€™d be rather shocked if SAP, which likes to dictate integration on its own terms, will buy in. And of course, JBossâ€™s objections are already well known.
Eclipse is undergoing organizational growing pains made possible by its embrace of a technology (OSGi) whose versatility opens up huge new possibilities. But as any organization spreads its wings, preserving consensus becomes far more challenging, not to mention maintaining focus. Although the Eclipse Foundation is not a standards organization per se, it shares challenges similar to confederated standards bodies like Oasis that have lean, loose governance structures. All too often, you wind up with anarchy as competing, overlapping projects admitted with the intent of encouraging participation instead compromise the very principle by which most of these organizations were founded: interoperability.
So we return to our theme of last year: Eclipse’s life is about to get a lot more complicated.