Eclipse 3.0 OSGi runtime - introducing a service-oriented architecture to an IDE's plugin-based extendable architecture
As many people know, the Eclipse IDE version 3.0 introduced a new service-based architecture within the Eclipse runtime environment.
One of the main motivations that led to this was the desire for an ability to do dynamic late loading of Eclipse plugins - and also unloading of them when they were no longer in use. The advantages of this are faster start times, less resources wasted by plugins that are not being used or needed by the user at the moment anyway, and a smaller overall memory footprint. Under Eclipse 2.x, once a plugin loaded, there was no way to completely unload it.
If you are not already familiar with OSGi, the Open Service Gateway interface, here is OSGi in a Nutshell.
If you are not already familiar with the Eclipse 3 additions to the Eclipse IDE, read this interview with Erich Gamma, famed technical leader of the open source Eclipse IDE project, discussing Eclipse 3 prior to it coming out.
10 Goto 10: The Eclipse OSGi runtime explained - Servlets on your PocketPC is a nice article that gives some background on OSGi as it pertains to Eclipse.
The OSGi Technology page over at the OSGi web site also gives a lot of useful introductory background about OSGi as well.
Here is the OSGi portion of Eclipse and the Eclipse core's OSGi runtime at the Eclipse CVS repository web site.
A lot of time when a new technology is introduced, people ask, "Yes, but where is the expertise for this new technology?". Well, a few things to say to that. First, OSGi experts are out there. According to the aQute OSGi web page they are one. Two, there has been a book out on OSGi for several years. It is part of the Addison-Wesley Sun Java Language series and is quite well written. Third, there are plenty of Java programmers in the world. If we believe the marketing math, there are millions of them - and OSGi is implemented in Java, used by Java programs, and has a Java API. I do not think we will have any problems there. Fourth, and finally - OSGi does not have a complex architecture or API.
One creates "Bundles" for OSGi which contain deployable services that can be added into an OSGi environment by an OSGi server administrator. These bundles are similar to the JavaBean and executable .jar java archiive files, web application server .war web archive files, enterprise Java Bean (EJB) .ear files, service archive .sar files, and so on. They have a manifest with some meta data in them and they contain a lot of Java class files in a ZIP file arranged internally into a directory hierarchy that is organized as a tree of Java package names, with each class in its respective package.
Bundles can be loaded, unloaded, advertise services, looked up by service, etc. Gravity has created an OSGi-aware ServiceBinder to help exploit the resource offered by all these services. Here is an OSGi and Gravity Service Binder Tutorial.
OSGi comes to Eclipse at a pretty good time. Judging from the number of plugins that are already available for Eclipse 3, we seem to be poised on the verge of having a deluge of useful plugins available to us programmers using Eclipse. For instance, right now I am aware of the following plugins available out there that are pretty nice looking:
With OSGi in Eclipse, we can install quite a few plugins into Eclipse, and as long as we are not using them all at once we are not going to bog down our IDE and slow down our programming efforts. The purpose of plugins is to speed up the production of software. The purpose of OSGi in Eclipse, among other things, is to speed up even the most decked-out Eclipse power-user's IDE. That means the more you use Eclipse plugins in Eclipse 3, the more you benefit from OSGi.
One of the main motivations that led to this was the desire for an ability to do dynamic late loading of Eclipse plugins - and also unloading of them when they were no longer in use. The advantages of this are faster start times, less resources wasted by plugins that are not being used or needed by the user at the moment anyway, and a smaller overall memory footprint. Under Eclipse 2.x, once a plugin loaded, there was no way to completely unload it.
If you are not already familiar with OSGi, the Open Service Gateway interface, here is OSGi in a Nutshell.
If you are not already familiar with the Eclipse 3 additions to the Eclipse IDE, read this interview with Erich Gamma, famed technical leader of the open source Eclipse IDE project, discussing Eclipse 3 prior to it coming out.
10 Goto 10: The Eclipse OSGi runtime explained - Servlets on your PocketPC is a nice article that gives some background on OSGi as it pertains to Eclipse.
The OSGi Technology page over at the OSGi web site also gives a lot of useful introductory background about OSGi as well.
Here is the OSGi portion of Eclipse and the Eclipse core's OSGi runtime at the Eclipse CVS repository web site.
A lot of time when a new technology is introduced, people ask, "Yes, but where is the expertise for this new technology?". Well, a few things to say to that. First, OSGi experts are out there. According to the aQute OSGi web page they are one. Two, there has been a book out on OSGi for several years. It is part of the Addison-Wesley Sun Java Language series and is quite well written. Third, there are plenty of Java programmers in the world. If we believe the marketing math, there are millions of them - and OSGi is implemented in Java, used by Java programs, and has a Java API. I do not think we will have any problems there. Fourth, and finally - OSGi does not have a complex architecture or API.
One creates "Bundles" for OSGi which contain deployable services that can be added into an OSGi environment by an OSGi server administrator. These bundles are similar to the JavaBean and executable .jar java archiive files, web application server .war web archive files, enterprise Java Bean (EJB) .ear files, service archive .sar files, and so on. They have a manifest with some meta data in them and they contain a lot of Java class files in a ZIP file arranged internally into a directory hierarchy that is organized as a tree of Java package names, with each class in its respective package.
Bundles can be loaded, unloaded, advertise services, looked up by service, etc. Gravity has created an OSGi-aware ServiceBinder to help exploit the resource offered by all these services. Here is an OSGi and Gravity Service Binder Tutorial.
OSGi comes to Eclipse at a pretty good time. Judging from the number of plugins that are already available for Eclipse 3, we seem to be poised on the verge of having a deluge of useful plugins available to us programmers using Eclipse. For instance, right now I am aware of the following plugins available out there that are pretty nice looking:
With OSGi in Eclipse, we can install quite a few plugins into Eclipse, and as long as we are not using them all at once we are not going to bog down our IDE and slow down our programming efforts. The purpose of plugins is to speed up the production of software. The purpose of OSGi in Eclipse, among other things, is to speed up even the most decked-out Eclipse power-user's IDE. That means the more you use Eclipse plugins in Eclipse 3, the more you benefit from OSGi.
posted by John Collins | 2:00 PM
1 Comments:
Dude, so you got a hybrid gas/electric. I salute you, Johnny - owner of the software saloon!
Post a Comment
<< Home