Summary
Jini aficionados of the first hour will probably remember the discussions about UPnP and Jini. Where Jini successfully continued in the non-device arena UPnP seem to die away slowly, until Web Services came to rescue...

Back in the days when Jini was still wrongfully marketed as a networking technology for spontaneously connecting small devices, there was another kid on the block from Microsoft called UPnP. I’m not saying ideas were stolen, but the ‘vision’ behind UPnP had a striking resemblance with what the Jini team came up with a few years earlier. These were the days of plug ’n play, and hardware cooperation without system crashes or hours of manual configuration was the Holy Grail. In an exemplary move Microsoft borrowed some vision from the Jini visionaries, took their own Plug ‘n Play brand and tried to take a piece of the pie.

As has been well documented by the original team there was a mismatch between the vision behind Jini and the message uttered by SUN’s marketing department. Anybody questioning the power of marketing communication should have a talk with any of these members of the original Jini team; they’re still licking their wounds.

Jini is meant for spontaneous networking between services, where it doesn’t matter whether these services are offered by a small device (printer service offered by a printer) or by a regular server (calculation service). Jini is not interested in devices, but in services. Unfortunately for the Jini team Jini was too demanding to run on limited devices. Amongst others the memory footprint was too big and it required object (de)serialization, which was unavailable on small devices. Up till this day that’s still the case; for example, MIDP 2.0 is the latest J2ME standard available on most of the new mobile phones but it still doesn’t support object serialization, which is mandatory for mobile code. Current status: IncaX has a beta version of their Jini IDE geared towards J2ME Jini services development, but next to the surrogate architecture project that’s one of the few Jini enterprises out there.

That doesn’t mean Jini is unsuccessful. On the contrary, the focus on services kept the door open to back-end systems where hardware limitations are less of an issue. Nowadays Jini is being used in a fast growing number of such back-end systems. Once small devices become powerful enough, and they will, Jini will finally enter that highly anticipated arena as well.

In the meantime UP’nP with its focus on hardware disappeared into the background and stayed there for many years.

While Jini was fighting against its own marketing department another kid on the block showed up: web services. XML-based RPC over HTTP was suddenly all the rage.

The Jini crowd, being used to taking the 7/8/X fallacies of network computing seriously, was flabbergasted by this move back to the dark ages. Many a webpage has been filled with discussions about the inherent flaws of Web Services, but still Web Services prevailed. My guess is that that’s due to the original simplicity of Web Service.

Things have changed, though. Web Services have become the largest virtual acronym swamp ever (try to think of any 3 letter acronym starting with a ‘W’ that is not a Web Service related technology), and, more important, the Web Service community started to realize that their technologies were limited with respect to distributed systems. They could never fulfill the promises that, for example, Jini could. One important aspect in this is mobile code, the ability to not only move data but also functionality across the network. Mobile code is actually the fundamental layer of abstraction Jini is based on. This layer is in turn based on Java but could, with some effort, be based on another execution environment. Another aspect is that Web Services don’t have a notion of dynamic, automatic, service cooperation, meaning that services have to be glued together by hand. With the rapidly growing number of Web Services this wouldn’t be a problem if every human has a second job as system administrator… Jini folks hate to say, “we told you so”, but they’d have every right to.

So the Web Services community realized they had a problem and turned to their biggest backer, Microsoft. Fortunately the latter had a half-baked technology lying around that could be used to fill the missing functionality-gaps in Web Services: UPnP! I know that sounds amazing, but read about it on Microsoft's Developer Network site , the article is called ‘Devices Profile for Web Services, A Proposal for UPnP 2.0 Device Architecture’.

It might be me just hanging around too long in the Service Oriented Architectures arena, but I find that kind of funny. How about you?

Talk Back!

Have an opinion? Readers have already posted 8 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Berco Beute adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Berco Beute is innovator with the Dutch research & development institute TNO, where his focus is on the human side of distributed systems in the telecom industry. He has a Master's degree in both mass communication and artificial intelligence, and a PhD in distributed multimedia. Besides software engineering his interest is using software for cognitive science and creating multimedia.