ACTION-25

Hi everyone,
Here's my write-up for ACTION-25 to propose the wording for a possible 
addition to the SOAP/JMS spec to account for the use of a TextMessage as 
an alternative to a BytesMessage.     My intent here is to describe the 
problem and possible solution in a way that could spur some discussion 
from the WG.   If we decide to update the spec for this after we've 
settled on things, then I could go back and define the specific set of 
changes to the spec.

Background:
>From the customer feedback that I've received regarding our existing 
implementation of SOAP/JMS in the WebSphere product (which is very similar 
to what is in the SOAP/JMS spec, except for JMS Message and JMS URI 
property names, etc.), I think there would be two main reasons for 
allowing the use of a TextMessage instead of a BytesMessage:
1) The customer is trying to interoperate with some sort of legacy system 
or component and it supports only a TextMessage.
2) Customers sometimes have auditing/logging facilities in place and they 
are much happier dealing with TextMessages rather than BytesMessages.

There are situations where a TextMessage cannot be used (attachments, 
etc.) so this would have to be done in such a way as to not break that. I 
would certainly understand if the WG decided that this particular feature 
was not appropriate for the spec.  However, if folks think that this is 
important enough to mention in the spec, then at least we have a chance at 
solving it in a common way, which would be good for users.

Proposed Solution:
1) New property: "messageType".     My thought is that we could introduce 
support for an optional JMS URI property, called "SOAPJMS_messageType" 
whose value could be either "text" or "bytes".   If "text" is specified, 
then it would serve as a *hint* to the underlying runtime that it should 
use a TextMessage *if* it is possible to do so in that situation.   The 
vendor runtime would decide this based on the presence of attachments, 
etc.     If it's not possible to use a TextMessage, then a BytesMessage 
would be used instead.     An equivalent "messageType" property could also 
be supported in the WSDL as well, similar to how we support other 
JMS-related properties there (priority, deliveryMode, etc.).

Example of JMS URI property usage:
 
jms:jndi:jms/MyQueue&jndiConnectionFactoryName=jms/MyCF&SOAPJMS_targetService=MyPort&
SOAPJMS_messageType="text"

Example of property in the WSDL:
<wsdl11:binding name="StockQuoteSoapBinding" 
type="tns:StockQuotePortType">
   <wsdl11soap11:binding style="document" transport="
http://schemas.xmlsoap.org/soap/http"/>
   <wsdl11:operation name="GetLastTradePrice">
      ...
   </wsdl11:operation>

   <!-- We would like to use a TextMessage (if possible) for the 
operations
        contained in this binding -->
   <soapjms:messageType>text</soapjms:messageType>

</wsdl11:binding>


Notes: 
1) We might consider the JMS URI property to not be SOAPJMS-specific, in 
which case we should consider adding it to the JMS URI spec.  If that were 
the case, then the property name would simply be "messageType" rather than 
"SOAPJMS_messageType".

2) The "messageType" WSDL property in the example above could appear in 
the same places within a WSDL definition as the other JMS-related 
properties... namely the service, port/endpoint, and binding.

3) The message sending node would decide which message type to use based 
on these hints and the content of the message that will be sent 
(attachments, etc.).       This might seem to be non-deterministic in some 
sense, but for a particular situation, a user will likely know whether 
he's using attachments or not and I can see that having control over the 
message type used by the message sender component would be useful. 

4) As for the message receiving node, we would stipulate in the spec that 
it should (if possible) send a reply message using the same format as the 
original request.   So, in essence, it would use the request message type 
(bytes vs text) as a hint as to what to use for the reply.   If there are 
no attachments involved, then it would use a TextMessage if the request 
message was a TextMessage... otherwise a BytesMessage would be used. So 
this would basically be "respond-in-kind when possible".

Comments?

Phil Adams 
WebSphere Development - Web Services
IBM Austin, TX
email: phil_adams@us.ibm.com
office: (512) 838-6702  (tie-line 678-6702)
mobile: (512) 750-6599