ISSUE-69: Ambiguity in spec. and potential interoperability problem with BytesMessage payload [SOAP-JMS Binding specification]

ISSUE-69: Ambiguity in spec. and potential interoperability problem with BytesMessage payload [SOAP-JMS Binding specification]

http://www.w3.org/2002/ws/soapjms/tracker/issues/69

Raised by: Mark Phillips
On product: SOAP-JMS Binding specification

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.

Proposal
========
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 11:49:46 UTC