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
