Subject: EDIINT Transports: Support them all!!

From: "Gregory W. Vesper" <[email-masked]>
Date: Sun, 25 Apr 1999 09:58:11 -0800

Folks,

There are three viable EDIINT transports - SMTP, FTP, HTTP - each with their
strengths and weaknesses.

EDIINT products should work equally across all these transports and allow
the customer to choose which transport best complements their business
requirements and network architecture.  There need not be religious debates
over 'better' and 'worse' as each transport has its own set of strengths and
weaknesses.  Let them all flourish, let them all interoperate, and let the
customer choose.  Indeed, this was a critical design principle for the
product I am responsible for - Cyclone Interchange - and it servers our
customers well.

I include for your consideration an html page from our online documentation
outlining the strengths and weaknesses of each EDIINT capable protocol.

Cheers,
-Greg.

Gregory W. Vesper
Development Director, Cyclone Software
t. 602-793-3934 f. 602-607-4996
www.cyclonesoftware.com

-----Original Message-----
From: Bjorn & Lilian Schmid <[email-masked]>
To: Gunther Schadow <[email-masked]>; [email-masked]
<[email-masked]>
Date: Sunday, April 25, 1999 8:41 AM
Subject: Re: We do have a marketing problem ...

>I may be a little naieve, but I too am a little amazed at the resistance to
>smtp delivery and receipting of transaction data.  I am involved in a major
>Health Interconnectivity project here in Australia.  Due to the vast
>distances and relatively poor telecommunications available in many areas,
we
>are not considering anything but smtp as a common means of messaging.  It
is
>ubiqutous, anyone anywhere can have an email address with a minimum of
>equipment and connectivity.
>
>Of course there are time-critical or high-volume requirements which may
only
>be solved by a high capacity intranet or point-to-point connections of some
>sort, but these are usually higher-end application users as well.
>
>I subscribed to EDIINT to be involved in solutions like AS1 propose.
>I hope to see the final release soon.
>Regards,
>Bjorn Schmid
>-----Original Message-----
>From: Gunther Schadow <[email-masked]>
>To: [email-masked] <[email-masked]>; [email-masked]
><[email-masked]>; [email-masked]
><[email-masked]>; [email-masked] <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: Saturday, 24 April 1999 4:07
>Subject: Re: We do have a marketing problem ...
>
>
>>To wrap this up:
>>
>>(A) I am glad that Gary does agree that FTP is definitely *not* the
>>better alternative.
>>
>>(B) I believe it is absolutely wrong to share the following beliefs
>>with the masses:
>>
>> synchronous  = good
>>
>> asynchronous = bad
>>
>>It is not cool to juggle with the terms "synchronous" and
>>"asynchronous" in that way, since it shows that the juggler didn't
>>understand much more than the bare definition of those terms.
>>
>>Both modes of communication have their use cases. It is important to
>>keep that in mind once and for all. For example:
>>
>>
>>EX1:
>>
>>An electronic bidding system: the buyer sends out a multicast message
>>to all the sellers asking for a price and setting a dead line. The
>>sellers respond with tehir quote (that might have been manually
>>determined and approved.)
>>
>>There is little use for synchronous communication in this example.
>>
>>
>>As a system designer, you have to ask yourselves:
>>
>>(1) do I want to be blocked by waiting for the response?
>>
>>(2) do I want to handle errors here?
>>
>>(3) do I need any information of the response message in order
>>    to move on with my job?
>>
>>If the answer is "no" or "probably not", then your best bet is going
>>asynchronous. Let your mail transfer agent take care of the queueing
>>and delivery.  Yes, you have to match your response, but as I showed
>>earlier last year, there is a simple way to match responses as they
>>come in.  This is especially useful if you do not have automatic
>>standard ways of how to correct an error. Resend and timeout are
>>things that any mail transfer agent has built in. So why do you want
>>to reinvent the wheel only to be able to say "ours is synchronous
>>(implying 'better')".  If you alarm and log failures after all retries
>>and timeouts anyway, you are not better off with HTTP. With e-mail you
>>can route and filter your bouncing messages much nicer.
>>
>>And finally, as Carl Hage preaches so often (nobody seems to believe
>>him), you can use SMTP in synchronous mode with one session for both
>>request and response messages.
>>
>>
>>(C) E-mail is not unreliable.  When can we finally sell this message
>>at least on this list?
>>
>>  - e-mail can be run as directly and as synchronously as HTTP
>>
>>  - where e-mail starts relaying, your chances to be able to
>>    use HTTP drop significantly.
>>
>>    If your trading partner sits behind a dialup line and polls his
>>    e-mail with POP, you won't have much success to get through to
>>    him with HTTP either. All the same with firewalls, and non-IP
>>    networks.
>>
>>
>>In short, AS #1 is the more flexible (shall I say powerful) way to
>>go. AS #2 is certainly the more popular way to go.  But one thing is
>>clearly wrong:
>>
>>> I'm sorry but I just don't buy your argument.  HTTP is the only
>>> reasonable way to do high volume EDI over TCP/IP.
>>
>>AS #1 is definitely not unreasonable.
>>
>>regards
>>-Gunther
>>
>>PS: my point in starting this thread in the first place was to collect
>>success reports and journal article that would defend--what I believed
>>then--our common position.  But now I realize that popularity of AS #1
>>has dropped significantly even in this group.
>>
>>Gunther Schadow -----------------------------------
>http://aurora.rg.iupui.edu
>>Regenstrief Institute for Health Care
>>1001 W 10th Street RG5, Indianapolis IN 46202, Phone: (317) 630 7960
>>[email-masked] ---------------------- #include
><usual/disclaimer>
>>