RE: Ack Message Payload??

["Burdett, David" <david.burdett@commerceone.com>]

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:nhomest1@twcny.rr.com]
Sent: Tuesday, October 31, 2000 6:52 AM
To: Ebxml-Transport (E-mail)
Cc: ebxml-tp@lists.ebxml.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