Bytes/Text Message behavior over default wire format

[Kaushik Mukherjee <km...@gmail.com>]

Hi,

I am looking at the default wire format section in the current OASIS
JMS binding spec.

306 • Otherwise, the JMSMessage must be a JMS text message or bytes
message containing XML; an
307 SCA runtime MUST be able to receive both forms. When sending
messages either form may be
308 used; an SCA runtime MAY provide additional configuration to allow
one or other to be selected.

Most of the behavior described here is clear to me, except for what
the default message type should be for a response. For instance, if an
SCA service were to receive a bytes message, should the service
default to responding with a text message, or should it respond with
the same message type as the incoming request? It seems reasonable to
assume that a non-SCA client might expect the response to be of the
same type as the request, but I can see this being argued both ways.
Any thoughts on this would be appreciated.

Thanks,
Kaushik

Re: Bytes/Text Message behavior over default wire format

[Simon Laws <si...@googlemail.com>]

snip..

> My concern was that we're adding another column to the "wire format
> decision matrix", with columns already probably including "binding"
> and "wireFormat".   It's not that we couldn't do the job of coding and
> documenting this... it's that I'm worried the user will look at the
> "matrix" we document encompassing all the WFs and bindings and think
> that this is overly complicated.

+1

>
> But ... maybe I'm getting ahead of myself here...  we probably need to
> build our understanding of what a wireFormat behavior does from the
> bottom-up, one case at a time, so this has been a good place to
> start/continue the discussion.

+1. It's unfortunate that the default JMS wire format has this complexity.

>
> So let me add one more twist:  do we agree that participation in a
> callback does not add to the "context" here in determining the bytes
> vs. text default?   I.e., if, rather than sending a response to a
> forward request, I call over the callback interface, should I use
> 'bytes' as default no matter what?

Yes, you would configure a callback binding independently of a forward
call binding.

>
> Scott
>

Re: Bytes/Text Message behavior over default wire format

[Scott Kurz <sc...@gmail.com>]

On Fri, Mar 20, 2009 at 10:11 AM, Simon Laws <si...@googlemail.com> wrote:

> A single static default wire format is simpler to code/describe. I
> don't think it's as user friendly but I could live with it.

So with your approach, Simon, the pattern we're setting up is
something like:  "if I have a decision to make wrt how to serialize a
response, I might want to look at the request payload to guide my
decision."    I have to admit, that sounds reasonable and potentially
useful across other wire format & binding combinations.  This is
especially true when dealing with wire formats that are abstract to
some degree (e.g. I've got JAXB-serialized-to-XML but it might be in a
Bytes or Text msg), or wire formats that have multiple "cases"
inherent in their processing (e.g with binding.xxx, the "default wire
format" can handle either yyy format or zzz format).     (Of course,
this assumes we agree that abstract, multi-case WFs should even exist,
though WF.jmsdefault sets a precedent here).

My concern was that we're adding another column to the "wire format
decision matrix", with columns already probably including "binding"
and "wireFormat".   It's not that we couldn't do the job of coding and
documenting this... it's that I'm worried the user will look at the
"matrix" we document encompassing all the WFs and bindings and think
that this is overly complicated.

But ... maybe I'm getting ahead of myself here...  we probably need to
build our understanding of what a wireFormat behavior does from the
bottom-up, one case at a time, so this has been a good place to
start/continue the discussion.

So let me add one more twist:  do we agree that participation in a
callback does not add to the "context" here in determining the bytes
vs. text default?   I.e., if, rather than sending a response to a
forward request, I call over the callback interface, should I use
'bytes' as default no matter what?

Scott

Re: Bytes/Text Message behavior over default wire format

[Simon Laws <si...@googlemail.com>]

