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