On Mon, Sep 8, 2008 at 6:05 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> At this moment, we have all the binding related work done in the reference > binding Invoker and service binding Listener. To make it possible to plugin > code that deals with binding native message in the context of the binding, > we probably have to split the "Invoker" and "Listener" into a "pipeline". > > For example, we have the Axis2BindingInvoker handles the following: > > 1) Create SOAPEnvelope > 2) Create MessageContext with Options > 3) Handle some QoS at the SOAP/Axis2 level > 4) Create OperationClient > 5) Call the OperationClient.execute() to dispatch the request. > > We need to find out a good balance to regroup the functionalities with > reasonable pluggability. This can be exercised by writing up a few sample > logic that needs to access the binding specific message and context. > > BTW, +1 to enhance the Message interface with getHeaders() so that Message > can carry non-business contextual data through the invocation chain. > > Thanks, > Raymond > > From: Simon Laws > Sent: Monday, September 08, 2008 5:25 AM > To: [email protected] ; [EMAIL PROTECTED] > Subject: Request Response Binding - was: Re: Tuscany data binding framework > enhancements > > > > 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 > Hi Raymond That sounds interesting. If we split up the invokers/listeners what would the interface between the separate parts be. Are you thinking that the invoke(Message) interface. If so are you thinking that Axis context is passed in the message? Simon
