Very good points, Steve. I added some
food for thought
Bon apetite
>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
Our research has shown that these later methods, HTTPS
or FTP (provided the FTP process is properly governed by a certificate
process, and data transmitted is encrypted, or if SFTP is employed) are the
safest, most reliable methods for moving the data over the Internet to date.
Also, since the connection is point to point or "server to server"
the transmission is more expediant, and nothing is left behind on the
Internet for potential tampering.
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?
Indeed these problems do persist when it comes to any
form of email. We do test the transmission, and rarely experience failures,
however, it is not so reliable as a direct "server to server"
connection.
In these cases however, it's certainly viable to resend
any failed messages. It's important to keep in mind, however, that these
notifications do not represent any potential breach in security if
compromised, as an actually file of transaction data might.
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.
Here is where clearly, Dick's "Be in Control"
attitude is critical. If one is to rely on the IVAN's ability to perform
reliable expediant deliveries and retreivals, one must rely on the IVAN's
ability to initiate both ends of the transmission (Pushes
and Pulls), rather than depending on the remote VAN's scheduling
process for one or the other leg. Thus, as Dick puts it, "controlling
their own destiny" (or that of their clientele as it
were).
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
------ 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
HTML>
|
