Sponsored Link •
Bill Venners: Are you assuming all these proxies will be stubs? One of the nice things about Jini is there's a choice as to how to implement service interfaces. They can be completely implemented locally, or partly locally, partly remotely, or maybe it's a remote object and the proxy is just a stub.
Bob Scheifler: Jini security is not just for stubs. It certainly includes smart proxies.
Part of the trust mechanism goes back and asks the server if it trusts a
potentially smart proxy where you have downloaded code. If you look
JERI (Jini Extensible Remote Invocation) and secure JERI, in most cases we have gotten rid of stubs. We
java.lang.reflect.proxy to do dynamically generated
stubs. So in those cases, you might argue that you would not be
actually downloading a stub. It will all be local code. But we are
definitely catering to smart proxies.
Now the interesting case that you brought up is if my service proxy is a completely local object with no remote back end. How do I decide I trust it? The mechanism that I described doesn't give you a way because there is nobody at the other end to ask if it trusts the proxy.
Bill Venners: A proxy that's completely implemented locally could still give a bootstrap object that goes across and gets a verifier. Once the proxy is verified, the service could be fully implemented locally.
Bob Scheifler: There still has to be somebody at the other end whose identity I think I know in order to ask that question.
The Jini Community, the central site for signers of the Jini Sun Community Source Licence to interact:
To get involved in the Davis project, in which Jini security is being defined, go to: