Jini-talk with Jim Waldo -- Full transcript

Jini architect addresses Jini's importance in ever-changing environments

1 2 3 Page 2
Page 2 of 3

Sommers: Are you aware of similar technologies today that MIS managers could choose if they want such a different paradigm for their management information systems?

Waldo: Actually, I don't think so. Jini differs from most other technologies in that it takes the network seriously as an entity in itself. It's not a way to build things that get connected by the network, but a way to build networks of connected things. It makes the network an entity that always runs, and may have parts changing as it runs.

It is a different approach from most distributed systems, which say that the network is merely a data exchange mechanism between the things you build, so you build these components that get connected by these wires, as opposed to building a system that is the network.

The only people who think in the terms that we in the Jini world think of the network are the telcos (telephone companies), where the network is very much an entity, separate from all network-connected pieces.

Sommers: And telco networks are typically very reliable...

Waldo: The telcos are reliable because the network is the entity guaranteed to be there all the time. Things change all over the place in the telephone network, but the changes never bring the telephone network down. That's how we have to start thinking of our enterprise networks, our home networks, our personal networks, our ubiquitous networks. We rely on the network, not the things connected by the network.

During his JavaOne 2001 keynote, James Gosling made an interesting point. He said we talk a lot about network services and people translate that into servers, but services aren't servers, even though they may run on a server. The service lives on the network and if its location changes on the network, it shouldn't matter to the clients because they access the service from the network, not from an entity connected on the network.

The network provides the service, not the things on the network. You don't dial through a particular switch on the telephone network, even though the switch enables that to work. Instead, you just use a telephone network to call somebody on another telephone. We must think of our corporate computational networks in that same way.

Ubiquitous high-availability

Sommers: As people increasingly depend on the network-provided services, we will have less tolerance when these services are unavailable. Considering our experience with the reliability of existing computer software, do you think we are ready to place increasing trust in our networks?

Waldo: I sometimes talk these days about the environment we have led computer users to expect. We have conditioned them to expect unreliable computers that are fragile and break easily. They have grown used to their computers crashing.

As we start moving computation into a more embedded system, people won't see the thing that contains a computer as a computer. They will see it as a telephone, a refrigerator, or a television set. We don't expect those things to be fragile or to crash, or that they are complicated pieces of equipment that we can't rely on. As software people, we will have the same level of expectation placed on our product that is placed on many other products. Consumers will require reliable products. To make them reliable, we must make them smaller, simpler, and able to interact with other small and simple components. Then we have to make sure the whole thing works together, which will require the kind of network service architecture that Jini is about.

Jini is about little components offering simple services that can be knit together as needed to provide complex services. These little components, and their interaction, can be reliable. And if one crashes, you can easily find an equivalent service on the network to replace it. That's the key to reliability.

Sommers: Do you mean redundancy and replication for services?

Waldo: Absolutely. Redundancy and replication are the only ways to make reliable systems out of unreliable parts. At least, they're the only way we know. We have to apply those techniques in software, as well. We apply them in hardware sometimes, but not very well in software. In software, we've made larger and larger things so that any small errors somewhere in your big program can crash the whole thing. We should, and will soon, consider that unacceptable.

Sommers: Currently, when you talk about redundancy, typically, a high expense is associated with that. If you want to get your database management system up in a redundant fashion, you typically need additional licenses, which quickly becomes expensive.

Waldo: The expense of these redundant systems is often dictated by the scale of the thing that is made redundant. If you have a large and complicated database, running on expensive hardware, and you want to make that redundant, it's very expensive, because you have to buy a second, very large piece of software, running on a second, very large piece of hardware.

But you can get a cheaper level of redundancy and replication by making small components redundant. That doesn't add a lot of expense, because the thing that is redundant and replicated is small and simple. There are already a lot of small, redundant components in airplanes, automobiles, and other mechanical devices. We could do the same thing in software components.

Sommers: That will be bad news for a lot of software vendors, because they tend to have high revenues typically coming from enterprises willing to pay large amounts in return for high availability. Are you talking about the commoditization of high availability?

Waldo: Making things small and simple doesn't necessarily make them commodities. There are small and simple things that do one thing very well. I hope, in fact, this will open up the software market so that you don't have to compete by doing everything better than anybody else. You can compete by doing one small thing.

Type systems vs. the semantic Web

Sommers: Many people nowadays talk about XML's role in providing semantic context for Web services. Jini's primary mechanism of semantics, however, lies in the Java language's service type. Last March, the WWW Consortium's Tim Berners-Lee published "The Semantic Web" in Scientific American, describing what the future of the Web might be like. How do you envision Jini playing a role in the semantic Web? How would you compare the XML-based, semantic approach to Jini's reliance on a type system?

Waldo: I think we're a long way from understanding semantics. It would be wonderful if we could teach machines to understand things the way we understand them. We don't have a good model of how we understand semantics, much less a model that we can translate into a computer program. I think that work, like what Tim is pushing on the semantic Web, is wonderful. But I don't believe it will succeed in my lifetime. So, I'm looking at other aspects. I could be absolutely wrong, and they could be wildly successful. When they are, they might be able to replace all of the work we're doing on Jini. But I don't think so.

