OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-msg] A proposal for the interpretation of different synchronous 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC