Action item: Note about TextMessage from SOAP/JMS working group

As per my action item from this last conference call, here's a link to
the text which we just added around using TextMessage with JMS.

http://dev.w3.org/cvsweb/~checkout~/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#textmessage-considerations

Since this is a reference into a working document CVS, I'm pasting the
text below as well:

2.4.1
Considerations For Using TextMessage

While
the use of TextMessage may be attractive in some
scenarios, there are some considerations that go along with it.

  

    
Since the message is already in text
format the "encoding" attribute in the XML header must be ignored.

  

  

    
Messages with attachments will need to
use Content-Transfer-Encoding for attachment parts.

  

  

    
Depending on the range of characters
used by the SOAP message, using TextMessage may do more
than double the memory requirements to receive a message.

  

  

    
The impact on network consumption must
be measured for particular scenarios and JMS providers. 

  

Since
binary data needs to be encoded to be carried as text, SOAP attachments
via a TextMessage have the same concerns as the MIME
specification carrying messages over a 7-bit channel [IETF
RFC 2045]. The attachments will need to be encoded using one of the
Content-Transfer-Encoding options specified by MIME. If
the data is truly binary, such as a picture, a base64 encoding might be
appropriate.

In typical scenarios, using TextMessage will almost
certainly dramatically increase the memory requirements. This happens
as a consequence of the JMS API TextMessage.getText(),
which returns a Java String. The Java String class uses a UTF-16
representation to represent the data. This in memory representation
will generally be larger than the corresponding BytesMessage
representation. For example, if the message contains only US-ASCII
characters, and is encoded into XML using UTF-8, the Java String
representation of the message will take exactly twice as much memory. 

The in memory UTF-16 representation, coupled with base64 encoding of
an attachment, will consume much more memory than the equivalent BytesMessage
payload. To begin with, a base64 conversion yields a ratio of 33% more
characters than bytes. Combined with a UTF-16 representation of those
characters, the bytes required in memory will be 167% more than the
original binary data (an 8/3 ratio). As a consequence, carefully
consider any scenarios that use attachments with a TextMessage.

As significant as the concerns around memory consumption may be, the
effects on network payload size are more difficult to predict. Since
the JMS API does not specify exactly how messages are handled, the
effects on network traffic are JMS provider-specific. A JMS provider
might be encoding a TextMessage with UTF-8, and may
further compress such messages. With these two techniques, the data
transferred via network calls may end up being no larger than a
corresponding BytesMessage representation, even with
attachments. However, only actual monitoring will determine specific
effects of specific scenarios. Clients of this specification who are
using TextMessage are encouraged to do such monitoring. 

-Eric.