Type systems don't give you a complete semantics, but rather describe the kinds of things in the world. So, that way they are a semantics, because they tie some language into those things. We have rules on how you combine types to get other types. Semantics isn't just the meaning of constituent parts, but how you combine those meanings to define their combination. So the composition model really makes something into a semantics. We don't understand the semantics of natural language, but we do understand the semantics of type systems.

Bill Venners: I laugh because we're speaking a natural language, and we're understanding each other...

Waldo: We understand each other, but we don't understand why or how. It would seem easy if I knew the meanings of all the words to come up with rules that would let me say, If you combine these words together, here is what the meaning of the combination is. But it's unbelievably hard. The formal semantics that we have available for natural language are limited to trivial pieces. And the progress we're making, when it has worked, is quite small. Computers are understanding natural language better by basically ignoring the work that linguists have done for the past 20 years, and returning to a notion of statistical analysis and Markov models, where you get an idea of what might be said based on surface analysis and the probabilities of one word following another. But it doesn't really give this combinatorial ability.

Type composition, we understand. And in the Java language, we can specify it quite well. Java is an artificial language; it doesn't give us as rich a meaning as we get in a natural language. It's very hard to express metaphorical meaning in Java types. But the exact matching we get is what we ground the identification in Jini in. And that's why we use a type system.

Sommers: You're saying that type systems have a well-proven logical model, whereas for these other types of semantic notions there is no model at all, at least not yet.

Waldo: That's right. Or what models we do have are known to be inadequate for anything interesting. We're engineers in the Jini group. We took something that we understood to be inadequate but well specified and used it as the foundation of what we've built. And we're seeing how far that train will lead us. We think it's a fairly interesting train.

Venners: Would you give an example of what you mean by composition of types in the Java system?

Waldo: The whole polymorphic type hierarchy is a notion of compositionality, as is the notion of being able to implement multiple interfaces. One problem if you're using natural language in a directory system to describe a service is what you do with a multifunction device. So, if the device is a printer, scanner, and a fax machine, how do you describe the relationship between combinations of printers/scanners/fax machines to printers, and scanners, and fax machines?

Using the type system, that's simple. The device implements three interfaces: the printer interface, the scanner interface, and the fax interface. Using a descriptive language, like English, it's difficult to describe what their relationship is.

In Java, we have compositionality of subtyping. A color printer is a printer type, which gives us one form of compositionality. In addition, there is the notion of mixing interfaces together to build types out of other types. Both are well specified. It's not rich semantics; you really only have two types of relationships: subtype and compositional type. But it's rich enough to do a lot, and that's what we're looking for.

Venners: I once heard you say that computers are not good at understanding strings, but are good at understanding types, which is what people aren't. But doesn't the programmer understand type when writing code and then sending it out the door? Isn't that a proxy for the programmer understanding a type? So, isn't it the programmer who doesn't understand the strings, also?

Waldo: A program is good at comparing a couple things for type equivalence. It's really hard for a programmer to compare two strings for meaning equivalence. As a programmer, I can understand the meaning equivalence of those two things. I know that a color printer is a type of printer, but a ribbon printer is not. But it's tough to write a program that understands that. Subtyping and compositional relationships in a type system are easy in Java: I say, Is this a ..., and I'm done. I don't have an equivalent primitive in the Java language that says "means the same as" and that takes two strings. We could get the Java people to do that, but it would be difficult.

Sommers: If you look at most successful technologies, many are based on rigorous mathematical and logical theories. For instance, relational algebra provided a foundation for many successful database technologies today. In distributed computing, could type systems be a logical foundation?

Waldo: It's part of a logical foundation. I'm not sure what the logical foundation of distributed computing is yet. It's one of the things I like to think about in my spare time. A number of logics get built into distributed computing. One is an identification logic, which in Jini's case is based on the type system in Java, and therefore could be specified fairly well mathematically. There are also various security logics. Butler Lampson came out with his logic of authentication some time ago, which is the beginning of such a formal specification about what it means to authenticate over a distributed system. I think that needs a lot of work. Now that we know we can do it, we need to do it in a more expansive way, to see what alternatives there are. Luca Cardelli, now at Microsoft Research, has worked a lot on various Lambda calculi for distributed systems. Interesting stuff, but it hasn't quite connected with reality yet.

One of my favorite cartoons is on the cover of Sape Mullender's Distributed Systems. Its character looks into a river; the character is pointing one way, and his reflection is pointing the other. And it's labeled "Where theory meets practice." In distributed systems, we have good theory and good experience in implementing systems, but the two don't quite meet yet. We haven't grounded the systems that we've built on the theories that we've developed in such a way that the two are connected. We may be close.

Related:
1 2 3 Page 2
Page 2 of 3