In "Eclipse Goes Server-Side!
," author Wolfgang Gehner describes the creation of Eclipse plugins that deploy to a servlet container. There are a number of possible benefits to this, such as using the Eclipse component model for server-side applications, "web-enabling" an existing RCP SWT UI, and more.
The article includes a sample application, a set of questions this raises, and a description of possibilities. What do you think about the idea of using a rich client platform as a component model for server-side applications?
I've noticed traces of EMF and the eclipse help system in IBM's WebSphere offerings.
Funny, OSGi came up at a recent demo of Apache Geronimo which prides itself (and rightly so) on its GBeans deployment implementation. Someone asked why not OSGi? The response was that it seemed really just an IDE plugin paradigm. Seems like Geronimo with its IBM connection could be a candidate to offer YADS. JMX deployment being another style (JBoss).
What is cool about this is its finer grain deployment unit compared to conventional EAR/WAR/RAR/JAR units. Could be a better portlet model. It would have to be done by an opensource server framework since it may not mesh with the J2EE certificated Rheinheitsgebot-style containers like WebLogic or Websphere.
Good points Andrew. There seems to have been some work on Geronimo wrapping GBeans with OSGi.http://www.mail-archive.com/dev at geronimo dot apache dot org/msg10923.html
I wonder if it is heads-up or down or gestating at this point, and what the detail reasonings are for them.
When you look at how RCP contributes menu or action bar items from different plugins to one UI, or dig into Eclipse IDE, this seems to have become a wider scope than "just" deployment. Though deployment is very important for someone selling functionality, I think it's deployment combined with the ability to encapsulated functionality in a way that it can fairly easily be linked between modules, which makes this potentially so powerful. Demonstrated somewhat by RCP, this is about going from RCP to RSP (Rich Server Platform).
I initially spend some time trying to mentally force each OSGi bundle (plug-in) into one separate WAR, because it seemed natural to me, but as I am working with it, I increasing to feel the value of bundles as they come together to allow the application to have more substantial functionality. WAR is just a wrapper now, the interesting thing is going on inside.
being supported by eclipse and becoming a community owned project is good,but it is definetly not a new idea as i used it b4(but with different mechanism) to provide our application suite with plugin structure without reinventing the wheel
my approach consist of two main parts:
1- context listener to initialise the OSGi container on the application startup,and to provide it with events about the application and session
2-a servlet filter to redirect all the http requests to the OSGi http bundle
We have done the same thing as you.
And using it in our product now.
Great! What is your product? Please provide a link.
This is exciting stuff, isn't it? We seem to gather evidence that this approach will be BIG.
We've used Eclipse plug-ins to structure logic that goes into a WAR for about a year now, and for us, it was the Equinox incubator who provided "a missing implementation link". But it's not about who invented it - unless you hold a patent, that is. [May claiming patent holders herewith come forward or remain silent forever :)]
The strength lies in the community here. Being able to link stuff to build a greater solution. True open source spirit that can stand up to the Billies of this world.
This sound very great and improves reusability a lot.
I haven't read the article in full lenght, just saw that it mentions 3.2 which will enable this feature.
But isn't BIRT (http://www.eclipse.org/birt/
) doing this already in their webapp version?
Seams like OSGi is a really neat framework.
Sure, being able to develop server-side applications with plugins and and Eclipse extension registry and all that is definitely a good thing.
However, it's always been possible to use use OSGi to develop server-side applications since OSGi has always had Servlet support built into it, from the very first 1.0 specification.
This approach does not enable any new functionality and seems mostly just a way for developers to shoehorn new functionality into existing environments that do not support OSGi.
So, while it's nice to see people gettng excited about using OSGi on the server side - this approach does not make anything possible that wasn't possible years ago.
Shouldn't be the other way around?
Eclipse plugins enforces a componentness model, and nowadays we can see JTA, servlet, JCA, EJB, and many other APIs capable to be deployed isolated. We get these APIs implementations to provide services in the form of plugins.
That's the way it should be, just plug what you need, and use the Eclipse Platform as the infrastructure.
I think what Eclipse needs now, is to provide extensible web adminstration consoles, so admins are capable to deploy plugins, which could be for example a web application, a SOA engine or SOA service.
The old fat container should RIP. The J2EE expert group, should consider in making a new standard container API that is pluggable.
I actually read that post before I put my article online; it definitely made me think.
The author has a very valid point: simplicity rules; or should role, anyway.
There is nothing that justifies unnecessary complexity. A well engineered machine has less parts that could and will fail. Doing OSGi bundles brings me a good step forward in simplifying large webapps that otherwise be what we call here a gas factory: "usine à gaz".
One of the things to look out for in the task of simplifying will in this regard will be Groovy, a slender way of coding (http://groovy.codehaus.org
). I believe RSP should have Groovy whereever possible.
I also make the argument that OSGi can be very light. This point is made elsewhere in comments about my article.
Eclipse started off without it, so it still has some bulges here or there.
Then of course, everything should be as simple as possible, but not simpler. Apparently, the WAR just doesn't cut it any more. From DLL-Hell to Jar-Wars isn't really satisfying. The first thing I did for the demo is to try remove or simplify build processes where possible. Tomcat reads directly from the dev directory, the (OSGi) platform launcher copies directly from source project to tomcat. We're not fully there, but it's more productive than 3 deployment steps somewhere. When we started webapp development in 1998, everything was simpler. It seems things have gotten more complex, often for no reason. So I definitely concur. I still shiver at horror stories when deploying a large ear to some proprietary appserver DB took 55 minutes. As a developer I should not spend half of my time test-deploying.
So I'd like to ask: who thinks (from experience) that the Eclipse component framework is too complex? While I am on that, I remember I had numbered the questions in my article from [Q1] to [Q16]. Anyone out there couragous enough to pronounce himself on any of these points?
[Q1:] Will this kill Spring, Struts, Webwork etc?
Not Spring. All platforms needs something like Spring. The OSGi R4 specification defines new functionality called "Dependency Management" which is essentially Spring for OSGi services.
However, Spring is not well suited for OSGi/Eclipse development since it is not 'dynamic' enough for the OSGi platform (for instance, what should happen if the bundle that hosts a dependency is uninstalled?).
Therefore, some extended OSGi Dependency Management facility will probably replace Spring for Eclipse development.
[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.
You should be dragged out back and shot for making that SWT comment :-). I used to think that SWT was a mistake (years ago). Now I consider it one of Eclipse greatest strengths.
SWT (yes, SWT!) will become the widget API used to write both server-side and client-side applications.
[Q3:] Should RSP as a kind of "Eclipse on the server" be bound to a particular UI framework?
Why yes, SWT!
Using SWT as the universal Widget API will make it possible to write applications that can run as either a fat client application or a browser based server application.
[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.
Nope, we use Eclipse/OSGi on the client side - the base framework framework is only a few hundred K.
[Q 13:] How would you leverage the shown plugin-mechanisms on the server? Can you think of other "WOW"s?
Suppose you are a user of an ERP system that is built with OSGi. Wouldn't it be cool to be able to simply 'plug-in' a new module, like Project Management, into your ERP and try it out?
And if you didn't like it then you would simply uninstall it and try another one from a different vendor?
And wouldn't it be cool to get updates to your modules installed automagically without hassle? (assuming you give permission to install the update of course)
OSGi/Eclipse makes this possible.
[Q16:] Would you be interested in joining an RSP community, covering "all things helping to run 'Eclipse' on the server"?
Sure, but I'm not interested in running OSGi inside a web server, I think it should be the other way around. The web servers should run on top of OSGi.
Consider this... most of the servers around already run on top of JMX - and there are OSGi bundles available that add JMX support to OSGi servers.
Therefore it should be an easy thing to simply repackage any JMX-based server as a set of OSGi bundles and run the server on top of OSGi.
The 'RSP' should not just mean running OSGi inside a web server.
Actually we see very good potential for the integration of Spring and OSGi. The two technologies are very complementary, with OSGi providing strong module (bundle) lifecycle support, sophisticated classloading, and versioning, and Spring providing full dependency injection and configuration capabilities both for bundles themselves, and we envision for references between bundles.
There are a number of options for integrating Spring and OSGi that we are investigating. Publishing a bean factory as an OSGi service offering "getBean" (with suitable bean-client assistance to hide as much of the lookup process as possible - ideally all of it!) is one avenue. Another interesting option is to do something very similar to the way that Spring integrates with JMX, by allowing an application context to transparently export one or more of its beans as OSGi services. Both routes allow integration with OSGi ServicePermissions, filters, and versioning support.
We also started some very neat work during my time at IBM to seamlessly integrate load-time weaving into Equinox (the Eclipse OSGi implementation). That's bearing fruit now as an open equinox incubator project led by Matthew Webster and Martin Lippert. So Spring + AspectJ could be fully operational in an OSGi environment near you soon!
Watch for more coming from the Spring team in this direction over the next few months...
Watch for more coming from the Spring team in this direction over the next few months...
I will be watching. Hopefully, it will also support the Eclipse bundles, and not only OSGI bundles.
[Q1:] Will this kill Spring, Struts, Webwork etc?
As the article shows Struts
running inside an OSGi container, I doubt it will kill 'the web framework'.
There is a question whether some frameworks are better suited for this kind of componentization. I would state that frameworks specifically designed for componentization, such as Tapestry
, and Wicket
, are a better match for OSGi based development than the model2 frameworks.
Indeed, several people from the Felix
project (OSGi implementation for Apache), have written an article
on using Wicket
, the precursor for Felix.
From my own experience, using an OSGi framework is very nice indeed. We were able to drop in a new (version of a) jar file, and have the framework start that bundle. The new functionality was readily available for use by our customers, and they didn't have to take down the app, nor the appserver. It didn't take long before they wanted us to only deliver bundles.
As for the complexity question, with the Gravity Service binder, things are better. It has been a while since I touched the code though, so there may be even better bundles out there that make development with OSGi bundles even better.
I've already talked with Wolfang yesterday, so this will probably be nothing new for him :)
I developed a inhouse server application using OSGi/Eclipse last year.
At first I started with plain OSGi (Knopflerfish) but there were certain small things (like development aids available in PDE) that led me to use Eclipse.
Our application's purpose is to centrally generate our correspondence (word to postscript to pdf), post-process it, and finally send it via fax, e-mail or mail.
It is build as a central server which receives requests from our clients (the users) and then invokes the needed services which can be located on other machines.
It is designed for internal use so it has of course a few rough edges and I would not go so far as to say that is built on a "Generic Rich Server Infrastructure (tm)" but I tried to give it an extensible underlying system in the time we had. Every functionality is represented as an plug-in and the plug-ins communicate over OSGi services. I've not used extension points simply because i started with OSGi and had many of the osgi-services already running as I migrated to Eclipse.
Aside from a few problems and a quite steep learning curve I'm really in love with Eclipse/OSGi and will use it again any time.
The technology is extremely interesting for us, since we have an eclipse-based product that we want extend (as part of a research project) towards a server-based application (incl. thin-client).
I have a practical question: I got the example running and I would like to know how to proceed with own plugins. Once I have created a "server-side" plugin in 3.2M4, how do I deploy it and install it? I played a little with the install command, but it wasn't clear to me what would be the appropriate procedure to install a plugin from a local folder. (If I use the path to the jar-archive as uri I get no error using "install" but I guess this is not the correct way to do it).
Any hints (or links for further reference appreciated!
Moritz, you will be delighted to read this:http://www.infonoia.com/en/content.jsp?ts&d=inf.05.09
It is a technical walkthrough, with augmented examples.
SVN is completely new, so you will need to download the rspDemo-0.2.zip mentioned.
Thank you very much, just some 15 minutes before your reply I saw the example on the infonoia site. This really helps.