Sun lets Jini Starter Kit 1.1 out of the bottle

JavaWorld author Frank Sommers talks with Jini architect Jim

This year is shaping up as a success for Jini technology. Jini licensees now exceed 50,000, and the technology is deploying everywhere from automobiles to enterprise software systems. The upcoming Fifth Jini Community Meeting, scheduled for December 11-12 in Amsterdam, Netherlands, has received a remarkable response. The meeting reached its capacity well in advance, and excess registrations spilled over onto a waiting list. For developers, the year's most important event may have been the October release of the 1.1 version of the Jini Starter Kit (JSK).

Jim Waldo and his team at Sun have been instrumental in this success story. Waldo has been investigating the use of Java technology for distributed computing and persistence for the past 6 years. Waldo is also an adjunct faculty member at Harvard University in the department of engineering and applied sciences, where he teaches distributed computing.

Prior to joining the Java group, Waldo was a principal investigator for Sun Microsystems Laboratories; he did research in the areas of object-oriented programming and systems, distributed computing, and user environments. Before joining Sun, Waldo spent 8 years at Apollo Computer and Hewlett-Packard working in the areas of distributed object systems, user interfaces, class libraries, text, and internationalization. He holds a doctorate in philosophy from the University of Massachusetts Amherst.

JavaWorld: What's new in the Jini Starter Kit 1.1?

Jim Waldo: First, it's important to realize that the 1.1 release is an addition to Jini, as opposed to a change in Jini. All of the interfaces and services that were available in the first release are still available and unchanged. Anything that used to run as a Jini service will still run as a Jini service.

For the 1.1 release, we put together some utility classes to make writing a Jini service or a Jini client easier. Some of these were actually included in the first Jini release. We tried to apply to them the same careful design effort that we put in the earlier interfaces that define Jini as whole, mainly to make these utilities easier to use and more robust. Mostly, people can use these utility classes -- yet they don't have to -- to write their services. We make a distinction between utilities, which are classes, and services that are real Jini services living out on the network. This time around, we put in a lease-renewal service, a lookup discovery service, and an event mailbox.

JavaWorld: What other utilities and services are you planning to introduce in a future version of the JSK?

Jim Waldo: One of these items might be a service used to send events. A number of people have been looking at a utility class that will grant leases, to make the whole leasing model somewhat simpler. Another addition will be a set of utilities or tools that will make it easier to configure a Jini network. Also, we will be adding services and utilities that will help you get your classpath right, and your code-base right.

JavaWorld: Will there be any security-related services?

Jim Waldo: Security is a rather large and hairy subject. Right now, Bob Scheifler is working on a security JSR (Java Specification Request) for basic RMI. The RMI security will form the semantic model for security in Jini, in the same way that RMI forms the semantic model for communication in Jini. You don't have to use RMI, but whatever you use has to preserve the meanings that RMI gives you.

JavaWorld: So this security mechanism will be an abstraction that one could implement in different methodologies or in different protocols as well?

Jim Waldo: In some ways, it is almost like a service provider interface. It details what security means inside an RMI and Jini framework. You can have many preferences and requirements associated with clients and services -- to indicate that you must authenticate either one, for instance, or that you desire privacy but don't require it, that you want encryption on the wire, and so forth. Depending on how the community review goes, it could actually show up in the next Java release, the Merlin release.

On top of that security model, we're also talking about adding services that can be used inside a Jini network to allow a fairly simple implementation of that security model within a Jini federation. These services will be built on top of the API and on top of the semantic model; they will provide the ability to obtain certificates for authentication, for instance.

JavaWorld: This will be a security service?

Jim Waldo: Exactly. That is something that we're looking at probably for the release after the next release of Jini, which we're talking about naming Alewife. We would name the release after Alewife, Davis. We're naming them after subway stops, for those of you familiar with Boston. The Davis release is the one that would include Jini security.

JavaWorld: Besides the new utilities and services, what else is new with Jini 1.1?

Jim Waldo: We also changed the commercial licensing terms. Jini is now free.

JavaWorld: Many programmers associate device programming with Jini. Has Jini been used in applications that do not involve devices at all, such as enterprise software?

Jim Waldo: Absolutely. Everything in Jini is set up to mask how a service is implemented. There is no real distinction in Jini between hardware and software, only alternate ways of implementing an interface. We've seen a lot of this happening, where a large enterprise software service wraps itself in a little Java code, which enables this service to register itself as a Jini service and be found by other services. A company called BizTone, out of Malaysia, was the first to do this. It built an entire ERP (enterprise resource planning) package out of components that talk to each other via Jini.

JavaWorld: Those might not even be Java-based components.

Jim Waldo: Some of them may not be Java-based. All BizTone does is present a Java object that can be used by somebody else to talk to their services.

One of the very interesting things about distributing Jini the way we have, which is essentially to make it freely available on the Web, is that we don't really know who our customers are. We find out about the customers who are having trouble because they call us up and tell us. We find out about our customers who aren't having trouble when they're about to ship their product and need a commercial license. That is, when they remember they need to obtain a commercial license before they ship, which many people forget, and we actually don't mind.

