Frank Sommers: During your JavaOne 2001 presentation, you talked about how the network's "edge" forces us to rethink how we build our networked information systems. Considering that the three largest cell phone manufacturers alone produce about six new cell phones every second, most of which access the Internet, that edge is expanding very fast. How does mobility impact our network-based software architectures?
Jim Waldo: Mobility is an interesting new wrinkle in our networks. We have always built networks with the idea that the things the network hooks together don't move around much. If you move your machine from one place to another, it essentially becomes a different machine. It's hard to convince the network that it's the same. Your identity may be the same if you have certificates issued by a certificate authority, or if you can log in through some network-wide login mechanism. But, say, if you take your laptop from one office to another, your machine gets a new IP address through DHCP (Dynamic Host Configuration Protocol) or some other mechanism. As far as the network is concerned, it's a different machine.
One way to deal with that problem is to consider the machinery and the things that move around as being "relocateable" services. Just as objects can move around the network, objects can move outside the network and relocate themselves, find services, and offer services that are in a different place.
If I move from place to place, there are pieces of information associated with me: my current phone number, my current location, the home directory with which I'm working, and where my mail is delivered. One way to deal with this is to have a static location where everything that knows my location goes, and that then forwards the needed information to me. This is the notion mobile IP takes, for instance. It works as long as you assume that the network doesn't break and you're never out of touch with your home network -- assumptions that are, generally, false.
Another way to deal with this is to say that when I move from one place to another, there are a set of services associated with me: a service that tells where I am, or one that tells how to contact me. You need to register those services locally, and propagate those services on the network.
The easiest way to do that is to return to where those services were and add a forwarding address. But you may also have a hierarchy of lookup services, so that when you look for services that represent an individual, you have some hint as to where that person last was. But if hints don't work, you may go into higher-level lookup services until something directs you to the current location.
In essence, the physical device becomes an implementation of the service. Implementations change over time. So, if you move from one place to another, you may change the implementation of the machine by which the service is being offered, but it's the same service.
Sommers: Many people associate mobility with small devices. But you're saying that size does not matter when it comes to mobility.
Waldo: Small devices are an interesting form of a service's mobile implementation. But Jini is not about devices any more than Java is about applets. Jini is about services and their users, and hooking the two together. You can implement those services in any appropriate way: as a device, as a piece of software, or as a collection of other services. It really isn't about devices. It's about accomplishing things on the network, and isolating what you want done, described by a Java interface, from how it gets done, which is an implementation.
Motion is really just a form of change. Jini is really about networks' ability to change without having to stop and restart. It lets networks change in chaotic and spontaneous ways. One way change can happen is when a networked service moves around. Another way is when something gets pulled off or put on the network. Those are all ways networks experience change all the time.
Embrace change in the enterprise MIS
Sommers: When you mention the word "change," most corporate MIS (management information system) managers associate large expenses with change. What you're saying suggests that Jini is a great way to reduce that cost, because it's an infrastructure designed for change.
Waldo: That was our original thought. Change is not a rare event -- it's constant. We had to figure out a way to allow change to happen without involving people. If change required people, and considering networks now growing into millions of machines and the amount of change those networks experience, we would all have to become system administrators. The only way to avoid that is to automate the ability to deal with change.
Sommers: Do you think Jini is the ultimate model for an MIS infrastructure?
Waldo: I think Jini is the best model we have currently for a network infrastructure. Enterprises tend to use networks a lot; therefore, it's an enterprise network infrastructure as well. But if people start using networks in their homes, then it becomes a home infrastructure. Enterprises want to save money; you don't want to hire a system administrator at home.
This is true even for automobile electronics. If you change your CD player to the newest and latest CD or MP3 player, you still want it to interact with other things in your car -- your speakers or the telephone. You don't want the kid at Best Buy reconfiguring your auto network when he installs the new CD player. You want that to be automatic.
So the same problem you have in enterprises, in your home, and in your automobile exists anywhere there is a network. Enterprises have the problem first because they tend to have the largest networks. But it will be everywhere.
Sommers: For many MIS managers, change is not only a source of expense, but is also a source of fear, because change is also a chance for making errors. How does Jini address the issue of reliability in the presence of constant change?
Waldo: Change is something that MIS managers rightfully fear. On the other hand, MIS managers also know that they must have change. Change was never really planned for in most distributed computing environments because we assumed networks were fairly small and static. But as networks became bigger, and as the rate of change became faster, the need to design a network system that allows for change has become more important.
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.
Traditionally in distributed computing systems, those who have agreed on a wire protocol have gained interoperability. Jini and Java RMI (Remote Method Invocation) really changed the rules by saying that since you're getting the object that talks to the service from the service, how that wire protocol information is exchanged is a private matter between the object piece from the service that gets injected into the client, and the service.
This means you can hide the protocols behind the Java objects that move around the network. If you had private protocols that work well for you, or can't be changed, you can wrap them in a Java object and actually use them while developing new services with more modern protocols. Whatever protocol is best for that service the client can also use. And different implementations of the same service can use different protocols in the Jini world. That's a fundamental change in the way we build distributed systems.
Sommers: In the 1980s and early 1990s, many American corporations realized the need to reengineer their operations to better respond to global competition. With networked services becoming strategic to many organizations, and networks becoming overly complex, do you think the time has come to think about reengineering the corporate MIS infrastructure as well? Do you see Jini playing a role in this arena?
Waldo: There is a tremendous amount of talent in MIS departments around the world being used for fairly trivial tasks. Troubleshooting and crisis management are not terribly enjoyable, nor challenging. They are challenging only in the sense that they are constant and you have to do it. It's like being in the line of fire all the time. People in these MIS organizations have the talent to figure out ways in which companies can use their computational resources more effectively. However, with the existing infrastructure, they don't have the time to do the thinking that's required to accomplish that.
I think Jini could help reengineer MIS infrastructures. Rather than being a reactive organization, where the MIS manager's goal is to keep things from falling into total chaos, using Jini, the organization can become more proactive, where the MIS manager's goal is to plan for the strategic network upgrade over time to meet user needs. Managers will have the time to think about what is needed, instead of reacting to their day-to-day problems. MIS management becomes a very different job; it's not troubleshooting, it's planning. Using Jini, managers can concentrate on things like service quality. They can manage the change and do long-range planning. They can focus on what they will need a year from now rather than keeping what they have together with the bailing wire and chewing gum they currently use.
Sommers: If an MIS manager decides he's ready to make this paradigm shift, how would you suggest he go about it? What would be the first steps?
Waldo: First, begin to understand what Jini really is and how a Jini network works. Many books and articles can help you in that area.
Next, embrace Java as fully as you can. Many MIS managers have already done that, but they especially need to realize that Java and the object mobility it provides is a key entry into Jini.
Beyond that, start some pilot projects to see how this could work. Pick two or three problem projects, services that are necessary but difficult to maintain, or services users demand but you're not quite sure how to create. Create those services in a Jini-enabled fashion, and then experiment with how you can change them over time. The nice thing about Jini is you don't have to convert everything to Jini all at once. You can convert just a small area, a portion of the enterprise, or just some applications used in the enterprise. You can ease into it as you gain more experience.