Why You Should Bundleize
2006-01-16
Being ahead of the pack is not always easy. This weekend I wasted hours and I’ll blame the rest of the world that they haven’t seen the benefit of OSGi yet.
I am preparing an OSGi course that will be posted on this site. One of the components is support for Rendezvous/Bonjour/mDNS. Behind these aliases is a zero-configuration architecture developed by Apple. The interesting part for me is the serice location protocol. Apple used a very clever trick: multicast DNS. DNS always had the possibility to provide information about services with the SRV query. However, normal DNS consists of dedicated servers that are configured with the required information. With a service location protocol you’d rather have a solution where each device could provide this information independently. The trick was to have a DNS server in each device combined with multi-cast addressing. A device that wants to know a service or address just broadcasts the query, any device that has the given information responds with the answers. This is of course a bit of a simplification, the complexity of the protocol lies in the optimizations to reduce traffic.
So I wanted a bundle supporting the mDNS protocol. After a lot of searching I found an article that described a Java implementation called jRendezvous. This looked good, at least it looked like a decent implementation and the license was LGLP. I should have looked further …
I took the library, copied it in Eclipse and turned it into a bundle, 10 minutes work. Unfortunately, it did not work as it should; the service was discovered but could not be resolved. The library fortunately included a browser. This browser recognized my Xerox printer immediately, but it did not resolve my test service. After several hours of debugging well written, but unfamiliar, code I found the problem. The library was written with a well configured DNS system in mind. I did not have such a DNS configured, which meant my IP address ended up in the record as the host name and confused the library. The browser tried to resolve the IP address as if it was a hostname and this obviously failed. The fix was easy and I was so happy. Being a good citizen, I tried to find a way to provide the author of jRendezvous with the patch. The package was written by Arthur van Hoff, one of Java’s founding fathers. Out of curiosity I clicked on the Products link of his site and was unpleasantly surprised with one of those products: JmDNS, a new and novel implementation of the jRendezvous library. Sigh.
So downloaded the project from sourceforge (they had changed the license to Apache 2.0) and spent another 10 minutes turning this code into a bundle, hoping that my problems were fixed in this new release. Unfortunately, it was not fixed, worse the structure of the code was significantly different so I would have to start debugging again. I decided to report the issue to the JmDNS forum, see what happens.
The underlying problem of this story is of course unrelated to JmDNS. We, as an industry, need a standardized format and catalog for software libraries. The OSGi Service Platform is the only suitable candidate for such a delivery model. The OSGi platform provides a good module system for Java that makes it an excellent candidate for such a repository. The OSGi Alliance is working on finalizing the OSGi Bundle Repository, do you have the bundles to fill it?
Peter Kriens
OSGi Evangelist
I am preparing an OSGi course that will be posted on this site. One of the components is support for Rendezvous/Bonjour/mDNS. Behind these aliases is a zero-configuration architecture developed by Apple. The interesting part for me is the serice location protocol. Apple used a very clever trick: multicast DNS. DNS always had the possibility to provide information about services with the SRV query. However, normal DNS consists of dedicated servers that are configured with the required information. With a service location protocol you’d rather have a solution where each device could provide this information independently. The trick was to have a DNS server in each device combined with multi-cast addressing. A device that wants to know a service or address just broadcasts the query, any device that has the given information responds with the answers. This is of course a bit of a simplification, the complexity of the protocol lies in the optimizations to reduce traffic.
So I wanted a bundle supporting the mDNS protocol. After a lot of searching I found an article that described a Java implementation called jRendezvous. This looked good, at least it looked like a decent implementation and the license was LGLP. I should have looked further …
I took the library, copied it in Eclipse and turned it into a bundle, 10 minutes work. Unfortunately, it did not work as it should; the service was discovered but could not be resolved. The library fortunately included a browser. This browser recognized my Xerox printer immediately, but it did not resolve my test service. After several hours of debugging well written, but unfamiliar, code I found the problem. The library was written with a well configured DNS system in mind. I did not have such a DNS configured, which meant my IP address ended up in the record as the host name and confused the library. The browser tried to resolve the IP address as if it was a hostname and this obviously failed. The fix was easy and I was so happy. Being a good citizen, I tried to find a way to provide the author of jRendezvous with the patch. The package was written by Arthur van Hoff, one of Java’s founding fathers. Out of curiosity I clicked on the Products link of his site and was unpleasantly surprised with one of those products: JmDNS, a new and novel implementation of the jRendezvous library. Sigh.
So downloaded the project from sourceforge (they had changed the license to Apache 2.0) and spent another 10 minutes turning this code into a bundle, hoping that my problems were fixed in this new release. Unfortunately, it was not fixed, worse the structure of the code was significantly different so I would have to start debugging again. I decided to report the issue to the JmDNS forum, see what happens.
The underlying problem of this story is of course unrelated to JmDNS. We, as an industry, need a standardized format and catalog for software libraries. The OSGi Service Platform is the only suitable candidate for such a delivery model. The OSGi platform provides a good module system for Java that makes it an excellent candidate for such a repository. The OSGi Alliance is working on finalizing the OSGi Bundle Repository, do you have the bundles to fill it?
Peter Kriens
OSGi Evangelist
Add a comment
| Previous Posts | Archives |
|---|---|