RE: Ack Message Payload??

[Marc Breissinger <marcb@webmethods.com>]

Yes, I think that definition is sufficient.  In addition, though, I believe
we need to think about taking it one step further and allow the implicit ack
to be carried in the transport-level response for synchronous transports
like HTTP (a la SOAP), instead of mandating an empty transport level
response for synchronous transports as in the current spec.

marc

p.s. - I am assuming when you said "I do agree," you were agreeing with me
that you would disagree with Rik's comment ;-)

-----Original Message-----
From: Burdett, David [mailto:david.burdett@commerceone.com]
Sent: Tuesday, October 31, 2000 2:47 PM
To: 'Marc Breissinger'; Rik Drummond; dick@8760.com; Jim Hughes
Cc: Nikola Stojanovic; Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: RE: Ack Message Payload??


Marc

I do agree, we must support an RPC like reliable messaging mechanism - do
you think my alternative definition of an ack (see my last email) would meet
this need.

David

-----Original Message-----
From: Marc Breissinger [mailto:marcb@webmethods.com]
Sent: Tuesday, October 31, 2000 11:03 AM
To: Rik Drummond; dick@8760.com; Jim Hughes
Cc: Nikola Stojanovic; Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: RE: Ack Message Payload??


Sorry, Rik.  I don't agree.  I have a hunch David Burdette won't either.
This functionality is not a performance issue, but gets directly to the
heart of ebXML TR&P's ability to support synchronous RPC like business
service invocations.  Reg/Rep and UDDI are simple technical examples of
applications for an RPC mechanisms.  Shipment Status and
Available-to-promise are business examples of prcesses that require this
kind of real time interaction.  It's an (increasingly) important pattern of
interaction that we shouldn't sweep away under the rubric of "performance."

marc

-----Original Message-----
From: Rik Drummond [mailto:rvd2@worldnet.att.net]
Sent: Tuesday, October 31, 2000 12:47 PM
To: dick@8760.com; Jim Hughes
Cc: Nikola Stojanovic; Ebxml-Poc (E-mail); Ebxml-Transport (E-mail)
Subject: RE: Ack Message Payload??


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/