[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] Re: [ebxml-msg] A proposal for the interpretation ofdifferent 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC