|
|
Re: Whatever Happened to Jini?
|
Posted: Jul 16, 2002 6:21 AM
|
|
Interesting article in many ways. As seems to have been the case over the life of Jini, the author likes the idea, but has not had a real problem to apply it to and has moved on to new "flavours" of computing technology. And, like the shift we've seen in the past year or so, he has hopped onto the web services bandwagon. That's the whole problem with the article, IHMO. He, and many like him, think the only interesting problem worth solving is that of web services. Every problem can be resolved with data and some presentation engine.
Though I'm biased, I think that Jini can be used for far more than that. Some of the successes of Jini have been in systems that can be characterized by their machine-to-machine interactions. No presentation mechanisms are required or wanted. A simple example is a sensor-controller network. The sensor should push a service that is basically its driver. The controller gets the service and uses it to access the sensor. Neither device knows any details about the other. All they really know is a common definition of the sensor service interface, and, of course, how to play in a Jini network. Doing the same kind of thing using SOAP and XML seems like overkill. Especially if I want the sensor to do as little as possible, need as little memory and CPU as possible, and cost as little as possible.
Another point that the author glosses over is the idea and strength of dynamic code. At best, the Jini alternatives he discusses can use some kind of RPC mechanism. Fine. But what is the cost of deploying the software needed to both ends of the client-server architecture? What's the cost of maintaining it, especially when your clients might be things like PDAs and cell phones, numbering in the 100's of millions? I can see it now, my local phone company managing not to screw up as it tries to get all its subscribers to upload and install new code on their phones. Not likely! Jini allows this to happen by default since the code can be served from a central, managed source.
Anyway, you get the idea. There is much more you can add about the advantages of moving Java bytecode around, but I think you know that already... I don't blame the author for his attitude... he's just mired in the "latest thing".
steven
|
|
Previous Topic
