Last week I learned a strong lesson about modularity: “Investigate before you take the easy route”. It started with a problem on the Felix mailing list. A Felix user had experienced Class Not Found exceptions for a Swing class that he did not use at all. Inspecting his code, there was no sign of him using that Swing class; the only reference was to a class that used the culprit as super class. The OSGi specifications only mandate the imports of classes you directly use.
The suspicion quickly turned to the boot class path. Normally, a VM uses hierarchical delegation. If a class loader gets a request for a class, it should first ask its parent loader, which should ask its parent, etc. The VM’s loader is at the root. This is a simple delegation policy with flaws (but that is another story).
However, the OSGi specifications forbid the delegation to the parent except for java.* packages. Why? We had found that bundles did not import packages they expected to be on the boot class path. This made it impossible to replace or add those packages by other bundles because the other bundles were never consulted; the request was delegated to the boot class before the package lookup was done.
Substitutability is one of the best features that an OSGi framework brings along, it was therefore clear that we had to deny the automatic parent lookup. This requires frameworks to export any packages that are on the boot class path.
However, unfortunately there is code delivered with the Java VM that implicitly assumes the parent delegation model. When it needs to load a class it uses whatever class loader is at hand, assuming that in the end the boot class path loader is used and the class is found in the end. It should be clear from the previous description that this is not true for an OSGi framework, causing seemingly random failures in bundles. In a previous version of Java there was a VM bug in the verifier that used the wrong class loader, breaking the modularity, which did not help as well. For pragmatic reasons we therefore added the org.osgi.framework.bootdelegation (Section 3.8.3) property. This property is a list of packages that requires delegation to the boot class path, bypassing the controlled class loading mechanism.
Ok, back to the original problem. As you can understand, we thought that the Class Not Found exception was caused by a VM bug or by some class that used the wrong class loader. The standard solution to these problems is adding the package to the org.osgi.framework.bootdelegation, and be done with it. The list showed some pressure to Richard Hall, the main Felix core committer. However, he was stubborn. His solution was to add the missing package to the imports of the bundle. I was against this solution because if this was caused by the VM bug, the standard boot class path delegation was the solution. Problems should be fixed at the right place, fixing a symptom is bound to bite you later.
Other people joined the discussion and we found out that one framework vendor had default set the org.osgi.framework.bootdelegation to *, which basically means the old parent delegation model. This is ok for a deployment but it is bad during development. A * for boot delegation effectively hides any import problems. This was Richard’s greatest objection, delegating everything to the boot class path would not allow you to find class path problems until you were in the field.
During the discussion I was getting the uneasy feeling we had screwed up in the specification if these types of problems were popping up. So I asked Richard to send me the offending bundles. Assuming this was a VM bug, I tried to create a smaller problem with the same sequence. However, I could not get it to fail. I therefore decided to recreate the bundle using my own build environment. This environment uses BTool which analyzes the bundles and write the manifest. To my surprise, BTool created an import statement for the class that generated the error; the code must therefore refer to the class despite the fact it was not directly using it. I immediately realized how stupid I was; this was the same bug we had had last year and that I had solved by extending BTool. I had been sidetracked by the VM bug and boot class path delegation discussion!
Last year I had analyzed that the compiler can insert a reference to a superclass if a method of the superclass is used on a subclass. For example, of you use the HttpServlet class and you refer to for example getServletInfo, the compiler will insert a reference to the GenericServlet class, even though you do not import this in your source file.
So what did I learn from this exercise? First, Richard was right on two counts. He resisted the pressure to make boot class path delegation default * and he was right (for the wrong reason!) to import the culprit class in the bundle. After this exercise, he decided to improve Felix by analyzing Class Not Found exceptions and provide a clear message how to solve them.
However, the most important lesson I learned is that we need a simple tool to verify a bundle. In my sparse spare time I started to write a simple certifier. It is still in its infancy, but I already find lots of errors in freely available bundles. Nevertheless it might be useful so you are free to download the jar (or exe) it and use it. Just run it with:
java –jar certifier.jar (filedir)…
Please note that this is not an official OSGi bundle and has no official status, use it at your own risk.
I’ll probably make some updates in the coming weeks. Feedback appreciated!
Peter Kriens
OSGi Blog
Monday, April 17, 2006
Friday, April 7, 2006
The Bundle Repository
First, if you go to JavaOne, get your calendar and not the following information:
I sure hope to see you there! While we are at it, the OSGi Alliance organizes a webinar. This webinar will take place at Thursday, April 20, 2006, 9:30 AM - 11:00 AM US Eastern time. The webinar will provide updates on: Plans for upcoming and future OSGi technology releases, OSGi technology with JSR 291, Dynamic Component Support for Java™ SE, Expanding OSGi Alliance participation: new Adopter Associates class of membership, and OSGi Alliance leveraging of open source.
Time for the real stuff! The OSGi Alliance has been working on a Bundle Repository for the last few months. A bundle repository is a natural extension to the OSGi Alliance because they want to promote a bundle market. Markets perform best when they are transparent; a searchable repository provides for this transparency. A bundle repository is not a new idea; Richard S. Hall pioneered a repository with his Oscar Bundle Repository (OBR). OBR was an XML based federated repository combined with a tool that could run on any Framework. The tool made it very easy to manage a framework installation from within the framework itself. Richard has helped us develop the version we are introducing today. He is also working inside Apache Felix to make a compatible bundle repository application.
The most visible part of the repository is the web based interface. You can search for bundles, which are then presented in a list. You can select a number of bundles and resolve these bundles. Resolving the bundles means that their dependencies are used to find other bundles that can resolve those dependencies. This will give you a nice list of bundles that you can download and install. When you hover over the link of a bundle, you see the description. Clicking on the link gives more detailed information. This window also contains comments and if you wish, you can add new comments. The web based interface enables you to brows the repository at your leisure. Richard Hall will soon make an updated version of OBR available that uses this repository.
From a technical point of view I think the repository is quite interesting. We have used a very generic capability-requirements model. This model is partly derived from JSR 124: J2EETM Client Provisioning Specification but is simpler and more powerful. Each bundle (resource as we call it, we can also handle other things than bundles) has a set of capabilities (property sets) and requirements, which are extended OSGi filters. A resource has a set of mandatory or optional requirements. Requirements can require a single instance out of many, or it can actually use many. The Bundle Repository is not an OSGi standard specification; it is only a utility provided by the OSGi Alliance. However, we have described the format and requirements in an RFC that is publicly available. This RFC also contains an API to access a repository locally. Richard Hall’s OBR tool will use this API (which, again, is not part of the OSGi specifications).
Currently the repository contains over 700 bundles from ProSyst, Eclipse, the old Oscar repository, and some of mine. The goal of this repository is to become the central clearing house for bundles. We are therefore very interested in parties that are willing to become part of the OSGi Bundle Repository. Participating is rather easy; you will have to host a repository.xml file and your bundles on any host. Creation of this XML can be done in several ways. The hardest way is to hand code it, I do not recommend that approach. You can write your own program to generate the file, however, we have also written a generic one for you. The bindex utility is a small Java program that can traverse a directory and generate the repository.xml file from the manifest in the bundles. If your manifest is nicely formatted (description, license, etc) then you get a very expressive repository file. You can send the URL for this repository to me. After we verified that you are a legitimate company or person we will add this to our main repository.
As a note, the repository and the web based interface are hosted on an OSGi Framework running on bundles.osgi.org, we are surely eating our own dog food. The software has been written from scratch. I am very interested in feedback around this repository. Please send me your ideas of how to extend the repository, or to get rid of the inevitable bugs. You can use our bugzilla or you can mail me.
Enjoy!
Peter Kriens
- Wednesday, May 17 10:30 PM 50 Franciscan II & IIIComponent Programming with OSGi
- Thursday, May 18, 08:30 PM 50 Esplanade 304/306The OSGi Service Architecture, From Embedded to Enterprise
I sure hope to see you there! While we are at it, the OSGi Alliance organizes a webinar. This webinar will take place at Thursday, April 20, 2006, 9:30 AM - 11:00 AM US Eastern time. The webinar will provide updates on: Plans for upcoming and future OSGi technology releases, OSGi technology with JSR 291, Dynamic Component Support for Java™ SE, Expanding OSGi Alliance participation: new Adopter Associates class of membership, and OSGi Alliance leveraging of open source.
Time for the real stuff! The OSGi Alliance has been working on a Bundle Repository for the last few months. A bundle repository is a natural extension to the OSGi Alliance because they want to promote a bundle market. Markets perform best when they are transparent; a searchable repository provides for this transparency. A bundle repository is not a new idea; Richard S. Hall pioneered a repository with his Oscar Bundle Repository (OBR). OBR was an XML based federated repository combined with a tool that could run on any Framework. The tool made it very easy to manage a framework installation from within the framework itself. Richard has helped us develop the version we are introducing today. He is also working inside Apache Felix to make a compatible bundle repository application.
The most visible part of the repository is the web based interface. You can search for bundles, which are then presented in a list. You can select a number of bundles and resolve these bundles. Resolving the bundles means that their dependencies are used to find other bundles that can resolve those dependencies. This will give you a nice list of bundles that you can download and install. When you hover over the link of a bundle, you see the description. Clicking on the link gives more detailed information. This window also contains comments and if you wish, you can add new comments. The web based interface enables you to brows the repository at your leisure. Richard Hall will soon make an updated version of OBR available that uses this repository.
From a technical point of view I think the repository is quite interesting. We have used a very generic capability-requirements model. This model is partly derived from JSR 124: J2EETM Client Provisioning Specification but is simpler and more powerful. Each bundle (resource as we call it, we can also handle other things than bundles) has a set of capabilities (property sets) and requirements, which are extended OSGi filters. A resource has a set of mandatory or optional requirements. Requirements can require a single instance out of many, or it can actually use many. The Bundle Repository is not an OSGi standard specification; it is only a utility provided by the OSGi Alliance. However, we have described the format and requirements in an RFC that is publicly available. This RFC also contains an API to access a repository locally. Richard Hall’s OBR tool will use this API (which, again, is not part of the OSGi specifications).
Currently the repository contains over 700 bundles from ProSyst, Eclipse, the old Oscar repository, and some of mine. The goal of this repository is to become the central clearing house for bundles. We are therefore very interested in parties that are willing to become part of the OSGi Bundle Repository. Participating is rather easy; you will have to host a repository.xml file and your bundles on any host. Creation of this XML can be done in several ways. The hardest way is to hand code it, I do not recommend that approach. You can write your own program to generate the file, however, we have also written a generic one for you. The bindex utility is a small Java program that can traverse a directory and generate the repository.xml file from the manifest in the bundles. If your manifest is nicely formatted (description, license, etc) then you get a very expressive repository file. You can send the URL for this repository to me. After we verified that you are a legitimate company or person we will add this to our main repository.
As a note, the repository and the web based interface are hosted on an OSGi Framework running on bundles.osgi.org, we are surely eating our own dog food. The software has been written from scratch. I am very interested in feedback around this repository. Please send me your ideas of how to extend the repository, or to get rid of the inevitable bugs. You can use our bugzilla or you can mail me.
Enjoy!
Peter Kriens
Monday, April 3, 2006
Misconceptions about OSGi Headers
This week there was an interesting discussion on a mailing list that showed a number of misconceptions about the difference between importing a package (Import-Package) or importing a Bundle (Require Bundle). This is a complicated and subtle area so the misconceptions are likely to be widespread. I'll try to clear up some of these misconceptions in this blog.
Require-Bundle ensures that the required bundles are initialized before you can use them.
False. Require-Bundle and Import-Package only relate to resolving. Resolving is the process where different bundles are wired to each other on package level. From the perspective of a bundle, this is an atomic process. The start/stop primitives are completely independent from this resolving process. The only difference between Require bundle and Import Package is granularity. Require bundle is internally transformed to the same wires as import package uses (except when the more esoteric split packages are desired).
Any bundle can contribute classes to imported packages False. The Framework must select a single exporter for a package that is imported. We call the case where a package can come from multiple sources a split package. This is a common case with the traditional Java class path and a potential source for errors because a package should contain highly cohesive classes; there are also security implications. To address this problem Java added sealed packages. On top of this, the OSGi Specifications added the constraint that a package must have a single source.
This said, there is an exception because in certain cases (Java localization for example), split packages are a necessity. Require Bundle can therefore be used as a façade to multiple bundles that are aggregated. From the outside it looks like the bundle exports a single package but it gets the content from its bundle classpath or other required bundles. Fragments can also be used to provide split packages. However, split packages should be exceptions because of the related security and confusion problems.
With require bundle you are ensured all packages come from the same source This is true, but the same result can be better achieved with Import-Package and the uses directive. When packages are not cohesive and are aware of each other’s implementation details then it is paramount that they actually import the same package. In those cases packages can not be substituted independently. Import-Package solves this problem with a package directive that lists the referred (used) packages. For example bundle A has package p that uses package q. The Framework ensures that A, and all its wired bundles, share the same class loader for package q.
Require-Bundle can actually worsen the problem because it can use packages that are internal. The requiree can easily get into trouble if it imports these private packages. For example, a bundle requiring Xerces could separately import javax.xml.parsers. If this package is also available privately to the Xerces bundle then a class cast exception will occur.
You must import all packages of an exporter False. A bundle should only import the packages that it actually uses. This list is easy to generate from the class files (next generation Eclipse PDE will track this) and it is usually shorter than most people think. Well designed libraries have a few access points. These access points must be exported to use the library, however, all the packages that can be referred from the exported package do not have to be exported or imported. Once you have an object from a library, any classes that are linked from this object are automatically loaded from the same class loader. Most Java standards limit the use of a library to a single package that is shared between all implementations. For example, if you use the Apache Derby database you should not have to import any packages from that library, importing java.sql from the Java runtime should be sufficient.
Bundles are versioned, packages not False. Both bundles and packages are versioned. It is true that most programmers tend to ignore versions all together but good developers version both their bundles and packages.
A Required Bundle is a closed collection of code False. A bundle can be extended by fragments.
Peter Kriens
Require-Bundle ensures that the required bundles are initialized before you can use them.
False. Require-Bundle and Import-Package only relate to resolving. Resolving is the process where different bundles are wired to each other on package level. From the perspective of a bundle, this is an atomic process. The start/stop primitives are completely independent from this resolving process. The only difference between Require bundle and Import Package is granularity. Require bundle is internally transformed to the same wires as import package uses (except when the more esoteric split packages are desired).
Any bundle can contribute classes to imported packages False. The Framework must select a single exporter for a package that is imported. We call the case where a package can come from multiple sources a split package. This is a common case with the traditional Java class path and a potential source for errors because a package should contain highly cohesive classes; there are also security implications. To address this problem Java added sealed packages. On top of this, the OSGi Specifications added the constraint that a package must have a single source.
This said, there is an exception because in certain cases (Java localization for example), split packages are a necessity. Require Bundle can therefore be used as a façade to multiple bundles that are aggregated. From the outside it looks like the bundle exports a single package but it gets the content from its bundle classpath or other required bundles. Fragments can also be used to provide split packages. However, split packages should be exceptions because of the related security and confusion problems.
With require bundle you are ensured all packages come from the same source This is true, but the same result can be better achieved with Import-Package and the uses directive. When packages are not cohesive and are aware of each other’s implementation details then it is paramount that they actually import the same package. In those cases packages can not be substituted independently. Import-Package solves this problem with a package directive that lists the referred (used) packages. For example bundle A has package p that uses package q. The Framework ensures that A, and all its wired bundles, share the same class loader for package q.
Require-Bundle can actually worsen the problem because it can use packages that are internal. The requiree can easily get into trouble if it imports these private packages. For example, a bundle requiring Xerces could separately import javax.xml.parsers. If this package is also available privately to the Xerces bundle then a class cast exception will occur.
You must import all packages of an exporter False. A bundle should only import the packages that it actually uses. This list is easy to generate from the class files (next generation Eclipse PDE will track this) and it is usually shorter than most people think. Well designed libraries have a few access points. These access points must be exported to use the library, however, all the packages that can be referred from the exported package do not have to be exported or imported. Once you have an object from a library, any classes that are linked from this object are automatically loaded from the same class loader. Most Java standards limit the use of a library to a single package that is shared between all implementations. For example, if you use the Apache Derby database you should not have to import any packages from that library, importing java.sql from the Java runtime should be sufficient.
Bundles are versioned, packages not False. Both bundles and packages are versioned. It is true that most programmers tend to ignore versions all together but good developers version both their bundles and packages.
A Required Bundle is a closed collection of code False. A bundle can be extended by fragments.
Peter Kriens
Saturday, March 25, 2006
EclipseCon 2006, OSGi on the Rise
Wow! If you want to see what is happening with OSGi technology, you should have visited the EclipseCon 2006 conference in Santa Clara! OSGi is mentioned in an awful lot of presentations! There are so many people excited about what you can do with OSGi that it was heartwarming. Despite the fact that the OSGi is only the plumbing of Eclipse, many people realize that the OSGi component model is applicable in a wide range of applications. For many, it is a genuine discovery when they realize that the IDE plug-in model can also be used on a tiny embedded device like the Slug (which was very nicely demonstrated by Thomas Watson) or on the server side, which was discussed in Corona Project from Compuware, Wolfgang Gehner with his RSP proposal, and many others. An impressive number of people want to start deploying OSGi applications that (partly) replace J2EE application servers. More about that later.
On Monday Thomas Watson and I gave a tutorial about OSGi Component Programming. This went very well (though we could only finish half of our 100 slides). The feedback we got during the rest of the conference was nice; people loved the modularity and especially the service model. This was a bit of a surprise to me; I had not realized that most people know about the OSGi modularity layer but know little about the service layer. The service model is new for many people because Eclipse mainly uses extension points where the OSGi model uses services.
The difference between extension points is subtle, though important. An extension point allows a bundle to find, and work with, implementers of its own extension points. That is, the bundle owns the extension point contract and allows other to implement it. A service is more generic because it provides an interaction point between any number of bundles; there is no bundle that owns the service, any bundle can both register (implement) and get (use) a service. This distinction nicely reflects the perspective of Eclipse community and the OSGi Alliance. Extension points allow an implementation to find implementers. For example the Eclipse UI code uses extension points to find its menu entries in different plug-ins. The extension point model is not intended for another bundle to find these menu entries. In contrast, OSGi services are usable by any bundle that has the proper permissions. The OSGi model allows substitutability of the user of a service as well as the implementer of a service. There are some more differences like dynamics, versioning (extension points mandate only a single version resident at any moment in time), and life cycle, but the ownership of the contract is the most crucial.
Anyway, lots of people are using extension points that would have been nicer (ok, in my biased opinion) with services. This difference/overlap, and when to use one or the other was a big part of the talk by Jeff McAffer and BJ Hargrave. They did a joint presentation that did an excellent job of highlighting the similarities and differences. The format of 2 very knowledgeable guys taking their turns explaining the differences worked very well. There were an impressive number of people ready to listen to the Best Practices of OSGi and Eclipse.
So what is the number one aspect that signifies this conference to me? I think that it has become clear to me why there is a need for an OSGi Alliance. There is an impressive amount of projects underway. However, all these projects are about implementations. The people you meet here are very interested in collaborating on developing implementations. This approach is orthogonal to specifying service interfaces so that different implementations can collaborate. There is a clear distinction between an extension point that is unilaterally decided by a programmer and a service that is defined by a standards body or consortium. Using well specified service interfaces will allow commercial companies to compete with Eclipse, or other, implementations; something that the Eclipse community, commercial companies, other communities like Apache, but most of all the users can benefit from in the long run. Will the different communities have the patience and motivation to go through standardization processes?
The answer to this question is opportune for what will happen on the server side. The Eclipse model has made many people realize how well the component model works and they want the same benefits for the server side. There are a large number of initiatives to standardize Eclipse for the server. However, the danger is that different parties create implementations without proper regard for how all these different parts could interact. Obviously many implementations will work but properly designing a component architecture for Enterprise applications will enable substitutability, a very desirable property in my opinion. Maybe organizing a workshop about Enterprise Component Architecture could be held. Some key people in the industry could to outline such a component architecture. Good idea?
Peter Kriens
On Monday Thomas Watson and I gave a tutorial about OSGi Component Programming. This went very well (though we could only finish half of our 100 slides). The feedback we got during the rest of the conference was nice; people loved the modularity and especially the service model. This was a bit of a surprise to me; I had not realized that most people know about the OSGi modularity layer but know little about the service layer. The service model is new for many people because Eclipse mainly uses extension points where the OSGi model uses services.
The difference between extension points is subtle, though important. An extension point allows a bundle to find, and work with, implementers of its own extension points. That is, the bundle owns the extension point contract and allows other to implement it. A service is more generic because it provides an interaction point between any number of bundles; there is no bundle that owns the service, any bundle can both register (implement) and get (use) a service. This distinction nicely reflects the perspective of Eclipse community and the OSGi Alliance. Extension points allow an implementation to find implementers. For example the Eclipse UI code uses extension points to find its menu entries in different plug-ins. The extension point model is not intended for another bundle to find these menu entries. In contrast, OSGi services are usable by any bundle that has the proper permissions. The OSGi model allows substitutability of the user of a service as well as the implementer of a service. There are some more differences like dynamics, versioning (extension points mandate only a single version resident at any moment in time), and life cycle, but the ownership of the contract is the most crucial.
Anyway, lots of people are using extension points that would have been nicer (ok, in my biased opinion) with services. This difference/overlap, and when to use one or the other was a big part of the talk by Jeff McAffer and BJ Hargrave. They did a joint presentation that did an excellent job of highlighting the similarities and differences. The format of 2 very knowledgeable guys taking their turns explaining the differences worked very well. There were an impressive number of people ready to listen to the Best Practices of OSGi and Eclipse.
So what is the number one aspect that signifies this conference to me? I think that it has become clear to me why there is a need for an OSGi Alliance. There is an impressive amount of projects underway. However, all these projects are about implementations. The people you meet here are very interested in collaborating on developing implementations. This approach is orthogonal to specifying service interfaces so that different implementations can collaborate. There is a clear distinction between an extension point that is unilaterally decided by a programmer and a service that is defined by a standards body or consortium. Using well specified service interfaces will allow commercial companies to compete with Eclipse, or other, implementations; something that the Eclipse community, commercial companies, other communities like Apache, but most of all the users can benefit from in the long run. Will the different communities have the patience and motivation to go through standardization processes?
The answer to this question is opportune for what will happen on the server side. The Eclipse model has made many people realize how well the component model works and they want the same benefits for the server side. There are a large number of initiatives to standardize Eclipse for the server. However, the danger is that different parties create implementations without proper regard for how all these different parts could interact. Obviously many implementations will work but properly designing a component architecture for Enterprise applications will enable substitutability, a very desirable property in my opinion. Maybe organizing a workshop about Enterprise Component Architecture could be held. Some key people in the industry could to outline such a component architecture. Good idea?
Peter Kriens
Sunday, March 19, 2006
The OSGi GUI: Flash/SVG?
The OSGi specifications were originally developed for headless devices and user interfaces were therefore of no concern. This changed when the vehicle and the mobile groups worked on their specifications because they clearly required some graphic user interface. Within the vehicle group many discussion have taken place but we were never able to reach a consensus. The mobile group kept standardization of the UI specifically out of the charter because it was a hard choice and there are already standards for mobile phones..
Still, the lack of a good user interface standard makes it very hard to demo OSGi applications. Few decision makers get excited by a console running some cool (in my opinion) middleware. The lack of GUI is also a significant obstacle to portability between different environments. Why is it so hard to choose a specific user interface? The key problem is the wide range of devices that need to be supported; many devices do not even support a graphic display. However, there were more problems than just technical. Member companies also had a hard time compromising on the GUI technology because they already had favorite solutions. The interoperability issue was not of a major concern to most companies.
Swing and SWT are the standard solutions for Java applications. Both are toolkits with rectangular user interface components: text editors, sliders, lists, tables, etc. Though these toolkits are useful in desktop applications they fall far short of what is needed in a car dashboard or a highly usable mobile phone. They tend to consume lots of screen real estate, but worse, they are very static. In comparison to what is visible on the web nowadays, SWT and Spring applications are rather dull.
In the past few years many companies have turned to MacroMedia Flash for dynamic content. Try refusing to download the flash plugin and the web suddenly looks a lot less dynamic. Flash can play movies. Movies are sequences of animation of vector graphics. Vector graphics have many significant advantages. They are usually smaller than the corresponding bitmaps and they can be scaled, rotated, and translated while being displayed without loss of quality. Macromedia also added a programming language call ActionScript, making it possible to turn external events into changes in the movie as well triggering external actions on internal events; ActionScript is similar to Javascript. For example, on a mobile phone an incoming call can activate the part of the “movie” that shows different buttons to the end user. If the user presses such a buttons, the calls is taken or rejected. Sounds similar to SWT/Spring, the difference is that in Flash/SVG the buttons can change place, size, rotation, shape and color only limited by the imagination of the designer. Flash Lite, a stripped version of Flash that has been adapted to many mobile phones and provides phone specific APIs.
The most powerful aspect of Flash is the availability of powerful authoring tools. Macromedia and other companies provide tools for graphic designers to author compelling user interfaces. The result is impossible to achieve with Swing and SWT. And even if one could, good programmers are notoriously bad at UI design. Believe me, I tried and tried. Every time when I got a graphic designer on my design team the User Interface improved with a magnitude. I still do not know how they do it, but it works. Fortunately, they are usually lousy programmers.
Interestingly, there is also a standardization process going on at W3C for a format that is very similar to Flash: Scalable Vector Graphics (SVG), which is based on XML. SVG is not as mature as Flash yet, but they are improving quickly. SVG also has been extended with a Basic and Tiny profile so that it is suitable for smaller devices. Actually, the Flash Lite player can also play SVG-Tiny content. The obvious advantage is of course that SVG has no license cost. The bad news is that it will be harder to get SVG movies to play as consistent on a wide range devices as it is for a single company like Macromedia.
So what is the relation to OSGi? I feel that Flash/SVG might be a solution to the GUI problem. These technologies are primarily focused on the user interaction but have a fuzzier picture when it comes to programming real functionality. ActionScript is interesting, but it is no comparison what you can do with a real Java environment.
The OSGi Alliance could therefore specify how Flash/SVG content could be included in a bundle and how during runtime the events are bound to the bundle’s code. To support different screen formats, a bundle could include multiple versions. A desktop manager could load the content from the bundles and create the necessary bindings to the Java code when an application is activated.
This combination looks awfully attractive. It looks like such a model could finally provide the OSGi with the much needed User Interface option. Are there companies out there interested in this approach? Should we start working on this? Tell us what you think on the OSGi Developer mailing list ...
Still, the lack of a good user interface standard makes it very hard to demo OSGi applications. Few decision makers get excited by a console running some cool (in my opinion) middleware. The lack of GUI is also a significant obstacle to portability between different environments. Why is it so hard to choose a specific user interface? The key problem is the wide range of devices that need to be supported; many devices do not even support a graphic display. However, there were more problems than just technical. Member companies also had a hard time compromising on the GUI technology because they already had favorite solutions. The interoperability issue was not of a major concern to most companies.
Swing and SWT are the standard solutions for Java applications. Both are toolkits with rectangular user interface components: text editors, sliders, lists, tables, etc. Though these toolkits are useful in desktop applications they fall far short of what is needed in a car dashboard or a highly usable mobile phone. They tend to consume lots of screen real estate, but worse, they are very static. In comparison to what is visible on the web nowadays, SWT and Spring applications are rather dull.
In the past few years many companies have turned to MacroMedia Flash for dynamic content. Try refusing to download the flash plugin and the web suddenly looks a lot less dynamic. Flash can play movies. Movies are sequences of animation of vector graphics. Vector graphics have many significant advantages. They are usually smaller than the corresponding bitmaps and they can be scaled, rotated, and translated while being displayed without loss of quality. Macromedia also added a programming language call ActionScript, making it possible to turn external events into changes in the movie as well triggering external actions on internal events; ActionScript is similar to Javascript. For example, on a mobile phone an incoming call can activate the part of the “movie” that shows different buttons to the end user. If the user presses such a buttons, the calls is taken or rejected. Sounds similar to SWT/Spring, the difference is that in Flash/SVG the buttons can change place, size, rotation, shape and color only limited by the imagination of the designer. Flash Lite, a stripped version of Flash that has been adapted to many mobile phones and provides phone specific APIs.
The most powerful aspect of Flash is the availability of powerful authoring tools. Macromedia and other companies provide tools for graphic designers to author compelling user interfaces. The result is impossible to achieve with Swing and SWT. And even if one could, good programmers are notoriously bad at UI design. Believe me, I tried and tried. Every time when I got a graphic designer on my design team the User Interface improved with a magnitude. I still do not know how they do it, but it works. Fortunately, they are usually lousy programmers.
Interestingly, there is also a standardization process going on at W3C for a format that is very similar to Flash: Scalable Vector Graphics (SVG), which is based on XML. SVG is not as mature as Flash yet, but they are improving quickly. SVG also has been extended with a Basic and Tiny profile so that it is suitable for smaller devices. Actually, the Flash Lite player can also play SVG-Tiny content. The obvious advantage is of course that SVG has no license cost. The bad news is that it will be harder to get SVG movies to play as consistent on a wide range devices as it is for a single company like Macromedia.
So what is the relation to OSGi? I feel that Flash/SVG might be a solution to the GUI problem. These technologies are primarily focused on the user interaction but have a fuzzier picture when it comes to programming real functionality. ActionScript is interesting, but it is no comparison what you can do with a real Java environment.
The OSGi Alliance could therefore specify how Flash/SVG content could be included in a bundle and how during runtime the events are bound to the bundle’s code. To support different screen formats, a bundle could include multiple versions. A desktop manager could load the content from the bundles and create the necessary bindings to the Java code when an application is activated.
This combination looks awfully attractive. It looks like such a model could finally provide the OSGi with the much needed User Interface option. Are there companies out there interested in this approach? Should we start working on this? Tell us what you think on the OSGi Developer mailing list ...
Monday, March 13, 2006
Health Care and Self Care
Spring is coming. No, though the first blossoms are visible in the garden, it is not that kind of spring. It is also not the Spring Framework. It is the OSGi spring! Last week I talked to many different people and it keeps surprising me how many companies tell that they have been using OSGi for years or intend to start using it in the next project. It is like green buds appearing between the last remains of winter. There is such an increasing awareness that connected devices change the playing field; The OSGi specifications together with Java are a core part of the puzzle.
A key example of this spring was shown in a report about a large health care project. The aging of the western populations has a potentially devastating effect on the health care systems in Europe and the US. Older people (after ~ 65) need exponentially more care while at the same time the labor force is decreasing. If nothing is done, hospitals will be overwhelmed in the next two decades, therefore, the problem is urgent. We need to develop solutions that will allow the health care workers to spend their time on what only nurses and doctors can do while taking other tasks of their hands.
Automation can clearly supply parts of a solution, if applied with care. There are obvious efficiencies to be gained by further applying automation in, and between, health care institutions. However, the use of these solutions has been ongoing process. It is not likely that the required efficiency improvements (my estimate is at least a magnitude) can be achieved through administrative means.
The only solution seems to be to engage the patient: self care. Obviously this simple solution is not that simple otherwise it would already have been applied successfully on a world scale. A key problem that is hard to solve is the monitoring. A hospital monitors the patient for complications and can immediately take appropriate actions when needed. The huge challenge is to provide the means for self care as well as providing the monitoring infrastructure and inevitable emergency help.
This is a very complicated problem with an unpleasant number of aspects that can be categorized as fundamental. Solutions must be extremely reliable otherwise people will die or suffer; this kind of reliability is far away from current consumer electronics (and moving in the wrong direction). The usability of the solutions must be flawless because the users will be older people with reduced eyesight, handicaps, stiff muscles, reduced brain capacity and all those other burdens that age and sickness will put on all of us. Configuring solutions must be automated and trivial or we will have to exchange nurses for technicians. And last but not least, privacy must be maintained while at the same time allowing nurses and doctors access to the information they need.
Looking at the dramatic figures it is quite clear to me that there is no choice but to develop the technology that will enable self care on a large scale, and we better hurry. It also seems clear that domotica can play an important role. Sensors to monitor the patient and devices that can help administer the medications will require local support in the home to help providing the required reliability (e.g. network failures) as well as reduce the load on the central servers by reporting only exceptions to reduce the central load. However, also mobile phones could provide an important role so that the patient can lead an active life.
The biggest technical challenge of all will be software (and I can assure you that just the social challenge will be huge). Sensors, actuators, servers, analysis, monitoring, and managing largely consists of connected software components. We must realize that much of the required functionality is beyond the state of the art today. It is therefore paramount to develop an infrastructure that provides an even playing field for anybody that can contribute to a solution. Trying to create “the” solution is planning for failure.
The OSGi specifications provide a unique building stone for such an infrastructure. No other software technology provides so many of the crucial infrastructure aspects that are needed to implement large scale self care. The portability, security, reliability, integrity, and manageability are all prerequisites for a health care infrastructure. The tremendous challenge of large scale self care is an opportunity for the OSGi Alliance. It actually is surprising that no companies have flocked around this area and created a Self Care Expert Group. Let’s face it, what is the alternative?
Peter Kriens
OSGi Evangelist
P.S. Next week I will be at EclipseCon, hope to see you there!
A key example of this spring was shown in a report about a large health care project. The aging of the western populations has a potentially devastating effect on the health care systems in Europe and the US. Older people (after ~ 65) need exponentially more care while at the same time the labor force is decreasing. If nothing is done, hospitals will be overwhelmed in the next two decades, therefore, the problem is urgent. We need to develop solutions that will allow the health care workers to spend their time on what only nurses and doctors can do while taking other tasks of their hands.
Automation can clearly supply parts of a solution, if applied with care. There are obvious efficiencies to be gained by further applying automation in, and between, health care institutions. However, the use of these solutions has been ongoing process. It is not likely that the required efficiency improvements (my estimate is at least a magnitude) can be achieved through administrative means.
The only solution seems to be to engage the patient: self care. Obviously this simple solution is not that simple otherwise it would already have been applied successfully on a world scale. A key problem that is hard to solve is the monitoring. A hospital monitors the patient for complications and can immediately take appropriate actions when needed. The huge challenge is to provide the means for self care as well as providing the monitoring infrastructure and inevitable emergency help.
This is a very complicated problem with an unpleasant number of aspects that can be categorized as fundamental. Solutions must be extremely reliable otherwise people will die or suffer; this kind of reliability is far away from current consumer electronics (and moving in the wrong direction). The usability of the solutions must be flawless because the users will be older people with reduced eyesight, handicaps, stiff muscles, reduced brain capacity and all those other burdens that age and sickness will put on all of us. Configuring solutions must be automated and trivial or we will have to exchange nurses for technicians. And last but not least, privacy must be maintained while at the same time allowing nurses and doctors access to the information they need.
Looking at the dramatic figures it is quite clear to me that there is no choice but to develop the technology that will enable self care on a large scale, and we better hurry. It also seems clear that domotica can play an important role. Sensors to monitor the patient and devices that can help administer the medications will require local support in the home to help providing the required reliability (e.g. network failures) as well as reduce the load on the central servers by reporting only exceptions to reduce the central load. However, also mobile phones could provide an important role so that the patient can lead an active life.
The biggest technical challenge of all will be software (and I can assure you that just the social challenge will be huge). Sensors, actuators, servers, analysis, monitoring, and managing largely consists of connected software components. We must realize that much of the required functionality is beyond the state of the art today. It is therefore paramount to develop an infrastructure that provides an even playing field for anybody that can contribute to a solution. Trying to create “the” solution is planning for failure.
The OSGi specifications provide a unique building stone for such an infrastructure. No other software technology provides so many of the crucial infrastructure aspects that are needed to implement large scale self care. The portability, security, reliability, integrity, and manageability are all prerequisites for a health care infrastructure. The tremendous challenge of large scale self care is an opportunity for the OSGi Alliance. It actually is surprising that no companies have flocked around this area and created a Self Care Expert Group. Let’s face it, what is the alternative?
Peter Kriens
OSGi Evangelist
P.S. Next week I will be at EclipseCon, hope to see you there!
Monday, March 6, 2006
POJOs
Sometimes a not too familiar word suddenly pops up in totally different places. The first one or two times you ignore it, but then you start to wonder. POJO, which stands for Plain Old Java Object, is such a word for me. The concept is used to contrast between Java objects that can only exist within a larger framework and objects that only need the standard VM as their environment. For example, J2EE Java Beans can only run in a J2EE Framework because their implementations are closely intertwined with the framework’s classes and interfaces. The concept POJO was coined because of a very fundamental problem in the object oriented paradigm: coupling.
Objects entered my life more than 20 year. I had been trying to use Structured Programming techniques (Yourdon, DeMarco, Jackson, etc) in the context of embedded and distributed system software, but I was not very successful:. It just felt plain wrong. I tried many languages Assembly, Prolog, C, Plm, Pascal, Lisp but none felt right until Smalltalk (Digitalk V86) hit me. Using objects felt so right; I developed my own object oriented derivative of the C language: CO2. At that time, I remembered telling people how objects would change the software world. One of my key selling points to management was that one day we could create complex systems by just picking some objects. A rather naïve and overly optimistic view, my only excuse is that I was still pretty young.
The key reason that we cannot easily compose systems from objects can be described with one word: coupling. Objects almost got it right. They gave us encapsulation and polymorphism but we totally forgot one of the key lessons that Structured Programming taught us: coupling. Object oriented languages lack support to decrease effect of dependencies. For example, when you create a class you have to specify the exact class name, creating a very hard coupling to the implementation of that class, worse, everything that class is coupled to ad nauseam. Over the years, our community has found many solutions around this type of coupling. A key example is the factory pattern, which has the bad side effect of making the code harder to read. The causes of coupling are usually subtle but its effects are terrible. We all know the hopeless feeling that small functional changes turn into major rewrites, or when you download an interesting looking library that turns out to depend on 76 other libraries.
So what is the relation to OSGi specifications? The OSGi Service Platform was designed to address the problem of decoupling. OSGi services are POJOs, you can use any object you like for a service. This was not without opposition, some companies wanted a “Service” marker interface, but we won in the end. The whole purpose of import- and export packages is to minimize the dependencies, and therefore coupling, between bundles. The whole purpose of the service registry is to break the coupling between bundles that provide the functionality and the bundles that use the functionality.
However, also the OSGi Service Platform does not escape of being a container and thus creating unwanted dependencies. We therefore have always advised to separate OSGi code from domain specific code and minimize coupling inside your bundles. The golden rule: if a bundle can exist without knowing a fact, make sure it does not depend on that fact (that is one of the reasons why Require-Bundle is bad). In the case that couplings are necessary, concentrate them. Strive to have as few places as possible where you connect your domain objects to other subsystems. This is exactly the purpose of the popular core of the Spring Java 2 EE Framework. It is also known as Inversion of Control (IoC) or Dependency Injection (DI) principle. The Spring framework uses XML files to configure any number of Java subsystems to work together.
My favorite solution for the coupling problem since 1985 has been scripting languages. Scripting languages are perfectly suitable to connect different subsystems and to provide the always necessary glue code. A simple script language can be used both by the developer as well as the deployer to configure a system. My first attempt with a script language was EGO, a terrible forth like language just because it was easy to implement. Today there are many off the shelf solutions, a good example is the Beanshell. Beanshell is a dream for Java based solutions because it is tiny, supports the Java syntax and will integrate with any java environment seamlessly.
However, what tool you use to minimize and concentrate your dependencies is not so relevant. Most important is to reduce and concentrate coupling in large complex systems so that your users get the flexibility they need.
Peter Kriens
OSGi Evangelist
Objects entered my life more than 20 year. I had been trying to use Structured Programming techniques (Yourdon, DeMarco, Jackson, etc) in the context of embedded and distributed system software, but I was not very successful:. It just felt plain wrong. I tried many languages Assembly, Prolog, C, Plm, Pascal, Lisp but none felt right until Smalltalk (Digitalk V86) hit me. Using objects felt so right; I developed my own object oriented derivative of the C language: CO2. At that time, I remembered telling people how objects would change the software world. One of my key selling points to management was that one day we could create complex systems by just picking some objects. A rather naïve and overly optimistic view, my only excuse is that I was still pretty young.
The key reason that we cannot easily compose systems from objects can be described with one word: coupling. Objects almost got it right. They gave us encapsulation and polymorphism but we totally forgot one of the key lessons that Structured Programming taught us: coupling. Object oriented languages lack support to decrease effect of dependencies. For example, when you create a class you have to specify the exact class name, creating a very hard coupling to the implementation of that class, worse, everything that class is coupled to ad nauseam. Over the years, our community has found many solutions around this type of coupling. A key example is the factory pattern, which has the bad side effect of making the code harder to read. The causes of coupling are usually subtle but its effects are terrible. We all know the hopeless feeling that small functional changes turn into major rewrites, or when you download an interesting looking library that turns out to depend on 76 other libraries.
So what is the relation to OSGi specifications? The OSGi Service Platform was designed to address the problem of decoupling. OSGi services are POJOs, you can use any object you like for a service. This was not without opposition, some companies wanted a “Service” marker interface, but we won in the end. The whole purpose of import- and export packages is to minimize the dependencies, and therefore coupling, between bundles. The whole purpose of the service registry is to break the coupling between bundles that provide the functionality and the bundles that use the functionality.
However, also the OSGi Service Platform does not escape of being a container and thus creating unwanted dependencies. We therefore have always advised to separate OSGi code from domain specific code and minimize coupling inside your bundles. The golden rule: if a bundle can exist without knowing a fact, make sure it does not depend on that fact (that is one of the reasons why Require-Bundle is bad). In the case that couplings are necessary, concentrate them. Strive to have as few places as possible where you connect your domain objects to other subsystems. This is exactly the purpose of the popular core of the Spring Java 2 EE Framework. It is also known as Inversion of Control (IoC) or Dependency Injection (DI) principle. The Spring framework uses XML files to configure any number of Java subsystems to work together.
My favorite solution for the coupling problem since 1985 has been scripting languages. Scripting languages are perfectly suitable to connect different subsystems and to provide the always necessary glue code. A simple script language can be used both by the developer as well as the deployer to configure a system. My first attempt with a script language was EGO, a terrible forth like language just because it was easy to implement. Today there are many off the shelf solutions, a good example is the Beanshell. Beanshell is a dream for Java based solutions because it is tiny, supports the Java syntax and will integrate with any java environment seamlessly.
However, what tool you use to minimize and concentrate your dependencies is not so relevant. Most important is to reduce and concentrate coupling in large complex systems so that your users get the flexibility they need.
Peter Kriens
OSGi Evangelist
Subscribe to:
Posts (Atom)