On Tue, Sep 9, 2008 at 11:47 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
> 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/> > Another way could be to use attributes like a "messageType" attribute for the JMS Message type, eg <wireformat.jms messageType="Map" />. Probably not much either way and the non-attribute way is more concise if thats all there is, but we may end up also having other attributes for things like pluggable header and payload handlers in which case a messageType attribute might be more consistent. > 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/> > Is that saying you could use multiple wireformat elements to configure the binding? Thats not what i'd been thinking and its not what the schema from the spec email supports as it has <databinding />? not <databinding />* but as it is still a draft that doesn't mean we couldn't try to do it that way. > > 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 > There is the start of some definitions in that spec email, about half way down there is a section "8.6 Databinding" which shows <sca:binding.xml/> and <sca:binding.jms/>. > > 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. > perhaps a "handler" attribute to plug in custom user code to do the marshalling/unmarshalling. <wireformat.jms messageType="Map" handler="some.user.pkg.MyMapMsgHandler" />, but we'd have defaults so you don't need to specify it unless needed, so for example <wireformat.jmsobject> by default would use the JAXB databinding to get an array of Java objects for the JMS ObjectMessage payload and you'd only need the handler attribute if you want to change that. > 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. > > I'm struggling a bit to understand the best way to implement it - interceptors or something else - as its not that clear to me yet exactly what "it" is meant to be doing, so trying these specific SCDL examples to try to make it a bit clearer to me. ...ant
