Indeed, a VAN is not very much like an ISP at
all. Value Added Networks do not simply provide a connection. If this were the
case, they would just be called Networks. There's a "Value Add" for a
reason. VANs provide tracking and auditing of successful vs. failed passages of
data, they check for the syntactical correctness of data, and proper nesting of
envelopes. VANs also provide logistical handling of masses of envelopes on users
behalf. They allow for one point of contact for the trading partner entity,
instead of leaving the logistic nightmare to the user. They provide logs of
results, proprietary processing, archiving and most of all they are private
secure networks. In this world where we utilize (or bastardize) the Internet as
our "VAN" who is to be held accountable when something goes wrong, or
when someone gets their hands on your data? When was the last time your ISP was
able to instantaneously provide you with an error log for an email that
wouldn't go through? Or did you find out three days later?
Our customers say "We don't want to throw
out the baby with the bath water." But most importantly, with the increased
volume of characters that is expected with the implementation of XML, how are
all these companies (especially the small ones) supposed to maintain EC data
portals? How will they manage the trafficking of information? Will they each
have to maintain a server, connected through a high-speed Internet connection in
order to do EC? One can just imagine the horror of the little "Mom and
Pop" sock manufacturers, that do a majority of their business with just a
few large retailers, having to implement an XML high speed Internet EC Portal.
Our experience tells us that to maintain a secure TCP/IP EC portal of any scope
at all, requires millions of dollars. How many companies requiring Electronic
Commerce can afford that? More over, why would they bother when there are
Internet based VAN solutions that cost fractions of pennies on the dollar, and
do provide the same logistical handling and services that EC users have come to
expect?
sorry jgl, couldn't help myself!
Doug
My intent, in comparing
the traditional EDI with Internet EDI was to
highlight the subtle gap
between these two.The gap ofcourse is not that big,
that it cannot be
filled.
What is a VAN after all? It is nothing but an ISP if the gaps
are
filled.Like an old wine in a new
bottle.
Ashwani
>From: Doug Anderson <[EMAIL PROTECTED]>
>To:
[EMAIL PROTECTED]
>Subject:
RE: The need for speed: XML vs. Internet EDI
>Date: Wed, 19 Jul 2000
12:13:00 -0500
>
>Ashwani
>
>Interesting insights,
but I can't say that I agree with some of your
>conclusions on how
internet EDI is different from traditional EDI. The
>internet is
just a another transport mechanism.
>
>1. We
(Kleinschmidt) support any protocol. Therefore the sender
or
>receiver of the data is not tied down to any one means of
communication.
>We
>support TCP/IP if the customer wants
it. With the internet, if the ISP
>goes
>down you are
hosed, unless you have multiple ISP's (like we do). With a
>VAN,
if your ISP goes down you can still use the old "legacy" means
of
>communication like Xmodem, or Zmodem. Most VANs support
multiple
>protocols,
>you would have to check with your
specific VAN to see if they support the
>communication method that you
would like to use.
>
>2. Delay, interesting comment.
We don't delay data here at Kleinschmidt,
>unless the customer would
like us to deliver or pick-up data on a scheduled
>service. And
many do and that is a service we provide.
>
>We have 4 state of
the art Tandems in production with a fifth being
>installed as we
speak. We have two production sites with multiple phone,
>ISP's,
power supplies with different voltages, UPS (battery back-up not
the
>motor carrier), diesel generators etc. so that we have what we
think is the
>highest reliability in the market. Vs. the
internet, depends on the means
>of communication. Communication
over the internet where you get an
>immediate acknowledgment is good
for time sensitive data, but if you have a
>problem who do you
call? Using email can be very sporadic, sometimes
fast,
>sometimes you can get a message back hours later that your
message can't be
>delivered for hours.
>
>Note that my
earlier post to this message board was delayed from
yesterday
>afternoon to this morning, so I reposted. Problem
could be anywhere in the
>chain. A process must be in place with
each trading partner, defining what
>to do if you don't get the
acknowledgement back after sending the data.
>Don't forget that timing
of the acknowledgement's return can be different
>for each trading
partner. And if that process takes place after normal
>business
hours does, your company (and your trading partner and ISP)
have
>someone available to monitor that process 24 x 7? We
monitor each of those
>items (and so do some other
VAN's).
>
>3. Cost of communication. How do you
reach the internet? Do you have
>some
>magical way of
getting the data from your computer to the ISP or do you use
>some
type of communication line? Sounds to me like the cost for
the
>physical communication method is very similar. Don't know
about local or
>not. Here in Illinois businesses have to pay for
local calls like long
>distance calls, but the long distance is
cheaper. On top of that you can
>reach customers (suppliers) via
a VAN that want to use the internet and
>those that don't want to
without having multiple processes running.
>
>4. Basically
correct. You do pay for service. And you generally get
what
>you pay for. How many folks own a car, maybe a Lexus,
Mercedes, or
>something similar with leather seats and power windows,
vs. a Yugo or KIA.
>Both the Yugo and KIA will get you to the same
destination, for a lot less
>money, but is the reliability the
same. What about the service you receive
>when there is a
problem? Your decision on the car, your decision on cost
>vs.
service.
>
>5. I won't specifically comment on this one
since we don't sell software.
>However, we do provide
"in-network" or "outsourced" translation for many
of
>our customers. This is platform independent and saves our
customers money.
>We already are doing XML translations for
customers. Those customers did
>not need to change anything on
their side in order to communicate via XML
>vs.
"traditional" EDI.
>
>6. My personal
opinion. XML is EDI. It is a means of formatting data
>that
>is being transmitted between two something's, where the
something's can be
>applications, people or whatever. It (XML)
has its advantages and
>disadvantages, depending on the
application. XML is certainly more web
>browser friendly, but as
for moving data from application to application
>via
>the
internet I am not sure that it provides all the advantages
sometimes
>touted here.
>
>Doug
>
>Doug
Anderson
>Assistant Vice President Sales Support
>Kleinschmidt
Inc.
>450 Lake Cook Road
>Deerfield, IL
60015
>847-405-7457
>847-458-5234 (home
office)
>847-945-4619 (fax)
>mailto:[EMAIL PROTECTED]
>http://www.kleinschmidt.com
>
>
>-----Original
Message-----
>From: ashwani madan [mailto:[EMAIL PROTECTED]]
>Sent:
Tuesday, July 18, 2000 6:05 AM
>To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject:
Re: The need for speed: XML vs. Internet EDI
>
>
>Hi
Steve,
>
>I agree with discussion group members that XML won't
make much of a
>difference in transmisson time,because XML means just
a syntax/format
>change.Adding information about the data itself (meta
data) anyways flows
>with conventional EDI as well, in terms of
tags/codes.XML is a means to
>provide easy and efficienct data
processing capabilities.
>
>Just an insight, how Internet EDI is
different from conventional EDI is
>summarized as below
:
>
>1.Traditional EDI :-* VAN based. Uses proprietary
protocols.
>Internet EDI :- Internet based. Uses TCP/IP
protocol
>
>2.Traditional EDI :-* Offline - Delay in
delivery
>Internet EDI :- Online - Instant
delivery
>
>3.Traditional EDI :-* Expensive if VAN is not
local.May have invest in
>ISDN,Dialup,Leased Line,etc. to reach the
VAN network
>Internet EDI :- Can be reached through normal Internet
connection.
>
>4.Traditional EDI :-* Billing is generally by
character or transaction.
>Internet EDI :- Flat monthly fee (based on
pipe bandwidth or connect time).
>
>5.Traditional EDI :-* EDI
Softwares are not Platform independent. There has
>to be a different
version for installation on different OS e.g., Unix,
>windows
etc.
>Internet EDI :- Platform
independent
>
>6.Traditional EDI :-* EDIFACT, ANSI X.12,
TRADACOMS, etc are conventional
>EDI standards
>Internet EDI :-
XML is Internet oriented. Other conventional EDI standards
>can be
easily wrapped in
XML.
>
>Ashwani
>
>
>
>
>------
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
------ 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>
|
