----- Original message ----- > On 9/18/2011 6:21 AM, Peter wrote: > > In reality, the heart of the problem is there a single shared memory heap > > for applications sharing a jvm and we can't rely solely on permissions. > > When I think about Jini being used for Public APIs and for a more generic > public > service interface, over the internet, I think about the web browser experience > for the past 20 years, and look at the path followed to where things are at > now. > > The web browser is a form of what "ServiceUI" would potentially become. > Imagine > ServiceUIs in a tabbed environment, or multiple windows as the browsers let > the > user select now. Javascript/applets/plugins are the "mobile code" which for > Jini, would be implemented by ServiceUI and Proxies. Plugins, could include > 3rd > part codebases which would present an interesting issue for knowing what was > going on in the total service experience. > > It seems to me, that the IsolatedExecutor is a form of what is happening with > "plugins run in separate processes" that many browsers have been moving > to/towards. > > This is how it all lines up for me. And thus, I'm still wondering about what > would happen with ServiceUI to keep it out of the main JVM, but still able to > run inside of a single container, in some way. > > Gregg
That's some very visionary thinking. Provided it has been granted permission to open a window, the ServiceUI could easily operate outside the main jvm, it would just open as another process, like a separate application. If it misbehaves, just close it, no harm done. Thats the beauty of using IPC based jeri endpoints, the executor can be provided by a simple service, the callable object you use to run the ServiceUI, just needs to be serializable. Even the login could be performed in the isolated jvm with a dialogue box. But I think you'd want the service to provide some form of identity validation, better than the crappy certificate authority model. For that I think a trust service could be provided to emulate 7 degrees of separation. Ask others you trust if they trust the service origin, to eliminate man in the middle and impersonation attacks. Much of the hardwork has been done in Jeri, the implementation is relatively simple I think. The only difference though is I'm making the registrar proxy responsible for other proxy's it supplies, to reduce jvm instances. In other words, killing the jvm would kill the regisgtrar proxy and all the smart proxys of other services obtained from it. This makes sense though still, because each domain would be responsible for its own registrar registering only authorised services. Cheers, Peter.