On Fri, Mar 20, 2009 at 2:11 PM, Simon Laws <si...@googlemail.com> wrote:
>> complexity into our wire format behaviors (not that I couldn't be
>> convinced).    It's certainly simpler to describe the wireFormat if we
>> say there is a default used for serialization, period, than to have to
>> introduce the request-format-as-context into the mix.
>
> A single static default wire format is simpler to code/describe. I
> don't think it's as user friendly but I could live with it.
>
>>
>> Another point: IMHO, I think in general  non-SCA <-> SCA binding.jms
>> interactions maybe should be thought of as requiring wireFormat
>> configuration, even if that configuration choice happens to be using
>> wireFormat.jmsdefault. Maybe it involves some burden on the user to
>> realize this fact.   In SCA<->SCA flows, on the other hand, I would
>
> Some burden on the documentation to point it out I guess. I agree that
> if people are including binding.jms they are probably expecting to
> communicate with non-SCA systems. I don't think we should make it
> mandatory though to have to modify the default behaviour to make this
> work.
>
>> expect it's more important to "just work" without any extra config.
>> In this SCA/SCA case, though, if both sides implement the OASIS
>> binding.jms spec, they can handle either bytes/text, so this question
>> isn't super-important.
>>
>> Scott
>>
>
> Simon
>

The wider implication of this discussion is that we need to add a
specific wireFormat.jmsDefault. I've added a JIRA for this
(TUSCANY-2930).

Simon

Re: Bytes/Text Message behavior over default wire format

[Simon Laws <si...@googlemail.com>]

> complexity into our wire format behaviors (not that I couldn't be
> convinced).    It's certainly simpler to describe the wireFormat if we
> say there is a default used for serialization, period, than to have to
> introduce the request-format-as-context into the mix.

A single static default wire format is simpler to code/describe. I
don't think it's as user friendly but I could live with it.

>
> Another point: IMHO, I think in general  non-SCA <-> SCA binding.jms
> interactions maybe should be thought of as requiring wireFormat
> configuration, even if that configuration choice happens to be using
> wireFormat.jmsdefault. Maybe it involves some burden on the user to
> realize this fact.   In SCA<->SCA flows, on the other hand, I would

Some burden on the documentation to point it out I guess. I agree that
if people are including binding.jms they are probably expecting to
communicate with non-SCA systems. I don't think we should make it
mandatory though to have to modify the default behaviour to make this
work.

> expect it's more important to "just work" without any extra config.
> In this SCA/SCA case, though, if both sides implement the OASIS
> binding.jms spec, they can handle either bytes/text, so this question
> isn't super-important.
>
> Scott
>

Simon

Re: Bytes/Text Message behavior over default wire format

[Scott Kurz <sc...@gmail.com>]

On Thu, Mar 19, 2009 at 1:57 PM, ant elder <an...@gmail.com> wrote:
> I think ByteMessage is preferred by some messaging folks as it avoids
> some of the encoding issues that can arise when using TextMessage
> across platforms, so maybe bytes should be the default?
>
>   ...ant

I noticed that the W3 SOAP/JMS working draft indicates a preference
for BytesMessage, supporting Ant's idea.

So Kaushik's original question becomes:  assuming for
wireFormat.jmsdefault we use a default of BytesMessage when
serializing a request, should we also default to BytesMessage when
serializing a response (assuming the response is also WF.jmsdefault)?
   OR
Should the algorithm involve looking at the actual request payload,
remembering whether it is bytes or text, and using that to dynamically
determine the format of the response serialization?

As much as I agree the second approach is more likely to enable a
non-SCA =>  SCA  interaction w/o any special configuration (i.e.
taking all the defaults)...  I'm uncomfortable introducing this
complexity into our wire format behaviors (not that I couldn't be
convinced).    It's certainly simpler to describe the wireFormat if we
say there is a default used for serialization, period, than to have to
introduce the request-format-as-context into the mix.

Another point: IMHO, I think in general  non-SCA <-> SCA binding.jms
interactions maybe should be thought of as requiring wireFormat
configuration, even if that configuration choice happens to be using
wireFormat.jmsdefault. Maybe it involves some burden on the user to
realize this fact.   In SCA<->SCA flows, on the other hand, I would
expect it's more important to "just work" without any extra config.
In this SCA/SCA case, though, if both sides implement the OASIS
binding.jms spec, they can handle either bytes/text, so this question
isn't super-important.

Scott

Re: Bytes/Text Message behavior over default wire format

[ant elder <an...@gmail.com>]

I think ByteMessage is preferred by some messaging folks as it avoids
some of the encoding issues that can arise when using TextMessage
across platforms, so maybe bytes should be the default?

   ...ant

