A Jini voyager: an interview with David Norris of ObjectSpace

ObjectSpace is a well-recognized leader in Java and distributed object computing. Its products range in scope from a popular Java collections framework to the latest object request broker. In the release of its Voyager 3.0 suite, due out shortly, the Dallas-based company is also set to put Jini technology through its paces. ObjectSpace CEO David Norris recently spoke with us about his firm's plans for the new network-services technology and about how this came to be a reality.

EarthWeb: How is ObjectSpace putting Jini 1.0 technology to work?

Norris: Voyager is a distributed-computing infrastructural product line that has multiple levels of functionality: There's a low level, a medium level, and a high level. Level 2, medium, is where we actually have our Jini support.

We're not so much using Jini in our products as we are providing support for it in our product line. Product support for Jini will be released in Q2 of 1999 in Voyager. Our support will have interesting differences, as opposed to some of the things that Sun's doing. Would you like me to talk about that now?

EarthWeb: Yes, why don't you.

Now Voyager

Norris: The idea of our Voyager product line is interoperability. That's our number-one value proposition. At the lower levels, Voyager provides an object request broker, an ORB, that offers interoperability between CORBA and Microsoft technology, as well as Java RMI. If you have a component, and you want to talk to another component -- it doesn't matter what type those components are -- they can all talk. All transparently. So you don't have to worry about any processing. In the Jini level, we have the same philosophy. In fact, it's pervasive throughout our whole product line, anything that we do.

One of the challenges that Jini has is that it is Java-specific. So if I had Jini, and I wanted to talk to a non-Jini device -- an example would be a Windows CE device running UPP, Universal Plug and Play -- I couldn't do it. Voyager solves that problem. We provide interoperability not only at the component-messaging layer but also at the Jini level. With our Level 2 product, our Jini support will provide interoperability between Java and Jini, as well as UPP and CORBA trader services, allowing any component anywhere to use any other component and any services rendered thereof.

The way that we're using Jini, to answer your first question, is we're providing support for Jini 1.0 and interoperability between it and Microsoft's technologies and CORBA's technologies.

EarthWeb: I guess you have pretty good hopes for Voyager's success?

Norris: We believe that Jini has two major opportunities. One of them is at the device level, which is what Sun has been promoting so heavily. But even more important to us, we believe that Jini will have a bigger opportunity at the enterprise level. Our real proposal is to bring Jini to the enterprise to provide interoperability between different services at the enterprise level. This does not mean that we don't plan to do devices also, because we do plan to provide support for them; but at the enterprise level, services need to be able to find each other, and we plan to provide the interoperability to allow that to occur.

EarthWeb: I'm hearing that more and more. There seems to be some conflict between the Jini camp and the EJB camp.

Norris: That's right, we're introducing our Enterprise JavaBean support in Q2 also. The combination of Enterprise JavaBeans with good support for interoperability on the Jini side, I believe, is very powerful for the enterprise. Sun has chosen to focus on devices, device interoperability, which I think is a different marketplace, and it's a different opportunity -- we plan to take advantage of both of those and generate good revenue from each.

A pragmatic approach

EarthWeb: I notice you recently told a reporter: "We want to offer interoperability with the capabilities of Jini without just sticking to Java."

Norris: That's correct, so a C++ component on a Microsoft platform should be able to use a Java-Jini server.

EarthWeb: This isn't a religious thing. You guys are . . .

Norris: Pragmatic, is the word.

EarthWeb: I was going to go for ecumenical, but pragmatic sounds better.

Norris: Okay. We're out there in the real world building real solutions with real clients. They have every kind of system in the world, with every kind of legacy language you can imagine. We have to provide solutions for that. They're not a hundred percent pure Java, although we all wish they would be. It's impractical to think that way.

At the device level, Sun can definitely wish that, and they can try to make that happen. But at the enterprise level, it's simply just not feasible.

EarthWeb: Does this indicate that your upcoming products -- including those Jini-enabled -- will not be "100% Pure Java"?

Norris: Our upcoming products will be 100% Pure Java. [I was] addressing the need to interface to other, legacy systems that are not written in Java and, therefore, require other technologies, such as CORBA or DCOM.

EarthWeb: All right. Anything else you want to tell us about Voyager?

Norris: I stressed interoperability. Another major point is ease of use. One of our goals is to try to simplify distributed computing, because it is rather complicated. We've added some very neat capabilities in Voyager to make it easier to use, simpler to use. Some of those are patented and very unique.

EarthWeb: Okay. Some people talk about performance perhaps being a problem with Jini deployment -- have you experienced anything along those lines?

Norris: I think performance will be determined by the specific implementation of Jini, which is really a specification. In our implementation, the performance has been extremely well-received. It has been very reliable, it has performed very adequately for the applications we've looked to use it on. I've heard reports on Sun's implementation; but personally, I don't have experience on its performance.