OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: 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.


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 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]