The most impressive point is Point No. 4
Using HTTPS or FTP itself means you are graduating to Internet based EDI.
This is what my contention is , VANs shall have to graduate to Internet
Platform.The core EDI shall remain same, around which "Value Addition" will
be provided by VANs.
VANs will not perish
I reinforce VANs will not perish,they will just mutate.
rgds
Ashwani
Design Architect & Business Analyst
Bharti Telesoft Ltd
[EMAIL PROTECTED]
>From: Steve Bollinger <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: RE: The need for speed: XML vs. Internet EDI
>Date: Wed, 26 Jul 2000 14:38:00 -0700
>
>
> >When automobiles where introduced did people stop using trains? NO!
>
>
>This is a good point, Dick. Especially the train/auto example because the
>auto has been around for a hundred years and the train still has good value
>for some purposes. The shared model vs. in-control model is certainly a
>valid factor and is an excellent point.
>
>I would like to add some balance here (especially after some of the VAN
>bashing I have seen here recently) and point out that there are some other
>factors: pros and cons that have come to light in this thread. here are a
>few pros and cons as I see them and how they affect us:
>
>1. Distribution to TPs (trading partners): this is clearly a VAN "Value
>Added" benefit. where one has dozens and hundreds of TPs, doing a single
>connection is far easier to maintain. Doing your own transport to dozens
>and hundreds of sites requires in-house support and that incurs a cost.
>Where the number of TPs is small (as in our case under a half dozen), this
>is much less an issue.
>
>2. Security: I am finding there can be incompatibilities between differing
>Internet transport products. Also for "homegrown" Internet solutions, this
>requires some knowledge and maintenance again adding to the cost. This can
>be another "Value Added" in favor of the VAN and for many TPs is another
>reason to out-source.
>
>3. Cost: cost accounting is no simple subject and the simplistic " X
>dollars per KB on the VAN vs. zero dollars on the Internet" is really just
>a starting point on computing which one is going to be financially
>beneficial. Points one and two above are some of the other factors to
>consider in the cost issue. The VANs do things that the TP would otherwise
>have to maintain adding to the cost on the other side of the issue.
>Answers here are not at all clear cut.
>
>4. The Email black hole argument: this seems to be a recurring
>anti-Internet argument. I am not sure of the full validity of what I have
>read on both sides, but this does not affect me so much because we won't be
>using an email solution. Rather our solution will likely be a direct HTTPS
>or FTP connection where we know of success or failure immediately and can
>take appropriate action. Again this "taking appropriate action" requires a
>support infrastructure for us that is another valid "Value Add" argument
>for the VAN.
>
>5. Now we come down to the issue most important to my current project
>which is also the title of this thread: "The Need for Speed" I have some
>update info to give that modifies my earlier statement on our speed issues.
> Our VAN can route and deliver EDI messages within seconds if the TP is on
>our VAN.
>
>Yes, the TP still has to have a polling process to periodically pick up,
>but 1. this can be done in very small increments as in every so many
>seconds and 2. as Mark pointed out an electronic notification can be sent
>to trigger mail box polling to the receiving TP. Of course on the other
>side: 1. requires TP change that they may not be agreeable to and I need
>more data on 2. How is this notification sent? If by MIME, then don't we
>have the email problem as above?
>
>Most importantly however is the fact that different TPs use different VANs
>that must interconnect. Now as a general rule our VAN connects data to the
>other VANs every minute or two. This could be an acceptable speed for us
>except for one tiny fact. our VAN can only guarantee us a 2 hour delivery
>time where an interconnect to another VAN in involved. Obviously a VAN can
>guaranttee it's own services, but can't speak for all other VANs combined.
>
>This presents us with a huge problem. To re-iterate our needs we are
>building an XML equivalent to our existing EDI with our Logistics partners
>to support rapid delivery service orders to our customers that now are
>moving into two hour, four hour and soon one hour delivery requirements.
>This is to deliver on our customer service contracts that replace broken
>routers/parts. This is a very high speed need as companies rely heavily on
>24X7 internet services.
>
>Part of that 1, 2 or 4 hours is the message delivery time. we would like
>to consistently have message and functional ack complete under 30 seconds.
>This leaves the max amount of time to the logistics partner to execute the
>delivery. An EDI delivery system of 3 or 4 minutes might still be deemed
>acceptable except for one thing. If all we can guarantee is 2 hours and 4
>minutes (because of the 2 hour VAN interconnect guarantee) then we are
>completely hosed! even if the delivery is still normally 4 minutes, our
>service metrics are at the mercy of the 2 hour guarantee that is outside of
>our control. Even though I agree there are definite "Value Added" benefits
>to VANs, this one thing is a deciding factor that pushes us out of the VAN
>solution for this particular high speed application.
>
>If anyone has additional data that adds to, modifies or contradicts our
>view on this, I would love to hear about it. Nothing we are doing is
>written in stone and we continue to evaluate ideas and options.
>
>Steve
>Steve Bollinger 408-853-8478
>Cisco Systems B2B Service Logistics Pjt
>
>
>
>
>
>
>------ XML/edi Group Discussion List ------
>Homepage = http://www.XMLedi-Group.org
>
>Unsubscribe = send email to: [EMAIL PROTECTED]
>Leave the subject and body of the message blank
>
>Questions/requests: [EMAIL PROTECTED]
>
>To receive only one message per day (digest format)
>send the following message to [EMAIL PROTECTED],
>(leave the subject line blank)
>
>digest xmledi-group your-email-address
>
>To join the XML/edi Group complete the form located at:
>http://www.xmledi-group.org/xmledigroup/mail1.htm
>
>
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com
------ XML/edi Group Discussion List ------
Homepage = http://www.XMLedi-Group.org
Unsubscribe = send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
