The OSGi Alliance is where all the OSGi specs are developed as a collaboration effort of a number of companies (and sometimes invited researchers). To be able to contribute to specs you need to be a member. There are a number of reasons for this but probably the most important one is proper handling of IP flow.
In the past a number of people have told me that they would be interested in taking part in the specification work at OSGi but they simply could not afford the membership. Well for those people there is good news today. The OSGi Alliance has moved to a new membership structure where much cheaper options to become a member are available. Also the size of a company is taken into account at certain levels where smaller companies (under 250 employees) pay less.
There is also an entirely new type of 'low-fee' membership: Contributing Associate (which replaces the old Adopter Associate). Being an Contributing Associate is much more useful than Adopter Associate was as Contributing Associates can send up to 2 delegates to Expert Group meetings (such as the Enterprise Expert Group) where they can fully participate in the development of RFPs and RFCs, which ultimately can become OSGi specifications.
Any existing Adopter Associates are automatically moved to Contributing Associate, so they can start contributing right now! (well, you need to sign some docs, but that's all).
Ideally you want stuff like this to be free, but as any Standards Development Organization, the OSGi Alliance (which is a non-profit organization) has operating costs and the membership fees are used for that. As a representative on the Board of Directors I will always make sure that any money in the organization is used appropriately.
I'm personally very happy to see the OSGi restructuring finally taking place. I expect that it will open the door to more participation, especially from the large number of smaller companies who are successfully using OSGi in the field. The OSGi technology is great, but great things can always be improved. Doing this in the OSGi Alliance means that those improvements will be embodied in specifications and specifications ultimately lead to choice as multiple implementations can co-exist so that users will be free from vendor lock-in.
For all the details of the new membership structure see here: http://www.osgi.org/About/Join and here: http://www.osgi.org/About/Benefits#compare
Alternatively, feel free to contact me at david.bosschaert@gmail.com if you have questions, I may not be able to answer all of them but I can always point you at the person who does.
For a list of current OSGi specifications and their implementations see here: en.wikipedia.org/wiki/OSGi_Specification_Implementations
Thursday, November 10, 2011
Tuesday, October 11, 2011
OSGi Enterprise Specification Early Access Draft
A new Early Access Draft containing RFCs aimed at the upcoming OSGi Enterprise Specifications has been made public. The following RFCs are expected to be part of the OSGi Enterprise Release next year:
You can find this draft on the OSGi website here: http://www.osgi.org/download/osgi-early-draft-2011-09.pdf
- RFC 112 OBR
- RFC 152 Subsystems
- RFC 167 java.util.ServiceLoader support
- RFC 169 JMX updates
You can find this draft on the OSGi website here: http://www.osgi.org/download/osgi-early-draft-2011-09.pdf
Tuesday, July 12, 2011
JBoss Application Server 7 is out - with OSGi support!
JBoss AS7 has been released today - an amazingly fast and lightweight Application Server with built-in OSGi support. Just deploy your OSGi bundles and go!
For more information see the main AS7 page: http://www.jboss.org/as7.html
Or have a look at the quickstarts page!
The OSGi support in AS7 implements the OSGi 4.2 core specification. Thomas Diesler has contributed most of the code, and I have implemented some bits and pieces in there too... Lets us know what you think or if you find an issue. The forums are here: http://community.jboss.org/en/jbossosgi and more details on the project can be found here: http://www.jboss.org/jbossas/osgi
For more information see the main AS7 page: http://www.jboss.org/as7.html
Or have a look at the quickstarts page!
The OSGi support in AS7 implements the OSGi 4.2 core specification. Thomas Diesler has contributed most of the code, and I have implemented some bits and pieces in there too... Lets us know what you think or if you find an issue. The forums are here: http://community.jboss.org/en/jbossosgi and more details on the project can be found here: http://www.jboss.org/jbossas/osgi
Tuesday, June 28, 2011
The need for Modularity
The title of this blog is not new - it has been used by many other blogs and articles in the past, but Rod Johnson seems to think that Modularity not really needed any more so I decided to reuse the title and take a look at why we really need Modularity.
In this age of Cloud Computing where hardware utilization and energy consumption are being highly optimized you will find that more and more service providers are moving towards a multi-tenancy model where multiple deployments are co-located on a single platform. Whether these deployments are from different providers or from the same provider is the choice of the deployer, but the end-result is a situation where multiple deployments share a single platform. In such cases modularity is an absolute must as without it there is a reasonably big chance that the system won't work. This is because deployables might depend on incompatible versions of the same library, which means that in order to work, they need to be isolated from each other. Or, a deployable might depend on a library that also happens to be used by the platform provider, this is an even harder case which requires the platform itself to be developed in a modular fashion so that it's details don't bleed into the user-space.
Scenarios like this require modularity and in the case of Java this modularity is provided through OSGi and/or many application servers. Additionally, modularity can also be found in many non-appserver systems that allow plugins to be installed.
Further benefits of modularity relate to memory footprint and performance. A modular system can make intelligent decisions about its memory usage, where only modules that the end user actually needs are loaded. This makes it possible for a fully featured server to have a tiny runtime footprint if only a small portion of it is actually used. And all of these benefits have performance benefits too: you'll save a lot of time if you're only loading the modules you actually need rather than pre-loading the entire system as a single entity.
But even if you don't need modularity for side-by-side versioning, isolation or performance just yet, there are additional benefits associated with using a modular approach in your development. I think that even for small projects it's not a bad idea to start out by using Modularity. It's true - getting a modular project off the ground takes a larger initial effort compared to the 'traditional' approach. But that cost is quickly earned back once the project grows a little bigger. Once your project is structured to support modularity, it becomes much more maintainable, easier to understand and to extend while 'traditional' approaches tend to become much harder to maintain as they grow in size.
See the following diagram, adapted from a blog by Hal Hildebrand:
The investment in a Modular Architecture earns itself back quicker than you think.
Using a modular approach together with a service oriented architecture*) gives your system highly cohesive entities with a clear responsibility. This makes it easier to identify what parts are affected when a system needs to be enhanced or changed. Changes for a particular feature are often more localized to a specific set of modules, which enables better parallelization of development and will ultimately make your developers more productive.
So Modularity is highly desirable for a number of reasons and the best place to get modularity today is by taking an OSGi Framework, as OSGi has been providing Modularity as well as an excellent Services Framework to Java for over 12 years and is standardized in the OSGi specifications.
Part of the choice for a particular development architecture is always the consideration regarding tooling support. With OSGi the following tools are popular:
Additionally, Netbeans and IntelliJ have OSGi Support. While tools can always be improved the above toolsets are quite usable. Especially the Maven Bundle Plugin is very popular in the Open-Source world and many, many examples can be found that show its use.
To conclude, Rod Johnson says that especially on the server side, using a non-modular system is better for customers. This seems like a highly incorrect statement to me. Modularity is needed especially on the server side, as without it your deployments become fragile, especially if you have more than one deployment on that server...
*) Note that by saying 'service oriented architecture' I'm not implying a distributed SOA. Using services within a single process is highly valuable and works great in combination with modularity to avoid tight coupling. Yes, services open the door to distributing parts of your application, but that's really a different topic...
In this age of Cloud Computing where hardware utilization and energy consumption are being highly optimized you will find that more and more service providers are moving towards a multi-tenancy model where multiple deployments are co-located on a single platform. Whether these deployments are from different providers or from the same provider is the choice of the deployer, but the end-result is a situation where multiple deployments share a single platform. In such cases modularity is an absolute must as without it there is a reasonably big chance that the system won't work. This is because deployables might depend on incompatible versions of the same library, which means that in order to work, they need to be isolated from each other. Or, a deployable might depend on a library that also happens to be used by the platform provider, this is an even harder case which requires the platform itself to be developed in a modular fashion so that it's details don't bleed into the user-space.
Scenarios like this require modularity and in the case of Java this modularity is provided through OSGi and/or many application servers. Additionally, modularity can also be found in many non-appserver systems that allow plugins to be installed.
Further benefits of modularity relate to memory footprint and performance. A modular system can make intelligent decisions about its memory usage, where only modules that the end user actually needs are loaded. This makes it possible for a fully featured server to have a tiny runtime footprint if only a small portion of it is actually used. And all of these benefits have performance benefits too: you'll save a lot of time if you're only loading the modules you actually need rather than pre-loading the entire system as a single entity.
But even if you don't need modularity for side-by-side versioning, isolation or performance just yet, there are additional benefits associated with using a modular approach in your development. I think that even for small projects it's not a bad idea to start out by using Modularity. It's true - getting a modular project off the ground takes a larger initial effort compared to the 'traditional' approach. But that cost is quickly earned back once the project grows a little bigger. Once your project is structured to support modularity, it becomes much more maintainable, easier to understand and to extend while 'traditional' approaches tend to become much harder to maintain as they grow in size.
See the following diagram, adapted from a blog by Hal Hildebrand:
 |
