The difference between your use case and mine is clear now: in my use case there's only one user initiating requests within a same communication container while in your use case there can be many users, hence the need to send the security context in each request (while I can rely on the container ID that is already sent in each request).
Still there are similarities and to summarize here's a list of what would be needed (correct me if I'm wrong):
- Some method to add whatever data that needs to be passed in every request to a remote service: I'm not sure where this method should be but I guess on IRemoteServiceContainerAdapter and the method could be something like setRemoteServiceCallContext(IRemoteServiceCallContext context), similar to the IConnectContext but for remote service calls
- Some way to extract and/or process the data passed in a request when the request is handled: Could this be the IRemoteServiceCallPolicy interface we talked about some time ago?
- Both in Radostin's and my use case: some way to clean up the SecurityContextHolder (Spring security specific) when the remote call has finished: This is specific for the integration with spring security and maybe there's no need for an API here? (still had no time to investigate this...).
Consider the following scenario: A web application separated into two OSGI platforms - gui and business. The business platform provides (remote) services that the gui platform uses. Requests to (remote) business services can be
initiated from the gui platform by different users. So each request should be associated with some security context.
As I understand, once a remote service (proxy) is registered in the client platform and a communication container is created, all subsequent request are executed using the same container. Is this correct?
Hope no one minds my jumping in here...but the answer to this question is yes...that's correct...at least for the ECF containers.
Thank you for your answer.
A question that comes up for me then is this: I suppose an alternative to what you are doing (using a threadlocal variable to distinguish every call on the proxy...right?)...would be to design your remote service expose some method parameter..i.e.
public void foo(Integer token);
that the client would be expected to pass in. Is this right?
Yes, this is exactly our problem. We are trying to avoid adding this additional parameter to each service method.
Regards, Radostin
I'm not saying one is better than the other (it depends upon the use case, I guess), I'm just trying to understand what you are doing and how ECF/remote services might better support it.
Scott
_______________________________________________
ecf-dev mailing list
