Already, 2005 is ending. An eventful year that I will not easy forget for many reasons. One reason this is a year not to forget is because we made it to the 3 dB point. Two years ago I was happy when Google indicated 4,000 pages on the term OSGi. I was thrilled when it doubled to 8,000. Today it stands at almost 700.000. Search for OSGi books on Google and you find an amazing number of books that mention OSGi. Until recently, I was the sole advertiser on Google for this term, today there are 5 companies advertising. And I think this is only the beginning …
Looking back, the best thing that happened this year was the uptake of the OSGi specifications by Eclipse and Apache. I was closely involved in the early investigations to move Eclipse to OSGi so there is a personal satisfaction that the transition worked so well. However, the credit should go to Thomas Watson, Jeff McAffer, and many others who replaced the Eclipse runtime with an OSGi implementation without causing many backward compatibility problems. Kudos! Many of these people have now taken the gospel and are actively advocating OSGi based solutions (with an obvious Eclipse sauce). The RCP and eRCP projects will likely get many design wins and promote the use of OSGi technology. Just as exciting is the move from Apache to use OSGi in Harmony (Java VM), Cocoon (Web technology), Directory, and other projects. Richard S. Hall’s Oscar project is used as the basis. This project is taking more and more shape and I expect exciting things from Apache in the coming year.
A positive change for the OSGi was the greater openness. This year we got approval from the board to publish the Release 4 specifications as drafts. This is a good thing, although I am disappointed by the little feedback we have had so far. Even the feedback in JSR 232 was quite minimal. Maybe part of the reason is that the biggest users of the specification could participate in the specification process, however, the feedback was still disappointingly low.
2006 is likely going to be even more exciting than 2005. It will be the year that the OSGi Mobile Platform specifications will be released. These specifications represent a vast amount of work that can make a lasting impression on the industry. The OSGi specifications provide a vastly superior alternative to MIDP 2.0 (and likely 3.0). MIDP has always been crippled so that it does not provide capabilities for much more than games. In contrast, the OSGi specifications permit software architectures that are required by system functions and enterprise applications. The OSGi Mobile Platform can be the critical enabler for a software market that can take advantage of the surprising capabilities of today’s higher end mobile phones. I get some very good vibes about the adoption of the Mobile Service Platform though I am also aware of the politics that surround JSR 232 and MIDP 3.0. However, an OSGi Mobile Platform will be able to run 3.0 Midlets using its Foreign Application specification. A MIDP 3.0 only environment will not be able to provide the many advantages of the OSGi service oriented architecture. I am convinced that common sense will prevail over politics once the specifications and implementations are out in the market. I am supposed to get an OSGi based Nokia phone next month, be sure to read my experiences next year.
The coming year we will have to work very hard to maintain the momentum that we picked up in this year. As the new OSGi evangelist I am looking forward to work with all of you to realize the OSGi vision of a common execution standard. Happy New Year!
Peter Kriens
OSGi Evangelist
OSGi Blog
Thursday, December 29, 2005
Friday, December 23, 2005
OSGi on the CCNC 2005
A few weeks ago our distinguished VP of Marketing, Susan Schwartze, told me I had one business night to write a proposal for a CCNC 2005 panel. As a dutiful Technical Director/Fellow/Evangelist I obeyed and delivered a text before the sun rose (ok, in Hawaii). Surprisingly, the proposal was accepted and as luck had it, I will find myself in Las Vegas next month.
The subject of the panel is “When Applications Can Roam Freely”, for a technical guy pretty poetic don’t you think? One of the key issues we try to achieve is to have a single standard for application development. Most standardization efforts are about how different computers can communicate; both on protocol and hardware level. The OSGi Alliance took another route and standardized the execution environment. Our vision is that many devices, large and small, can run the same components, despite differences in hardware, capacity and performance. If we succeed, it will enable a huge market of networked services and the derived need for hardware. This can become similar to how the standardized PC drove a trillion dollar market. The OSGi technology is already being delivered in products and services shipping from numerous Fortune Global 100 companies.
To achieve this vision, we face a tremendous task. A software standard that allows applications to roam freely has a certain overhead. In a world with cut-throat competition, any overhead is deemed as unacceptable. However, there are a number of trends in the market that will make more and more companies accept the overhead because in the end the gain will be more than the pain. It finally looks like, for example, that flash memory and CPUs are getting to price levels that are so low that the cost for Java is paid with the simpler development and more robust results.
And robust results we need. It is frightening how many devices break down or do not work exactly as they should. My wireless base station looses connection about five times a day. This week I bought a TV transmitter, but the Infrared transmitter did not work, well mostly. And I can go on of the user-unfriendliness of most devices. This sad state of affairs is caused by too much brittle, ill designed, software. A unified execution environment will create a component market where quality can thrive. Currently the market for embedded software is so fragmented that many little kingdoms can survive, despite the quality.
The last, but not least, force that is moving the market in our direction is the interconnectedness. More and more devices are getting a wireless or wired connection. This connectedness enables remote management and it creates many software opportunities. The connectedness of devices was what drove the original OSGi specifications in the first place.
If you are interested in discussing these options, take a chance and come to the CCNC in Las Vegas. The panel is manned by the heavy weights of the OSGi: Jon Bostrom the Java Architect from Nokia, Vince Izzo, Business Development, Motorola (connected home), Dave Marples, Ph.D., Chief Architect, EU Global System for Telematics, Telcordia Technologies (automotive), Paolo Pastorino, CTO, Home Gateway Initiative, and me.
If this illustrious company cannot shed led on the future of roaming applications, who can?
The subject of the panel is “When Applications Can Roam Freely”, for a technical guy pretty poetic don’t you think? One of the key issues we try to achieve is to have a single standard for application development. Most standardization efforts are about how different computers can communicate; both on protocol and hardware level. The OSGi Alliance took another route and standardized the execution environment. Our vision is that many devices, large and small, can run the same components, despite differences in hardware, capacity and performance. If we succeed, it will enable a huge market of networked services and the derived need for hardware. This can become similar to how the standardized PC drove a trillion dollar market. The OSGi technology is already being delivered in products and services shipping from numerous Fortune Global 100 companies.
To achieve this vision, we face a tremendous task. A software standard that allows applications to roam freely has a certain overhead. In a world with cut-throat competition, any overhead is deemed as unacceptable. However, there are a number of trends in the market that will make more and more companies accept the overhead because in the end the gain will be more than the pain. It finally looks like, for example, that flash memory and CPUs are getting to price levels that are so low that the cost for Java is paid with the simpler development and more robust results.
And robust results we need. It is frightening how many devices break down or do not work exactly as they should. My wireless base station looses connection about five times a day. This week I bought a TV transmitter, but the Infrared transmitter did not work, well mostly. And I can go on of the user-unfriendliness of most devices. This sad state of affairs is caused by too much brittle, ill designed, software. A unified execution environment will create a component market where quality can thrive. Currently the market for embedded software is so fragmented that many little kingdoms can survive, despite the quality.
The last, but not least, force that is moving the market in our direction is the interconnectedness. More and more devices are getting a wireless or wired connection. This connectedness enables remote management and it creates many software opportunities. The connectedness of devices was what drove the original OSGi specifications in the first place.
If you are interested in discussing these options, take a chance and come to the CCNC in Las Vegas. The panel is manned by the heavy weights of the OSGi: Jon Bostrom the Java Architect from Nokia, Vince Izzo, Business Development, Motorola (connected home), Dave Marples, Ph.D., Chief Architect, EU Global System for Telematics, Telcordia Technologies (automotive), Paolo Pastorino, CTO, Home Gateway Initiative, and me.
If this illustrious company cannot shed led on the future of roaming applications, who can?
Friday, December 16, 2005
Apache and OSGi
This week I was on Apache Con 2005, the yearly conference of open source developers under the Apache flag. Together with Richard S. Hall, Enrique Rodriguez, Jeff McAffer, BJ Hargrave, Jason van Zijl , I was invited to participate in a panel about OSGi technology. Several Apache projects are already using OSGi (like the Apache Directory project) and others are eying it, like the Harmony VM project and Cocoon. This week I was there to spread the OSGi gospel as well as learn how these hard-core developers see OSGi.
I learned several things. First that there are only three things important about software: licenses, licenses, licenses. It is amazing how almost any technical discussion today ends up debating the merits of the Apache Software License 2.0 over the viral GPL, or how BSD lacks the patent clause. Where are the good old days we could discuss garbage collection without sweeping over copyrights, patents, and disclaimers?
The next hot thing seems to be the build. Building software is an art that many people try to master. Apache projects try to be self supporting so after the horror of ant they now consider maven the next best thing, well, maven-2, because maven one seem to have had some shortcomings. Despite the use of XML (which seems a mandatory requirement for an Apache project), maven is a significant improvement over ant for builds.
The problem with ant is that it basically a (terribly bad) script language, causing incredible redundancy and very hard to manage projects. Maven is different, it centralizes the rules of project building. The only thing the project provides is the Project Object Model (POM file, and yes, it is defined in XML), which provides a description of the project. This decouples the project from the build features. New features can be added that do not require changes in every POM file. Maven provides an impressive number of plugins, which provide the features. One such plugin is the OSGi plugin, which is being developed to create the OSGi bundles and its artifacts. Maven is definitely in the right direction except that the POM file should have been designed for human consumption instead of plugin consumption.
I also learned why many people in the Apache Foundation are eyeing OSGi: containerism. It is hard to get any details but Apache seems have sent the Avalon project to the wholly hunting grounds. Avalon was a project that should have made an OSGi like system available to all the other Apache projects. After a number of years the project was shut down because the group could not unify on a single design (I think this is an euphemism). I recall that a couple of years ago I tried to convince the Avalon project to take a look at OSGi, but I failed miserably to attract their attention.
On this conference, several people told me that the greatest strength of the OSGi is that Apache can not change it. Or as someone said, Apache is great at implementing a specification, but has serious problems with designing from scratch. This makes sense to me, when you have a diverse group of developers, spread around the world, with diverse backgrounds, and when they are all peers, then it is impossible to make complex designs. I am already terribly impressed with the breadth and the quality of the implementations they produce.
After this week, I am convinced that you will see a lot of OSGi at Apache. It seems to be the right moment for the organization to standardize on a single container model, and the OSGi is the best in the market. The Felix incubator project makes it very easy to use an OSGi Framework in an Apache project. The OSGi plugin for maven will make it easy to created the bundles. However, OSGi technology is not a run race for all projects. Some of the code bases are humongous and converting them into components will require effort. The key missing part is good tooling because providing the import export clauses by hand is too much work. This is a common problem and I am currently seeking approval to make the OSGi tools available to the community.
It will be interesting to see how much of the Apache code base will be converted over the coming year. I think many projects will convert. I bet next year I can directly download bundles from Apache.
I learned several things. First that there are only three things important about software: licenses, licenses, licenses. It is amazing how almost any technical discussion today ends up debating the merits of the Apache Software License 2.0 over the viral GPL, or how BSD lacks the patent clause. Where are the good old days we could discuss garbage collection without sweeping over copyrights, patents, and disclaimers?
The next hot thing seems to be the build. Building software is an art that many people try to master. Apache projects try to be self supporting so after the horror of ant they now consider maven the next best thing, well, maven-2, because maven one seem to have had some shortcomings. Despite the use of XML (which seems a mandatory requirement for an Apache project), maven is a significant improvement over ant for builds.
The problem with ant is that it basically a (terribly bad) script language, causing incredible redundancy and very hard to manage projects. Maven is different, it centralizes the rules of project building. The only thing the project provides is the Project Object Model (POM file, and yes, it is defined in XML), which provides a description of the project. This decouples the project from the build features. New features can be added that do not require changes in every POM file. Maven provides an impressive number of plugins, which provide the features. One such plugin is the OSGi plugin, which is being developed to create the OSGi bundles and its artifacts. Maven is definitely in the right direction except that the POM file should have been designed for human consumption instead of plugin consumption.
I also learned why many people in the Apache Foundation are eyeing OSGi: containerism. It is hard to get any details but Apache seems have sent the Avalon project to the wholly hunting grounds. Avalon was a project that should have made an OSGi like system available to all the other Apache projects. After a number of years the project was shut down because the group could not unify on a single design (I think this is an euphemism). I recall that a couple of years ago I tried to convince the Avalon project to take a look at OSGi, but I failed miserably to attract their attention.
On this conference, several people told me that the greatest strength of the OSGi is that Apache can not change it. Or as someone said, Apache is great at implementing a specification, but has serious problems with designing from scratch. This makes sense to me, when you have a diverse group of developers, spread around the world, with diverse backgrounds, and when they are all peers, then it is impossible to make complex designs. I am already terribly impressed with the breadth and the quality of the implementations they produce.
After this week, I am convinced that you will see a lot of OSGi at Apache. It seems to be the right moment for the organization to standardize on a single container model, and the OSGi is the best in the market. The Felix incubator project makes it very easy to use an OSGi Framework in an Apache project. The OSGi plugin for maven will make it easy to created the bundles. However, OSGi technology is not a run race for all projects. Some of the code bases are humongous and converting them into components will require effort. The key missing part is good tooling because providing the import export clauses by hand is too much work. This is a common problem and I am currently seeking approval to make the OSGi tools available to the community.
It will be interesting to see how much of the Apache code base will be converted over the coming year. I think many projects will convert. I bet next year I can directly download bundles from Apache.
Tuesday, December 13, 2005
The OSGi Mobile Specification
Last week the OSGi Alliance made the latest draft available of the Mobile Platform Specification. This draft is function complete and it is not likely to change anymore; only the last bits are being ironed out.
The Mobile Platform Specification is developed in conjunction with the JCP in the JSR 232. It would soon be available from their web site as well (it takes a surprising long time to reach the www.jcp.org web site after the document is submitted). The OSGi Mobile Platform Specification is up for inclusion in the upcoming JSR 249 Mobile Architecture for CDC. If the Mobile OSGi Platform is included in JSR 249, it will mean that higher-end mobile phones will start running OSGi service platforms.
The OSGi Mobile Platform primarily adds the Service Platform to mobile devices. This is exactly the OSGi R4 Service Platform that is already used for home automation, vehicles, desktop, and high end servers. However, the mobile experts, under guidance of Motorola and Nokia, have extended the platform with a number of services that were deemed crucial for the mobile market. The key focus has been on device management, managed deployment, application management.
A key requirement for the OSGi Mobile Platform was to simplify application programmer. MIDP has been a great source of revenue for operators because there are so many Midlets available. Obviously, any Mobile Platform must support this revenue stream. However, there are multiple MIDP versions and derivatives in this world. Worse, there also exist other application models like DoJa, BREW, Symbian, and other application models. OSGi Service Platforms are capable of hosting a large range of application models within their architecture. The Mobile platform has added two service specifications. The Foreign Application Specification defines how applications can interact with the OSGi service registry. Foreign Applications can both use as well as provide services. The Application Management Specification defines how different application models can be managed by other applications: launching, stopping, enumerating, etc. This specification allows screen managers that work on different mobile phones.
The Device Admin Specification borrows its concepts from the OMA DM standard, which is basically a tree based model for configuration information. The API allows both the implementation of nodes in this tree as well as the manipulation of the tree. For integrity, the manipulation can be fully transactional. A similar API was developed in Siemens’ JSR 246, we are working with this JSR to align the APIs. JSR 246 was originally based on the OSGi source base but over time deviated. It would be ridiculous to have two APIs that look very much alike but would not be compatible; the two teams therefore work actively together to resolve the issues.
The Mobile Expert Group felt that bundles were too small in granularity. We therefore added a new artifact: Deployment Packages. A Deployment Package, with mime type application/vnd.osgi.dp, can contain bundles and other resources. An advanced mechanism allows resources in a Deployment Package to be handled by an extendable mechanism. This architecture allows the processing of certificates, configuration information, and other types of resources. A special Deployment Package can be used to update an installed Deployment Package; such Fix-Packs only contain the new resources and bundles. The Deployment Admin service provides facilities, to enumerate, query, install, and uninstall Deployment Packages.
The OSGi Mobile Platform holds great promise for mobile devices. It provides a secure and managed computing platform that does not cripple its applications. Watch this space for information about SDKs for the Mobile Service Platform.
Do you have any questions about the Mobile Service Platform Draft, ask me!
Peter Kriens
The Mobile Platform Specification is developed in conjunction with the JCP in the JSR 232. It would soon be available from their web site as well (it takes a surprising long time to reach the www.jcp.org web site after the document is submitted). The OSGi Mobile Platform Specification is up for inclusion in the upcoming JSR 249 Mobile Architecture for CDC. If the Mobile OSGi Platform is included in JSR 249, it will mean that higher-end mobile phones will start running OSGi service platforms.
The OSGi Mobile Platform primarily adds the Service Platform to mobile devices. This is exactly the OSGi R4 Service Platform that is already used for home automation, vehicles, desktop, and high end servers. However, the mobile experts, under guidance of Motorola and Nokia, have extended the platform with a number of services that were deemed crucial for the mobile market. The key focus has been on device management, managed deployment, application management.
A key requirement for the OSGi Mobile Platform was to simplify application programmer. MIDP has been a great source of revenue for operators because there are so many Midlets available. Obviously, any Mobile Platform must support this revenue stream. However, there are multiple MIDP versions and derivatives in this world. Worse, there also exist other application models like DoJa, BREW, Symbian, and other application models. OSGi Service Platforms are capable of hosting a large range of application models within their architecture. The Mobile platform has added two service specifications. The Foreign Application Specification defines how applications can interact with the OSGi service registry. Foreign Applications can both use as well as provide services. The Application Management Specification defines how different application models can be managed by other applications: launching, stopping, enumerating, etc. This specification allows screen managers that work on different mobile phones.
The Device Admin Specification borrows its concepts from the OMA DM standard, which is basically a tree based model for configuration information. The API allows both the implementation of nodes in this tree as well as the manipulation of the tree. For integrity, the manipulation can be fully transactional. A similar API was developed in Siemens’ JSR 246, we are working with this JSR to align the APIs. JSR 246 was originally based on the OSGi source base but over time deviated. It would be ridiculous to have two APIs that look very much alike but would not be compatible; the two teams therefore work actively together to resolve the issues.
The Mobile Expert Group felt that bundles were too small in granularity. We therefore added a new artifact: Deployment Packages. A Deployment Package, with mime type application/vnd.osgi.dp, can contain bundles and other resources. An advanced mechanism allows resources in a Deployment Package to be handled by an extendable mechanism. This architecture allows the processing of certificates, configuration information, and other types of resources. A special Deployment Package can be used to update an installed Deployment Package; such Fix-Packs only contain the new resources and bundles. The Deployment Admin service provides facilities, to enumerate, query, install, and uninstall Deployment Packages.
The OSGi Mobile Platform holds great promise for mobile devices. It provides a secure and managed computing platform that does not cripple its applications. Watch this space for information about SDKs for the Mobile Service Platform.
Do you have any questions about the Mobile Service Platform Draft, ask me!
Peter Kriens
Tuesday, December 6, 2005
The Smell of Success
Today I got three different mails about Apache and OSGi. First someone proudly told me that Apache Derby was OSGi Ready! Yes, I knew for a ages! Derby was submitted to Apache by IBM. When inside IBM, they had made it available on SMF, their OSGi Framework implementation. Derby can now rightfully claim to be the first, stealth, OSGi beach head in the Apache Foundation.
In the beginning of this year, the Apache Directory project contacted Richard S. Hall and asked him if Oscar could become an Apache project. Enrique Rodriguez did much of the work in convincing the Apache board and Richard to follow the OSGi route. The transfer between Objectweb (Oscar’s previous home) and Apache was not completely smooth (I had to act as a virtual shoulder sometimes) but everything worked out in the end. Apache Felix is currently an incubator, but I hope they move it to a top level project soon. Looking at all the OSGi related activities in Apache it looks like it is becoming a crucial cornerstone.
So far this is history, but today I also learnt something new. I got a mail with a link to a blog: The Blockathon Report. It seems that Cocoon is also seriously considering bundleizing their work. From their web site: “Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development.” From that description, it seems that OSGi could provide a solid foundation. This made me curious of course, so I started to dig a bit to see if more projects were adopting OSGi. I found that Velocity, a template expansion language for web servers was also bundleized. Velocity seems to be derived from Webmacros, a template engine that I really enjoyed working with a couple of years ago. The OSGi version does not seem to be in the latest 1.4 revision, but I guess it will be there soon. In another blog I read that the James project is also considering OSGi. James is a mail server.
But the biggest surprise was when (also today) I got a mail that showed that the Apache Harmony project is considering the the OSGi Framework. The Harmony project is attempting to develop a Java VM with an Apache License (cool!). The idea that was expressed in the mail is to use the OSGi modularity layer in the VM, and deliver the core VM with the OSGi Minimum Execution Environment. This allows the JVM to bootstrap an OSGi Framework. The modularity and lifecycle layer can then be used to add additional APIs as desired. No more profiles that are always too much or too little, every deployment can decide what APIs are necessary. It is even possible to download APIs only when they are needed. That is the way J2SE should be delivered.
All this is really exciting for someone that recently watched the baby-steps of the OSGi Alliance. I think that the popularity of the OSGi specifications will continue to rise. We will face some interesting times, for example, will we be able to control the developments of new service interfaces? Apache, Eclipse, are vibrant organizations that will soon discover that it is cool to develop service specifications. It will be interesting to see if the OSGi can remain the focus point for the standardization of these services. For the sake of the industry, it would be best if we could share these interface definitions.
Well, did I forget any Apache projects that adopt OSGi? Let me know!
Hope to see many of you next week on ApacheCon 2005.
In the beginning of this year, the Apache Directory project contacted Richard S. Hall and asked him if Oscar could become an Apache project. Enrique Rodriguez did much of the work in convincing the Apache board and Richard to follow the OSGi route. The transfer between Objectweb (Oscar’s previous home) and Apache was not completely smooth (I had to act as a virtual shoulder sometimes) but everything worked out in the end. Apache Felix is currently an incubator, but I hope they move it to a top level project soon. Looking at all the OSGi related activities in Apache it looks like it is becoming a crucial cornerstone.
So far this is history, but today I also learnt something new. I got a mail with a link to a blog: The Blockathon Report. It seems that Cocoon is also seriously considering bundleizing their work. From their web site: “Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development.” From that description, it seems that OSGi could provide a solid foundation. This made me curious of course, so I started to dig a bit to see if more projects were adopting OSGi. I found that Velocity, a template expansion language for web servers was also bundleized. Velocity seems to be derived from Webmacros, a template engine that I really enjoyed working with a couple of years ago. The OSGi version does not seem to be in the latest 1.4 revision, but I guess it will be there soon. In another blog I read that the James project is also considering OSGi. James is a mail server.
But the biggest surprise was when (also today) I got a mail that showed that the Apache Harmony project is considering the the OSGi Framework. The Harmony project is attempting to develop a Java VM with an Apache License (cool!). The idea that was expressed in the mail is to use the OSGi modularity layer in the VM, and deliver the core VM with the OSGi Minimum Execution Environment. This allows the JVM to bootstrap an OSGi Framework. The modularity and lifecycle layer can then be used to add additional APIs as desired. No more profiles that are always too much or too little, every deployment can decide what APIs are necessary. It is even possible to download APIs only when they are needed. That is the way J2SE should be delivered.
All this is really exciting for someone that recently watched the baby-steps of the OSGi Alliance. I think that the popularity of the OSGi specifications will continue to rise. We will face some interesting times, for example, will we be able to control the developments of new service interfaces? Apache, Eclipse, are vibrant organizations that will soon discover that it is cool to develop service specifications. It will be interesting to see if the OSGi can remain the focus point for the standardization of these services. For the sake of the industry, it would be best if we could share these interface definitions.
Well, did I forget any Apache projects that adopt OSGi? Let me know!
Hope to see many of you next week on ApacheCon 2005.
Thursday, December 1, 2005
The OSGi Specifications are finding their home in places that we never dreamt of when we started in 1998. We always thought we were working for small embedded devices, doing things small and embedded devices do. Surprisingly, the specifications are increasingly being used in Enterprise applications as well.
The Apache foundation has adopted the OSGi specifications in the form of Felix, formerly called Oscar. The Apache Directory project started to use Oscar some time ago and fell in love with it (This is the first Apache project I know that does not have a silly name). Felix is now an incubator and many parties are looking at how they could use OSGi in their projects. Active work is going on in convincing Apache committers that it is worth to bundleize their work.
Last week I was pointed at an Alphaworks project called WSRF plugins that provides a number of bundles to use Web Services on an OSGi Service Platform. It enables services running in an OSGi Service Platform to expose themselves as remotely accessible and manageable resources using WSRF. The purpose of the Web Services Resource Framework (WSRF) is to model and access stateful resources using Web services. Examples are: mechanisms to describe views on the state, to support management of the state, and to describe how to extend this to groups of Web services. The toolkit provides an example how to make OSGi bundles stateful resources that can be lifecyle managed using web services. I did not yet have the time to play with it, but it looks very interesting if you work with web services. The download is a bit steep, but that is caused because it includes a lot of documentation and a copy of SMF. However, BJ Hargrave assured me that it should work on other OSGi Frameworks as well. For this blog I would have loved a tiny Hello World example, the Address Book example was just a trifle too big for me. If you have downloaded this toolkit, pop me a mail with your experiences.
As last example, JOnAS is a certified J2EE server that embeds an OSGi framework for modularity and deployment reasons. I have heard that they are not the only group looking at using OSGi frameworks in J2EE servers. The deployment aspects of J2EE have been partly overlooked and OSGi seems a perfect match for the needs.
Inside the OSGi we are working on a Web Container standard (for members only). The OSGi Web Container provides support for web applications using the Servlet and JSP interfaces. The current OSGi Http Service works requires application efforts to work well with web applications. We are investigating if we can seriously simplify this.
Much, much more is happening in the Enterprise world with OSGi. IBM has clearly seen the light and are using OSGi in many different applications. If you have applications in the Enterprise world please tell me.
Last but not least, next week I will visit ApacheCon in San Diego. I always love to talk to OSGi fans, so do not hesitate to contact me.
Peter Kriens
OSGi Evangelist
The Apache foundation has adopted the OSGi specifications in the form of Felix, formerly called Oscar. The Apache Directory project started to use Oscar some time ago and fell in love with it (This is the first Apache project I know that does not have a silly name). Felix is now an incubator and many parties are looking at how they could use OSGi in their projects. Active work is going on in convincing Apache committers that it is worth to bundleize their work.
Last week I was pointed at an Alphaworks project called WSRF plugins that provides a number of bundles to use Web Services on an OSGi Service Platform. It enables services running in an OSGi Service Platform to expose themselves as remotely accessible and manageable resources using WSRF. The purpose of the Web Services Resource Framework (WSRF) is to model and access stateful resources using Web services. Examples are: mechanisms to describe views on the state, to support management of the state, and to describe how to extend this to groups of Web services. The toolkit provides an example how to make OSGi bundles stateful resources that can be lifecyle managed using web services. I did not yet have the time to play with it, but it looks very interesting if you work with web services. The download is a bit steep, but that is caused because it includes a lot of documentation and a copy of SMF. However, BJ Hargrave assured me that it should work on other OSGi Frameworks as well. For this blog I would have loved a tiny Hello World example, the Address Book example was just a trifle too big for me. If you have downloaded this toolkit, pop me a mail with your experiences.
As last example, JOnAS is a certified J2EE server that embeds an OSGi framework for modularity and deployment reasons. I have heard that they are not the only group looking at using OSGi frameworks in J2EE servers. The deployment aspects of J2EE have been partly overlooked and OSGi seems a perfect match for the needs.
Inside the OSGi we are working on a Web Container standard (for members only). The OSGi Web Container provides support for web applications using the Servlet and JSP interfaces. The current OSGi Http Service works requires application efforts to work well with web applications. We are investigating if we can seriously simplify this.
Much, much more is happening in the Enterprise world with OSGi. IBM has clearly seen the light and are using OSGi in many different applications. If you have applications in the Enterprise world please tell me.
Last but not least, next week I will visit ApacheCon in San Diego. I always love to talk to OSGi fans, so do not hesitate to contact me.
Peter Kriens
OSGi Evangelist
Thursday, November 24, 2005
Btool, the OSGi Bundle Maker
Bundles are plain old JAR files, which in their turn are plain old ZIP files. The JAR files are a convenient container for code and resources, grouped in packages. Additionally, a manifest is provided that provides bits and pieces of information about the contents. The common way to make a bundle is to create a directory structure that mirrors the desired structure and then use the jar-tool of the JDK to create the JAR file.
Unfortunately, this way of working is error prone because the contents of the JAR are closely related to the manifest. The manifest must specify the packages that can be exported (available to others) as well as which packages must be imported. This is not trivial, especially when bundles are designed as small, self contained, cohesive units, for example, OSGi RI and TCK consist over 700 bundles, which have a myriad of relations among each other.
Another problem is that making the intermediate directory structure is usually done in highly project dependent ant or make files. These scripts are hard to read, which makes it difficult to get an overview how the JAR file is structured. A particularly tricky problem is when a JAR file needs a copy of a package that is on the class path, this is almost impossible without special support.
Meet Btool. Btool started its life in 1998 when I got so frustrated with making bundles using only the jar-tool as support. Tracking import- and exported packages and their versions are not my description of fun. I was working for Ericsson Research at that time and had to help a lot of people making bundles.
The first version of Btool was given a root class, which it then recursively parsed for all dependencies. Command line parameters were used to indicate which packages should packed in the JAR. From this information, Btool could calculate the import and export clauses. Versions were derived from a file called packageinfo, which we maintain in each package directory. The packageinfo file is also packed in the JAR.
Btool generates the manifest from the generated JAR and a raw-manifest file that can contain property references. An example raw-manifest file:
Manifest-Version: 1.0
Bundle-Name: ${p}
Bundle-Activator: ${p}.Activator
Bundle-Description: The %24{p} variable is
replaced with the project name ${p}
Comment: $(DATE)
$(IMPORT-PACKAGE)
$(EXPORT-PACKAGE)
$(PRIVATE-PACKAGE)
The manifest file is pre-processed and the property references are replaced with the appropriate information. Btool supports an extensive number of macros like substitute, prefix/suffix, sort, filter, and more.
Since then a lot has changed, we are currently at generation 3. Btool is now an ant task and completely driven by a properties file. Eclipse drove the use of the build.properties file (which is standard in Eclipse) but in the end they have become incompatible. A typical build.properties file looks like:
jars.compile.order=${p}.jar
expand.${p} = [com.acme.mybundle], \
com.acme.util.*
include.mybundle.jar = [doc/license.html], \
doc/help.html, \
[README.txt]
The expand property indicates the packages that should be stored in the JAR, which come from the project’s class path. If the package is enclosed with square brackets ([]), it means the package is to be exported. Package can contain wildcards, which will include all packages starting with that prefix. The project’s class path can be set with the Eclipse IDE (we use the .classpath file) or the classpath property can be set to a list of directories or JAR files. The include property will copy files into the JAR. If a file is enclosed with square brackets, it will be pre-processed just like the manifest.
While creating the JAR file, Btool can store all the sources in the OPT-INF/src directory, calculate the Name sections, create files for initial provisioning, and can do many more functions. However, crucial is the analysis phase at the end. When the JAR file is created, Btool can open it again and analyze it for consistency. It will check the import/export sections, checks if the Bundle Activator is in the JAR or imported, looks at the Bundle-Classpath, and does many more checks. The analysis has saved me from endless grief.
I am so used to Btool that for me personally it is hard to see how you can make bundles without it. However, must people are doing well without it looking at the large number of bundles that are created. However, there is work going on. In the Oscar/Felix project there is mangen that creates manifests for a set of bundles. There is also the OSGi plugin for the Maven project, Eclipse is working hard on bundle tools, and there are plugins. However, when you are member of OSGi, take a look at the OSGi repository on membercvs and see how Btool can be used to simplify your projects.
Unfortunately, this way of working is error prone because the contents of the JAR are closely related to the manifest. The manifest must specify the packages that can be exported (available to others) as well as which packages must be imported. This is not trivial, especially when bundles are designed as small, self contained, cohesive units, for example, OSGi RI and TCK consist over 700 bundles, which have a myriad of relations among each other.
Another problem is that making the intermediate directory structure is usually done in highly project dependent ant or make files. These scripts are hard to read, which makes it difficult to get an overview how the JAR file is structured. A particularly tricky problem is when a JAR file needs a copy of a package that is on the class path, this is almost impossible without special support.
Meet Btool. Btool started its life in 1998 when I got so frustrated with making bundles using only the jar-tool as support. Tracking import- and exported packages and their versions are not my description of fun. I was working for Ericsson Research at that time and had to help a lot of people making bundles.
The first version of Btool was given a root class, which it then recursively parsed for all dependencies. Command line parameters were used to indicate which packages should packed in the JAR. From this information, Btool could calculate the import and export clauses. Versions were derived from a file called packageinfo, which we maintain in each package directory. The packageinfo file is also packed in the JAR.
Btool generates the manifest from the generated JAR and a raw-manifest file that can contain property references. An example raw-manifest file:
Manifest-Version: 1.0
Bundle-Name: ${p}
Bundle-Activator: ${p}.Activator
Bundle-Description: The %24{p} variable is
replaced with the project name ${p}
Comment: $(DATE)
$(IMPORT-PACKAGE)
$(EXPORT-PACKAGE)
$(PRIVATE-PACKAGE)
The manifest file is pre-processed and the property references are replaced with the appropriate information. Btool supports an extensive number of macros like substitute, prefix/suffix, sort, filter, and more.
Since then a lot has changed, we are currently at generation 3. Btool is now an ant task and completely driven by a properties file. Eclipse drove the use of the build.properties file (which is standard in Eclipse) but in the end they have become incompatible. A typical build.properties file looks like:
jars.compile.order=${p}.jar
expand.${p} = [com.acme.mybundle], \
com.acme.util.*
include.mybundle.jar = [doc/license.html], \
doc/help.html, \
[README.txt]
The expand property indicates the packages that should be stored in the JAR, which come from the project’s class path. If the package is enclosed with square brackets ([]), it means the package is to be exported. Package can contain wildcards, which will include all packages starting with that prefix. The project’s class path can be set with the Eclipse IDE (we use the .classpath file) or the classpath property can be set to a list of directories or JAR files. The include property will copy files into the JAR. If a file is enclosed with square brackets, it will be pre-processed just like the manifest.
While creating the JAR file, Btool can store all the sources in the OPT-INF/src directory, calculate the Name sections, create files for initial provisioning, and can do many more functions. However, crucial is the analysis phase at the end. When the JAR file is created, Btool can open it again and analyze it for consistency. It will check the import/export sections, checks if the Bundle Activator is in the JAR or imported, looks at the Bundle-Classpath, and does many more checks. The analysis has saved me from endless grief.
I am so used to Btool that for me personally it is hard to see how you can make bundles without it. However, must people are doing well without it looking at the large number of bundles that are created. However, there is work going on. In the Oscar/Felix project there is mangen that creates manifests for a set of bundles. There is also the OSGi plugin for the Maven project, Eclipse is working hard on bundle tools, and there are plugins. However, when you are member of OSGi, take a look at the OSGi repository on membercvs and see how Btool can be used to simplify your projects.
Thursday, November 17, 2005
Why Did We Let Jini Out of OSGi R4
The OSGi Service Platform Release 4 was the first release where we actually dropped a specification. In R3, there was a special section that we named “Recommended”, clearly indicating that they were no specifications. It contained the UPnP™, JINI, Namespace, and Initial Provisioning recommendations.
So in R4 we needed to make the decision to elevate these recommendations to specification status. The UPnP and Initial Provisioning recommendations were obvious candidates for elevation while the Name Space recommendation was just as obvious for removal. The Jini recommendation was a harder because Jini itself was not completely dead. So after some soul searching we decided to remove the Jini recommendation for the following reasons:
So where the UPnP recommendation had several members highly interested, no such defenders could be found for the Jini recommendation. Also looking at the outside world, it is clear that the UPnP adoption is gaining momentum, in contrast with Jini.
Personally, I absolutely loved the Jini specifications, never read a more well written architecture specification. However, after I spent some serious time with it, which was in 1997 when I first met Jon Bostrom selling Jini together with Billy Joy, I was very disappointed. The implementation was so bad, that I have a hard time believing they have been able to solve all the problems in these 8 years.
I must admit I am surprised it keeps popping up in different places, but it somehow refuses to die, regardless of the number of places where it fails. Ever seen a consumer Jini device?
Interestingly, Service Location Protocol (SLP) seems to be popping up its pretty head again. This is intriguing because SUN, as author of SLP and JINI, politically decided to assassinate SLP in favor of Jini. SLP (as I recall) supports a mode where it carries a JAR file, which is of course a perfect match for OSGi. And SLP is basically the Jini network discovery protocol without the additional the requirements for Java and its security implications.
Maybe the OSGi should take a look at SLP? Let me know.
Peter Kriens
OSGi Evangelist
So in R4 we needed to make the decision to elevate these recommendations to specification status. The UPnP and Initial Provisioning recommendations were obvious candidates for elevation while the Name Space recommendation was just as obvious for removal. The Jini recommendation was a harder because Jini itself was not completely dead. So after some soul searching we decided to remove the Jini recommendation for the following reasons:
- None of the members showed any interested in this recommendation or defended it.
- Jini was considered more or less on life-support if not already declared dead.
- Security implications that are caused by Jini were not compatible with the strong security model of the OSGi specifications.
- Complex interactions between class loaders made the use of Jini cumbersome.
- The problem of loading ill-defined code in your VM
So where the UPnP recommendation had several members highly interested, no such defenders could be found for the Jini recommendation. Also looking at the outside world, it is clear that the UPnP adoption is gaining momentum, in contrast with Jini.
Personally, I absolutely loved the Jini specifications, never read a more well written architecture specification. However, after I spent some serious time with it, which was in 1997 when I first met Jon Bostrom selling Jini together with Billy Joy, I was very disappointed. The implementation was so bad, that I have a hard time believing they have been able to solve all the problems in these 8 years.
I must admit I am surprised it keeps popping up in different places, but it somehow refuses to die, regardless of the number of places where it fails. Ever seen a consumer Jini device?
Interestingly, Service Location Protocol (SLP) seems to be popping up its pretty head again. This is intriguing because SUN, as author of SLP and JINI, politically decided to assassinate SLP in favor of Jini. SLP (as I recall) supports a mode where it carries a JAR file, which is of course a perfect match for OSGi. And SLP is basically the Jini network discovery protocol without the additional the requirements for Java and its security implications.
Maybe the OSGi should take a look at SLP? Let me know.
Peter Kriens
OSGi Evangelist
Monday, November 14, 2005
OSGi Test Suites
I am currently working on the most important, but also very boring, part of the obligations we have in the OSGi Alliance: the test suites. This time around it was a bit different though, we had a single company writing most of the test suites. Normally this is more dispersed. CESAR is a Brazilian research institute that was hired by IBM and Motorola to provide many of the required test suites, and they have done a thorough job. The requirements of the test suites were higher for this release because we will license the test suites to any company that wants to be compliant with JSR 232. The test suites are of course free for any OSGi Alliance member.
The test suites are based on the nowadays standard JUnit model. The key difference is that we deploy them as bundles. We include a facility that allows test suites to run on the target machine and a facilitating machine, this setup makes it impossible to use a single bundle for a test suite. The facilitating machine sets up the environment and then downloads a testcase to the target. The target executes the testcases that can interact with the facilitating machine. This makes it possible to minimize the requirements on the target machine and removes the need for manual interaction. This has turned out to be a very elegant model, we are very happy with it.
But these weeks we have to get all the parts together, coming from several continents, and quite a lot of people. Lot of work, but fortunately, it looks like we are getting there.
There are discussion going on to make the OSGi test tooling available outside the OSGi Alliance. If you are interested, let us know.
Peter Kriens
OSGi Evangelist
I am currently working on the most important, but also very boring, part of the obligations we have in the OSGi Alliance: the test suites. This time around it was a bit different though, we had a single company writing most of the test suites. Normally this is more dispersed. CESAR is a Brazilian research institute that was hired by IBM and Motorola to provide many of the required test suites, and they have done a thorough job. The requirements of the test suites were higher for this release because we will license the test suites to any company that wants to be compliant with JSR 232. The test suites are of course free for any OSGi Alliance member.
The test suites are based on the nowadays standard JUnit model. The key difference is that we deploy them as bundles. We include a facility that allows test suites to run on the target machine and a facilitating machine, this setup makes it impossible to use a single bundle for a test suite. The facilitating machine sets up the environment and then downloads a testcase to the target. The target executes the testcases that can interact with the facilitating machine. This makes it possible to minimize the requirements on the target machine and removes the need for manual interaction. This has turned out to be a very elegant model, we are very happy with it.
But these weeks we have to get all the parts together, coming from several continents, and quite a lot of people. Lot of work, but fortunately, it looks like we are getting there.
There are discussion going on to make the OSGi test tooling available outside the OSGi Alliance. If you are interested, let us know.
Peter Kriens
OSGi Evangelist
Thursday, November 10, 2005
The UPnP and OSGi Specifications
A common misconception is that OSGi and UPnP are competing standards. Well, the good news is that they are definitely not in competition! Actually, they work surprisingly well together. That is good news for us because more and more devices are UPnP enabled. Interestingly, very few devices actually are labeled with the UPnP Forum brand, but it is introduced in virtually any networked device, which are in increasing number of consumer devices. For example, when I start an OSGi Framework at home, I can see the registration of:
A common misconception is that OSGi and UPnP are competing standards. Well, the good news is that they are definitely not in competition! Actually, they work surprisingly well together. That is good news for us because more and more devices are UPnP enabled. Interestingly, very few devices actually are labeled with the UPnP Forum brand, but it is introduced in virtually any networked device, which are in increasing number of consumer devices. For example, when I start an OSGi Framework at home, I can see the registration of:
- A Belkin Wireless Network Router
- A Linksys network storage unit
- A Go Video Networked DVD Player,
- Two Xerox Printers
- A Media-Player on another PC
- A Wireless camera
This silent revolution is very good news for OSGi users, UPnP addresses the key issue of how to communicate with CE devices, something that is beyond the scope of the OSGi Alliance. But what does the OSGi Alliance then provides? The OSGi provides the secure place to run all those programs that provide UPnP devices (like Media Players, for example) and programs that control those UPnP devices.
There is a big need for the flexibility that an OSGi Platform provides because not everything is rosy in the UPnP world. The specification is in certain areas rather loose, and too many programmers are rather lax, which means that there are many interoperability problems. I actually have to run two different media servers to server my two media players. However, these incompatibilities are an opportunity for OSGi based platforms. Additionally, not all devices have the resources to provide UPnP interfaces; a perfect opportunity for an OSGi Platform to bridge this device so that it can be controlled by UPnP remote controllers. The managed application is well suited to a world where many mediations between devices are necessary.
UPnP enabled devices are a very interesting opportunity for OSGi platforms. I know that many people are working on it. This will be big in the coming years, mark my words!
Peter Kriens
OSGi Evangelist
Wednesday, November 9, 2005
Welcome to the OSGi Alliance Blog. As the OSGi evangelist, I have the honor to fill this space on a regular basis. I will provide insights in how OSGi technology is used, inform you about events and shows that attract many OSGi adopters, or tell you about interesting deployments and developments in the market. If you have a story, a product, a rumor, or a company that should be discussed here. Send it to the OSGi Evangelist.
A complaint I often get is hard to understand what OSGi is all about. For them, it is hard to understand the excitement that people have for the OSGi Alliance. To ease the transition to this enthusiasm, we have written two whitepapers.
Business oriented people should read the first, while the technical people should read the second.
Today's tidbits
A complaint I often get is hard to understand what OSGi is all about. For them, it is hard to understand the excitement that people have for the OSGi Alliance. To ease the transition to this enthusiasm, we have written two whitepapers.
Business oriented people should read the first, while the technical people should read the second.
Today's tidbits
- Yesterday the Mobile Expert Group delivered a new draft of the Mobile Specification. The draft must not be approved by the board, which is planned for tonight, so we can make it available to you as soon as possible.
- November 15 the Vehicle Expert Group meets in Böblingen, Germany to discuss the Vehicle release. This is a members only meeting.
Subscribe to:
Posts (Atom)