ACTION-30 - ways to support TextMessage

In our last phone call, Phil was proposing a way to support TextMessage 
as a possible message format to carry SOAP messages.

I agreed to take an action item to write up all of the possible 
combinations of ways that we discussed (and any others that I could 
think of) so that we could back into a discussion of what the use cases 
might be to speak to any particular solution.

This email does not rehash the arguments for or against the use of 
TextMessage, but rather assumes their utility, and proposes ways that 
the specification can support them.

Strictly speaking, it would be possible (but bloated) to handle 
attachments and MTOM as TextMessages, but since the only solution I can 
think of would involve re-encoding that binary data in base-64, such an 
approach would completely defeat the point of using MTOM or attachments 
in the first place, so I do not assume that this is a realistic approach.

Option 1:
TextMessage supported for inbound requests.  In request/reply MEPs, 
responses echo the type of message received when possible.  That is, 
since the message type can unambiguously be determined by a recipient, 
it can simply process the TextMessage as is.  In a response to a 
TextMessage message, when the message payload does not preclude the use 
of a TextMessage - for example, no attachments or MTOM payload, send a 
TextMessage.

* Limitation: This leaves it to a vendor to specify when a text message 
might be carried, and this information would never be visible in the URI 
or the WSDL (at least not in a standard way)
* Comment: Changing from BytesMessage to TextMessage is very much like 
the HTTP "Content-Encoding", wherein any payload might be compressed.  
No further details needed.

Options 2 & 3
Support an alternate @transport attribute value that indicates 
TextMessage.  In option 2, the indication is that a TextMessage MUST be 
used, and in the third, a TextMessage SHOULD be used whenever possible.  
Currently we use "http://www.w3.org/2008/07/soap/bindings/JMS/" to 
indicate our binding.  We could support an alternate - 
"http://www.w3.org/2008/07/soap/bindings/JMS/text".  Conforming 
implementations must use TextMessage when the alternate binding is 
supported.

* Limitation: Since the @transport attribute encompasses a large set of 
messages, this approach #2 would break over for portTypes and interfaces 
that include a mix of messages that can be TextMessages, and those that 
cannot.  Hence approach #3, which does not require it.  Note, however, 
that "when possible" may involve introspection of XML Schema data to 
discover the use of xmlmime annotations, for example.

Options 4 & 5
Indicate TextMessage in the URI for the service (Phil's proposal).  That 
is, there would be a parameter "messageType" that indicates "text".  As 
with the previous example, there are two variants - that the TextMessage 
is always used, or that it should be used.

* Limitation: Same as with #2 & #3.
* Comment: One benefit here seems to potentially be separate from SOAP - 
the URI would carry this information.  However, since the JMS Message 
already carries the information to the recipient, its value in the URI 
is of minimal use.  Other uses of the JMS URI would still need to 
indicate whether the TextMessage was acceptable in any given circumstance.

Option #6:
Define a specific per-operation annotation that identifies whether a 
TextMessage will be used as part of the input, output, or fault messages 
in an exchange.

* Limitation: WSDL will be far more verbose in the case where 
TextMessage should be applied whenever possible.
* Comment: unambiguous as to when TextMessages will be sent.

Those are the options I can think of.

-Eric.

Received on Tuesday, 9 September 2008 05:25:23 UTC