Re: ACTION-30 - ways to support TextMessage

Eric,
I don't understand your statement:

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

To me, the "messageType" property is really no different than something 
like "deliveryMode" or "timeToLive" or "priority" which are all JMS 
message-related properties.   We allow these to be specified in the JMS 
URI via properties, and we go so far as to stipulate that the message 
sending node should strip those properties out of the endpoint URI string 
that is set in the outgoing JMS message (apparently since they would be 
redundant to keep them in there - they're available as JMS message 
properties at that point).     I think that the "messageType" property 
would belong to the same class of JMS message-related properties.   It 
simply indicates what type of JMS message *should* (not must) be used by 
the message sending node.

I suppose the "messageType" property could also appear in a WSDL document 
in the same places that the "priority", "timeToLive", and "deliveryMode" 
properties might appear.

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:
Phil Adams/Austin/IBM@IBMUS
Cc:
"SOAP/JMS (list)" <public-soap-jms@w3.org>, public-soap-jms-request@w3.org
Date:
09/09/2008 10:52 AM
Subject:
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.
>
>
>
>