The Artima Developer Community
Sponsored Link

Weblogs Forum
Universal Plug 'n Play: Jini's ex-rival back from the dead?

8 replies on 1 page. Most recent reply: May 15, 2004 3:13 PM by Tim Jansen

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 8 replies on 1 page
Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Universal Plug 'n Play: Jini's ex-rival back from the dead? (View in Weblogs)
Posted: May 11, 2004 10:45 AM
Reply to this message Reply
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...
Advertisement

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?


Tim Jansen

Posts: 4
Nickname: tjansen
Registered: Dec, 2003

Universal Plug 'n Play was never dead Posted: May 12, 2004 2:50 AM
Reply to this message Reply
Actually UPnP was never dead. It may have been not as successful as the proponents have hoped, but the the adoption of network-enabled home devices is also slower than anticipated.

Today UPnP (with the IGD profile) is in almost every consumer-level broadband router. IGD is also supported in a few clients, like Snom's SIP Phones.
The media profile is used in a number of network media gateways, like SMC's EZ Stream system.

On the other hand, I have yet to see a single Jini device.

Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Re: Universal Plug 'n Play was never dead Posted: May 12, 2004 12:12 PM
Reply to this message Reply
Yes, I've seen UPNP in many home-category routers. Now, I'd like to take advantage of these upnp-enabled routers. I heard about the Intel UpnP Java API. Does anyone have experience with that?

Here's a specific problem I would like to solve via UPNP routers: Many DSL and cable Internet users receive dynamically assigned IP addresses for their WAN interface. We have Jini services running on such networks, and we'd like to those services to be notified of changes occuring in the router's external IP address. That way, the Jini services could re-register with local lookup services, with the appropriate codebase annotations so that clients external to the local network can access and invoke those services. I imagine that the UpnP device should have some notification mechanism that the Jini services can register with. Since I'm not familiar with UpnP, that's just a guess. Has anyone any experience doing something like that?

Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

Re: Universal Plug 'n Play was never dead Posted: May 13, 2004 5:21 PM
Reply to this message Reply
> Actually UPnP was never dead. It may have been not as
> successful as the proponents have hoped, but the the
> adoption of network-enabled home devices is also slower
> than anticipated.

Do you believe that UPnP actually has sufficient capability to come out of the niche market of home-enabled devices; jini has, but this is more down to the implementations.

> On the other hand, I have yet to see a single Jini device.

Not wishing to be flippant, but I'll play Devil's advocate; I have yet to see a enterprise system/service that is UPnP enabled. The point here is that UPnP <i>was</i> all about, and designed to, devices; with Jini it was a bad marketing decision/PoC.

Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

Re: Universal Plug 'n Play: Jini's ex-rival back from the dead? Posted: May 13, 2004 5:31 PM
Reply to this message Reply
On the subject of object serialization.
<br/>
This is an extremely emotive issue, not simply because MIDP may not support it, but the issue over MIDP or for that matter PocketPC/SmartPhone X, actually having enough processing/memory for parsing complex XML documents (that could be many times larger than their binary equivalents) quickly enough for your average phone user that is paying by the minute or by the byte.<br/> By the time these things actually occur, serialization is likely to be just as available and effective as XML/Web Service integration. <br/>
My point is simply this -if object (de-)serialization is bad, XML is still a serialization format, which still has to be translated before the data it represents can be utilised, and is therfore still fairly constrained by the issues of serialzation - the <i>only</i> thing going for it is the fact that it's just a string, but it's verbosity even removes this advantage.

Tim Jansen

Posts: 4
Nickname: tjansen
Registered: Dec, 2003

Re: Universal Plug 'n Play was never dead Posted: May 13, 2004 5:54 PM
Reply to this message Reply
> Do you believe that UPnP actually has sufficient
> capability to come out of the niche market of
> home-enabled devices;
> [..]
> Not wishing to be flippant, but I'll play Devil's
> advocate; I have yet to see a enterprise system/service
> that is UPnP enabled.

UPnP never tried to be useful in an enterprise environment. It lacks security and scalability.

The protocols of the proposed UPnP 2.0 device profile may be able to achieve that, but not necessarily with the limitations that the device profile allows.

Calum Shaw-Mackay

Posts: 58
Nickname: calum
Registered: Mar, 2004

Re: Universal Plug 'n Play was never dead Posted: May 14, 2004 1:46 AM
Reply to this message Reply
> UPnP never tried to be useful in an enterprise
> environment. It lacks security and scalability.

So would you say that in the context of the bloggers original post, UPnP is a viable substrate for Enterprise Level WebServices?

Berco Beute

Posts: 72
Nickname: berco
Registered: Jan, 2002

Re: Universal Plug 'n Play: Jini's ex-rival back from the dead? Posted: May 15, 2004 5:02 AM
Reply to this message Reply
> By the time these
> things actually occur, serialization is likely to be just
> as available and effective as XML/Web Service integration.

Well, effective XML-parsing is actually available. I've written several applications that use KXML that run excellent on my mobile phone (and a couple of other MIDP2 phones). I must say the phone is one of the fastest you can get (SonyEricsson P900), but it can be done. Serialization not, and not in the near future either.

> <br/>
> My point is simply this -if object (de-)serialization is
> bad, XML is still a serialization format, which still has
> to be translated before the data it represents can be
> utilised, and is therfore still fairly constrained by the
> issues of serialzation - the <i>only</i> thing going for
> it is the fact that it's just a string, but it's verbosity
> even removes this advantage.

I totally agree on the disadvantages of XML as a 'serialization' format, but it seems like that's the only available solution we'll get in the near future on mobile terminals. And I think that's not only a bad thing for J2ME, but for Java in general.

Tim Jansen

Posts: 4
Nickname: tjansen
Registered: Dec, 2003

Re: Universal Plug 'n Play was never dead Posted: May 15, 2004 3:13 PM
Reply to this message Reply
> So would you say that in the context of the bloggers
> original post, UPnP is a viable substrate for Enterprise
> Level WebServices?

UPnP 1.0 not.

The specs that the UPnP 2.0 profile is based on, like SOAP, WS-Discovery and WS-Security, are designed to be sufficient for enterprise-level. I am not sure about the profile itself, it has quite a few restrictions, but I havent looked at it in detail yet. I'd expect it to have a few restrictions, especially in the authentication mechanisms.

I can't really compare it to Jini, because I don't know Jini very well and AFAICS there is no comparable profile for Jini on machines with very limited memory. Or at least I can not find any limits for object sizes or strings in the documentation, or anything else that would guarantee interoperability without a large memory reserve.

Flat View: This topic has 8 replies on 1 page
Topic: Re: Opinion: Martin Fowler's First Law of Distribution Previous Topic   Next Topic Topic: Is Apple's OS X The Best (or even A Good) Platform for Java Development?


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us