W3C home > Mailing lists > Public > public-soap-jms@w3.org > December 2010

Completion of ACTION-235

From: Mark Phillips <M8PHILLI@uk.ibm.com>
Date: Thu, 16 Dec 2010 11:54:58 +0000
To: public-soap-jms@w3.org
Message-ID: <OF61256734.82C03E7C-ON802577FB.004101E2-802577FB.00417555@uk.ibm.com>

I have investigated the BytesMessage problem mentioned on the 2010-12-07
[1]  call, and raised ISSUE-69 [2] which details the problem and proposes a
solution.  For convenience I have pasted the text of the issue below.

This completes ACTION-235 [3].


[1] http://www.w3.org/2010/12/07-soap-jms-minutes.html#item09
[2] http://www.w3.org/2002/ws/soapjms/tracker/issues/69
[3] http://www.w3.org/2002/ws/soapjms/tracker/actions/235

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
= = = = = = =

Issue 69 Description:
      The binding specification states that the JMS Message should be
      either BytesMessage or TextMessage, but it is not specific about
      which JMS API methods are used to read and write the message payload.
      For TextMessage this is not a problem because there are only two
      methods (setText and getText) but there are many different methods
      for composing and reading a BytesMessage.

      The choice of methods on BytesMessage leads to a potential
      interoperability problem. For example, in IBM we have seen problems
      where one system writes a BytesMessage payload with the writeBytes()
      method, and another system attempts to read the message with the
      readUTF() method. The readUTF() fails or produces unpredictable
      results because the payload has not been formatted as a
      length-prefixed Java UTF8 string.

      This is a simple problem to solve for organisations that own (and can
      modify) both sending and receiving applications to ensure that they
      write and read the BytesMessage in a consistent way, but if the
      message is written or read inconsistently by different vendor's
      middleware stacks (as could be the case with SOAP/JMS) then it will
      lead to incompatible implementations.

      To remove this ambiguity I propose the following amendment to the
      SOAP JMS binding spec.:

      In section 2.4, after the sentence...

      "The contents of the JMS Message body MUST be the SOAP payload as a
      JMS BytesMessage or TextMessage."

      ...add a new sentence which reads:

      "If the message is formatted as a JMS BytesMessage then the sender
      MUST write the payload with a writeBytes() method, and the receiver
      MUST read the payload with a readBytes() method.".
Received on Thursday, 16 December 2010 12:03:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:24:48 UTC