>
>
> Let's see what others have to say here... and I'll think more about
> the issue in parallel.
>
>
Luciano's right that providing access to detailed call context information
goes against the SCA approach somewhat.
In your scenario it sounds like you are trying to pass security context
information from the service binding to the reference binding. Do you really
need to process this context information in the service implementation?
Can you do what you need to do by adding policy handlers that process the
message before it arrives at the service operation?
I think the only concession to providing access to this kind of message
context information from within the service implementation is where the
RequestContext API provides access to the security subject, e.g. it's used
in some of our security tests.
public class HelloWorldServiceImpl implements HelloWorldService {
@Context
protected RequestContext requestContext;
public String getGreetings(String name) {
Subject subject = requestContext.getSecuritySubject();
if (subject == null){
return "Hello " + name + " null subject";
} else {
return "Hello " + name + " " + subject.toString();
}
}
}
If you really, really needed message context in the service operation I
guess you have two options.
1/ pass it in as an operation parameter
2/ extend the RequestContext API
Of these 1 is more immediately practical as you could probably create your
own policy to make it work with no changes to the Tuscany runtime. Doing 2
would involve changes to the infrastructure code itself and would mean
extending the SCA specifications.
Regards
Simon
