Re: [ecf-dev] RemoteService + Context

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

Hi Radostin,

On 10/27/2010 10:19 AM, Radostin Surilov wrote:

Hi Franky, hi Scott,

Franky, thanks for letting me know about the previous discussion - it is indeed quite similar to what I'm doing.

More about our use case - when a request to a remote service is executed, the security context has to be passed together with the request. The remote platform should receive the request and put the context in a thread local (before the actual method execution), so the security details are available for the current call stack.

Scott, I understand that something similar should be provider specific, so I am using ecf generic provider.

One thing to make clear:  although there is no problem with using the ecf generic provider, the code in org.eclipse.ecf.provider.remoteservice bundle does *not* depend upon the ECF generic provider (yes, I know the package name org.eclipse.ecf.provider.remoteservice.generic makes it sound like that, but that's an unfortunate package name that I now cannot change without breaking existing API).

Rather, the org.eclipse.ecf.provider.remoteservice depends upon the shared object API...and this API is currently implemented by several providers:  xmpp, jms, javagroups providers.  This allows *all* of these to reuse the RegistrySharedObject (and the Request/Response classes).

The solution I found so far is based on aspects. We are weaiving org.eclipse.ecf.provider.remoteservice so:
- When a new org.eclipse.ecf.provider.remoteservice.generic.Request is created the security context is put in the RemoteCallImpl instance of the Request.
- Before each execution of the org.eclipse.ecf.provider.remoteservice.generic.RemoteServiceRegistrationImpl.callService(RemoteCallImpl) the security context is get from the RemoteCallImpl parameter and put in a thread local.

Do you see any problems with this approach or maybe suggest a more elegant solution?

I don't see any problems with this.  I think the discussion about more elegant solution can be had around whether or not some new API should be added to either ECF remoteservices...or the RegistrySharedObject...but I think given your use case what you've done makes sense.  And I assume it's working for you.

If you are willing, maybe you could share the Request/Response subclasses and the RegistrySharedObect subclasses, and that would allow Franky and all of us to see if there are things that could be generalized to meet several authentication use cases with future API additions/changes.

Thanks,

Scott