At Year's End
2005-12-29
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
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
Comments
OSGi on the CCNC 2005
2005-12-23
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?
Apache and OSGi
2005-12-16
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.
The OSGi Mobile Specification
2005-12-13
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
The Smell of Success
2005-12-06
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.
Comments
2005-12-01
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
| Previous Posts | Archives |
|---|---|
You mentioned lack of feedback on the R4 Spec. Is it too late for feedback/comments? I would like to give some on the Metatype Service.
thanks,
John