Ant, JMS bindign spec does describe the facility to specificy a data binding type at different levels of granularity. But it doesn't say about how it should be implemented.
When I started the JMS binding I was tempted to do my own data binding inside the JMS Invoker, but looking at the bigger picture I decided against it. If we do this in the framework then we can reuse these data binding across other bindings as well. If u look at section 1.5.2 more closely the default binding suggests we use a WSDL schema for the XML serialization of the message and then to use document wrapped for multiple parameters. This means that we could easily use any data binding provided by the ws.binding code. Also the above is a default recomended binding, the implementor is free to implement it's own binding. One such thing could be java serialization using Bytes Message. Regards, Rajith On 12/15/06, ant elder <[EMAIL PROTECTED]> wrote:
On 12/15/06, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > > HI, > > I am making some attempts to understand the DataBinding fwk and so shall > say > something here so that others will help me understand better. My > apologies > if I have mentioned something outrageous as I am just about entering into > this discussion :) > > - By employing the databinding interceptors we expect that when the data > comes into the JMS Target Invoker as payload, it is already transformed > and > ready to be dispatched. Is that so? > > - Why not do this transformation that is specific to the JMS Binding in > the > JMS Target invoker. Can we not simply invoke the transformers or the > tranformer chain providing the source and target data types from within > the > invoker? Why is it that we must do it as part of the DataBinding inceptor > in the middle of the invocation chain.? Why not do it at the end of the > chain which is in the invoker and do this transformation explicitly? There was an IRC chat and email thread related to this back in September: http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200609.mbox/[EMAIL PROTECTED] I'm starting to think you may be right and it would be easier to have more of this in the JMS binding itself, especially when looking at implementing support for section 1.5.2 of the current JMS binding draft spec. ...ant