On Thu, Mar 19, 2009 at 5:48 PM, Kaushik Mukherjee <km...@gmail.com> wrote:
> Your question about the MAY clause reminded me of another point. I am
> adding a flag to configure the message type that is sent, and I was
> assuming that text message would be the default if no message type is
> specified, but there is really no indication in the spec as to what we
> should use as the default. We could either choose a default format if
> nothing is specified, or we could require the message type always be
> set explicitly. I would prefer to have a default type which we can
> override with an optional attribute. Initially I was thinking of
> something like this...
>
>    <wireFormat.jmsdefault sendBytes="true"/>    //default is false
>
> but I like what you suggested better so we can explicitly configure
> either format:
>
>    <wireFormat.jmsdefault sendFormat="bytes"/> //default is text?
>
> -Kaushik
>
>
> On Thu, Mar 19, 2009 at 12:54 PM, Simon Laws <si...@googlemail.com> wrote:
>> ...snip
>>> Most of the behavior described here is clear to me, except for what
>>> the default message type should be for a response. For instance, if an
>>> SCA service were to receive a bytes message, should the service
>>> default to responding with a text message, or should it respond with
>>> the same message type as the incoming request? It seems reasonable to
>>> assume that a non-SCA client might expect the response to be of the
>>> same type as the request, but I can see this being argued both ways.
>>> Any thoughts on this would be appreciated.
>>>
>>> Thanks,
>>> Kaushik
>>>
>>
>> My vote would go with replying with the type you received unless a
>> particular type has been specified.
>>
>> Are we proposing to implement the "MAY" clause and allow the format to
>> be specified, e.g. something like...
>>
>> <wireFormat.jmsDefault sendFormat="text"/>
>>
>> or similar?
>>
>> Simon
>>
>

Re: Bytes/Text Message behavior over default wire format

[Kaushik Mukherjee <km...@gmail.com>]

Your question about the MAY clause reminded me of another point. I am
adding a flag to configure the message type that is sent, and I was
assuming that text message would be the default if no message type is
specified, but there is really no indication in the spec as to what we
should use as the default. We could either choose a default format if
nothing is specified, or we could require the message type always be
set explicitly. I would prefer to have a default type which we can
override with an optional attribute. Initially I was thinking of
something like this...

    <wireFormat.jmsdefault sendBytes="true"/>    //default is false

but I like what you suggested better so we can explicitly configure
either format:

    <wireFormat.jmsdefault sendFormat="bytes"/> //default is text?

-Kaushik


On Thu, Mar 19, 2009 at 12:54 PM, Simon Laws <si...@googlemail.com> wrote:
> ...snip
>> Most of the behavior described here is clear to me, except for what
>> the default message type should be for a response. For instance, if an
>> SCA service were to receive a bytes message, should the service
>> default to responding with a text message, or should it respond with
>> the same message type as the incoming request? It seems reasonable to
>> assume that a non-SCA client might expect the response to be of the
>> same type as the request, but I can see this being argued both ways.
>> Any thoughts on this would be appreciated.
>>
>> Thanks,
>> Kaushik
>>
>
> My vote would go with replying with the type you received unless a
> particular type has been specified.
>
> Are we proposing to implement the "MAY" clause and allow the format to
> be specified, e.g. something like...
>
> <wireFormat.jmsDefault sendFormat="text"/>
>
> or similar?
>
> Simon
>

Re: Bytes/Text Message behavior over default wire format

[Simon Laws <si...@googlemail.com>]

...snip
> Most of the behavior described here is clear to me, except for what
> the default message type should be for a response. For instance, if an
> SCA service were to receive a bytes message, should the service
> default to responding with a text message, or should it respond with
> the same message type as the incoming request? It seems reasonable to
> assume that a non-SCA client might expect the response to be of the
> same type as the request, but I can see this being argued both ways.
> Any thoughts on this would be appreciated.
>
> Thanks,
> Kaushik
>

My vote would go with replying with the type you received unless a
particular type has been specified.

Are we proposing to implement the "MAY" clause and allow the format to
be specified, e.g. something like...

<wireFormat.jmsDefault sendFormat="text"/>

or similar?

Simon