Re: [ebxml-cppa] Re: [ebxml-msg] A proposal for the interpretation ofdifferent sy nchronous reply modes in the CPP/A

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Sat, 27 Oct 2001 21:34:36 -0400
   From: Martin W Sachs <mwsachs@us.ibm.com>

   At the MS level, it is clear that the RM ACK to a message sent reliably
   must be able to be repeated exactly if a duplicate of the first message is
   received.  If there is anything in that ACK that can't be simply
   regenerated in response to a duplicate, the ACK (or at least certain
   information in the ACK) must be persisted in order to be re-sent.

I agree completely.

I hope that it turns out that the ACK can simply be regenerated.  I
currently don't know any reason that it can't.  It would make
implementations faster if they didn't have to persist ACK's.

   At the application level, the MSH is not aware of the difference between
   requests and responses.  However to me it makes sense to include
   non-normative advice that if a message is sent reliably, the
   application-level response should be sent reliably.

When you say that "the MSH is not aware", is that synonymous with
saying that "the ebXML MS protocol layer is not aware"?

   As to your final paragraph, it can't happen.  Once a message is delivered
   reliably, any duplicate sent by the From application would have a new
   message ID and so the duplication (correctly) would not be noticed by the
   MSH.

But Chris said "The response message to any reliably delivered message
MUST be persisted." and " (the response is retrieved from persistent
storage and returned in response to receipt of a duplicate message."
(See below.)  Are you disagreeing?  Or are you saying that the
statement may be true but is outside the scope of the ebXML MS
protocol, and/or outside the scope of responsibilities of the MSH?

   By the way, should the MSG team decide to pursue this, application requests
   and responses can be associated by the MSH using refToMessageId.  However I
   agree that this should not be a concern of the MS protocol.

(I assume you are referring to the MessageHeader/MessageData/RefToMessageId field.)

I think what you're suggesting is that the MS-layer's refToMessageId
field could be made available to callers of the MS-layer; the MS
protocol itself would not interpret or act on the contents of the
field, but would deliver the field to the caller of the MS-layer at
the To Party, and the caller would be free to interpret it.

That's OK as long as the MS-layer isn't using the refToMessageId
element for some other purpose simultaneously.  I'm not sure of the
complete list of facilities in the MS protocol that use this element.
I know we're using it for error messages.  I guess error messages are
sort of as if sent via a special internal "application", so real
applications don't have to worry about colliding with error messages.

   Regards,
   Marty

-- Dan


   *************************************************************************************

   Martin W. Sachs
   IBM T. J. Watson Research Center
   P. O. B. 704
   Yorktown Hts, NY 10598
   914-784-7287;  IBM tie line 863-7287
   Notes address:  Martin W Sachs/Watson/IBM
   Internet address:  mwsachs @ us.ibm.com
   *************************************************************************************



   Dan Weinreb <dlw@exceloncorp.com> on 10/27/2001 03:16:46 PM

   Please respond to Dan Weinreb <dlw@exceloncorp.com>

   To:    chris.ferris@sun.com
   cc:    bruce_pedretti@hp.com, david@drummondgroup.com, arvola@tibco.com,
	  ebxml-msg@lists.oasis-open.org, ebxml-cppa@lists.oasis-open.org
   Subject:    Re: [ebxml-msg] A proposal for the interpretation of different
	  sy   nchronous reply modes in the CPP/A



      Date: Fri, 12 Oct 2001 11:31:58 -0400
      From: Christopher Ferris <chris.ferris@sun.com>

      I think that this is an oversight in the spec. The response message
      to any reliably delivered message MUST be persisted. What it says on
      line 1799+ suggests thsi, but you are correct in that nowhere does it
      say that the response message(s) need to be persisted. They MUST be
      in order for this to function as intended (the response is retrieved
      from persistent storage and returned in response to receipt of a
      duplicate message.

   I'm confused about the extent to which the ebXML MS definition, and
   MSH implementations in general, are supposed to understand the concept
   of "response message".

   The MS Spec currently says:

      Business processes often anticipate responses to messages they
      generate.  The responses may take the form of a simple acknowledgment
      of message receipt by the application that received the message or a
      companion message that reflects action on the original message.  Those
      messages are outside of the requirements defined for the MSH.

   In general, it always seemed to me that the MS protocol is primarily
   about how to deliver a message from hither to yon, perhaps with
   reliability, confidentiality, authentication, etc., but just "a message":
   one message, unidirectionally.

   If, at a higher level, some business-oriented software chose to think
   of one messages as a "response" to some other message, that's it's own
   interpretation.  The MS does have a concept of "conversation", and
   that any two messages might be part of the same conversation or not.
   But it doesn't say anything about relationships between messages where
   one is thought of as a "response" to another.

   However, there are places where the MS spec does talk about responses,
   particularly when MS is talking about "sync" mode.

   In the topic discussed above, the concept of responses also appears.
   Are we saying here that it is part of the responsibility of the MS
   (when doing reliable messaging) that when it receives a message, it
   should not only notice that the incoming message is a duplicate and
   not re-deliver it to the application, but *also* it should find a
   saved copy of a second message, being a message that we sent earlier,
   understand that the second message is a "response" to the first
   message, and retransmit the second message?

   If so, the MS needs to be explicitly aware of the relationship between
   messages that are "requests" and messages that are "responses", and it
   has to know how to recognize which response goes with each request.
   It has to have a model about how messages relate to each other.  Can a
   request ever have zero responses, or multiple responses?  Can it be
   true that message B is a response to message A and message C is a
   response to message B (i.e. B acts as a request and then also acts as
   a response), or must each message be either a request or a response
   but not both?  Are some messages neither requests nor responses?  It
   seems to me that if MS is going to start talking about responses, all
   these questions need to be explicitly addressed.

   Here's another question.  Consider again the scenario that we are an
   MSH receiving a message, and we find that it's a request that we have
   already replied to.  When we transmitted that response, suppose we
   used reliable messaging.  And suppose that the response did get
   delivered by the reliable messaging, and suppose we got an
   Acknowledgement (or a Delivery Receipt or whatever), such that as far
   as "MS reliable messaging" is concerned, it was definitely delivered.
   But if we get the request again, are we saying that we'll send the
   response again, EVEN THOUGH we already delivered it "reliably"?

   -- Dan

   ----------------------------------------------------------------
   To subscribe or unsubscribe from this elist use the subscription
   manager: <http://lists.oasis-open.org/ob/adm.pl>




   ----------------------------------------------------------------
   To subscribe or unsubscribe from this elist use the subscription
   manager: <http://lists.oasis-open.org/ob/adm.pl>