Re: ACTION-30 - ways to support TextMessage

Hi Phil,

Phil Adams wrote:
>
> 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 take your point.  I've never been too big a fan of the other 
properties being a part of the URI, and I suppose that came through here.
>
> 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.
Yes.  I think there is a different character to "messageType" though, in 
that nothing about it will affect the quality of service that you get 
from the message exchange, whereas the other settings might.

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

Received on Friday, 12 September 2008 19:08:00 UTC