Re: ACTION-30 - ways to support TextMessage

Eric,
For options 4 & 5 you stated:

>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.

I'm not sure I understand where you're coming from when you say "However, 
since the JMS Message
already carries the information to the recipient, its value in the URI is 
of minimal use."

Adding something like "messageType=text" in the JMS URI would actually be 
used by the message sending node to determine what type of message to be 
sent.     In other words, the user would specify that in the endpoint 
location URI of the request to cause the vendor's client-side runtime to 
send a TextMessage rather than a BytesMessage.    You're correct that it 
would not necessarily be useful to the message receiving node since it can 
already determine the type of the message that it receives via the JMS 
API, but putting the extra property in the JMS URI would certainly be 
useful to the message sending node's vendor runtime...

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




From:
Eric Johnson <eric@tibco.com>
To:
"SOAP/JMS (list)" <public-soap-jms@w3.org>
Date:
09/09/2008 12:25 AM
Subject:
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.