Re: EDI over http

["Carl Hage" <carl@xxxxxxxxx>]

> From:          "Susan P Croley"<spcroley@xxxxxxxxxxxxxxx>

> I am the current Gas Industry Standards Board (GISB) Future Technology Task
> Force (FTTF) Chair. ...  This may, at least,
> provide you some insight as to why we chose HTTP.

> There were several business objectives:
> 1)  Provide delivery of EDI documents to your trading partner in a
> time-critical manner ...  Secondly, an 855 Quick
> Response is required to be returned by the pipeline to the sender of the
> 850 Nomination within the next quarter of an hour.
> It was determined by
> the business representatives in GISB that the sender should not have to
> return to the trading partner's site to look up the response and that
> having fully-automated communication of EDI that was integrated with the
> back-end applications was preferred.

(i.e. both TPs must integrate HTTP servers & back-ends.)

> 2)  Provide secured communication of EDI documents with non-repudiation.
> Basic authentication is implemented at each trading partners Web server.

Note that SSL-HTTP does not provide non-repudiation, only 
authentication. The encryption and authentication come for free 
though.

> Also, EDI documents are encrypted before transmission with digital
> signatures.
> 3)  Speed of transmission between trading partners was vital.
> 4)  The size of EDI documents transmitted should not be limited.

> we ruled out
> SMTP based on the problems Derin noted below, in addition to the business
> requirements stated above.

These problems do not apply with non-gatewayed SMTP, i.e. both TPs 
run dedicated SMTP servers-- same as the connection type required by 
HTTP. The SMTP processing would also work with dialup connections 
which polled a POP3 or SMTP relay every 5 minutes, whereas HTTP would 
not work at all.

> To handle exception errors when either the
> trading partner site cannot be reached or there is a rejection by the TP
> site of your transmission, the posting program or "batch browser" records
> the problem and retries three times (set by a business standard) if
> successful transmission is not yet made.  Implementations of this model
> usually include paging or some other automated notification by the
> application for that EDI transmission when it fails.

You can also do this with SMTP.

Unfortunately, when many people compare SMTP and HTTP, they discuss 
aspects of general purpose email vs HTTP, which includes store-and 
forward, gateways, routing through non TCP/IP nets, etc. SMTP itself 
is the same nature as HTTP except the syntax is different, and HTTP 
uses Content-Length instead of the SMTP EOF line.

The advantage of using SMTP is that it is compatible with gatewayed, 
etc. TPs. I'm posting here because I would like people to implement 
appropriate SMTP instead of implementing another protocol or using 
bug-prone email.
--------------------------------------------------------------------------
Carl Hage                                              C. Hage Associates
<mailto:carl@xxxxxxxxx> Voice/Fax: 1-408-244-8410      1180 Reed Ave #51
<http://www.chage.com/chage/>                          Sunnyvale, CA 94086