Re: Synchronous Messaging Proposal - Some Thoughts

[Prasad Yendluri <pyendluri@webmethods.com>]

Dick,

These requirements seem consistent with the model I proposed. With the
clarification that I just sent to your concern regarding, the ability to support
request/response (RPC like) synchronous exchanges, looks like we captured the
Energy Industry's requirements as you listed below. To summarize again, in this
model a synchronous response or acknowledgment message shall be sent on the
transport level connection. The request and the corresponding acknowledgment and
response messages would be no different from the corresponding ebXML messages in
the asynchronous model, but for any elements that correspond to the synchronous
nature of the exchange. This would mean addition elements in the ebXML Header
(per my proposal #2).

So, taking HTTP as example transport, here is a view of the synchronous
exchanges. Note each HTTP exchange (the POST and the corresponding response)
involves a complete (MIME packaged) ebXML message (see Fig 7-1 page 9, of ebXML
TR&P Message Service Specification version 0.8).

A) Synchronous Ack only.

             -------------------------------------------->
MSH-1           HTTP POST "request message"             MSH-2

            < --------------------------------------------
                      200 OK  "ack  message"

B) Synchronous Response only.

            -------------------------------------------->
 MSH-1           HTTP POST "request message"             MSH-2
             < --------------------------------------------
                   200 OK  "response  message"

Did I miss anything from EI requirements?

Prasad

Dick Brooks wrote:

> 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