[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Synchronous Messaging Proposal - Some Thoughts
Prasad, Here is a "use case" and set of requirements for synchronous processing behavior from the Energy Industry. For the past four years the US Energy industry has relied on a HTTP based B2B transport mechanism that requires synchronous acknowledgement receipts. The protocol is initiated when an "MSH" packages an encrypted/signed "business payload" in a multipart/form-data MIME envelope that is sent to a trading partners "designated site URL" using HTTP POST. The receiving server is responsible for sending an acknowledgement receipt synchronously to the sender. The acknowledgement receipt contains the date/time of issue, issuing host name (FQDN), a unique transaction ID and a status. The status can indicate a positive or negative acknowledgement. Acknowledgement receipts are sent on the same socket used to send the "business payload", along with an HTTP 200 status response (usually within 2 seconds of receiving the last octet of the data). Acknowledgements must be delivered after validating the metadata (to,from, etc.) associated with the "business payload", but before any processing of the "business payload" (e.g. decryption, verification, translation, etc.). Acknowledgement receipts are not acknowledged! EDIINT AS2 (ref: http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-07.txt ), which is the standard used by the US Natural Gas industry, provides the facilities for implementers and profile builders to define their own acknowledgement receipts. Acknowledgement receipts have a defined format, content and semantics, for example AS2 refers to a GISB-Acknowledgement-Receipt that defines content, structure and semantics. Senders can request a particular type of acknowledgement receipt as part of the metadata associated with a "business payload". Senders can also request that acknowledgement receipts be signed by the receiver, for non-repudiation purposes. Senders can tell the receiver (via the message metadata) what type of hashing algorithm and digital signature standard to use when signing an acknowledgement receipt. Different types of acknowledgement receipts can be used during RPC or messaging interactions. For example an RPC service such as a "stock quote server" might provide a "stock-quote-receipt" which contains a "stock price". The requester would send a "business payload" containing a stock symbol which the stock quote server would respond to with a "stock-quote-receipt". Dick Brooks Group 8760 110 12th Street North Birmingham, AL 35203 dick@8760.com 205-250-8053 Fax: 205-250-8057 http://www.8760.com/ InsideAgent - Empowering e-commerce solutions
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC