[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Ack Message Payload??
Nikola I agree that the "Implicit Acknowledgement" is a "VeryImportantPattern" - we absolutely have to support this if we want reliable messaging to be used over synchronous transports between a HTTP client and an HTTP Server - there are too many solutions out there that use this mode of communication for us to say we don't support it. Now, I'd like to alternative definition of what represents an acknowledgement to a message that solves both the implicit and explicit ack requirements. Simply it is ... "An acknowledgement to a message that was previously sent is identified by the receipt of a message that includes a "RefToMessageId" that contains the MessageId of the message that was previously sent." This means that MessageType=Normal or Message Type=Error could both be acknowledgements. You only need a separate message with MessageType=Acknowledgement if you are sending a "one-way" message or an asynchronous message where the "response message" (either, Normal or an Error) will be sent back using a separate session. I don't think we actually need anything else - thoughts. David -----Original Message----- From: Nikola Stojanovic [mailto:email@example.com] Sent: Tuesday, October 31, 2000 6:52 AM To: Ebxml-Transport (E-mail) Cc: firstname.lastname@example.org Subject: Re: Ack Message Payload?? <Chris> David put forth a discussion on implicit ACKs while we were in Dallas. The idea was that a MessageType=Normal *could* be used as both a BP-level response as well as an implicit ACK. </Chris> Some of us discussed this before, and I've expressed my stand that this is a "VeryImportantPattern". We might call it "ImplicitAcknowledgement" Pattern, but just for a short period (see David's post and my response on Multi-hop RM). It looks like it is already in use by POC people for RR lookup. Using "Normal" and "RefToMessageId" (you can use "ConversationId" on top of them if you want) gives us not only a mechanism for "ImplicitAcknowledgement", but also for "AsynchronousRPC" and for "LongCollaboration" Patterns. <Chris> We agreed to defer the discussion to phase II because it was felt that we had our plate full and we couldn't easily get to consensus. </Chris> I hope we are not going to drop the ball on this one. <Chris> Regardless, I think that a BP-level ACK *should* have a payload, even if it is a minimal one like: <status>OK</status> </Chris> I had thought of a possible solution when you might use "Normal" and "ServiceInterface" and "Action" with an empty payload in order to "BusinessAcknowledge", but I am not sure if that should be considered as a kludge or not. Empty Business Payloads ("Normal") that DO Business stuff via "ServiceInterface" and "Action" might not be that bad? <Chris> It SHALL have a MessageType="Normal" and it SHALL have a ServiceInterface and Action appropriate to its purpose at least for the current state of affairs. </Chris> You have my FULL support on this one. Regards, Nikola
Powered by eList eXpress LLC