Page 2 of 6
Jini was designed with the idea that change occurs all the time, making change nearly automatic. MIS managers need, really, a way to change the broken things without causing other things to break. Jini gives you that isolation.
For instance, Jini lets you run your old and your new services simultaneously. You can plug in a service's new version, and your old clients can use it, even while the old version still exists, because those versions are just alternate implementations of the same interface. You can then instrument the new service, and if it has a problem, you can shut it down, and every service client can return to the old version immediately. That happens automatically. You just have to unplug the new service's machine, or unregister it, and then you can phase in those kinds of changes. You don't have to change the whole network; you can change one thing at a time.
To avoid human error, you avoid requiring human involvement. Many human errors occur in network configurations because of typing errors; for example, in assigning network addresses, where services are misdescribed or misapplied by the system administrator.
In the Jini world, when you plug in a service to the network, once it gets its IP address (automatically done via DHCP), a mechanism started programmatically registers the service with the Jini lookup service without any human intervention. The description is not human-entered, but is the Java type of the service being offered. The clients that need to use it already know what that type is in order to make the method calls to talk to the service. We avoid human error by automating the process that was error-prone.
Sommers: Enterprise-wide networked systems use many protocol types. Not only network protocols, such as TCP/IP, but also "homemade" protocols, invented by a company's own programmers. Many enterprises maintain these in manuals and operational books, which often descend from generations of MIS managers. When such a protocol changes, everything using that protocol breaks. How does Jini address this issue?
Waldo: Protocol means a lot of things. The low-level networking protocols, like TCP, describe how you send packets of information. Jini does not deal at that level; it assumes that your network can move packets of bits from one place to another. The next protocol layer is how those bits get interpreted, such as protocols like XML and IIOP (Inter-ORB Protocol). Jini allows a service to use whatever protocol is appropriate for it.
In the Jini world, the client doesn't talk to the service directly using one of those protocols. Instead, the client gets a Java object from a lookup service that implements the right interface representing the service. That object was put into the lookup service by the ultimate service providing the information or the computation that the client needs. In effect, the client injects a piece of the service into its own address space, and makes method calls on that Java object. That object generates the wire protocols to talk to the service. This means that different services can use different protocols.