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. Im 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 SUNs marketing department. Anybody questioning the power of marketing communication should have a talk with any of these members of the original Jini team; theyre still licking their wounds.
Jini is meant for spontaneous networking between services, where it doesnt 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 thats still the case; for example, MIDP 2.0 is the latest J2ME standard available on most of the new mobile phones but it still doesnt 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 thats one of the few Jini enterprises out there.
That doesnt 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 UPnP 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 thats 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 dont 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 wouldnt be a problem if every human has a second job as system administrator Jini folks hate to say, we told you so, but theyd 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?
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.
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?
> 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.
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.
> 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.
> 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.
> 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.
Previous Topic
