[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] RemoteService + Context
|
Hello,
On 10/25/2010 2:42 AM, Radostin Surilov wrote:
Hello,
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,
"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.
Thanks,
Scott
