Re: Ack Message Payload??

[NEVE John <john.neve@swift.com>]

Agree as well.  Seems the obvious way to go.  Also a reminder of the need for scenarios.
John

Marc Breissinger wrote:

> 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/

--
This e-mail and any attachments thereto may contain information that is confidential and/or proprietary and is intended for the sole
use of the recipient(s) named above.  It is not intended to create or affect any contractual arrangements between the parties.  If
you have received this e-mail by mistake, please notify the sender and delete it immediately. Thank you for your co-operation.

begin:vcard 
n:Neve;John N.
tel;fax:+32 2 655 30 05
tel;work:+32 2 655 30 87
x-mozilla-html:TRUE
url:www.swift.com
org:S.W.I.F.T. s.c.;Marketing- Standards
adr:;;avenue Adele 1;La Hulpe;;B1310;Belgium
version:2.1
email;internet:john.neve@swift.com
title:Systems architect
fn:John N. Neve
end:vcard