[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-bindings] Action item: Note about TextMessage from SOAP/JMSworking group
> Since the message is already in text format the "encoding" > attribute in the XML header must be ignored. Perhaps not the best place to discuss this, but why is the encoding attribute in the XML preamble ignored? -Anish -- Eric Johnson wrote: > 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 > <http://dev.w3.org/cvsweb/%7Echeckout%7E/2008/ws/soapjms/soapjms.html?content-type=text/html;%20charset=utf-8#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 |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. > > --------------------------------------------------------------------- To > unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]