On Thu, Mar 19, 2009 at 1:57 PM, ant elder <[email protected]> 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
