Ok so we've established that this stuff shouldn't be referred to as
Databinding alone so I've renamed the page [1]. Let's move on and work out
what we need to make this work...
A couple of points on the words added by Raymond and Ant:
Addition of native message data to the Tuscany message does open up the
possibility of adding interceptors to process the message but this doesn't
work so well on the reference side. Consider the following:
Reference -> interceptor -> binding -----> binding -> interceptor ->
service
In the policy example (different from operation selection etc but works for
demonstrating my point here) I have interceptors that do generic message
processing, e.g. on the reference side
public Message invoke(Message msg) {
// could call out here to some 3rd part system to get credentials
msg.getQoSContext().put(BasicAuthenticationPolicy.BASIC_AUTHENTICATION_USERNAME,
policy.getUserName());
msg.getQoSContext().put(BasicAuthenticationPolicy.BASIC_AUTHENTICATION_PASSWORD,
policy.getPassword());
return getNext().invoke(msg);
}
and on the service side
public Message invoke(Message msg) {
String username =
(String)msg.getQoSContext().get(BasicAuthenticationPolicy.BASIC_AUTHENTICATION_USERNAME);
String password =
(String)msg.getQoSContext().get(BasicAuthenticationPolicy.BASIC_AUTHENTICATION_PASSWORD);
if (username != null) {
System.out.println("Username: " + username + " Password: " +
password);
// could call out here to some 3rd part system to do whatever
you
// need to turn credentials into a principal
msg.getQoSContext().put(Message.QOS_CTX_SECURITY_PRINCIPAL,
username);
}
return getNext().invoke(msg);
}
But this means there has to be code in the binding to extract this info from
the message or put this info into the message, e.g. in the
Axis2BindingInvoker
if (basicAuthenticationPolicy != null) {
Axis2BasicAuthenticationReferenceBindingConfigurator.setOperationOptions(operationClient,
msg, basicAuthenticationPolicy);
}
And in the Axis2ServiceProvider
if (basicAuthenticationPolicy != null) {
Axis2BasicAuthenticationServiceBindingConfigurator.parseHTTPHeader(inMC,
msg, basicAuthenticationPolicy);
}
If for this request/response binding were to put native message content in
the tuscany message then we could implement interceptors on the service side
to pull out the approrpiate parts but on the reference side we would have to
do some generic processing and then extend the binding to read the generic
message and turn it into binding specific configuration. The binding
configuration structures are only available within the binding on the
reference side. It seems a little asymetric.
Now this may be what is being suggested but it would seem more appropriate
if we separated the current listeners/invokers up in so that their function
is spread amongs message mapping, fault mapping, etc functions. If we were
to stick with the tuscany message interface we would have to pass suitable
structures from one to the other in order to complete the processing.
Leading on from this we seem to need to hold header info in the Tuscany
message. I've added the following to the message interface to support some
policy experiments I've been doing but am open to suggestions...
Map<String, Object> getHeader();
Simon
[1]
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding
