Said much better than I could. Thanks Mark
"Mark Malatak" <[EMAIL PROTECTED]> on 07/21/2000 10:23:38 AM
Please respond to "Mark Malatak" <[EMAIL PROTECTED]>
To: "ashwani madan" <[EMAIL PROTECTED]>,
[EMAIL PROTECTED], [EMAIL PROTECTED]
cc: (bcc: Roger Trout/Sterling Commerce)
Subject: Re: The need for speed: XML vs. Internet EDI
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?
Just curious @ www.fciwebnet.com
sorry jgl, couldn't help myself!
-----Original Message-----
From: ashwani madan <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>;
[EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, July 21, 2000 3:03 AM
Subject: RE: The need for speed: XML vs. Internet EDI
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
| Q 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?
Just curious @ www.fciwebnet.com
sorry jgl, couldn't help myself!
------ 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> \��y؆���+ ��"�r����Z��m���� 0���j躚+�I칻 �&ޱ��zf���1�W�� 躙^j���ƨ��j����.n7����n�r��azg��� nV�� ��ب���z����1�W�� 躚0��݊ƨ��� ����\��鞲Ơz��u������+��lzwm���Z0�x&z���h�+-���v+��%y�����r�b���jy ����yؠ���ʋ�zf���]��,N��{ays ��b�.��&�W�z�^~�文��Z�m���� f��b��.�����yؠ����f��Xm |
