So yesterday Fedex delivered a nice red box at my doorstep! It is always nice when a company spends a bit of effort on designing the box; this package reminded me of my first TomTom, a company that also took care in making the unwrapping experience fun.The content was a BUG with 4 modules. The BUG itself is the core computer that drives (hopefully) cheap modules. The core contains a small LCD, a minimal joystick, a push button and 4 LEDs that can also be pressed. It is powered through a separate (universal) power supply. Unfortunately, the also present small USB connector is not used to power the device; it is only there for the communications with the development computer. A slide-switch acts as on-off button.
There are 4 modules included:
- LCD Display
- GPS
- Motion Detector
- Camera
The development environment is based on (surprise!) Eclipse, called DragonFly. They told me to use Eclipse 3.3 (Europa) but I decided to live risky and use my current 3.4 Ganymede copy of Eclipse. At least this way I can only blame myself for some of the things that did not work. DragonFly replaces PDE but there are a number of similarities. Also, the manifest file is the driver for the generation. Overall it was very simple to write a new bundle when you are familiar with Eclipse. DragonFly nicely creates a complete project for you with the classpath setup correctly.
For debugging there is a pretty good emulator that reuses the same Java code and implements the services that abstract the devices. You just ask a project to "Debug As" and the select the Virtual Bug. Very smooth. Once the Virtual BUG is running it appears as a device in the list of Bugs. You can drag and drop your project to these devices and that will install them. This drag and drop interface works very well for device management.
The runtime is of course the most interesting part of this device. It runs the (now) open source PhoneME project. This is a CDC VM that supports most of the core Java SE libraries. On top of this VM, BUGLabs uses a Concierge framework. Concierge took the decision to not move to Release 4 but stick on Release 3 because of size reasons. This makes my feelings toward concierge slightly ambivalent. Release 4 added some very important changes that I hate to miss. I know that size matters, but the difference is not that dramatic with today's memory prices. Ok, I prefer OSGi over no OSGi, but staying behind on release level is very tricky. Lots of bundles now use the Bundle.getBundleContext() method, like Declarative Services, which is not part of R3. Also, the modularity layer got an important boost in R4. However, the biggest problem is compliance. Concierge was not tested for compliance and with the OSGi's current rules we cannot certify it anymore. During the development of R4 we seriously discussed the problem of the size the new features would take. Siemens, who had their own OSGi implementation for the vehicle market, even did a study to the impact. We very consciously decided that these new features were worth the added memory. I guess there is not much we can do about this, but it is a pity that we now have a split in OSGi, a split which we tried to avoid so hard. Anyway, better an OSGi R3 than no OSGi I guess ...
I decided to build a little application to get a feel for the whole thing. I decided to build an automatic camera that would take a picture whenever the GPS indicated that you had moved more than 50 meters. The track thus created would then be available over a web interface. Formatted as a KML file, it can be displayed in Google Earth. Simple.
Well, writing the application was quite smooth and the debugger was great. Getting it to run on the device was a bit harder because it just did not take pictures. It took some time to figure out how to use the Concierge shell. Even that did not help, there was something with the GPS service. Anyway, I guess with some help this will work before the community event. See if I can get my trip to Berlin recorded!
I wish I had had this device while I was working for Ericsson Research in 1998. It is absolutely perfect for trying out automation scenarios. I remember soldering an IO board, a movement sensor and a mobile phone to demonstrate a burglar alarm system based on sending a picture to the police. This scenario would have been a snap with the BUG.
So what are the application areas for the BUG? If you are one of those lucky people that can now and then wander from the virtual world into reality, then this is abslutely your device. You get a quite powerful computer that can be extended with a snap, ehh, 4 snaps. Obviously, if you still can get excited of what you can do with computers (like me), then it is just too much fun to miss. And if you give OSGi tutorials, well, this kind of device makes OSGi shine.
This is not to say they have arrived. BUG labs still has a lot of work carved out for them. The success will depend on amount of modules they can turn out in the coming years. I wish they had developed a breadboard module first so other companies and individuals could make modules. In earlier times I played a lot with the PIC processors from Microchip and it would be quite easy to interface these into the system. Also, a 1-Wire interface would be really fantastic. 1-wire devices are relatively cheap, and very easy to interface. For a few dollars you could extend a BUG with a temperature sensor, humidity sensor, unique ids, switches, cryptography tokens, etc. Remember the famous Java ring? Well, that was a 1-wire device.
The development environment and the documentation also require some work. As a true open source project they use a Wiki for their documentation so do not hesitate to help to make the BUG more popular. There is also a need for more BUG modules as well: Wifi, audio in/out, power switches, video, bar code readers, proximity detectors, RFID readers, fingerprint readers, Zigbee I/O, Bluetooth, infra-red, geiger-tellers, etc., etc.. There is a mighty amount of work awaiting them.
I really do hope other companies will pick up this concept and start to leverage it. Again, I wish I had had this device in 1998 when we were struggling to create demos!
Peter Kriens
P.S. But what on earth is the Teleporter module going to do???
Peter, I agree that memory consumption is far less an issue nowadays and in fact the BUG has plenty of it. What still matters a lot, especially when it comes to mobile embedded systems, is power consumption. Unfortunately, batteries do not scale with Moore's Law. Therefore, a framework implementation like Concierge which has a lot less cycles per, let's say, service request can effectively pay off.
ReplyDeleteWhen it comes to the advantages of R4, I agree that there has been some significant progress made on the module layer which is important for a lot of applications. However, I so far haven't encountered too many embedded applications that require many different versions of the same bundle running in disjoint class loader spaces.
I would personally love to see OSGi more emerging into a kind of microkernel architecture (where you have the choice to use or not to use feature X) than increasingly pushing more functionality into the framework to support more fancy applications.
As a matter of fact, OSGi is a modular system but the framework is not...
I never said I would never bring Concierge to R4. In fact, would be a nice challenge to find out how small an R4 framework can be (and maybe also how fast Eclipse would start on an R4-compliant Concierge :-)) Unfortunately, this is more an engineering challenge than a research challenge, meaning that I can probably do such a project only as skunk work and this will take some time.
Well, finally, as you mention declarative services, forgive me for being so bold, but I think that's a bad example for (without doubt existing) technical progress made with R4.X. Declarative services have been IMHO broken from the very beginning because they broke the relationship between the service and the bundle which registers it (well, wants do register it by declaring it). Consequently, in R4.1 you had to introduce the hack with Bundle.getBundleContext() to fix this so that the DS service could really register declarative services on behalf of the bundle. Well, passing the bundle context between bundles has always been considered to be bad practice (e.g., R3 specs page 62). Technically more mature implementations of the idea of declarative services like iPOJO, which inject services rather than acting externally on behalf of the declaring bundle, do not require such a hack.
Cheers,
Jan.
1. Power Consumption
ReplyDeleteWell, this argument is one red herring. I do not think there is any relationship between size and battery consumption. A linear search is much smaller than a hash search but the hash will use much less CPU cycles. If there is a relation, it is probable reverse from what you indicate.
E.g. a large part of Equinox' code base is devoted to minimize CPU cycles at startup to improve the user experience. I'd love to see you try to beat them at start up time, but I think you will have a terribly hard time because they spent an insane amount of effort to improve startup time ....
To conclude this point, you can only make such a claim when you measured it because minimization of power consumption is awfully hard to predict.
2. Microkernel
Sigh. You better team up with Richard Hall, he has been ganging up on me forever about this (though I think he is turning around very slowly).
Modularity has two aspects: coupling and cohesion. You want to minimize coupling and maximize cohesion. In JSR 291 we tried to break out the service layer. However, we found that we then needed another extension mechanism. Throwing away a small and perfectly good extension mechanism to replace it with a lousy one did not seem a good idea.
As Exupery said: 'Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.' I think leaving out the service layer would have done more harm than good, indicating that we were not totally wrong.
As a researcher a module toolbox is cool and challenging, I can absolutely sympathize. However, for the industrial programmers there is an advantage to have a minimum granularity.
In R4 we added Require-Bundle and Fragments as options because we tried hard to keep OSGi viable for embedded as well. However, options create confusion and incompatibilities, which was the reason we removed the optionality in R4.1. We really asked the members, and the ones focused embedded extra hard, if they saw this as an issue, and they did not.
To conclude this point, I think the granularity of the framework is not bad, I definitely do not want to break out the layers. There is some garbage but that is inevitable with a spec that has 10 years of history.
3. Declarative Services (DS)
Well, first get your facts straight :-)
DS was never intended to register services with its own Bundle Context. From day one, it was clear that these services needed to originate from the declaring service.
However, we had this false assumption that it was safer to hide the Bundle Context from other bundles. So DS was made a framework extension, it would require a framework specific back door to get the Bundle Context of the target bundle.
Two things happened. The extender pattern became more and more popular because it showed some very interesting decoupling characteristics. Second, one day we realized that you can get to the Bundle Context with reflection if you wanted. Only a security manager can make this safe.
So the getBundleContext() was added to Bundle because it turned out to be very useful and we did not enable anything new, just made it more convenient.
Yes, we warned against this in R3 page 62, and I still think one should be careful with handing out Bundle Context objects. However, since then we learned how incredibly value the extender pattern is. The extender pattern allows you to minimize the complexity of application bundles and offload some of the work to the extenders, with very little work. Would it not be strange if we had not added getBundleContext() because we once warned against it?
A hack is one you take a shortcut because you do not want to do it right. I really fail to see why getBundleContext() falls under this category?
iPOJO is an incredibly interesting approach but it requires development time programming. This can be useful in certain cases, and sometimes the runtime option is better. I do not think it would be good if OSGi would promote one or the other.
I actually like DS a lot ... :-)
4. Multiple versions
Last but not least, the multiple versions, the biggest step we made in R4. I agree they might not be a compelling argument in the embedded world. Though I am sure that in the next decade this problem will also happen in that world.
However, the value of R4 is not in this or some other features. The cost of staying at R3 is the the fork in the OSGi world. Your customers choose a dead end in the long run, with potentially costly consequences in the future. Is that really worth the $0.002 for the 200K extra flash?
Anyway, I think you are doing great work but I strongly believe that the best road forward is to add R4 compatibility pass run the test suites.
Kind regards,
Peter Kriens
1) You can (often) trade a higher memory consumption for CPU time (e.g., through hashing, indexing, ...), no doubt. But I am talking about the relationship of the amount of code executed and the power consumption and I don't see how in a general case, significantly more bytecode executed could save energy. I essentially measured and optimized Concierge for months when I wrote the EuroSys paper and even though I agree that measuring precise power consumption on mobile devices is tricky, the difference in execution- and CPU time when running the same (pretty long-running) set of bundles where so striking when I compared to the R3 frameworks of that time that I feel pretty on the safe side. Meaning, it's not only a difference in SLOC, there is a difference in instructions executed.
ReplyDelete(And I don't say that Equinox is slow. But, why couldn't a minimalistic design like Concierge be faster? RISCs have been typically faster than CISCs, haven't they :-) We'll see).
2) The service layer is the last that I would remove. How could I do remote services then?
Actually, it's not so much about removing anything particular, it's more about how to enable new future ideas and directions without too often extending the frameworks and/or drilling new holes. Microkernel-like architectures are pretty good in this regard.
3) Interesting to hear about the background of getBundleContext(). The extender pattern is great and I frequently use it. E.g., R-OSGi is one big extender pattern. However, I rarely needed getBundleContext(). (But, since I only have to sell ideas and never products, I only build systems and rarely have to write complex applications, which could be a reason)
4) I am pretty sure that I will have R4.1 Concierge ready before the next decade :-) And I would even implement DS for Concierge if this would just help to finally wipe out CLDC on embedded devices (like mobile phones). I guess, slightly more worrying than a poor old-fashioned R3 framework are the amount of up-to-date devices that still cannot run OSGi at all.
Cheers,
Jan.