- From: Eric Johnson <eric@tibco.com>
- Date: Mon, 06 Oct 2008 16:08:24 -0700
- 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 UTC