Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] RemoteService + Context

That's quite similar to what I'm doing. That's the reason why I started the discussion about how to add authorization on remote service calls via the proposed IRemoteServiceCallPolicy interface. The discussion about this matter is on hold for some time due to the ECF 3.4 release. Maybe we can start the discussion again once 3.4 has been released?
Radostin: I will reply on the original email thread about the authorization discussion so that you can follow what has been discussed up till now.
2010/10/25 Scott Lewis <slewis@xxxxxxxxxxxxx>

On 10/25/2010 2:42 AM, Radostin Surilov wrote:

We are building an application based on OSGI services. Everything is working fine in one VM but now we want to integrate a remote services implementation.
ECF seems a great choice - thank you for the work so far!

In our current implementation we have session and security contexts in ThreadLocals. Now when talking about remote services (which are in different VM) we want to pass
the session and security tokens over the "wire" and to use them in remote VMs.

How we can extend ECF to pass such parameters? Is it going to be a provider specific fix (ecf generic, r-osgi, etc.) or the fix can be done in a more abstract layer?

ECF has the notion of a 'connect context', which is used to pass credentials/credentials to the remote container upon container connection.  This is represented in the API by the IConnectContext in the IContainer.connect(ID,IConnectContext) call.  The IConnectContext *usually* has password information, but it can contain other information (e.g. serializable forms of the session and security contexts that you wish to send).

Note also that there is a way to set the connect context for remote service container adapters...i.e. via IRemoteServiceContainerAdapter.setConnectContextForAuthentication(IConnectContext).  This is the connect context that's used when connections are formed implicitly to targetID by the call to (e.g.) IRemoteServiceContainerAdapter.getRemoteServiceReferences(targetID, "",null);

The use of the IConnectContext for/by any given provider is indeed the provider dictates what information (from the IConnectContext callback) is actually sent over the wire upon connection.

For the generic provider, it's also possible to extend the RegistrySharedObject (in org.eclipse.ecf.provider.remoteservice bundle), which is the code responsible for sending remote call requests and responses.  So I believe it would be possible to extend this with call-specific information.

If your use case requires/implies some new API then we can certainly consider that for future versions of it might be useful for me and the entire community if you describe what you are doing a little further.



ecf-dev mailing list

Back to the top