OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


> 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
unfortunately I will not be attending the Tokyo meeting (take good notes,

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
can support this behavior without modification (I think). The advantages to

- The protocol remains constant; send normal message (request) and receive
acknowledgement, regardless of processing mode (RPC or messaging). This
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
are possible "something" (tpa perhaps) has to define proper protocol
(in case 1 expect a Normal message, in case 2 expect an Ack message, each
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

my .02

Dick Brooks

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC