Sponsored Link •
Bob Scheifler talks with Bill Venners about Jini Extensible Remote Invocation, a new implementation of the RMI programming model.
Many potential applications of Jini require network security. Although various third parties have made proprietary security extensions to Jini, until now the only security available to users of the standard Jini release is the security infrastructure of the Java platform. The Jini Community's Davis project is about to change that. Bob Scheifler is leading the development of the next release of Jini, in which security is the central concern, as part of the Davis project.
On Friday, April 12, 2002 Bill Venners visited the Sun Microsystems campus in
Burlington, Massachusettes and interviewed
Bob Scheifler, Sun Distinguished Engineer and architect in the Jini Group.
In Part I of this interview, Scheifler discusses the need for security in Jini and the special security considerations
of dynamically downloaded code.
In Part II, Scheifler describes the mechanisms used to determine whether a proxy should be trusted.
In Part III, Scheifler covers the mechanisms used to achieve object integrity.
In Part IV, Scheifler discusses security constraints and the
In Part V, Scheifler describes the dynamic granting of permissions to proxies.
In this sixth and final installment of the interview, Scheifler discusses Jini Extensible Remote Invocation.
Bill Venners: Can you give an overview of JERI?
Bob Scheifler: JERI is Jini Extensible Remote Invocation. JERI is a new implementation of the RMI programming model. So it is on a par with RMI's native JRMP protocol. It's also on a par with RMI/IIOP in the sense that all of these are implementations of the RMI programming model. They use different protocols underneath. They have different protocol stacks. They expose things to different degrees. But they all implement RMI semantics. One of the things we have always said about Jini is it is not about protocols. It is about interfaces. All of the services we ship to date use JRMP. That's an artifact because JRMP was the most convenient protocol to get the object semantics we wanted.
We always said JRMP is not necessarily the only protocol. JERI is now another example. It's a new implementation of RMI. It has the same kind of RMI semantics as JRMP, though not the same protocol stack. We'd like to be able to implement services with JERI as well. Clients still shouldn't care whether you use JERI, JRMP, or RMI/IIOP. As long as the protocol you choose meets the semantics of the interface you specify, that should be good enough.