|Re: [ecf-dev] RemoteService + Context|
Hello,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).
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?
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, "org.foo.Foo",null);
The use of the IConnectContext for/by any given provider is indeed provider-specific...as 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 ECF...so it might be useful for me and the entire community if you describe what you are doing a little further.
Back to the top