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

[Martin W Sachs <mwsachs@us.ibm.com>]

Dan,

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.

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.

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.

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.

Regards,
Marty

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

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>