Moderator (MDR): MDR-GregVoss

Guest-Speaker (SPK): SPK-Jim Waldo

MDR-GregVoss: Welcome everyone. Today we'll be talking with Jim Waldo, who has designed the new Java protocols for Remote Method Invocation (RMI) and object serialization. Jim has worked with Ann Wollrath and Ken Arnold to put together these new protocols, which will be incorporated into standard Java with the release of JDK 1.1. We're ready to accept questions for Jim, so if you have any, go ahead and submit them. Jim has arrived. We're ready to start.

SPK-Jim Waldo: Hi Greg and everyone else...sorry to be a little late.

MikeP: In your documentation, you specify that applets cannot export remote objects (therefore servers cannot call methods in an applet). However your chat applet is written otherwise. I am a bit confused...

SPK-Jim Waldo: Well, we lied in the first implementation where you could have an applet receiving callbacks. Doing that violated some of the guarantees that we wanted to make about garbage collection and referential integrity. But our users made it real clear that they wanted callbacks from applets, so that will be in the 1.1 release, subject to the usual applet security constraints

ts: How is security being addressed with RMI?

SPK-Jim Waldo: Well, security can mean a lot of different things, so I'll try to answer for some of the meanings. In terms of privacy, we are adding the ability to connect to other forms of sockets (like SSL) to allow encryption of RMI traffic. In terms of authentication of the principal making the RMI call (and whether that principal has the authority to make the call), we are working with the JavaSoft security team to try to figure out how to do distributed authentication and delegation. We don't have the answer nailed down completely, but we think we have some promising directions.

MikeP: Following up with my earlier question, what I hear you saying is that servers will be able to invoke methods in applets (without the applet having to set up a server socket). Is that a correct conclusion?

SPK-Jim Waldo: Subject to security restrictions, yes. Applets can only be connected to the server from which they came, but that server can make calls. We are also looking at ways of doing call redirection to give more general functionality in the callback, but want to make sure we understand the security impact of such redirection.

ChacoInc: How is versioning handled in serialization? It wasn't clear when reading the 0.9 spec. And are there any rough dates for 1.1?

SPK-Jim Waldo: The attempt in the versioning spec. is to give enough information so that you can tell from a serialized stream that you have a version mismatch, and that you might be able to recover from the mismatch. But versioning is a really hard problem that we are only beginning to wrap our heads around. I think that it is going to be the single hardest unsolved research problem that faces the Java community in the near future. We are more than willing to take anyone's good ideas on the subject. As for 1.1—if I told you, they would have to kill me and disavow any knowledge of my action.

aurora: I attended the JavaOne conference where you talked about JavaSpaces. Is there a place where I can get more information from? What is the closest equivalent implementation of JavaSpaces in other platforms/languages today?

SPK-Jim Waldo: The closest thing to JavaSpaces around today would be the Linda systems out of Yale University. JavaSpaces are basically Linda extended to Java and the network. We've been doing some advanced development in this area for the past while in my group. We hope to have some early documentation out fairly soon, and some first implementations for people to work with by the end of the year. Depending on the reaction, we might think of turning it into a product. But the crush of real products (like RMI and serialization) tend to get in the way of making progress as quickly as we would like.

ts: Has the RMI team addressed the issue of using RMI thru firewalls?

SPK-Jim Waldo: Yeah, one of the better programmers has been wearing hip boots for the past couple of weeks working on this one. The problem is that firewalls are meant to keep everything out. The only solution is to use HTTP, a protocol designed for doing anything other than RMI. We have HTTP tunnelling working pretty well, but there is some administration on the server side that is needed to do the right kind of forwarding. It will be available, I believe, in the pre-beta version that we are about to ship (today if no other huge bug stops us, tomorrow otherwise).

MDR-GregVoss: There's some confusion about where object serialization leaves off, and where object databases start, for many programmers. This question might give you a chance to clarify, Jim.

JohnEng: To what extent can object oriented databases benefit from (or be built upon) object serialization?

SPK-Jim Waldo: Serialization was never really meant to be used as an object-oriented database format. We were just trying to give the simplest way of transforming a Java object into a self-describing byte stream that we could (mostly for RMI). But things never turn out the way you thought they would—folks seem to be using serialization for all sorts of things we never dreamed of using it for. I suppose using it for a database would be okay, and it does have the advantage of being part of the base platform (or it will have that advantage). But it doesn't break down the component parts of an object in the way that most databases would like, so the granularity is pretty large. I guess my answer is that some will try it, and I wish them the best of luck.

MikeP: What effects do you think will result from incorporating object serialization into JDK1.1? Will we see different kinds of applications written once people start thinking more comfortably in terms of the new APIs?

SPK-Jim Waldo: This is a genuinely interesting question. As I said before, we did serialization so we could do RMI (we think of it as a way to do marshalling and unmarshalling). But it also allows persistence, and to some degree it allows the transportation of code from one JavaVM to another (either over the wire or via a disk). This allows all sorts of new possibilities—code that moves around allows dynamic changing of the behavior of an existing program. This is another area where Java has changed the rules concerning what a program is and how we approach our jobs. I hope that some unexpected applications arise that use this functionality, but I don't have a clue what they are or what they will do. Our customers constantly surprise us.

MDR-GregVoss: This persistence on a wire idea is getting very interesting given recent announcements about JavaStations—Java machines with no disks. Did you design the APIs specifically for JavaStations?

