Jini-talk with Jim Waldo -- Full transcript

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

1 2 3 Page 3
Page 3 of 3

One thing I like about distributed systems is they require both types of thinking -- practical engineering and the theoretical ability. At some point you hope they would touch. Doing distributed computing, I often think, is an act of faith. You never know, but you believe you will be able to do these things. I think everybody that does distributed computing is, at heart, a mystic.

Sommers: It looks like almost everybody does distributed computing these days...

Waldo: Well, almost everybody does computing that gets distributed. I'm not sure I would say everyone does distributed computing, yet. I think everybody should do distributed computing. A lot of people tend to forget that they are. They try to forget that there is a network involved there, one that makes fundamental changes in their lives.

Discovering services

Sommers: Many people working with Jini quickly discover that an object -- a Jini proxy, for instance -- contains data as well as method calls. Currently, Jini provides a fairly limited way to use that data in service discovery. Jini service discovery is based primarily only on Java language type, simple matching of entry attributes associated with a service, and a unique service ID. Do you envision richer semantics for Jini service discovery?

Waldo: I wouldn't say those three are the only means of service discovery. Those are the only ways we guarantee will always exist, but Jini's whole architecture is based on the notion that the infrastructure should be simple, and that the ability to provide value-added services should be easy to do. So, when people say they want much more complicated ways of finding their services, I tell them to write services that offer those complicated ways. You could have another service beyond the Jini lookup service that registers itself in the Jini lookup service, but also takes the contents of that lookup service and organizes it in completely different ways.

Sommers: A data access layer?

Waldo: It could be an access layer, it could be a SQL database on the attributes of the entities in the Jini lookup service. It could be a specialized filter that watches things coming in and informs you of things in which it thinks you might be interested. All those things are possible services. They are not part of the Jini infrastructure because that infrastructure is an attempt to keep things as small and simple as possible, but the Jini infrastructure does enable those services because the information is there and it can find and use them.

Those sorts of services could provide others ways of accessing and massaging that information in a way you find most easily digestible. What you find most easily digestible may not be the same as what other people find most easily digestible, which is another reason we don't provide these kinds of services in Jini, because Jini is trying to be the layer everybody requires. You may have a service that organizes the information in a way you find best. I may have a service that organizes the information in a very different way, which I find best. I shouldn't foist my service off on you, nor should you foist yours on me. That would be incompatible with the Jini philosophy.

By having these things as services, I can, by the way, find your service and see how you view the data in case that might be useful for me, assuming you will allow me to do that.

Building a team

Sommers: I'd like to ask you about something rather different. What your team at Sun has been able to do is quite remarkable. You're really defining a new paradigm of computing. I would like to ask you about the concept of leadership. As the Jini team leader, you have clearly assembled some very remarkable people.

Waldo: God help any manager who has to deal with a team like the Jini team. Our manager, Mark Hodapp, fortunately takes management as seriously as I take technology, and he's exceptionally good at it. I don't know how he puts up with us most of the time.

I spend a lot more time thinking about this than I generally would admit -- on how you build a team, and how we got the Jini team. Part of it is being careful about hiring at all levels, and making sure you get exceptional people. We had a lot of discussions where we said, "Well, this person seems to be good enough," but we weren't staggered by them. We finally got to the point of saying, "If we are not staggered by them, we don't hire them." I also try to hire people who are a lot smarter than I am. I think I've succeeded in most cases.

Much of it is just finding people who have the right sense of aesthetic -- a lot has to do with taste, and a desire to keep things simple and elegant. Finding those people is very hard. When you find them, you try to keep them at all cost.

The Jini team has been an exceptionally stable team. Very few people have left the team, and much of the team's core predates Jini by a lot. Bob Scheifler was working on X Windows, so, of course, we knew his work. But he was the last member of the group to join. Prior to that, Ann Wollrath and I worked together for nine years. Ken Arnold and I had worked together for 15 years, on the first CORBA implementation and earlier projects. So, finding good people, keeping them happy and interested, and having a manager who gives engineers the freedom and time to do the work were the keys to putting our team together.

My previous manager had an epiphany one day. He came by my office, and said, "You know, I finally got it figured out. There are two kinds of managers. There are managers who are in control, and know what's going on, and lead the team, and they are the ones who make the decisions. I am not that kind of manager. Not with this team." By the way, that was not the current Jini team, but was an equally good group of people. He continued, "Then there are managers like rock group managers: To make sure the equipment is set up, the bus arrives on time, and everybody gets out of the way, so the band can play. That's the kind of manager I've got to be." Being the sensitive guy that I am, I told him, "And make sure the brown M&Ms are out, too."

He had it right, if you have a top-notch group of engineers, the manager's job is to get people out of their way, and let them do their work. And you're not going to understand it, or figure out what they're doing. But you've got to have faith that what they're doing is top-notch work, because they've done it before. At Sun, we were lucky; it's more fun than you can imagine, working with people like that.

What's next?

Sommers: What's next for the Jini team? What are you working on?

Waldo: Right now we're working on the problem of how to make a secure distributed system where you move code around. That's our biggest, single task right now. We're also working on a set of things that will make Jini more scalable, and easier to use out of the box.

With security, we'll try a new model for release. We have released things in a classical fashion, where we would put out an early release, and then a beta release, and then a final release, with a fair amount of time in between. With the security release, we will put out a very early release, and then put out releases more often so that the Jini community can give us as much feedback as possible. Security is really hard. The more people we have looking at it, the more likely we'll get it right.

One of the other great things about Jini has been the Jini community -- a bunch of people who aren't part of the official Jini team, who have adopted the technology, and are interested enough in the technology to work on it and contribute to its development. So, for example, Bill Venners, to pick a random example, who is now in the room, did the service UI work. That's as much a part of the core Jini specification as anything else, even though it hasn't been fully blessed by the Jini community, because we're still figuring out how to do that full blessing. But it's a de facto standard. People are just using it because it's good work.

And we have other people in the community doing things that really expand the notion of who develops Jini. The core Jini team is doing some stuff, but other Jini developments are going on by people who are just as good as the core team. It is a community effort. They're doing it because they believe in it, they think it's good stuff, and they want to contribute to that. So I don't know what's next for Jini, because other people are doing a lot of interesting stuff as well.

Frank Sommers is founder and CEO of Autospaces, a company focused on bringing Jini technology to the automotive software market. Bill Venners has been writing software professionally for 14 years. Based in Silicon Valley, he provides software consulting and training services at Artima Software. He is the author of Inside the Java 2 Virtual Machine (Enterprise Computing, October 1999) and creator of Artima.com, a resource for Java and Jini developers.

Learn more about this topic

1 2 3 Page 3
Page 3 of 3