You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/10/02 12:38:04 UTC
JMS Text/XML default databinding
I'm looking for a little insight as to how the JMS default data binding
should work when text/xml messages are in force.
The JMS spec says that when there is a single operation parameter then the
message body is the XML serialization of that single parameter. It goes on
to say that when there are multiple parameters the message body is encoded
using the document wrapped style. So would you expect the following:
Single parameter
<name>Fred Bloggs</name>
Multiple parameter
<getPersonGreetings>
<firstName>Fred</firstName>
<lastName>Bloggs</lastName>
</getPersonGreetings>
What happens if someone adds an implementation.wsdl to a reference/service
that is not doc/lit/wrapped?
Regards
Simon
Re: JMS Text/XML default databinding
Posted by Simon Laws <si...@googlemail.com>.
On Thu, Oct 2, 2008 at 12:14 PM, ant elder <an...@gmail.com> wrote:
>
>
> On Thu, Oct 2, 2008 at 11:38 AM, Simon Laws <si...@googlemail.com>wrote:
>
>> I'm looking for a little insight as to how the JMS default data binding
>> should work when text/xml messages are in force.
>>
>> The JMS spec says that when there is a single operation parameter then the
>> message body is the XML serialization of that single parameter. It goes on
>> to say that when there are multiple parameters the message body is encoded
>> using the document wrapped style. So would you expect the following:
>>
>>
>> Single parameter
>>
>> <name>Fred Bloggs</name>
>>
>> Multiple parameter
>>
>> <getPersonGreetings>
>> <firstName>Fred</firstName>
>> <lastName>Bloggs</lastName>
>> </getPersonGreetings>
>>
>> What happens if someone adds an implementation.wsdl to a reference/service
>> that is not doc/lit/wrapped?
>>
>> Regards
>>
>> Simon
>>
>
> I guess ideally the JMS message body would still be encoded using the
> doc/lit wrapped style regardless of the reference/service interface right?
> Not sure what would actually happen in the current code though.
>
> As a slightly related FYI, the current code doesn't follow the spec on
> this. Currently it will use the wrapped style for both of those cases and
> also the return value will also always be wrapped where as the spec says it
> shouldn't be. Probably need the changes to support the new wireFormat to fix
> this as its a bit hard with the current Tuscany code.
>
> ...ant
>
>
Ok, thanks for that ant. I thought that maybe there was some magic in the
databinding transform but couldn't see anything obvious. I think you're
right that we need to pick up this as a scenario on the request/response
binding thread.
Simon
Re: JMS Text/XML default databinding
Posted by ant elder <an...@gmail.com>.
On Thu, Oct 2, 2008 at 11:38 AM, Simon Laws <si...@googlemail.com>wrote:
> I'm looking for a little insight as to how the JMS default data binding
> should work when text/xml messages are in force.
>
> The JMS spec says that when there is a single operation parameter then the
> message body is the XML serialization of that single parameter. It goes on
> to say that when there are multiple parameters the message body is encoded
> using the document wrapped style. So would you expect the following:
>
>
> Single parameter
>
> <name>Fred Bloggs</name>
>
> Multiple parameter
>
> <getPersonGreetings>
> <firstName>Fred</firstName>
> <lastName>Bloggs</lastName>
> </getPersonGreetings>
>
> What happens if someone adds an implementation.wsdl to a reference/service
> that is not doc/lit/wrapped?
>
> Regards
>
> Simon
>
I guess ideally the JMS message body would still be encoded using the
doc/lit wrapped style regardless of the reference/service interface right?
Not sure what would actually happen in the current code though.
As a slightly related FYI, the current code doesn't follow the spec on this.
Currently it will use the wrapped style for both of those cases and also the
return value will also always be wrapped where as the spec says it shouldn't
be. Probably need the changes to support the new wireFormat to fix this as
its a bit hard with the current Tuscany code.
...ant