RE: Ack Message Payload??

[Rik Drummond <rvd2@worldnet.att.net>]

an ack being used to return a business level response is not a functionality
issue, but is a performance issue. the return of information from the
business applications and be done just fine under the current spec. i always
am reluctant to worry too much about performance issues, especially one
which is in my view minor, in the functional definitions in the early stages
because it reduces the focus on the required functionality and moves it to
performance issues which are usually addressed in a version two of a product
or spec.... so i would like to table this thread.... (i mean table in the
USA sense and not the English sense) rik

-----Original Message-----
From: dick@8760.com [mailto:dick@8760.com]
Sent: Tuesday, October 31, 2000 8:12 AM
To: Jim Hughes
Cc: Nikola Stojanovic; Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: Re: Ack Message Payload??


Jim,

> With respect to MS ACKs sent for Reliable Messaging, the end of MS spec
> 0.21d section 7.11 details the values used... If we agree that an ACK is
> also used to convey BP-level information, then I agree we need to talk
> about this in Tokyo...

It is the piggybacked ACK/BP (RPC-like)  scenario I'm interested in
discussing,
unfortunately I will not be attending the Tokyo meeting (take good notes,
please).

To help kick this discussion off; I believe an ACK should be allowed to,
optionally, contain a piggybacked business level response (e.g.
request_stock_quote <----> response_stock_price). The ebXML envelope and
headers
can support this behavior without modification (I think). The advantages to
this
approach:

- The protocol remains constant; send normal message (request) and receive
an
acknowledgement, regardless of processing mode (RPC or messaging). This
makes
for a simpler state machine.

- Protocol violations are easier to detect because there is only one type of
acknowledgement message (MessageType=Acknowledgement). When two different
ack's
are possible "something" (tpa perhaps) has to define proper protocol
behavior
(in case 1 expect a Normal message, in case 2 expect an Ack message, each
case
has to be defined accordingly) .

- The MessageType=Normal has a single set of semantics (essentially it's
used to
initiate an exchange) and is never used for "acknowledgement" purposes.

- Acknowledgements become a bit more "functional", the payload can contain a
piggybacked business level "response", this would benefit RegRep and other
services that may use RPC like behavior
(e.g. request_tpp <------> response_tpp_document in a
MessageType="Acknowledgement").

my .02

Dick Brooks
http://www.8760.com/