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: Synchronous Messaging Proposal - Some Thoughts


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

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

Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
Fax: 205-250-8057

InsideAgent - Empowering e-commerce solutions

[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