[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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