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: 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]