Last week Tim Diekmann and I presented an overview of the new specifications that are part of the OSGi 5.0 Enterprise Release. You can find this presentation online at this link.
Draft releases of the OSGi R5 specs can be downloaded from here:
The actual final specifications will be made available not too long from now. They are currently in the voting process at the OSGi Alliance. Except for some typos and minor formatting issues the final specs are identical to the above EA drafts.
Monday, April 2, 2012
Tuesday, February 7, 2012
OSGi Cloud Workshop at EclipseCon/OSGiDevCon 2012
Many people are seeing how well OSGi fits conceptually with Cloud Computing. Its modularity is frugal on memory, and provides isolation. Additionally it focuses components on a particular task, which makes them better maintainable too. Furthermore, OSGi dynamicity makes it possible to create Cloud components that react to changes in the cloud environment in a natural way. They can be dynamically configured, reconfigured and an OSGi Framework can be dynamically provisioned and re-provisioned as well!
Over the past while the OSGi Cloud Working Group has been looking at how OSGi can be enhanced to provide additional support for Cloud Computing. This has resulted in a requirements document called RFP 133.
At this point in time we need to discuss which of these requirements should be tackled first? Is it Discovery in the Cloud? Or Metadata? Or Management or maybe something else?
At the same time we should embrace any existing standards in this area and certainly not attempt to reinvent the wheel!
This discussion is the topic of the Second OSGi Cloud Workshop which is held this year at the EclipsCon/OSGiDevCon venue on Thursday March 29 at 9am.
It is set to be a morning with some presentations (the lineup currently is: Paremus, JClouds, eBay and RedHat/JBoss), a demo, and a lot of time for discussion. Entrance is free - you don't need an EclipseCon pass, but you do need to register as numbers are limited (see here also for details on the location of the venue): http://osgi-cloudworkshop-2012.eventbrite.co.uk
Oh, and just to be sure: EclipseCon/OSGiDevCon 2012 has moved and is in Washington/Reston this year!
Over the past while the OSGi Cloud Working Group has been looking at how OSGi can be enhanced to provide additional support for Cloud Computing. This has resulted in a requirements document called RFP 133.
At this point in time we need to discuss which of these requirements should be tackled first? Is it Discovery in the Cloud? Or Metadata? Or Management or maybe something else?
At the same time we should embrace any existing standards in this area and certainly not attempt to reinvent the wheel!
This discussion is the topic of the Second OSGi Cloud Workshop which is held this year at the EclipsCon/OSGiDevCon venue on Thursday March 29 at 9am.
It is set to be a morning with some presentations (the lineup currently is: Paremus, JClouds, eBay and RedHat/JBoss), a demo, and a lot of time for discussion. Entrance is free - you don't need an EclipseCon pass, but you do need to register as numbers are limited (see here also for details on the location of the venue): http://osgi-cloudworkshop-2012.eventbrite.co.uk
Oh, and just to be sure: EclipseCon/OSGiDevCon 2012 has moved and is in Washington/Reston this year!
Friday, January 6, 2012
JavaSE 8 Modularity, Project Jigsaw and OSGi
One of the requirements for the JavaSE 8 module system is to provide support for and be able to integrate with OSGi. I am therefore very happy to see that a new OpenJDK project is being proposed to focus on precisely this: Project Penrose. Tim Ellison posted the proposal here: http://mail.openjdk.java.net/pipermail/discuss/2012-January/002320.html
They're still looking for initial supporters, authors and committers, so if you're interested in helping out just sign up!
BTW I posted before on this topic, see here: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html
They're still looking for initial supporters, authors and committers, so if you're interested in helping out just sign up!
BTW I posted before on this topic, see here: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html
Thursday, November 10, 2011
New OSGi Alliance membership stucture
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
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
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...
Subscribe to:
Posts (Atom)
