Hi re. the point about "having some binding neutral impls like <databinding.jaxb>, <databinding.xmltext> etc which then could be used by specific bindings to get at native message so <databinding.jmsobject> would use <databinding.jaxb> and <databinding.jmsxmltext> would use <databinding.xmltext>"
Not sure I quite understand your proposal so let me replay it. For JMS the wire format will always be JMS Message but the type of message varies and the type of content in that message varies. So you could have, <wireformat.jmsmessage/> //by which I mean any jms message type <wireformat.jmsbytes/> <wireformat.jmstext/> <wireformat.jmsstream/> <wireformat.jmsmap/> <wireformat.jmsobject/> Then, for example, given one of these formats you can further specify how the request/response message is marshalled into the message <wireformat.jmstext/> <wireformat.xml/> I would expect that the JMS binding spec defines these types of databindings and the relationship between them but you are right that we will have to support this kind of thing from an implementation point of view In some cases, for example, a combination of jmsmessage and xml, you'll definitely need to have a pluggable piece of logic to work out how to do the transform. This brings us to how we add that logic. Wireformat, operationselection, faulthandleing elements in the model can all be used to create providers in a similar way that policies in the model do. I think the discussion is now focusing in on what sort of thing these proviers should provide. The proposal on the table is that they could create interceptors. I have some doubts about this, especially on the client side, but I'm prepared to give it a go and see if it hangs together. Does this sounds like an accurate summary? Regards Simon