| Cost of Software Maintenance |
Using a modular approach together with a service oriented architecture*) gives your system highly cohesive entities with a clear responsibility. This makes it easier to identify what parts are affected when a system needs to be enhanced or changed. Changes for a particular feature are often more localized to a specific set of modules, which enables better parallelization of development and will ultimately make your developers more productive.
So Modularity is highly desirable for a number of reasons and the best place to get modularity today is by taking an OSGi Framework, as OSGi has been providing Modularity as well as an excellent Services Framework to Java for over 12 years and is standardized in the OSGi specifications.
Part of the choice for a particular development architecture is always the consideration regarding tooling support. With OSGi the following tools are popular:
Additionally, Netbeans and IntelliJ have OSGi Support. While tools can always be improved the above toolsets are quite usable. Especially the Maven Bundle Plugin is very popular in the Open-Source world and many, many examples can be found that show its use.
To conclude, Rod Johnson says that especially on the server side, using a non-modular system is better for customers. This seems like a highly incorrect statement to me. Modularity is needed especially on the server side, as without it your deployments become fragile, especially if you have more than one deployment on that server...
*) Note that by saying 'service oriented architecture' I'm not implying a distributed SOA. Using services within a single process is highly valuable and works great in combination with modularity to avoid tight coupling. Yes, services open the door to distributing parts of your application, but that's really a different topic...
Tuesday, June 7, 2011
OSGi Enterprise Specification Early Access Draft available!
An early access draft for the upcoming OSGi Enterprise Specifications has just been made available. This is really interesting stuff and it shows what we've been working on in the Enterprise Expert Group over the last year or so. Although still work in progress, some of these specifications will be included in the next OSGi Enterprise Release which is currently planned to be released during the first half of 2012.
The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.
Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).
Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, as I've blogged about in 2008, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on an implementation of this in Apache Aries, if you're interested in trying it out.
Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to the osgi-dev mailing list.
You can find the EA draft here: http://www.osgi.org/download/osgi-early-draft-2011-05.pdf
The main theme for the Enterprise Release is around Subsystem/Application support and OBR (the OSGi Bundle Repository). These are covered in RFC's 152 and 112. Together they greatly improve the way you can define and distribute, assemble and install OSGi applications and I'm really looking forward to the moment that these specs are finished and broadly implemented.
Additionally you can find in the draft: RFC 146 JCA support, two new Blueprint specifications and an update to the JMX specification (chapter 124 in the Enterprise Release 4.2).
Finally there is RFC 167. This is a new RFC that I've been working on. It intends to fix a small but quite annoying issue: the fact that java.util.ServiceLoader() and META-INF/services use generally don't work in OSGi. You can work around it, as I've blogged about in 2008, but it's ugly. Using RFC 167 this issue can be addressed so that any non-OSGi code that uses this pattern can work in OSGi without too much hassle. I've been working on an implementation of this in Apache Aries, if you're interested in trying it out.
Note that the specifications are not yet final so significant changes might still occur. Also, feedback is welcomed! You can leave comments here on my blog or write an email to the osgi-dev mailing list.
You can find the EA draft here: http://www.osgi.org/download/osgi-early-draft-2011-05.pdf
Wednesday, May 25, 2011
Java SE 8 Modularity Requirements
Mark Reinhold posted the requirements for the Module System in JavaSE 8 here today: http://openjdk.java.net/projects/jigsaw/doc/draft-java-module-system-requirements-12 . And, I won't deny it, I was part of the group that worked on getting these requirements formulated, although I don't fully agree with all of them, but more on that below.
There are many, many good requirements in this document and Java will certainly gain from having these realized - if this is done in an open and inclusive manner.
So what does this mean for OSGi? OSGi is a widely used, mature, modularity standard today, existing for 10+ years.
Well, the good news is that the new requirements are not incompatible with OSGi. There is actually a specific requirement around the necessity for OSGi to be able to interact with the JavaSE modules.
Many of the requirements mentioned in the document are already supported by OSGi today. The file format that defines the modules will most likely not be the MANIFEST.MF file that is used by OSGi today, but another file of some sort. OSGi will support this new mechanism to declare the module as well in the future; the semantics are the same, the format will be slightly different.
Another good thing is that once modularization is part of Java SE 8, moving to OSGi will be easier than it is today. The biggest stumbling block for migrating an existing system to OSGi today is often the modularization of a system that wasn't created in a modular way in the first place. It's not an issue with OSGi per se, but with modularity as a concept. If you have existing code that is non-modular, it can be difficult to modularize it. With JavaSE 8 this problem will appear earlier in the development cycle which should help people design their systems in a modular way from early on. If you need more than the basic JVM module system then you can move to OSGi taking your existing JavaSE 8 modules and they will just work as-is - so migration will be a breeze. Then you can enhance the modules to take advantage of the OSGi benefits (see below).
Why not take OSGi as-is?
Well, this would be nice. And it should be quite possible to take a (possibly reduced) OSGi framework and make that the module system for Java SE 8. But to a certain degree it's an implementation detail. The important thing is that the Java SE 8 Module System is a well-defined standard. Whether JRE implementations take OSGi as the basis for their module system or write their own from scratch is up to them.
Does OSGi still add value? Absolutely! Here are some points:
Where are the disagreements?
They're actually spelled out in the requirements document.
Conclusion
I congratulate Mark Reinhold and all others involved in this for providing the basic requirements and design proposal that will make OSGi work nicely with the JavaSE 8 module system. OSGi will extend the basic JavaSE 8 modules and both systems will work with each other to form a layered design.
There are many, many good requirements in this document and Java will certainly gain from having these realized - if this is done in an open and inclusive manner.
So what does this mean for OSGi? OSGi is a widely used, mature, modularity standard today, existing for 10+ years.
Well, the good news is that the new requirements are not incompatible with OSGi. There is actually a specific requirement around the necessity for OSGi to be able to interact with the JavaSE modules.
Many of the requirements mentioned in the document are already supported by OSGi today. The file format that defines the modules will most likely not be the MANIFEST.MF file that is used by OSGi today, but another file of some sort. OSGi will support this new mechanism to declare the module as well in the future; the semantics are the same, the format will be slightly different.
Another good thing is that once modularization is part of Java SE 8, moving to OSGi will be easier than it is today. The biggest stumbling block for migrating an existing system to OSGi today is often the modularization of a system that wasn't created in a modular way in the first place. It's not an issue with OSGi per se, but with modularity as a concept. If you have existing code that is non-modular, it can be difficult to modularize it. With JavaSE 8 this problem will appear earlier in the development cycle which should help people design their systems in a modular way from early on. If you need more than the basic JVM module system then you can move to OSGi taking your existing JavaSE 8 modules and they will just work as-is - so migration will be a breeze. Then you can enhance the modules to take advantage of the OSGi benefits (see below).
Why not take OSGi as-is?
Well, this would be nice. And it should be quite possible to take a (possibly reduced) OSGi framework and make that the module system for Java SE 8. But to a certain degree it's an implementation detail. The important thing is that the Java SE 8 Module System is a well-defined standard. Whether JRE implementations take OSGi as the basis for their module system or write their own from scratch is up to them.
Does OSGi still add value? Absolutely! Here are some points:
- dynamicity and lifecycle: OSGi modules are dynamic; you can add, remove and update modules from a running framework. It allows patching applications without taking them down! (I have demo'ed this many times) This will probably not be possible in the JavaSE 8 modules.
- advanced service registry: the OSGi Service Registry is much richer than the Java SE java.util.ServiceLoader class. It allows filtering for services on additional metadata (beyond the interface name), supports multiple instantiation modes and, again, is dynamic: services can come and go.
- richer dependency metadata: OSGi has an extremely rich metadata model that supports specifying dependencies in many ways. It does support module-level dependencies (as is proposed in the Mark's requirements doc) through the Require-Bundle header. However, most people who have been working with OSGi for the last 10+ years have realized that pure module-level dependencies are inferior to declarative dependencies such as the ones provided by OSGi's Export-Package and Import-Package. Since OSGi 4.3 generic capabilities and requirements are also supported, which allows you to create your own dependency system.
- many other OSGi specifications: there are many OSGi specifications that describe useful things which can be used on top of any OSGi framework. See the compendium and enterprise specifications for the details.
Where are the disagreements?
They're actually spelled out in the requirements document.
- The form of the module definition. Having module metadata in a file different from MANIFEST.MF is fine, in my opinion. MANIFEST.MF is a near text-file format with some strange limitations. A proper DSL would be nice for module definitions. I don't see the value, however in compiling that information into some binary format. It has been invaluable to me many times in the past to be able to open an OSGi bundle, look at the manifest and see exactly from that information what the module definition is. Compiling the information into a binary format will make it harder to see the module definition and it might also make life harder for tools that work with the module system.
- The file extension of the module definition. Some argued that the module source definition should be in a .java file and because it's in a .java file there should be a compiled .class file in the resulting Jar file. However, I think that the structure of a module definition screams for a specific DSL that might be quite different from ordinary Java. Especially the extensibility requirement makes a DSL much more natural than a traditional .java source file. I think the module definition should be in META-INF/module.jmod or something like that. Then it becomes natural to migrate that file as-is to the resulting jar. In a sense the existing MANIFEST.MF does cover most of the requirements. Sure, it has some issues (esp. the 76 chars-per-line limit) but it's clear, simple and extensible - and - it is readable by humans in the Jar file.
Conclusion
I congratulate Mark Reinhold and all others involved in this for providing the basic requirements and design proposal that will make OSGi work nicely with the JavaSE 8 module system. OSGi will extend the basic JavaSE 8 modules and both systems will work with each other to form a layered design.
Wednesday, May 18, 2011
Nice magazine about OSGi
The people behind the Jax conferences have created a PDF magazine with a focus on OSGi. There's some good articles in there, so definitely worth a read!
Table of Contents:
Table of Contents:
- Introduction to OSGi by Jerome Moliere
- What's new in Core 4.3 by BJ Hargrave and Peter Kriens
- Developing with BndTools by Marcel Offermans and Alexander Broekhuis
- OSGi a la Carte by Valentin Mahrwald and Holly Cummins
- OSGi and JPA by Dmytro Pishchukhin
- Cure for Complexity (Business focus) by Richard Nicholson
- Enterprise OSGi by Tim Diekmann and myself
Friday, April 29, 2011
Enterprise OSGi in JBoss AS7
As many of you know, I have been working on OSGi support in the JBoss Application Server for the past year now. My colleagues at JBoss/Red Hat and I have built an OSGi Framework from the ground up with as focus the best possible integration with the Application Server.
AS7 has been OSGi-enabled since its Alpha1 release and over the past few weeks Beta's have been pushed out on a bi-weekly basis. It's starting to look really good!
Next week at Red Hat Summit/JBoss World in Boston I'll be presenting and demoing the current state of things w.r.t. to Core OSGi, Enterprise OSGi and OSGi/AS integration in AS7. My session is on Friday at 11am: http://www.redhat.com/summit/sessions/jboss.html#38 - hope to see you there!
AS7 has been OSGi-enabled since its Alpha1 release and over the past few weeks Beta's have been pushed out on a bi-weekly basis. It's starting to look really good!
Next week at Red Hat Summit/JBoss World in Boston I'll be presenting and demoing the current state of things w.r.t. to Core OSGi, Enterprise OSGi and OSGi/AS integration in AS7. My session is on Friday at 11am: http://www.redhat.com/summit/sessions/jboss.html#38 - hope to see you there!
Friday, March 25, 2011
OSGi 4.3 core proposed final draft now available
The OSGi 4.3 core specification proposed final draft if now publicly available!
New and noteworthy:
Get it here: http://www.osgi.org/Download/File?url=/download/osgi.core-4.3.0-pfd.pdf
Update - the final 4.3 Core spec is now public: http://www.osgi.org/Download/Release4V43
New and noteworthy:
- Generified Framework API
- Generic Requirements and Capabilities
- New BundleWiring API
- New Bundle and Resolver Hooks
- New Weaving Hoooks
Get it here: http://www.osgi.org/Download/File?url=/download/osgi.core-4.3.0-pfd.pdf
Update - the final 4.3 Core spec is now public: http://www.osgi.org/Download/Release4V43
Tuesday, February 15, 2011
OSGi Cloud Computing RFP 133
I'm quite excited by the work that is being done in the OSGi Cloud Working Group recently. In this working group we are looking at what role OSGi standards can play in a Cloud Computing environment. Currently we're focusing on the possible requirements in RFP 133. Both OSGi Alliance members as well as non-members are involved in defining this document.
If you're interested, have a look at the RFP. It's available as an attachment to this bug in the public OSGi Bugzilla system: https://www.osgi.org/bugzilla/show_bug.cgi?id=114. Feel free to comment!
If you're interested in becoming more involved, join the OSGi Cloud Working Group mailing list: https://mail.osgi.org/mailman/listinfo/cloud-workshop.
If you're interested, have a look at the RFP. It's available as an attachment to this bug in the public OSGi Bugzilla system: https://www.osgi.org/bugzilla/show_bug.cgi?id=114. Feel free to comment!
If you're interested in becoming more involved, join the OSGi Cloud Working Group mailing list: https://mail.osgi.org/mailman/listinfo/cloud-workshop.
Subscribe to:
Posts (Atom)
