Reflecting on EclipseCon 2007
2007-03-12
If you followed this blog you have noticed how BJ Hargrave practiced real time blogging from his Blackberry. If you were not on the conference, you must have realized what you have missed a lot. For any OSGi aficionado, this was the conference to be.
So what were the top 3 observations?
Number one by far is just the sheer number of people that talked about OSGi success stories. I can only conclude that the OSGi technology must work. JBoss (who has just become an OSGi member), BEA, IBM, Siemens, Compuware, Oracle, and others all indicate that modularity really helps. Companies seem to benefit tremendously by having modularity. John Wells from BEA made an interesting observation about this. They had always thought they worked in a modular fashion until they tried to use the OSGi technology. To their utter surprise they found out when they ported their system to an OSGi platform that very little existing code was actually modular. I think this is common for all of us; if you do not verify the modularity of the systems you build, it is highly unlikely that you will have it. The only way to get the benefits of modularity is by enforcing the rules, and the OSGi specifications are one of the few standards in this area.
The second observation is that the OSGi service model is becoming more and more important. Interesting, because a few years ago we had serious discussions inside the OSGi Alliance if the service model was relevant. We even broke up the specification in different layers to allow the specifications to be advocated in parts: the execution environment, the module layer, the life cycle layer, and the service layer. Several parties in the industry told us that the modularity layer was cool but they had no use for the service layer. Some even said that did not want to use OSGi just for the service layer. Even in JSR 291 we considered removing the service layer. In the end we decided to keep this layer because it felt too weird to create a novel mechanism to provide the optional services like Package Admin service and Start Level service. It is now hard to believe that we ever considered this! Most projects presented on the EclipseCon were heavily using the service registry. There were even complaints about the support for making service usage simpler, a clear task for R5. A good example of the power of the service model was shown by Jan S. Rellermeyer from ETH. He made the service registry distributed, allowing applications to use each other’s services even if they ran on different machines. Distribution is a cornerstone for the Enterprise Expert Group so Jan’s presentation was very interesting in this light.
The last, but probably most important, observation is that we really need a book. I think that every presentation that I sat in started with complaining about the lack of documentation for beginners. Almost unanimously they like the quality of the specification but indicate that the specification is too concise and detailed for programmers that want to use the specification. It really is time to start writing this book about OSGi ... I am pretty sure others are working on this as well but I guess I can provide a lot of background information that others cannot. Sigh, if I only had more time.
We will clearly do something again on EclipseCon 2008. It was heartwarming to see how the people from the Eclipse Foundation have helped us this year: Ian Skerret, Mike Milinkovich, and Bjorn Freeman-Benson. They sure radiated a lot of enthusiasm for the OSGi technologies (I actually had to blush during the press conference). Thanks! I can assure you that the experience has been very good for us too!
Peter Kriens
P.S. I am speaking on Thursday at QCon inLondon
P.P.S. Next week we have a Vehicle Requirements meeting in Eindhoven, the Netherlands, which is open to non-OSGi members. Read more …
So what were the top 3 observations?
Number one by far is just the sheer number of people that talked about OSGi success stories. I can only conclude that the OSGi technology must work. JBoss (who has just become an OSGi member), BEA, IBM, Siemens, Compuware, Oracle, and others all indicate that modularity really helps. Companies seem to benefit tremendously by having modularity. John Wells from BEA made an interesting observation about this. They had always thought they worked in a modular fashion until they tried to use the OSGi technology. To their utter surprise they found out when they ported their system to an OSGi platform that very little existing code was actually modular. I think this is common for all of us; if you do not verify the modularity of the systems you build, it is highly unlikely that you will have it. The only way to get the benefits of modularity is by enforcing the rules, and the OSGi specifications are one of the few standards in this area.
The second observation is that the OSGi service model is becoming more and more important. Interesting, because a few years ago we had serious discussions inside the OSGi Alliance if the service model was relevant. We even broke up the specification in different layers to allow the specifications to be advocated in parts: the execution environment, the module layer, the life cycle layer, and the service layer. Several parties in the industry told us that the modularity layer was cool but they had no use for the service layer. Some even said that did not want to use OSGi just for the service layer. Even in JSR 291 we considered removing the service layer. In the end we decided to keep this layer because it felt too weird to create a novel mechanism to provide the optional services like Package Admin service and Start Level service. It is now hard to believe that we ever considered this! Most projects presented on the EclipseCon were heavily using the service registry. There were even complaints about the support for making service usage simpler, a clear task for R5. A good example of the power of the service model was shown by Jan S. Rellermeyer from ETH. He made the service registry distributed, allowing applications to use each other’s services even if they ran on different machines. Distribution is a cornerstone for the Enterprise Expert Group so Jan’s presentation was very interesting in this light.
The last, but probably most important, observation is that we really need a book. I think that every presentation that I sat in started with complaining about the lack of documentation for beginners. Almost unanimously they like the quality of the specification but indicate that the specification is too concise and detailed for programmers that want to use the specification. It really is time to start writing this book about OSGi ... I am pretty sure others are working on this as well but I guess I can provide a lot of background information that others cannot. Sigh, if I only had more time.
We will clearly do something again on EclipseCon 2008. It was heartwarming to see how the people from the Eclipse Foundation have helped us this year: Ian Skerret, Mike Milinkovich, and Bjorn Freeman-Benson. They sure radiated a lot of enthusiasm for the OSGi technologies (I actually had to blush during the press conference). Thanks! I can assure you that the experience has been very good for us too!
Peter Kriens
P.S. I am speaking on Thursday at QCon in
P.P.S. Next week we have a Vehicle Requirements meeting in Eindhoven, the Netherlands, which is open to non-OSGi members. Read more …
2. I made sort of a distributed service layer back in 2002. Didn't understand what I really was doing them tho... The ability to communicate between machines in a standardized way without using RMI or the Web service family was the goal.
3. Where's your book Peter? ;-) My wife says time is all we've got, it's a matter of priorities... I've now almost learned to appretiate the truth in it.