Infonoia

Server-side Eclipse

Printer-friendly version

Or: Have you heard about RSP and bundlets yet?

Author: Wolfgang Gehner (Infonoia SA)

The Eclipse incubator Equinox has worked it out: it looks like with Eclipse 3.2 and it's underlying OSGi [1] services, you will be able to create plug-ins that deploy to a servlet container.

A simple working demo is available for download here [2, please follow the instructions here]. It wraps Equinox code described here [3].

With this, you can package functionality, like code, but also servlets, JSPs and other http resources in Eclipse-style plug-ins for the server-side. You can deploy ("register") and un-deploy while the container WAR keeps running. The working demo shows this with Tomcat 5.5.

The Eclipse plug-in infrastructure and way of coding has a learning curve.

However, it has a very decent component model. You can specify how a plug-in "contributes" functionality to the platform (itself contributed by other plug-ins), such as adding items to a menu bar or "views". Dependencies between plug-ins are well-defined. It has "hot" remote deployment.

This makes it a natural candidate for a lot of things, once you can run it on the server side.

What "plug-ins that deploy to the server" really mean:

You can use the Eclipse component model for server-side applications. WOW! Whole portals defined via menu/action bar contributions etc. If you have written Eclipse plug-ins or an RCP (Rich Client Platform) [4] application before, chances are that you will be able to appreciate this a lot. Even if not, you may have been frustrated by the classic "one WAR fills all" deployment approach, especially on larger applications. Any web application except maybe the most basic could be a candidate, not just portals.
You could "web-enable" existing RCP SWT UI, by adding some JSP or other rendering "view" part (maybe a HTML renderer for SWT), useful when you need both web clients and desktop clients. WOW2!
You could create web-based plug-ins that run on the server, but could also be used for rendering components as HTML as parts of an RCP rich client application. WOW3! That might really simplify and speed development of UI for RCP applications. Did you know that Eclipse Help has been running in an "embedded Tomcat plug-in" for a long time? [5] Plug-ins could run in that Tomcat as a kind of "client-side plug-in container".
You could bring together AJAX [6] components from many sources, and use dependency declarations to help avoid browser DOM collisions between different implementations. WOW4!

This has the potential to reunite client-side afficionados and the server-side advocats. Let server-side developers write components and apps that can deploy and run standalone, too. Let client-side developers expose their components on the server-side.

Is this the next big thing? I think so. I call this RSP, for "Rich Server Platform". RSP alludes to RCP. It might be much bigger than RCP.

I think that this is a disruptive technology.

Where does this lead us to?

One or many "server-side UI frameworks" that use the Eclipse/OSGi component model are bound to be created. One may well come out of the Eclipse project, probably implemented mostly by people paid by IBM, but I'm really only guessing here. But a lot of questions come to mind for discussion:

[Q1:] Will this kill Spring, Struts, Webwork etc? [Q2:] Do you want the Eclipse foundation to define your server-side UI framework? Having linked Eclipse/RCP to SWT has mostly been seen as a mistake. [Q3:] Should RSP as a kind of "Eclipse on the server" be bound to a particular UI framework?

My favorite large webapp may use Struts or WebWork for some components, Spring (and Spring-Web) for other components where IOC is important. With some AJAX interspersed. Some Laszlo sprinkled in [7]. Maybe REST for simplicity [8]. The RSP component model could allow that. Visual RSP components might be called bundlets (The OSGi specification calls plug-ins "bundles", and someone already uses the term "pluglets" for something else). There are a lot of things that could be mixed and matched.

[Q4:] Will this kill portlets? Some say that current JSR 168 portlets have suffered from the fact that inter-portlet communication and dependencies could have been better defined from the start. [9] Portlets might be augmented into "bundlets", and wired via OSGi.

[Q5:] Will this kill JSF? JSF components could be leveraged as bundlets.

[Q6:] Will this kill Tiles? One "view" implementation in a RSP component could draw Tiles from bundlets.

[Q7:] Will this unlock the power of AJAX in a structured way?

[Q8:] Or do you think the Eclipse architecture or OSGi services model are too complex for all but the largest server-side applications? Note that Eclipse is not OSGi. There might well be OSGi-services based server-side UI frameworks without any dependency on Eclipse code. Though Eclipse has a head start, since the Eclipse IDE already comes with a lot of plug-in builders.

[Q9:] Will the recent Eclipse platform focus draft need to be rewritten? [10] [Q10:] Or does this simply just transcend the Eclipse project boundaries, if we take it that java server-side is "bigger" than java client-side programming, i.e. that there are more java webapps than java client apps?

[Q11:] Should Eclipse "server-side UI frameworks" build on top of an existing server-side UI framework? Or should the Eclipse foundation build one independently?

[Q12:] How would the Eclipse project like to receive input from the server-side afficionados? An example: I would think it a mistake to use "single-url" navigation per default in such a server-side UI framework (the type where a browser back or refresh might kill your application state). Because this would eclipse (pun intended) 90% of traditional web-based apps or sites that could otherwise benefit from the OSGi component model.

[Q 13:] How would you leverage the shown plugin-mechanisms on the server? Can you think of other "WOW"s?

[Q14:] As a company, would you want to build your server-side applications on an open source framework that uses OSGi services? [Q15:] Should the Eclipse project be "associated with" such a framework, or even "be" that framework, such as in an Eclipse Technology Project?

[Q16:] Would you be interested in joining an RSP community, covering "all things helping to run 'Eclipse' on the server"? By reading or contributing articles, code samples, plug-ins that work on the server-side, maybe with plug-ins that use your preferred server-side UI framework? Such as the demo [2] that uses the displaytag library as sample plug-in, but the sky's the limit, really. If your answer is yes on this one, just send me an email.

What do you think?

I have set up a quicktopic thread for your thoughts, comments, ideas, feedback and discussion here [11]

If you enjoyed hearing about this, and would be interested in hearing more over time, please join the Infonoia community. Note that you can opt out at any time by unselecting "You may email me...".

Enjoy!

Wolfgang Gehner
www.infonoia.com

The author of this article is co-author of the book "Struts Best Practices" published in German (2004) and French (Feb 2005). He has been working with Java n-tier web since 1998, including SilverStream appserver, before the advent of open source and J2EE.
His company, Infonoia SA is editor of multi-platform, multi-repository software and solutions around document retrieval and publishing. Infonoia also provides consulting services, mentoring and training (English, French, German) on best practices in the web technologies and frameworks they use, such as Struts, Eclipse and RSP. Wolfgang is also available for speaking engagements on RSP.
Wolfgang can be reached at wgehner [at] infonoia [dot] com

This article was reviewed by: Simon Kaegi