Re: ACTION-30 - ways to support TextMessage

Hi Phil,

Phil Adams wrote:
>
> 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."
I guess my point here is that the URI is configuration that the two ends 
need to share.  In this case, the sharing is spurious, because it is 
only a hint to the sender, for the receiver, the information is redundant.
>
> 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...
There are use-cases in HTTP, I can imagine, where one might wish to 
indicate the Content-Encoding in the URL for the resource being sent or 
retrieved.  However, I observe that HTTP does not standardize the way 
that one would go about doing that.

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

Received on Tuesday, 9 September 2008 15:52:54 UTC