SPK-Jim Waldo: Not really...although JavaStations are one of the first general-purpose machines that could use what we are doing. I think that the overall definition of a computer is going to change in the very near future (warning—this is where I go into my futurist zealotry). It used to be that a computer was a CPU, memory, disk, monitor, and keyboard. That's what we programmed to, and the OS offered all of the platform services we needed. I think that soon the computer will be a CPU, some memory, and a network connection. Those services that used to be offered by the operating system, like persistence, naming and authentication, will have to be offered by the network. That is the sort of platform we are trying to provide in my group—object serialization and RMI are just the beginning.

MDR-GregVoss: Talk about your future zealotry a little. You're a pretty interesting guy when you "go off." Where do you think we're heading—in terms of the big picture—for computing.

SPK-Jim Waldo: This just encourages the sort of behavior that marketing hates...but what the heck. The simple fact is that there are more computers that we don't see than computers that we do—my favorite example is my microwave oven, which I recently took apart and discovered is powered (in the CPU sense) by a 68000. The same chip that was in my first high-powered engineering workstation. It doesn't have much of a user interface, but there are a lot of computers going to waste. There is no reason that these computers can't be hooked into the network and used in ways that we can't imagine.

This is the sort of thing William Gibson has been talking about for some time, but even he hasn't seen that it is coming true—the technology is there, even if we haven't seen it. It is a paradigm shift in the true sense that Thomas Kuhn talked about in his "Structure of Scientific Revolutions," where practitioners of the old science (where computers had keyboards and screens but no network) can't even understand the new science. I worry that I may be one of the old practitioners, because I can't see where this is going to lead. But this is more fun than computing has been for a long time.

MDR-GregVoss: I hear William Gibson is actually surprised to find himself so frequently quoted by hard core techies.

Venkat: Hi Jim! I have faced quite a number of issues implementing the chat applet here (using HTTP) so that it works through firewalls (needless to say I ran into several problems). Are you simulating a full duplex connection for the HTTP connections in RMI?

SPK-Jim Waldo: We are trying to, but that requires that we do our own multiplexing over the one channel. Very much like trying to suck a bowling ball through a garden hose. I don't actually know what the status is of the engineering on that particular problem (being an architect keeps me further from some of the code than I would like to be). Of course, the other problem with firewalls is that you can only test against the ones you know about now. If someone comes up with a new firewall that has yet another protection scheme, all bets are off. We do our best, but the best we can often do is "Satisfaction guaranteed or we won't be surprised."

MDR-GregVoss: Hmmm, not sure if I understand about new firewall thing you talked about.... I thought it was a function of the WWW proxy server (which should be uniform)?

SPK-Jim Waldo: We thought so too until we tried to tunnel through them. We found that there were interesting differences in different products that claimed to be simple firewalls. And then there are the custom firewalls that know how to do things better—I don't even want to think about them. Our solution has been to take an obvious standard and make sure that we can get through it. If we fail in other cases, we worry about it then or when a significant number of our customers tell us it is important.

ts: On the same note of the future, I would like to see consumer device vendors imbed Java and add a network port to their products. The next step would be to add a remote object, and publish a spec that describes the interface so that consumers or vendors could write Java "control" applications to, for example, start/stop the VCR, etc. What are your thoughts on using RMI for this purpose?

SPK-Jim Waldo: This is one of the things we designed RMI to do. The neat thing about RMI is that you can add functionality to the device by passing new objects (by value) into the device to let it have new behavior (like rewinding when you reach the end of the tape).

aurora: What do you think are the most interesting application areas for RMI? Serialization? (Is JavaBeans a type of application you had in mind when developing serialization, since it (JavaBeans) appears to use serialization quite heavily)?

SPK-Jim Waldo: Starting at the end—we didn't develop serialization for Beans (we had finished most of the serializaiton design before we even thought about Beans). The fact that it could be used for Beans we take to be an indication that the overall design wasn't too bad—generalized use is one of those things you like to see.

The applications I find interesting for RMI are applications that are widely distributed—applications made up of objects that appear all over the internet, that need to stay up for weeks at a time, and that need to adapt as conditions of use change or even the code used in the various components change. This is a characterization by structure rather than by application characteristic, but I think there are lots of possible applications that fit this structure—from wide-scale collaboration tools to enterprise auditing utilities. Of course, if I really knew what the "killer app" for RMI was going to be, I'd be spending my time on the business plan rather than a chat session....

MDR-GregVoss: We're running out of time, so I'm ready to wrap things up. Any final thoughts? I'm giving you more license here than any sane moderator should, but I love it when you talk about things like Thomas Kuhn and William Gibson in the same sentence. I've been warned against encouraging you, but I can't resist.

SPK-Jim Waldo: Sure. The thing that I find interesting about Java is that it has changed the rules for developing software—we no longer think of programs as static entities that are compiled and linked, and then later run. Instead, we compile chunks, and then link-and-run, changing the components as the need arises. This has been a big change, but I don't think it is anything compared to what is going to happen when we really start using Java for distributed computing.

Being able to move code around the network means that we can finally do object-oriented distributed computing; moving both data and the behavior of that data around. This really changes everything. We are no longer trapped in a world of static network protocols—the network has become an evolving, changing entity. Again, I don't know what this is going to lead us to, but it is going to be different, and it is going to be great fun getting there.

MDR-GregVoss: Great stuff. Thanks Jim, for spending some time with us. I've gotten some interesting insights, and hope others have as well.

SPK-Jim Waldo: My pleasure, and thank you all for your questions and your attention.

MDR-GregVoss: Thanks everyone. See you next time.