At the moment I am sitting in the train coming back from a consultancy job. A mid-sized company in Holland is developing a control system for their high end analytical devices. The devices are for a highly specialized market; the amount of knowledge that goes into these instruments is staggering. I was asked to review the architecture because their new architecture is based on OSGi technology.
At the end of the day I got a very enthusiastic tour of the company. I was shown all the different systems and the myriad of adapters that they can add to the core device. All these adapters must be supported by the software, using the standard OSGi Device Management. It is really cool to see all that stuff work in practice. Getting paid for learning so much new domain knowledge!
As you probably have noticed, I am not allowed to tell which manufacturer, or what he actually produces, because the company wants to keep the use of OSGi confidential. This is unfortunately true for many OSGi applications. It is always really hard to see these incredibly interesting applications of OSGi technology and then have to keep silent. I would love to tell you about the solutions they found to the hard problems of device control in high end technology.
Higher end devices are a perfect space for OSGi technology. We developed the specification for small embedded devices that are focused on consumer electronics. However, adoption of OSGi technology in this space is not high because of the eternal trade off between Bill Of Material (BOM) cost and development cost. When you intend to produce 100.000 devices, a single dollar saved in the BOM translates to 100.000 dollars in development. The extra requirements that the OSGi/Java puts upon the device (higher end CPU, more Flash, and more dynamic memory) are therefore often seen as prohibitive. I am not sure the arguments are still that valid, a Megabyte of Flash nowadays costs 2 dollar cents, but the consumer electronics is a very conservative industry. In these markets OSGi technology will not find large scale adoption until the end users start demanding it or providers like telcos see that they can generate money by selling electronic services.
However, as my visit showed, the level above consumer electronics thinks that the OSGi proposition is very interesting. In the higher end markets, the BOM is easily dwarfed by development and management cost. When your market is 600 devices a year and you have to feed a thousand mouths, the cost for a few megabytes and a faster processor is trivial. For these devices, using OSGi technology should almost be a no-brainer. High end embedded devices show a lot of diversity; in certain cases almost every configuration is unique. Any experienced person knows that this poses a nightmare for software maintenance. Trying to integrate this type of diversity in a single static image is just not workable. So far, only component systems can cope well with this problem and the OSGi Service Platform is the premier component system in the market. The OSGi technology for industrial devices can reduce development cost, simplify management, and opens up new business cases.
I do not think this goes unnoticed by many companies. During almost every trip I make I hear another story of a company that has been using OSGi for years. Most companies are proud about it but do not seek publicity. I think it is a character trait of embedded people to just get it done and not talk too much about it. There are also other reasons. For some companies it is such a strategic advantage that they do not want their competition to learn about their use of OSGi.
From my experience, I expect that in the next two years a lot of stories will surface where people tell how they successfully used OSGi technology to control many, many high end embedded devices. If you apply OSGi technology in an interesting environment, and you can talk about it, let me know. I’d love to write some articles about cool applications with OSGi technology.
Peter Kriens
OSGi Blog
Monday, June 5, 2006
Monday, May 22, 2006
OSGi Alliance @ JavaOne
This blog is terribly late due to a security issue at our provider that interfered with a spam filter on Gmail :-( Excuses.
The OSGi BOFs that we had organized were a complete success. The Thursday BOF attracted over a hundred people; this is incredibly successful considering that this BOF was at 8.30 PM while the “JavaOne After Dark Bash” was going on at the same time. The BOF started a bit scary because the organization had not setup the tables I had requested. Fortunately, we could steal some tables from the public space. We started with a presentation by BJ Hargrave. He was regularly interrupted with questions. Often he did not get a chance to answer the questions because someone in the audience did. This created a very interactive feeling, which worked well. After 20 minutes we asked the people to go to the demonstrations or get an OSGi T-Shirt. Though the T-Shirts won the popularity contest in the beginning, the demonstrations then won hands on. We had presentations from ProSyst, Siemens, Paremus, and Luminis. While all this was going on we presented a slide show of 240 slides (!) that consisted of presentations that I had received about OSGi related projects (Thanks all submitters!). In the end we had to be forcefully removed from the room for the next BOF.
The BOF on Wednesday, Component Programming was also quite successful. We attracted around 50 people, which at 10.30 PM and a million parties going on is amazing. I presented the introduction to the OSGi. Thomas Watson gave a presentation how Eclipse can be used to program components and Jeff McAffer talked about the Slug. We got lots of good questions and the feedback was very positive.
We also had lots of questions about the OSGi during the conference. I had made some nice shirts with “Ask me about OSGi” on the back and this generated the desired response. I also had printed stickers with this slogan and hand wrestled everybody that knew anything about the OSGi specifications to wear them. It was a bit awkward that there were actually a surprising number of people that had never heard of “OSGi”. Well, I guess there still is a lot of evangelizing to do.
Very positive are the reactions about OSGi and the enterprise. I have met many people that are extremely excited about OSGi technology being used with Spring and other enterprise technologies. I think the coming year will be very exciting with all the developments in this area. The OSGi Alliance really must organize a workshop on OSGi in the Enterprise soon.
From an OSGi Alliance point of view JavaOne was a great success!
The conference itself was, from my point of view, rather disappointing. It is big and it is monopolized by Sun; it was not easy to find a technical presentation by a non-Sun employee. I actually think I got a bit of a rash from too much sun exposure …
Peter Kriens
The OSGi BOFs that we had organized were a complete success. The Thursday BOF attracted over a hundred people; this is incredibly successful considering that this BOF was at 8.30 PM while the “JavaOne After Dark Bash” was going on at the same time. The BOF started a bit scary because the organization had not setup the tables I had requested. Fortunately, we could steal some tables from the public space. We started with a presentation by BJ Hargrave. He was regularly interrupted with questions. Often he did not get a chance to answer the questions because someone in the audience did. This created a very interactive feeling, which worked well. After 20 minutes we asked the people to go to the demonstrations or get an OSGi T-Shirt. Though the T-Shirts won the popularity contest in the beginning, the demonstrations then won hands on. We had presentations from ProSyst, Siemens, Paremus, and Luminis. While all this was going on we presented a slide show of 240 slides (!) that consisted of presentations that I had received about OSGi related projects (Thanks all submitters!). In the end we had to be forcefully removed from the room for the next BOF.
The BOF on Wednesday, Component Programming was also quite successful. We attracted around 50 people, which at 10.30 PM and a million parties going on is amazing. I presented the introduction to the OSGi. Thomas Watson gave a presentation how Eclipse can be used to program components and Jeff McAffer talked about the Slug. We got lots of good questions and the feedback was very positive.
We also had lots of questions about the OSGi during the conference. I had made some nice shirts with “Ask me about OSGi” on the back and this generated the desired response. I also had printed stickers with this slogan and hand wrestled everybody that knew anything about the OSGi specifications to wear them. It was a bit awkward that there were actually a surprising number of people that had never heard of “OSGi”. Well, I guess there still is a lot of evangelizing to do.
Very positive are the reactions about OSGi and the enterprise. I have met many people that are extremely excited about OSGi technology being used with Spring and other enterprise technologies. I think the coming year will be very exciting with all the developments in this area. The OSGi Alliance really must organize a workshop on OSGi in the Enterprise soon.
From an OSGi Alliance point of view JavaOne was a great success!
The conference itself was, from my point of view, rather disappointing. It is big and it is monopolized by Sun; it was not easy to find a technical presentation by a non-Sun employee. I actually think I got a bit of a rash from too much sun exposure …
Peter Kriens
Wednesday, May 10, 2006
Why Installers are Evil
About 7 years ago the OSGi Alliance forced me to switch from a Macintosh to a PC. Ok, they did not wrestle my arm but I needed access to the latest (and not so greatest) version of Java to do my work properly. With regret, I parted with my dear Macintosh and dived into the wonderful new world of PCs. Now, as a Mac owner you are bound to be a bit naïve about computing, you actually think it is not such a big deal. Well, you find out how wrong you are when you migrate to the PC.
The first time I stepped into the PC mess was when I wanted to clean up my disk. Excited about all the free downloadable goodies (and baddies) I had collected quite a set. I had installed these applications in different places on my hard disk and and decided to group them nicely in a folder. As you know, and I do know now, that is a distinctly stupid idea. It is useful, but still stupid because Windows does not want you to do that and in a fight between you and Windows, you find out why many call it “Win”.
Well, maybe that is too much credit; Windows has actually no clue that you moved the application file; the next time it needs the application it will blindly look in the old place and fail miserably with a cryptic message. After having too many of those cryptic message, I decided to reformat and reinstall Windows. I learned my lesson and after that occasion I never cleaned up anymore (My wife sometimes has a problem with this behavior, but fortunately she is significantly more benign than Windows).
So what is this rant doing in an OSGi related blog? Well, there is a lesson that we learned early in the OSGi: installers are evil. This is easy to say, but I will try to make it clear to you. Let us analyze why it became so painful to move these files around on a PC and not on a Mac. On the Mac, an application is a single file (on System X, it is actually a directory). This file is a simple database that consists of the code resources and other resources like configuration files, icons, html pages, properties, translations, etc. Anything that the program needs is stored in this single file. This file is introspective; this means that other programs can inspect the contents and react according to this content. We call these progams/utilities that react to this content extensions. Extensions are extremely useful.
Application files have a special type in the Mac, and this type is recognized by the disk operating system. Whenever you copy or move an application file the OS will track this in an application database. The OS actually looks in the application file's database and finds the information about the files it can open and other useful aspects. Ergo, you can move the applications around as much as you want; the OS just finds them when you need them. It has this genuine advantage that if you trash the application file, you really cleaned up all aspects of that application.
So why does Windows fail so miserably when you move an application to another directory? Well, Windows does not track the applications because it has installers! An installer is an ingenious piece of software that most PC users think is a necessity of nature. It is usually zipped and then compressed after which it is squeezed, requires a lot of thinking, asks you questions you have no clue how to answer or could not care less (fortunately there are defaults), shows lines that you cannot read because they are replaced too quick (which at least gives you the cozy feeling something is happening), splatters files all over your hard disk (sometimes in quite unexpected places), overwrites important DLLs, then spends minutes updating the registry, after which it asks you to read a README file that is incomprehensible until you need it because the application balks at you; unfortunately at that time you have no clue where to find it anymore. And if this all went well, you can run the application. The fact that this is all overkill is demonstrated by Eclipse that has no installer.
You would expect that for security reasons Windows would have a registry of these installed applications, and a way to forcefully uninstall an application. Well, you thought wrong. There is something of a voluntary registry that the installers can fill in if they feel like it. However, the information is not guaranteed by Windows. Worse, to uninstall an application Windows will ask the original installer to remove all the files, remove the registry changes, and generally clean up. The uninstaller sometimes fails because a file is missing or something else is wrong. At such a moment you have an orphan application that likely remains as a bit-squatter until you have to reformat your hard disk. Lots of these orphans can bring that time significantly closer.
When we designed the OSGi framework we were sure that the Windows Installer model was not where we wanted to go; the Mac model looked a lot more attractive. Fortunately, the JAR file model of Java is an even more powerful format than the Mac resource file. The ZIP file format is flexible enough to allow all kinds of application extension scenarios based on resource name and directory. However, due to the security risk attached to running applications we decided to strictly control all the aspects of the installation, update, and uninstallation; all these are primitive in the OSGi, there is no untrusted code involved. OSGi applications (bundles) can normally not move files to odd places and modify all kinds of settings. OSGi applications can declare information in their JAR files and other applications or utilities can inspect this information and act upon it. This is a clear example of Inversion of Control or IoC: “Don't call us, we'll call you!” For example, an application using Declarative Services contains an XML file with the proper setup. When the application is installed the Declarative Service implementation will find this file, the application does not have to register.
This is an incredibly robust model that prevents a lot of abuse and errors. As a simple example, assume an application fails all the time and you want to uninstall it. The fact that the application fails makes it very likely that the uninstaller will also fail. Leaving remnants in lots of places on your system. An OSGi application can always be uninstalled by the Framework. The uninstallation will notify any applications that performed some function on behalf of the uninstalled application. These other applications are in a good state and can therefore cleanup correctly, regardless of the state of the culprit.
The application model of the OSGi has learned from its predecessors and provides excellent characteristics. Most importantly: An overview what you have really installed and a guarantee that you can always throw anything away.No code can run without the Framework being aware of it.
Every time when new groups enter the OSGi Alliance we have the Installer discussion again. Every time people ask me how it can be wrong when Windows does it that way? 100 million users can't be wrong, can they? I leave that up to you to figure it out.
Peter Kriens
The first time I stepped into the PC mess was when I wanted to clean up my disk. Excited about all the free downloadable goodies (and baddies) I had collected quite a set. I had installed these applications in different places on my hard disk and and decided to group them nicely in a folder. As you know, and I do know now, that is a distinctly stupid idea. It is useful, but still stupid because Windows does not want you to do that and in a fight between you and Windows, you find out why many call it “Win”.
Well, maybe that is too much credit; Windows has actually no clue that you moved the application file; the next time it needs the application it will blindly look in the old place and fail miserably with a cryptic message. After having too many of those cryptic message, I decided to reformat and reinstall Windows. I learned my lesson and after that occasion I never cleaned up anymore (My wife sometimes has a problem with this behavior, but fortunately she is significantly more benign than Windows).
So what is this rant doing in an OSGi related blog? Well, there is a lesson that we learned early in the OSGi: installers are evil. This is easy to say, but I will try to make it clear to you. Let us analyze why it became so painful to move these files around on a PC and not on a Mac. On the Mac, an application is a single file (on System X, it is actually a directory). This file is a simple database that consists of the code resources and other resources like configuration files, icons, html pages, properties, translations, etc. Anything that the program needs is stored in this single file. This file is introspective; this means that other programs can inspect the contents and react according to this content. We call these progams/utilities that react to this content extensions. Extensions are extremely useful.
Application files have a special type in the Mac, and this type is recognized by the disk operating system. Whenever you copy or move an application file the OS will track this in an application database. The OS actually looks in the application file's database and finds the information about the files it can open and other useful aspects. Ergo, you can move the applications around as much as you want; the OS just finds them when you need them. It has this genuine advantage that if you trash the application file, you really cleaned up all aspects of that application.
So why does Windows fail so miserably when you move an application to another directory? Well, Windows does not track the applications because it has installers! An installer is an ingenious piece of software that most PC users think is a necessity of nature. It is usually zipped and then compressed after which it is squeezed, requires a lot of thinking, asks you questions you have no clue how to answer or could not care less (fortunately there are defaults), shows lines that you cannot read because they are replaced too quick (which at least gives you the cozy feeling something is happening), splatters files all over your hard disk (sometimes in quite unexpected places), overwrites important DLLs, then spends minutes updating the registry, after which it asks you to read a README file that is incomprehensible until you need it because the application balks at you; unfortunately at that time you have no clue where to find it anymore. And if this all went well, you can run the application. The fact that this is all overkill is demonstrated by Eclipse that has no installer.
You would expect that for security reasons Windows would have a registry of these installed applications, and a way to forcefully uninstall an application. Well, you thought wrong. There is something of a voluntary registry that the installers can fill in if they feel like it. However, the information is not guaranteed by Windows. Worse, to uninstall an application Windows will ask the original installer to remove all the files, remove the registry changes, and generally clean up. The uninstaller sometimes fails because a file is missing or something else is wrong. At such a moment you have an orphan application that likely remains as a bit-squatter until you have to reformat your hard disk. Lots of these orphans can bring that time significantly closer.
When we designed the OSGi framework we were sure that the Windows Installer model was not where we wanted to go; the Mac model looked a lot more attractive. Fortunately, the JAR file model of Java is an even more powerful format than the Mac resource file. The ZIP file format is flexible enough to allow all kinds of application extension scenarios based on resource name and directory. However, due to the security risk attached to running applications we decided to strictly control all the aspects of the installation, update, and uninstallation; all these are primitive in the OSGi, there is no untrusted code involved. OSGi applications (bundles) can normally not move files to odd places and modify all kinds of settings. OSGi applications can declare information in their JAR files and other applications or utilities can inspect this information and act upon it. This is a clear example of Inversion of Control or IoC: “Don't call us, we'll call you!” For example, an application using Declarative Services contains an XML file with the proper setup. When the application is installed the Declarative Service implementation will find this file, the application does not have to register.
This is an incredibly robust model that prevents a lot of abuse and errors. As a simple example, assume an application fails all the time and you want to uninstall it. The fact that the application fails makes it very likely that the uninstaller will also fail. Leaving remnants in lots of places on your system. An OSGi application can always be uninstalled by the Framework. The uninstallation will notify any applications that performed some function on behalf of the uninstalled application. These other applications are in a good state and can therefore cleanup correctly, regardless of the state of the culprit.
The application model of the OSGi has learned from its predecessors and provides excellent characteristics. Most importantly: An overview what you have really installed and a guarantee that you can always throw anything away.No code can run without the Framework being aware of it.
Every time when new groups enter the OSGi Alliance we have the Installer discussion again. Every time people ask me how it can be wrong when Windows does it that way? 100 million users can't be wrong, can they? I leave that up to you to figure it out.
Peter Kriens
Friday, May 5, 2006
The OSGi Needs You!
More than 20 years ago Brad Cox promoted his Software ICs. In those 20 years, Object Oriented technologies have solved many problems and during this time frame it has become a tremendous success, Java could not have existed without OO. However, so far we did not succeed in creating the component market that Brad Cox once envisioned. The key reason that it never worked out is that software is the wrong name for what we are producing; brittleware would have been a better name. Despite the improvements in tools and knowledge, component oriented systems turned out to be very difficult to engineer. What are the reasons that this attractive idea is so hard to achieve?
The following is my list of requirements that must be satisfied for a successful component model:
This is clearly not a list that a single company can develop as a product. It is also clearly more than just the Java environment, though Java provides a big chunk. A cross industry component model requires the cooperation of large number of companies to create the required eco system. This is exactly what the OSGi Alliance has done. Over the past 7 years they developed a component framework that satisfies all these technical requirements, and more.
We seem to have achieved our technical goal as is proven by the large number of applications building upon OSGi technology. However, to achieve our long term vision of “components roaming freely”, we need more, much more. To achieve adoption in the mainstream software shops we need to cross a chasm; a chasm that any new technology must cross. This is a difficult passage because most people resist change.
To resist the change, people currently use the following arguments against OSGi based solutions:
Hardware cost? We have been telling people that the cost issue will go away and today I am glad to tell you, it really did go away. OK, kidding, but with flash going for 1 cent per MByte the hardware cost issues is really on its way of becoming moot. There is of course the extra processor capacity required and the VM can be a significant cost but more and more vendors are providing good alternatives to SUN’s VMs for reasonable cost. The OSGi component model simplifies the use of alternative VMs so much that the Apache Harmony VM (free!) has chosen OSGi at its foundation.
Testing is another problem. Mainstream developers, project managers, and general managers are skeptical that anything dynamic in their software configuration can really work. Most seasoned developers have lived through nightmarish situations with late and buggy software. To manage their processes, they have installed safeguards and measures to ensure that the product that goes out the door is actually working in at least one context. Often these safeguards require a frozen system when it is tested; something that is very much at odds with a component model where the components each have a different life cycle.
This fear of change in itself is at odds with where the mainstream of computing is heading. Devices are networked and must survive in a continuously changing world. As an industry we must evolve to a model where software is less brittle and more robust. Freezing the world during testing, as so many do, just means that many, many errors will be found by the users in the real world where time tends not to be frozen. Facing the problems up front is the better solution.
Unproven? Type in OSGi in Google and browse … Should the US National Guard order a system to detect bio terror attacks on an unproven technology? Would Eclipse knowingly put unproven technology under the hood knowing that their IDE will be downloaded millions of times? Don’t think so, the OSGi specifications have already clearly proven themselves over and over, in many different situations.
I am convinced that the OSGi Alliance provides a crucial function to achieve this ubiquitous computing model we have trying to achieve for so many years. We have the technology, we have the enthusiastic early adopters, and we have the ears of many in the mainstream markets, among them some of the largest software companies in the world like IBM, Siemens, and Nokia. However, to continue, we also need your help as well. To achieve the credibility needed to cross the chasm, the OSGi Alliance needs many more mainstream companies to use and help promote the OSGi specifications. You can do this for the pay off, which can be big: a cross industry component market will be gigantic. You can do this because a unified component market will simplify your development and reduce its cost. You can do it because you share our vision and want to help it come true. Or you can do this because you believe this is the right way to go. Whatever your motives, the OSGi Alliance needs your support as a member, as an adopter associate, or if you cannot afford the fee, as an enthusiastic user.
Hope to see you on the next OSGi member meeting!
Peter Kriens
The following is my list of requirements that must be satisfied for a successful component model:
- Portability – The model must be supported on virtually any device, or critical market size will not be achieved.
- Deployment & Management – Today’s devices are all networked. This will require remote management and deployment of components.
- Loosely coupled – Objects never made it as components because they were too tightly coupled to their environment. Components should be allowed to mix and match.
- Security – A component model for networked devices requires security to prevent the system against viruses, malicious code, and erroneous code.
- Dynamic – Component updates should not cause the system to shut down completely. Change is an integral part of today’s computing world.
- Non Intrusive – The programming model should not overly restrict the programmer or create unnecessary intrusions in plain old java code.
This is clearly not a list that a single company can develop as a product. It is also clearly more than just the Java environment, though Java provides a big chunk. A cross industry component model requires the cooperation of large number of companies to create the required eco system. This is exactly what the OSGi Alliance has done. Over the past 7 years they developed a component framework that satisfies all these technical requirements, and more.
We seem to have achieved our technical goal as is proven by the large number of applications building upon OSGi technology. However, to achieve our long term vision of “components roaming freely”, we need more, much more. To achieve adoption in the mainstream software shops we need to cross a chasm; a chasm that any new technology must cross. This is a difficult passage because most people resist change.
To resist the change, people currently use the following arguments against OSGi based solutions:
- Too expensive or too slow
- Hard to test
- Unproven
Hardware cost? We have been telling people that the cost issue will go away and today I am glad to tell you, it really did go away. OK, kidding, but with flash going for 1 cent per MByte the hardware cost issues is really on its way of becoming moot. There is of course the extra processor capacity required and the VM can be a significant cost but more and more vendors are providing good alternatives to SUN’s VMs for reasonable cost. The OSGi component model simplifies the use of alternative VMs so much that the Apache Harmony VM (free!) has chosen OSGi at its foundation.
Testing is another problem. Mainstream developers, project managers, and general managers are skeptical that anything dynamic in their software configuration can really work. Most seasoned developers have lived through nightmarish situations with late and buggy software. To manage their processes, they have installed safeguards and measures to ensure that the product that goes out the door is actually working in at least one context. Often these safeguards require a frozen system when it is tested; something that is very much at odds with a component model where the components each have a different life cycle.
This fear of change in itself is at odds with where the mainstream of computing is heading. Devices are networked and must survive in a continuously changing world. As an industry we must evolve to a model where software is less brittle and more robust. Freezing the world during testing, as so many do, just means that many, many errors will be found by the users in the real world where time tends not to be frozen. Facing the problems up front is the better solution.
Unproven? Type in OSGi in Google and browse … Should the US National Guard order a system to detect bio terror attacks on an unproven technology? Would Eclipse knowingly put unproven technology under the hood knowing that their IDE will be downloaded millions of times? Don’t think so, the OSGi specifications have already clearly proven themselves over and over, in many different situations.
I am convinced that the OSGi Alliance provides a crucial function to achieve this ubiquitous computing model we have trying to achieve for so many years. We have the technology, we have the enthusiastic early adopters, and we have the ears of many in the mainstream markets, among them some of the largest software companies in the world like IBM, Siemens, and Nokia. However, to continue, we also need your help as well. To achieve the credibility needed to cross the chasm, the OSGi Alliance needs many more mainstream companies to use and help promote the OSGi specifications. You can do this for the pay off, which can be big: a cross industry component market will be gigantic. You can do this because a unified component market will simplify your development and reduce its cost. You can do it because you share our vision and want to help it come true. Or you can do this because you believe this is the right way to go. Whatever your motives, the OSGi Alliance needs your support as a member, as an adopter associate, or if you cannot afford the fee, as an enthusiastic user.
Hope to see you on the next OSGi member meeting!
Peter Kriens
Saturday, April 29, 2006
OSGi Design Technique
Details are important when you are responsible for writing a spec. You are the one to get blamed when one of the myriad of details is ambiguous, or god forbid, forgotten. This focus on details sometimes makes me forget how important the high level view is. The details can be perfected, but if it is not useable in real systems, we have a serious problem. I therefore want to discuss some higher level design issues that come up once you have decided to develop your next project on top of an OSGi Service Platform.
Where do you start with design? What are good OSGi based designs? Obviously, most criteria for good design are shared with non-OSGi based systems. However, the OSGi Framework provides an environment for components. Designing with components is clearly not yet mainstream and there are few established rules. So let me give you my 2cts worth.
What is a component? An OSGi component is a dynamically deployable unit that provides a function through a set of services, which are defined by a Java interface. For example, an OSGi Log component would be implemented in a bundle, its packaging, which could potentially contain other components. If this bundle is started it provides a Log Service and a Log Reader Service to the world. Other bundles can get these services and use them as they see fit. From a design point of view we can therefore treat the component as a black box with ports (the services) for the communication.
I know there are today standard module and interface symbols in UML but I never got the hang of them (I really tried!). They happen to be the most complicated symbols in UML, while a component design uses them almost exclusively. Also, the dynamic nature of OSGi services is very difficult to represent with UML. Trying to use UML for what belongs to the primitives of an OSGi Framework tends to clutter the picture. I therefore usually use a circle for a bundle and a triangle for a service. The service can be used in 3 different ways by a bundle, and this needs to be depicted:
1. Consumer – The bundle that gets the service is the consumer. The arrow from the bundle attaches to the horizontal or vertical line on a service triangle. An OSGi service can be consumed many times by any bundle. Many bundles can therefore connect to the horizontal or vertical line of the triangle.
2. Implementer – The bundle that implements the service must register it. This is depicted by drawing a line to a corner of the triangle. An OSGi service can be registered many times by the same or different bundles.
3. Listener – A listener bundle connects to one of the angled lines of the triangle. A listener is notified of registrations, modifications and unregistrations of the service. A service can have many listeners.
A service is identified by its interface. The service can be seen as a joint or flexpoint in the system. It decouples bundles from each other and decoupling is something you have to pay a lot of attention to! This decoupling is achieved because all three involved dependencies are directed towards the service. None of the bundles has a dependency on any of the other bundles. I might bore you, but I can not stress enough how important this concept is!
So where do you need these joints in the system? Well, the simple answer is: everywhere you want to decouple, which should be in a lot of places. The trick is to put a service whenever you can break the coupling between bundles.
Services are obvious for big functions like a log service, a configuration admin service, and, for example, the permission admin service. These types of services are similar to what you would get from JNDI or interfaces that would be injected with systems like Spring. These types of services are used to wire the application to providers of specific types of function blocks. Normally, the dependency on these services is static because the bundle can not operate without the presence of these function blocks.
Services are also applicable when you dynamically need instances of a specific type, but you could not care less how they are implemented. An example of this class is the archetypical OSGi scenario of controlling lights. You would not believe how many home automation protocols exist, and each protocol has its own cumbersome and particular way to control a light. The service registry was developed with this use case very much in mind. Different bundles could register a “Light” service, mapping the interface semantics to different protocols. The bundle that needed to control the lights no longer has to worry about trivial details like bits and protocols; it could just get the Light services and play with them as it sees fit, oblivious of implementation details. This pattern translates well to Bluetooth devices, available database servers, available printers, legacy system connections, etc. This pattern very clearly elucidates why OSGi services are dynamic.
Another class of services is the listeners. After release 1 we realized that we could seriously simplify applications when we used the whiteboard pattern. The whiteboard pattern is an example of inversion of control (IoC). That is: “Do not call us, we will call you”. If you need something from the world or have something useful functionality to offer to the world, register a service and wait till somebody calls you. The basic approach of the whiteboard pattern is to announce what you have, but in no way try to control the usage. You provide, but you do not control. Today there are many standard OSGi services that use this pattern: Event Admin, for example, will send its events to any service that registers itself as an Event Handler. The Event Handler uses properties to select the events it is interested in, preventing unnecessary callbacks. This is an extremely successful model, albeit many programmers have a hard time getting used to the loss of control that they feel.
The best litmus test for a service is: “Do I decrease coupling”? If I put a service here, do we need less people to decide upon its interface then when I put it there? If you can minimize interactions between bundles (implementations) you are moving in the right direction. The reason that you want to minimize the coupling is because this usually directly translates to development cost. Trying to agree on interfaces between 10 parties is a lot harder than agreeing between 2 parties. Later phases are also more complex when more coupling is present. For example, testing decoupled components is so much easier than components that are coupled to the kitchen sink as well as to the coffee maker.
At first this way of designing is cumbersome, you have the feeling you create lots of interfaces and do not do anything really productive like writing code. However, hours spent selecting those interfaces are probably your most productive hours of the entire project. Do not hesitate to throw designs and start over from scratch. For one customer, I found almost 200 deliverables (bundles, OSGi services, or external interfaces). This large number explained why they had had so much problem progressing with the development of the system. Doing this analysis gave them an insight in the complexity for the first time. A part of that system is shown in the following picture (the parallelograms are web services). Though I can not show the details due to confidentiality agreements (the fuzziness is on purpose), it shows the extensive use of services and bundles.
After you have done this work, the next step is to develop the service interfaces. This is frustrating work! It usually involves hard negotiations between different parties at the time that most participants have not much of a clue yet. So assume you won’t get it right the first time. However, do not worry about it too much because it will need iterations anyway. Your gain is that you minimized the parties involved in a discussion because you minimized coupling. Most of the time, a service interface is owned by a small group or even a person, and used by other groups or persons. If you did the design right, you should have found the minimum number of interactions. So yes, it will be a lot of work but at least it will be the minimal amount of work.
A key advantage with this model is that you now have a relatively stable set of services and that all involved parties can start coding against these interfaces, and even compile. For larger projects it is worth the effort to develop test stubs early in the process. This will allow the users of the interfaces to test their code as well. If you can get the group(s) responsible for implementing these key services to write them, you will notice that they usually modify them in this process because they learn a lot from this experience.
The next phase is implementing the bundles. This is usually the longest part because it means getting things to work really. Do not hesitate to refactor the service interfaces when you learn the original design was flawed. Developing software is in a large part a discovery process, refactoring is inherent in the fact that your insights change. If you had followed the guidelines and had minimized the overall decoupling of the system, refactoring of the interfaces should be straightforward. Never hesitate to improve the service interfaces if you see a possibility where you can do better. You might save a few days by ignoring these improvements but you will pay much more later if you ignore those improvements.
A well designed component system will notice that interactions between groups are significantly less and more focused on specific service interfaces than monolithic designs. Obviously, this directly translates in development dollars.
The only caveat I know is the surprise that comes at integration time when you do not prepare early for that surprise. Unconstrained, bundle programmers will happily code away and implement the requested functionality in the best way they can. However, what they can not see is how their components will work when put together with 200 other components. A typical example is the initialization time. Bundle programmers will not notice a 2 second initialization time because they do a simple DNS lookup in the Bundle Activator. However, multiplying this with 200 will not put a smile on your manager’s face: 400 seconds is still six and a half minute. If this happens a day before the navigation system needs to be delivered, it will be sufficient time to walk to your desk and pack your belongings. Therefore, a component design requires early integration and lots of later integrations. This is the only way to find bottlenecks early on.
Hmm, maybe this subject is a bit too much for a blog, I do not think I ever got to page 5 before. However, this subject needs more attention because designing with services for an OSGi service platform is different than writing a normal Java application. Let me know if you think this is useful or if I should stick to the details from now on …
Peter Kriens
Where do you start with design? What are good OSGi based designs? Obviously, most criteria for good design are shared with non-OSGi based systems. However, the OSGi Framework provides an environment for components. Designing with components is clearly not yet mainstream and there are few established rules. So let me give you my 2cts worth.
What is a component? An OSGi component is a dynamically deployable unit that provides a function through a set of services, which are defined by a Java interface. For example, an OSGi Log component would be implemented in a bundle, its packaging, which could potentially contain other components. If this bundle is started it provides a Log Service and a Log Reader Service to the world. Other bundles can get these services and use them as they see fit. From a design point of view we can therefore treat the component as a black box with ports (the services) for the communication.
I know there are today standard module and interface symbols in UML but I never got the hang of them (I really tried!). They happen to be the most complicated symbols in UML, while a component design uses them almost exclusively. Also, the dynamic nature of OSGi services is very difficult to represent with UML. Trying to use UML for what belongs to the primitives of an OSGi Framework tends to clutter the picture. I therefore usually use a circle for a bundle and a triangle for a service. The service can be used in 3 different ways by a bundle, and this needs to be depicted:
1. Consumer – The bundle that gets the service is the consumer. The arrow from the bundle attaches to the horizontal or vertical line on a service triangle. An OSGi service can be consumed many times by any bundle. Many bundles can therefore connect to the horizontal or vertical line of the triangle.
2. Implementer – The bundle that implements the service must register it. This is depicted by drawing a line to a corner of the triangle. An OSGi service can be registered many times by the same or different bundles.
3. Listener – A listener bundle connects to one of the angled lines of the triangle. A listener is notified of registrations, modifications and unregistrations of the service. A service can have many listeners.
A service is identified by its interface. The service can be seen as a joint or flexpoint in the system. It decouples bundles from each other and decoupling is something you have to pay a lot of attention to! This decoupling is achieved because all three involved dependencies are directed towards the service. None of the bundles has a dependency on any of the other bundles. I might bore you, but I can not stress enough how important this concept is!
So where do you need these joints in the system? Well, the simple answer is: everywhere you want to decouple, which should be in a lot of places. The trick is to put a service whenever you can break the coupling between bundles.
Services are obvious for big functions like a log service, a configuration admin service, and, for example, the permission admin service. These types of services are similar to what you would get from JNDI or interfaces that would be injected with systems like Spring. These types of services are used to wire the application to providers of specific types of function blocks. Normally, the dependency on these services is static because the bundle can not operate without the presence of these function blocks.
Services are also applicable when you dynamically need instances of a specific type, but you could not care less how they are implemented. An example of this class is the archetypical OSGi scenario of controlling lights. You would not believe how many home automation protocols exist, and each protocol has its own cumbersome and particular way to control a light. The service registry was developed with this use case very much in mind. Different bundles could register a “Light” service, mapping the interface semantics to different protocols. The bundle that needed to control the lights no longer has to worry about trivial details like bits and protocols; it could just get the Light services and play with them as it sees fit, oblivious of implementation details. This pattern translates well to Bluetooth devices, available database servers, available printers, legacy system connections, etc. This pattern very clearly elucidates why OSGi services are dynamic.
Another class of services is the listeners. After release 1 we realized that we could seriously simplify applications when we used the whiteboard pattern. The whiteboard pattern is an example of inversion of control (IoC). That is: “Do not call us, we will call you”. If you need something from the world or have something useful functionality to offer to the world, register a service and wait till somebody calls you. The basic approach of the whiteboard pattern is to announce what you have, but in no way try to control the usage. You provide, but you do not control. Today there are many standard OSGi services that use this pattern: Event Admin, for example, will send its events to any service that registers itself as an Event Handler. The Event Handler uses properties to select the events it is interested in, preventing unnecessary callbacks. This is an extremely successful model, albeit many programmers have a hard time getting used to the loss of control that they feel.
The best litmus test for a service is: “Do I decrease coupling”? If I put a service here, do we need less people to decide upon its interface then when I put it there? If you can minimize interactions between bundles (implementations) you are moving in the right direction. The reason that you want to minimize the coupling is because this usually directly translates to development cost. Trying to agree on interfaces between 10 parties is a lot harder than agreeing between 2 parties. Later phases are also more complex when more coupling is present. For example, testing decoupled components is so much easier than components that are coupled to the kitchen sink as well as to the coffee maker.
At first this way of designing is cumbersome, you have the feeling you create lots of interfaces and do not do anything really productive like writing code. However, hours spent selecting those interfaces are probably your most productive hours of the entire project. Do not hesitate to throw designs and start over from scratch. For one customer, I found almost 200 deliverables (bundles, OSGi services, or external interfaces). This large number explained why they had had so much problem progressing with the development of the system. Doing this analysis gave them an insight in the complexity for the first time. A part of that system is shown in the following picture (the parallelograms are web services). Though I can not show the details due to confidentiality agreements (the fuzziness is on purpose), it shows the extensive use of services and bundles.
After you have done this work, the next step is to develop the service interfaces. This is frustrating work! It usually involves hard negotiations between different parties at the time that most participants have not much of a clue yet. So assume you won’t get it right the first time. However, do not worry about it too much because it will need iterations anyway. Your gain is that you minimized the parties involved in a discussion because you minimized coupling. Most of the time, a service interface is owned by a small group or even a person, and used by other groups or persons. If you did the design right, you should have found the minimum number of interactions. So yes, it will be a lot of work but at least it will be the minimal amount of work.
A key advantage with this model is that you now have a relatively stable set of services and that all involved parties can start coding against these interfaces, and even compile. For larger projects it is worth the effort to develop test stubs early in the process. This will allow the users of the interfaces to test their code as well. If you can get the group(s) responsible for implementing these key services to write them, you will notice that they usually modify them in this process because they learn a lot from this experience.
The next phase is implementing the bundles. This is usually the longest part because it means getting things to work really. Do not hesitate to refactor the service interfaces when you learn the original design was flawed. Developing software is in a large part a discovery process, refactoring is inherent in the fact that your insights change. If you had followed the guidelines and had minimized the overall decoupling of the system, refactoring of the interfaces should be straightforward. Never hesitate to improve the service interfaces if you see a possibility where you can do better. You might save a few days by ignoring these improvements but you will pay much more later if you ignore those improvements.
A well designed component system will notice that interactions between groups are significantly less and more focused on specific service interfaces than monolithic designs. Obviously, this directly translates in development dollars.
The only caveat I know is the surprise that comes at integration time when you do not prepare early for that surprise. Unconstrained, bundle programmers will happily code away and implement the requested functionality in the best way they can. However, what they can not see is how their components will work when put together with 200 other components. A typical example is the initialization time. Bundle programmers will not notice a 2 second initialization time because they do a simple DNS lookup in the Bundle Activator. However, multiplying this with 200 will not put a smile on your manager’s face: 400 seconds is still six and a half minute. If this happens a day before the navigation system needs to be delivered, it will be sufficient time to walk to your desk and pack your belongings. Therefore, a component design requires early integration and lots of later integrations. This is the only way to find bottlenecks early on.
Hmm, maybe this subject is a bit too much for a blog, I do not think I ever got to page 5 before. However, this subject needs more attention because designing with services for an OSGi service platform is different than writing a normal Java application. Let me know if you think this is useful or if I should stick to the details from now on …
Peter Kriens
Monday, April 24, 2006
maven
This weekend Richard S. Hall and his wife Ya-Ching visited us. We picked them up from Nîmes train station after which we had an original French lunch under the city trees. I am pretty sure not enough of this was spent on Richard and me because obviously we had a lot to discuss. To my shame I must admit we probably bored our partners to death with our lingo. Fortunately my wife is hardened after watching me talk shop for over 26 years with hundreds of technical guests.
Though we had lots of subjects we wanted to discuss, it often turned back to Richard pressuring me to become an Apache Felix committer (Ok, I wore my Eclipse committer shirt). So during the weekend we download the Apache Felix source code on my disk. The first hurdle was maven, so far I resisted maven because ant, its predecessor, has always left me with a bad taste in my mouth. However, Apache projects are more or less forced to use maven because it provides an interesting shared repository model, which is obviously crucial for an organization like Apache. Unfortunately, the repository architecture is based on simple hard references instead of the more powerful capability/requirement model of the OSGi bundle repository.
The interesting approach of maven is that it does not try to be a scripting language (which ant tried) but that it works with a declarative model. Project rules are defined in a central place shared between different products while products only declare information. This looks very familiar to me because that is how I always used make (and also later when I was forced to use ant). Redundancy is the root of all software evil, and most ant files I have seen are so redundant because of their copy-paste history that they put Lucifer to shame. Maven addresses this issue by rigidly specifying a project directory structure, which is excellent.
In Maven, each deliverable needs a pom file. A pom file is, you guessed right, an XML file. How anybody can use XML for a human writeable/readable format escapes me, but it has taken epidemic forms. Not sure it is caused by CS students not reading the Dragon Book, or that there are too few CS students writing open source software? Anyway that was enough ranting. The pom file describes the unique facts of your deliverable and its dependencies. Maven reads the pom file and provides this information to the overall shared rule set that then builds your product accordingly.
A crucial aspect of maven is dependency handling. The pom file refers to dependent JARs by a symbolic name. A URL based repository is used to retrieve those dependencies automatically when needed. This works fairly well though I had some troubles operating offline (and the dependency set is amazingly large, I think it downloaded the whole of Apache, though we might have missed Geronimo).
Maven provides a plugin model for special actions. Plugins are activated from the pom file and can access the information in the pom file. Enrique Rodriguez created a special Maven-OSGi plugin that handles the OSGi required manifest entries. When we looked to this I noted that the pom files also contained the import package clauses. This is of course a maintenance nightmare because they depend on the actual code. I recently had written a certifier that basically contains all the required code to calculate the imports, and much more. So I indicated to Richard that it would be a couple of hours work to automatically generate this information. The advantage of Java class files is that they contain so much information.
This sounded like fun so we added the imports. This turned out to be so easy that we decided to do some extra checking. We verified the export statement, we detected bundle activators and allowed them to be automatically set, and we added the hard to write yourself “uses” directive on an export. Obviously we took care to be backward compatible, if you specified the header in the pom file, we verified it. Otherwise we generated it. This is all pretty complex stuff but it went amazingly smooth. I have released the code to Felix so now the Felix community must take a look and see if it fulfils their needs and quality requirements. I guess that is going to be the hard work.
Doing this was just a fun exercise; I always enjoy doing these joint exercises because you learn so much working with someone else. Explaining to our partners that this is more fun than enjoying the sunny weather with them was the hard part.
Peter Kriens
P.S. The OSGi Alliance has a public webinar the Thursday 27th of April. Please join us for information about the new membership class, plans, and the possibility to ask the questions about the OSGi Alliance you were always afraid to ask.
P.P.S. For JavaOne I am still looking for 2-4 slide presentations.
Though we had lots of subjects we wanted to discuss, it often turned back to Richard pressuring me to become an Apache Felix committer (Ok, I wore my Eclipse committer shirt). So during the weekend we download the Apache Felix source code on my disk. The first hurdle was maven, so far I resisted maven because ant, its predecessor, has always left me with a bad taste in my mouth. However, Apache projects are more or less forced to use maven because it provides an interesting shared repository model, which is obviously crucial for an organization like Apache. Unfortunately, the repository architecture is based on simple hard references instead of the more powerful capability/requirement model of the OSGi bundle repository.
The interesting approach of maven is that it does not try to be a scripting language (which ant tried) but that it works with a declarative model. Project rules are defined in a central place shared between different products while products only declare information. This looks very familiar to me because that is how I always used make (and also later when I was forced to use ant). Redundancy is the root of all software evil, and most ant files I have seen are so redundant because of their copy-paste history that they put Lucifer to shame. Maven addresses this issue by rigidly specifying a project directory structure, which is excellent.
In Maven, each deliverable needs a pom file. A pom file is, you guessed right, an XML file. How anybody can use XML for a human writeable/readable format escapes me, but it has taken epidemic forms. Not sure it is caused by CS students not reading the Dragon Book, or that there are too few CS students writing open source software? Anyway that was enough ranting. The pom file describes the unique facts of your deliverable and its dependencies. Maven reads the pom file and provides this information to the overall shared rule set that then builds your product accordingly.
A crucial aspect of maven is dependency handling. The pom file refers to dependent JARs by a symbolic name. A URL based repository is used to retrieve those dependencies automatically when needed. This works fairly well though I had some troubles operating offline (and the dependency set is amazingly large, I think it downloaded the whole of Apache, though we might have missed Geronimo).
Maven provides a plugin model for special actions. Plugins are activated from the pom file and can access the information in the pom file. Enrique Rodriguez created a special Maven-OSGi plugin that handles the OSGi required manifest entries. When we looked to this I noted that the pom files also contained the import package clauses. This is of course a maintenance nightmare because they depend on the actual code. I recently had written a certifier that basically contains all the required code to calculate the imports, and much more. So I indicated to Richard that it would be a couple of hours work to automatically generate this information. The advantage of Java class files is that they contain so much information.
This sounded like fun so we added the imports. This turned out to be so easy that we decided to do some extra checking. We verified the export statement, we detected bundle activators and allowed them to be automatically set, and we added the hard to write yourself “uses” directive on an export. Obviously we took care to be backward compatible, if you specified the header in the pom file, we verified it. Otherwise we generated it. This is all pretty complex stuff but it went amazingly smooth. I have released the code to Felix so now the Felix community must take a look and see if it fulfils their needs and quality requirements. I guess that is going to be the hard work.
Doing this was just a fun exercise; I always enjoy doing these joint exercises because you learn so much working with someone else. Explaining to our partners that this is more fun than enjoying the sunny weather with them was the hard part.
Peter Kriens
P.S. The OSGi Alliance has a public webinar the Thursday 27th of April. Please join us for information about the new membership class, plans, and the possibility to ask the questions about the OSGi Alliance you were always afraid to ask.
P.P.S. For JavaOne I am still looking for 2-4 slide presentations.
Wednesday, April 19, 2006
OSGi and Navigation
One of the most exciting devices I know is a navigation system. I can still feel the awe for this technology despite understanding mostly how it works. It has something uncanny when you follow the instructions of a computer voice you end up right on the exact doorstep. It is amazing. Trying to explain how it works to people usually shows that most people think that the GPS satellites know exactly where you are. It makes you wonder how much people really worry about privacy invasion …
Navigation systems can exemplify why OSGi is important. Currently, all navigation systems that I know are closed boxes. The vendor provides a fixed set of functionality and that is it. However, this means that the navigation system works for the common tasks but not for more specialized tasks. The navigation system vendor has neither the money nor the knowledge to address an almost infinite need of requirements in the real world. These specialized tasks might address a smaller audience than the general tasks, however, the margins in addressing these smaller markets are usually much higher.
This is therefore a perfect example why these systems should have an OSGi Framework and a standardized interface to the navigation system. Allowing third parties to integrate seamlessly with a navigation systems enables third parties to build applications on top of it. Did you ever look at Google Maps? For example, a housing application, earthquakes, or even a game. This creativity and market opportunities are released because Google provides the access to the maps and other “details” while the developer can focus on his specialty. This model is obviously very successful for both parties. In this case Google gets to sell advertisements and the site gets some interesting new functionality.
This exact model is also possible with embedded devices. The only difference is that the vendor can make his profit more easily by selling the device and add-ons. For example, a real estate agent needs to drive a route when she shows a customer potential properties. A plain off the shelf navigation systems is awkward because then she must fill in all the addresses. A small bundle could make a world of difference. It could obtain the addresses from a database, convert them to the navigation system, create the route and provide all the details of the properties when the car approaches. This can seriously reduce the amount of work for the real estate agent, meaning she is willing to pay real money for such a service.
There are many more similar scenarios:
The key reason is of course fear for the future. There are some scary aspects in allowing other parties to use your device. You need more memory and a bigger CPU, which could be prohibitive in a highly competitive market. However, costs are never a problem when the user gets a significant advantage, unfortunately, he first has to see this advantage before believing it. Fortunately there are two trends that will make this feasible soon. Navigation systems are becoming commodities, which will make the vendors look for features, and the price of memory and CPUs is dropping faster and faster.
Another problem currently is that there is no standard API to manage the navigation system from another bundle. The reason that I wrote this blog because I started working on a Navigation Model Service for the OSGi Alliance which made me realize how much you could do with this API. And best of all, once there is a standard API, you might even run these navigation applications in your car as well as in your new OSGi Mobile Platform phone.
Peter Kriens
Navigation systems can exemplify why OSGi is important. Currently, all navigation systems that I know are closed boxes. The vendor provides a fixed set of functionality and that is it. However, this means that the navigation system works for the common tasks but not for more specialized tasks. The navigation system vendor has neither the money nor the knowledge to address an almost infinite need of requirements in the real world. These specialized tasks might address a smaller audience than the general tasks, however, the margins in addressing these smaller markets are usually much higher.
This is therefore a perfect example why these systems should have an OSGi Framework and a standardized interface to the navigation system. Allowing third parties to integrate seamlessly with a navigation systems enables third parties to build applications on top of it. Did you ever look at Google Maps? For example, a housing application, earthquakes, or even a game. This creativity and market opportunities are released because Google provides the access to the maps and other “details” while the developer can focus on his specialty. This model is obviously very successful for both parties. In this case Google gets to sell advertisements and the site gets some interesting new functionality.
This exact model is also possible with embedded devices. The only difference is that the vendor can make his profit more easily by selling the device and add-ons. For example, a real estate agent needs to drive a route when she shows a customer potential properties. A plain off the shelf navigation systems is awkward because then she must fill in all the addresses. A small bundle could make a world of difference. It could obtain the addresses from a database, convert them to the navigation system, create the route and provide all the details of the properties when the car approaches. This can seriously reduce the amount of work for the real estate agent, meaning she is willing to pay real money for such a service.
There are many more similar scenarios:
- Games using real world maps and positioning (maybe not such a good idea in a driving car)
- Destinations that move. For example navigating to a person, querying the position and then navigating to that person wherever he is.
- Traffic alerts
- Showing the position of other people
- Taxis, receiving the route from the dispatcher
- And so much more …
The key reason is of course fear for the future. There are some scary aspects in allowing other parties to use your device. You need more memory and a bigger CPU, which could be prohibitive in a highly competitive market. However, costs are never a problem when the user gets a significant advantage, unfortunately, he first has to see this advantage before believing it. Fortunately there are two trends that will make this feasible soon. Navigation systems are becoming commodities, which will make the vendors look for features, and the price of memory and CPUs is dropping faster and faster.
Another problem currently is that there is no standard API to manage the navigation system from another bundle. The reason that I wrote this blog because I started working on a Navigation Model Service for the OSGi Alliance which made me realize how much you could do with this API. And best of all, once there is a standard API, you might even run these navigation applications in your car as well as in your new OSGi Mobile Platform phone.
Peter Kriens
Subscribe to:
Posts (Atom)