On Mon, Sep 29, 2008 at 2:35 PM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > On Thu, Sep 11, 2008 at 2:29 PM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> >> >> On Tue, Sep 9, 2008 at 6:00 AM, Jean-Sebastien Delfino < >> [EMAIL PROTECTED]> wrote: >> >>> From: Simon Laws >>>> >>> ... >>> >>>> 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(); >>>> >>>> >>> Here's a suggestion: >>> >>> List<Object> getHeaders(); >>> >>> - there's multiple headers (the trailing 's' makes that clear) >>> - a List supports multiple instances of a named header >>> - and is closer to a JAXB representation of XML <header>* >>> >>> Hope this helps. >>> -- >>> Jean-Sebastien >>> >> >> Apologies Sebastien, I didn't come back to you on this suggestion. I had >> in the back of my mind that having multiple headers with the same name could >> cause problems in terms of knowing what to do with them as they are >> extracted from the native message. If we're just pushing message headers >> into the Tuscany message then duplicates aren't a problem I guess. If we're >> trying to map them to operation parameters then it could be more problematic >> as it's difficult to tell which named header maps to which parameter. I may >> be talking my way into agreeing that multiple headers with the same name in >> the Tuscany specific message is OK though with it being a binding problem if >> it can't then translate that into something sensible on the native wire. >> >> Simon >> > > Hi > > This thread has been quiet for a couple of weeks, I notice in the mean time > that Raymond and Ant have added more details to the wiki page on this > subject [1]. I've re-organized the page to start pulling the Request > Response Binding ideas together using the JMS binding as an example. > > Regardless of how the OASIS TC decide to specify the selection of, for > example, wire format, I'd like to do some more work on how we might add > binding specific interceptors to our runtime assuming that the model > contains approriate information. Raymond made a proposal [1] but we need to > look at the details. Specifically how are interceptors chosen and called? > > The binding provide knows what's in the model and could be extended to give > it more control for organizing interceptors so I'd like to start there to > see what can be done. > > Regards > > Simon > > [1] > http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Binding > So if we imagine that the wireFormat/operationSelection proposal comes to pass in the various binding specifications in OASIS I'm interested in what the implications would be for the Tuscany runtime. A binding would contain some extensibility elements the result of which would be additional/alternative message interceptors for doing wire format and message selection processing at the reference and service. How are these interceptors get created and how are they placed on the wire. Taking wire formats as an example I would imagine that there are two mechanisms; 1. For default transformations the reference or service binding provider can look up the default interceptor based on the wire format element name in the binding 2. For custom transformations we need to allow the class name of the interceptor to be specified somewhere. What OASIS come up could have a bearing on this. If it really is a class name the interceptor could be loaded directly by the binding provider. If it was abstract in some way then another provider structure would be required. I've started expanding the notes at http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Request+Response+Bindingwith scenarios that look at some possibilities. I'm particularly interested in those who put the provider framwork in place see the addition of binding configuration see this as an extension of the binding providers or see this as a new set of providers? Regards Simon
