W3C home > Mailing lists > Public > public-soap-jms@w3.org > October 2008

Action 36 - Writeup of details around TextMessage

From: Eric Johnson <eric@tibco.com>
Date: Mon, 06 Oct 2008 16:08:24 -0700
Message-ID: <48EA9A68.20802@tibco.com>
To: "SOAP/JMS (list)" <public-soap-jms@w3.org>

Action item: http://www.w3.org/2002/ws/soapjms/tracker/actions/36

Proposal:

Add:
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 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 (See Section 6 of
MIME).  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 for a 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
ration of 33% more characters than bytes.  Combined with a UTF-16
representation of those characters, the bytes required in memory 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 vendor-specific.  A vendor might be
encoding a TextMessage with UTF-8, and may further compress such
messages.  With these two techniques, the data transfered 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.

------------------
Appendix A:
Add MIME reference to RFC 2045. http://tools.ietf.org/html/rfc2045

-Eric.
Received on Monday, 6 October 2008 23:12:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 18:16:19 GMT