JavaWorld: Let's return for a moment to Jini 1.1. What is the relationship between the Jini core, the Jini extended specifications, and the JSK that you're including all of these services in?

Jim Waldo: The Jini core is what really defines Jini. It is the base set of interfaces, and not much else. That's where the Jini programming model is defined, and where what it means to be a Jini system is defined. The Jini core defines things such as the interface to a lookup service, the basic discovery protocol, the interfaces for leasing, events, and the two-phase commit for transactions. The extended APIs are our service APIs. They don't define what it is to be Jini, but rather what you can expect from a service that's in a Jini federation.

Outside of the core, we also have implementation. There is Reggie, which is our implementation of the lookup service. And then there's also JavaSpaces. The interface to JavaSpaces is a definition of a service interface. JavaSpaces at one time was outside of the central part of Jini. Now JavaSpaces is part of the basic release. It was just too confusing to separate the extended services, which was JavaSpaces, from everything else in Jini. So, now it's one download, and one package.

JavaWorld: So, basically, this extended API is the extension point where other APIs could be introduced for specific services?

Jim Waldo: Absolutely.

JavaWorld: And that's open to the community process?

Jim Waldo: Yes. Now, the community process can also introduce services into the core, but these services will be introduced very slowly. We're going to be very conservative about that, at least if I have anything to say about it.

JavaWorld: Are you aware of Jini core implementations or extended APIs by companies other than Sun?

Jim Waldo: ProSyst, in Germany, has been shipping their own implementation of a lookup service for about a year. The ProSyst lookup service does not use RMI to talk between the lookup service and the entity that communicates with the lookup service. They decided they would try a different protocol. They hand out an object that implements the lookup service interface, but it uses a different wire protocol than RMI.

Just recently, PersonalGenie introduced a lookup service that they claim has some security features in it. They implemented their own security scheme inside their own lookup service, and it follows all the rules of a Jini lookup service. We don't require that the implementation be the same. We just require that it implement the same interface. That's all we care about, the interoperation.

JavaWorld: In addition to the APIs that define basic Jini behavior and services, do you foresee industry-specific APIs that will expose certain business functionality?

Jim Waldo: At JavaOne, Ford showed a system for the car, where a Palm Pilot had a directory service that interacted with the GPS device and the navigation system in the car, both of which interacted with a voice recognition system. When you place your Palm Pilot in the car's cradle, it registers itself as a directory service with the lookup service that runs inside the car. While you're driving, you could say, "I want to get to Carl's house." The voice recognition system would recognize that as a request for a route. It would recognize Carl as a name. It would then go to the directory service on your Palm Pilot to obtain an address that matches Carl. Finally, it would feed that to the location service, which is your navigation system, find a route, and display it.

JavaWorld: It would be a useful service if, when you enter your car, your cell phone could locate the car's stereo system as the speaker and mic for the phone.

Jim Waldo: That is exactly the kind of interaction we've been talking about. If you said, "I want to call Carl," the system in your car would look up his number in your directory service and hand that to the telephone, which could then dial him up. You could hear Carl and talk to him via the stereo system's speakers and microphone, while keeping your hands on the wheel.

JavaWorld: Besides the automobile industry, are you aware of other efforts for industry-specific Java APIs?

Jim Waldo: A group in Europe is using Jini to stitch together a system for tourism. That group found that many of the service providers in Europe's tourism industry use customized software that doesn't interact with everybody else's software. They've defined a set of Jini interfaces for the tourism industry that can then be implemented to talk to these various legacy systems and present a unified front to everybody else.

JavaWorld: Could other companies implement that API as a layer on top of their existing legacy systems?

Jim Waldo: Yes. And then they can tie together all of the tourism systems that have subscribed inside of Europe. You could find out what hotels are available in the area, what services they offer, make your reservation. You could make your reservation for the next night, at the next place you're going to. All of this will be tied into the network.

JavaWorld: Suppose the cell phone in your car is part of a network of Jini services. How would this device discover what business-specific APIs are available in the Jini federation? How would it know that it can reserve hotel rooms, find gas stations and service stations, access weather and ski reports, etc.? How would it learn about the existence of an API it never used before?

Jim Waldo: Clearly, you need a client that knows how to talk to the API. We don't have any magic there.

JavaWorld: Is there some semantic, some kind of a translation that would say, "Give me a tourism-specific API"?

Jim Waldo: Not that we have now. Although you could look for services that had a particular label, like "Tourism API." If they supported the ServiceUI, you could then download a client program that could talk to it.

JavaWorld: On the Web, search engines allow users to learn about Webpages they did not know of before -- for instance, by keywords. You can type in "Hotel rooms, Berlin" and you get a list of Websites that, very likely, have information about hotel rooms in Berlin. Do you foresee a Jini search engine that provides some easy human readable way of locating services based on functionality?

Jim Waldo: That would be an interesting service for people to provide inside the Jini world. Remember that Jini was really designed not so much for people to talk to services as for programs to talk to services. Programs are remarkably bad at understanding human language. That is why we use the Java type system to discover things: because we suspect that it will be programs that are looking for services.

1 2 3 Page 1
Page 1 of 3