Enterprise Workshop
2006-09-13
I am typing this on my way back home from a very successful enterprise workshop. Over 30 people from many different companies had taken the trouble to show up for this requirements gathering session; many of them OSGi members but also a number of new companies that are interested in using the OSGi service platform in less resource constrained environments than home gateways, cars, or mobile phones. After this busy day I can safely say that there is sufficient interest to start working on enterprise OSGi! We will create the charter for the EG in the coming weeks.
How do you gather the requirements from 30 people at the same time? Not an easy task. We decided to first get a short introduction from all participatns and then let volunteers present their position statement. We got a few interesting presentations from Siemens, SAP, and others about where they see the opportunities for the OSGi specifications to play a role. We then spent some time doing a round table discussion to capture the ideas and requirements from the different participants. These ideas were categorized and then sorted by voting. After several failed voting system attempts we decided to vote with post-it notes glued to the projector screen, which reminded Jon Bork from Intel of “hanging chads”. Fortunately, we did not need the supreme court to intervene.
“Stay modular and small”. This was one of the first things Hal Hildebrand from Oracle said, and nobody disagreed. People like the OSGi technology because it was created for a constrained environment, which has given it a lean appearance. Unanimously, we liked to keep it that way. The new specifications required for the enterprise group should not fragment the world like J2ME and J2SE and neither should they bloat like J2EE. New features should be added in a modular fashion so that the basic framework is still usable in embedded environments.
A key requirement we identified was distribution. The strength of the OSGi specifications are that they specify a very efficient model for multiple applications to share a single VM in a single process. However, when moving to the enterprise it becomes crucial to provide mechanisms to scale to multiple processes, multiple VMs, multiple machines, and multiple languages. So far, we have not addressed outside VM issues because inter-process communications requires very CPU intensive mechanisms that are just no viable in resource constrained environments. It is, however, clear that the enterprise world is more than willing to pay the extra price for the increased scaling, availability, reliability, and access to applications written in other languages than Java that a distributed model can provide. As was remarked, most new code is just the fur on a giant hairball of legacy applications. From an implementation point of view, the OSGi service registry seems the perfect candidate to implement these requirements.
Another requirement was more focus on the whole life cycle of applications. The OSGi Alliance provides good specifications for the service platform but development, debugging, deployment, management, auditing, monitoring, patching, education, and certifications of applications have so far been out of scope. These were considered crucial aspects for “universal middleware” standard to succeed in the enterprises.
There was also a very interesting discussion about more comprehensive dependency management. Can we model the aspects that are outside the VM? More extensive metadata can go a long way to make deployments more accurate and offers possibilities in grid computing like models.
A number of new services were proposed. An interesting one was the network awareness service. I remember discussing such a service at least 5 years ago. Time flies. Also, people would like to see even more security mechanisms, an enhanced configuration admin, data synchronization, web services stacks, and several more.
There were many more topics raised and all of them deserve further discussions. However, the previously sketched areas seem to cover the most urgent needs. The next steps we have to take is chart a charter for the expert group, select a chair (if you are interested, you should propose yourself as a candidate), get board approval and then have our kick off meeting so we can start working. Most companies volunteered people to work on different aspects of the specifications..
The general scope of the EG is clear: We want to make OSGi feasible in the more distributed enterprise world and address the non-Java oriented aspects of enterprise applications. If your company is working in this scope, I would seriously consider joining. Looking at the current adoption rate of OSGi in his area and the participating companies, I would say that we will probably develop some pretty important standards in the coming time; specifications that will impact the work of many. Though we have a sufficient number of companies to get started, we can always use more!
Peter Kriens
.
How do you gather the requirements from 30 people at the same time? Not an easy task. We decided to first get a short introduction from all participatns and then let volunteers present their position statement. We got a few interesting presentations from Siemens, SAP, and others about where they see the opportunities for the OSGi specifications to play a role. We then spent some time doing a round table discussion to capture the ideas and requirements from the different participants. These ideas were categorized and then sorted by voting. After several failed voting system attempts we decided to vote with post-it notes glued to the projector screen, which reminded Jon Bork from Intel of “hanging chads”. Fortunately, we did not need the supreme court to intervene.
“Stay modular and small”. This was one of the first things Hal Hildebrand from Oracle said, and nobody disagreed. People like the OSGi technology because it was created for a constrained environment, which has given it a lean appearance. Unanimously, we liked to keep it that way. The new specifications required for the enterprise group should not fragment the world like J2ME and J2SE and neither should they bloat like J2EE. New features should be added in a modular fashion so that the basic framework is still usable in embedded environments.
A key requirement we identified was distribution. The strength of the OSGi specifications are that they specify a very efficient model for multiple applications to share a single VM in a single process. However, when moving to the enterprise it becomes crucial to provide mechanisms to scale to multiple processes, multiple VMs, multiple machines, and multiple languages. So far, we have not addressed outside VM issues because inter-process communications requires very CPU intensive mechanisms that are just no viable in resource constrained environments. It is, however, clear that the enterprise world is more than willing to pay the extra price for the increased scaling, availability, reliability, and access to applications written in other languages than Java that a distributed model can provide. As was remarked, most new code is just the fur on a giant hairball of legacy applications. From an implementation point of view, the OSGi service registry seems the perfect candidate to implement these requirements.
Another requirement was more focus on the whole life cycle of applications. The OSGi Alliance provides good specifications for the service platform but development, debugging, deployment, management, auditing, monitoring, patching, education, and certifications of applications have so far been out of scope. These were considered crucial aspects for “universal middleware” standard to succeed in the enterprises.
There was also a very interesting discussion about more comprehensive dependency management. Can we model the aspects that are outside the VM? More extensive metadata can go a long way to make deployments more accurate and offers possibilities in grid computing like models.
A number of new services were proposed. An interesting one was the network awareness service. I remember discussing such a service at least 5 years ago. Time flies. Also, people would like to see even more security mechanisms, an enhanced configuration admin, data synchronization, web services stacks, and several more.
There were many more topics raised and all of them deserve further discussions. However, the previously sketched areas seem to cover the most urgent needs. The next steps we have to take is chart a charter for the expert group, select a chair (if you are interested, you should propose yourself as a candidate), get board approval and then have our kick off meeting so we can start working. Most companies volunteered people to work on different aspects of the specifications..
The general scope of the EG is clear: We want to make OSGi feasible in the more distributed enterprise world and address the non-Java oriented aspects of enterprise applications. If your company is working in this scope, I would seriously consider joining. Looking at the current adoption rate of OSGi in his area and the participating companies, I would say that we will probably develop some pretty important standards in the coming time; specifications that will impact the work of many. Though we have a sufficient number of companies to get started, we can always use more!
Peter Kriens
.
Comments
| Previous Posts | Archives |
|---|---|
It would be great to join OSGi to work in this exciting area. Unfortunately it costs $20,000 per year and I don't have the support of a big software vendor or consulting firm as my employer to pay for this.
It's good that OSGi opened up a little with its Adopter Associate program ($3000 per year) but that is still too much for a small company or an individual, and anyway this membership level doesn't allow any participation in the EGs.
It's a shame that OSGi doesn't have the concept of an "individual expert"... even the good old JCP recognizes the value of contributions from individuals.
Regards
Neil