[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: email@example.com [mailto:firstname.lastname@example.org] 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/
Powered by eList eXpress LLC