Sun lets Jini Starter Kit 1.1 out of the bottle

JavaWorld author Frank Sommers talks with Jini architect Jim

1 2 3 Page 2
Page 2 of 3

If a program doesn't know the API, it's hard to change the program on the fly to use that API. It can be done, and there are all sorts of experiments in AI [artificial intelligence] that allow you to do this. Any of those would work just as well in the Jini system as they do anywhere else because Java does have the ability to do reflection.

But, in most cases, a client program will look for a service that implements an interface that the client program already knows about. Now, the client may not know the implementation, but that's okay. All the Jini clients know is the interface, and they will download the object that implements the interface.

JavaWorld: How can companies or individuals recommend or specify business-specific APIs? For example, say an insurance company would like to allow customers to report insurance claims through devices such as cell phones or computers. They would benefit from a common API so that all insurance companies could cooperate or use this particular software service. So, if two people get into an accident, their respective insurance companies can exchange claim information via this common API. How could one go about defining such an "Insurance API"?

Jim Waldo: One way is for a company or an individual to come up with the API, publish it to the Jini community, and see if people started to use it. It's always good to have an implementation as well. You could just publish the API without the implementation, but nobody may use it.

JavaWorld: So an organization or an individual would create an "Insurance API" project on the Website, publish its API recommendation, possibly upload an implementation...

Jim Waldo: And off they go. Another alternative is to start a project beforehand and collect community input. The printer group has followed this route for the Jini printing API. Basically all of the major printer manufacturers are working through what the API for printing should be in the Jini network.

We try to provide people with the mechanisms they need to actually pull together these projects and move them forward. Sometimes we may even supply some cycles from some of our people to help them, to shepherd along the work. We may not know printing, for example, but we know Jini pretty well.

JavaWorld: You provide input that mainly simplifies the API or tailors it to the Jini environment?

Jim Waldo: That's certainly what I try to do. There is a certain aesthetic to Jini. We take the network-failure problems very seriously, so we worry about what happens when your call fails in unexpected ways. With this experience alone, we can help people in designing their interfaces.

JavaWorld: And that's where the discussion groups, or projects, come in?

Jim Waldo: Absolutely. For example, the ServiceUI project was started inside the community by Bill Venners. People put together an interface, and after preparing a draft, Bill actually spent a day with the Jini group. We looked it over, made a suggestion here, filed off an edge there, and asked some questions. As a result of that interaction, Bill made some minor changes in the ServiceUI. That's the way we see magnifying the talents inside the Jini group. That's why we've migrated to this open source approach.

JavaWorld: What would an industry-specific API look like? For our hypothetical "Insurance API" expert group, what sort of functionality should they be thinking about?

Jim Waldo: In addition to service interfaces specific to their industry, we would certainly encourage not to duplicate the functionality currently in Jini. If an expert group had a notion of something like leasing, they should use the leasing interface. If they had a notion that was similar to two-phase commit, they should use the two-phase commit interfaces. That way they can interoperate with other services. The Jini programming model is built around how services interoperate with other services.

What basic conventions are required? First, the Jini programming model says that leasing is basic because you need a time-based convention to deal with failure. Second, if you're going to have agreement between multiple entities, you must previously have an agreement about how you came to that agreement. That's why Jini includes the two-phase commit interfaces. Third, if you're going to react to events happening someplace else, you have to know what an event is and how you send it. That's why Jini includes the event interfaces. Fourth, you also must agree on how you advertise yourself, and how you find things. For an implementation to be a Jini service it must be able to find lookup services, register itself with those lookup services and renew its leases with those lookup services, just as any other Jini service would. And, finally, you must be able to hand out an object that can represent you in another address space. That's the Java programming type object that is placed in the lookup service and is reconstituted when you obtain a service from the lookup service.

JavaWorld: You mentioned a moment ago that clients need to know about the Jini interfaces in advance. If an industry expert group creates and publishes an API and its implementation, do they need to follow a standards procedure similar to the Java Community Process? How would they make their API known?

Jim Waldo: The Jini community process differs slightly from the Java Community Process. We don't have anything nearly so formal as the JSR. To guarantee acceptance by the community, there are a number of tracks you can follow. One is to just publish your interface. Although you can't publish it as part of the net.jini or the net.jini.core namespace, people may start using your project, which will make it useful to other parts of the Jini community. If it becomes useful, then no extra step is needed. Some people feel that their project should have a more official status. In that case, put the project out for community review and ask the community to vote.

Right now, the community has essentially two houses. In one house stands the Jini community who can vote; in the other, the companies that hold a commercial Jini license. If both groups vote affirmatively, then the interface and the type definitions can be included in the net.jini name space.

The Technical Oversight Committee provides our checks and balances; it's basically an appeals body. Currently, nine members make up the Technical Oversight Committee.

JavaWorld: How do people get on this board?

Jim Waldo: They are nominated by the community, and then the board is voted in at a community meeting.

JavaWorld: So the members are representing individuals, not corporations?

Jim Waldo: Yes. The Technical Oversight Committee can decide if a vote was essentially not one that the Jini community should have followed. It's sort of an analog of the Supreme Court.

JavaWorld: So, they have a final say as to what's going to be included in the net.jini name space?

Jim Waldo: Yes. At this point, they do.

JavaWorld: But if something becomes really popular then it might not even be necessary to go through that process.

Jim Waldo: I am a huge believer in de facto standards, as opposed to de jure standards. I think they work much better.

JavaWorld: To switch topics, could you talk about scaling Jini down to small devices, specifically the Surrogate Project?

Jim Waldo: The Surrogate Project began when we started thinking seriously about devices that had limited resources, particularly in regards to memory. Many people think that the Surrogate Project focuses on how to deal with devices that can't run Java at all. But it's more than that. Even if a small device could be running Java, the idea behind Jini is that you move an object into the client that enables the client to use the service. If you have a memory-limited device that runs Java, and you start receiving objects, at some point you're going to exhaust the available memory. Your system will break in a way that will be hard for you to understand, because it will seem random.

JavaWorld: Because it will no longer be able to load classes or data into memory.

Jim Waldo: Exactly. We realized that the code-motion in this case was going the wrong way, to the limited device. The Surrogate Project defines an environment where these limited devices can move Java code to a host where no limits prevent the code from running on the device's behalf.

JavaWorld: That would be the surrogate host.

Jim Waldo: The surrogate host will be discovered by anything that wants to find a spot that can run an object on its behalf. Rather than trying to download classes to my Palm Pilot or some other small, memory-limited device, I'm going to find a surrogate host and move code from my Palm Pilot to that host. The code will run on the host; it will talk Jini to the rest of the network, and it can talk to me directly because it knows my details.

JavaWorld: How would a device discover its surrogate host?

Jim Waldo: The surrogate architecture includes a discovery protocol for finding surrogate hosts. It features the same idea that Jini uses, where inside Jini, the discovery protocol is saying, "Find me a lookup service." In this case, a discovery protocol will allow a device looking for a surrogate host to match with a surrogate host.

JavaWorld: So this device would have to have a piece of software that knows that protocol?

Jim Waldo: Right. And by the way, this protocol may differ over different networks. Bluetooth, for example, may not be running TCP/IP.

JavaWorld: So the surrogate discovery protocol is specific to the underlying network transport?

Jim Waldo: Right, the discovery protocol has to match your actual physical networking. So we can foresee, for example, a surrogate discovery protocol running over FireWire. With FireWire, when you plug in a device, it basically sends the moral equivalent of a bus interrupt down the FireWire network. In that case, the surrogate host can discover that a new device has turned on and contact it directly, instead of having the device send out a query such as, "Are you a surrogate host?"

JavaWorld: So the surrogate architecture could be used by items other than devices, for example, applications that, for some reason or another, would not want to run the service themselves. Do you envision the surrogate architecture to be used to interoperate with non-Java based software -- Microsoft Windows-based COM objects, for example?

Jim Waldo: Absolutely. That is another way to talk to non-Java things, or even to those items not written in a programming language. You could have something that plugged in that talked straight socket packet. But you can now do that in standard Jini. If you were to put something into the network that didn't understand Java, but would be able to obtain an interface to a lookup service and register a proxy with it, then that object does not need to know Java at all to communicate with its proxy.

JavaWorld: It could create its own private protocol...

Jim Waldo: Exactly. Many people don't understand this concept. Our implementation of Jini uses RMI. When we implement our Jini services, we use RMI to talk between the object and the proxy that represents this object in a Jini federation. But you don't have to do that. You could, in fact, just open up a socket and talk to a socket.

JavaWorld: Would the communication protocol between the proxy and the object have to use some sort of a TCP/IP connection currently?

Jim Waldo: Currently, yes, because our current implementation of Jini runs over TCP/IP networks. If you know your network is not a TCP/IP network, you don't have to use TCP/IP. What you know as the service can export the object that you hand out to people to talk to you. How you talk to that exported object is a private matter between you and the object.

JavaWorld: What is the status of the Surrogate Project?

Jim Waldo: Right now the spec is being reviewed. I think the implementation is about a week behind the spec. Once the spec has been decided, an implementation of it will be available shortly. I believe there are [other companies and individuals] that will provide implementations as well.

JavaWorld: Beyond the Surrogate Project, what challenges do you see in scaling Jini down in small devices?

Jim Waldo: We're also thinking about how we could scale down to places where a surrogate host cannot run. As well, there are some interesting questions that may require additions to the Java environment itself. How can I ask a virtual machine how much memory it has available? How do I ask an object how much space it needs?

JavaWorld: Somehow, the VM would have to relay this information...

Jim Waldo: Exactly, and the other thing that would be needed in a case like this is better garbage collection for classes, not just objects, inside Java. That's a hard problem, by the way.

I've talked about this to the small-VM guys a fair amount; they get headaches and say they'll work on it. We'll see. It is an exciting area because we don't know the answers. Jini started up in a research group back in Sun Labs. We still have the feeling that if we really knew all the answers to what we were talking about, then we shouldn't be doing it in the first place.

JavaWorld: To venture out in the other direction, what are the challenges scaling Jini up to large, perhaps worldwide, networks? What's the largest Jini deployment so far, in terms of number of services and number of users?

Jim Waldo: I don't know what the largest one is, but I do know a group that completed a benchmark with a large system. The performance of the lookup service scaled absolutely linearly. This group had something like up to 10,000 agents. The time to register 500 agents didn't change, no matter how many agents were already there. The time to look up an agent was absolutely flat.

1 2 3 Page 2
Page 2 of 3