RE: The need for speed: XML vs. Internet EDI

[Dick Brooks]

Mark wrote: >Well, in fact, I do have quantifiable examples to illustrate my point. You see we also utilize and provide turnkey FTP packages that handle multiple FTP session and sends of EDI and >other EC data. And indeed, in instances where a user needs to communicate with several trading partners, at several different host addresses, the log on process alone (given the >variety of the quality of the servers hosting the FTP service) can take up to 100 times as long as a simple deposit of a file containing several hundred ISAs in a secure Internet based >VAN. Now, from there, it's up to the quality of the VAN to assure instantaneous delivery. Those that are posting simple FTP servers (like what you're proposing large EDI/XML users >do) are unable to provide instantaneous deliver because they require intermediate processing to take place which grabs and feeds data to interpretors. A higher quality IVAN >centralizes the process, so deposits are in effect, posts to the trading partners mailbox. Also, a "fly by night" IVAN might simply let the data sit there until the trading partner picks it >up. A quality IVAN will send electronic notification to the trading partners systems, which can be utilized as an instantaneous trigger to run a batch process to retrieve that data. These >are things that traditional telephony based VANs can do without tremendous costs. Again, as our customers say: "Don't throw out the baby with the bath water."   Based on the description above I counted at least two logins per interchange, one by the "sender" into your VAN to send data, the second by the "intended recipient" into your VAN to retrieve data. How can two separate logins be faster than a single login by the sender into the intended recipients own system?     In your scenario, I'm assuming the "intended recipient" uses a polling process to check for new messages at your VAN, this polling interval ALONE could be longer than the time it would take a sender to login and send data directly to the intended recipient. Your conclusion that a VAN provides faster delivery than a direct connection are not backed by the evidence you present. There is another assumption in your assertions, in order to receive your supposed efficiency all parties MUST BE ON THE SAME VAN, what about the overhead and cost incurred when multiple VAN's are involved in an interchange? >Still, in order to experience reliable, secure and timely transmissions, the receiver must have, at minimum, an FTP server on stand-by, waiting to receive your  >transmission. You must also have something to manage the outbound and inbound traffic.   I never said anything about FTP, I always recommend HTTP because of it's ability to handle both bulk file exchanges and interactive web forms.  The software that's needed to manage inbound/outbound Internet EDI is relatively low cost, compared to many companies VAN charges. >And so what you propose is that high volume trading partners interact directly, and low volume users utilize intermmediary VANs to gonglomerate data. That's interesting because our  > high volume clients say "For the price, I'd rather pick it up all in one place, not have to maintain a system for managing traffic myself, not have to higher people to maintain it and not  > make my trading partners worry about several different methods of security, transmissions and communications." But you have a valid point here. Perhaps there are users at some > level (approximately $1000 a month user (approximately 2.5 MB worth of EDI)) who could post an FTP server for about $400 dollars a month and save money. Oh wait! I'm wrong. 2.5 > MB of EDI only costs less than $200 bucks on our VAN! That same 2.5 MB could be sent over the Internet, directly, for $0 incremental cost provided a company has an Internet connection, most already do. Also, you're not counting the "FULL COST" to exchange the 2.5 MB of EDI data, both the sender and receiver are charged $200, the real cost to exchange this data is $400 ($200x2).    Again, I never suggested using FTP, that was an assumption on your part - MY suggestion is to use HTTP/Web technology for both bulk EDI and Interactive Web Form based E-Commerce.   All this discussion about cost and efficiency is interesting but candidly another major advantage for companies that establish their own E-Commerce capability is "CONTROL OVER THEIR DESTINY". These companies are free to implement advanced, unique E-Commerce applications without having to "negotiate" with a VAN over pricing and functionality.   VAN's will continue to service companies that believe E-Commerce is not strategic or cannot "cost justify" implementing their own E-Commerce solution.   I'm becoming concerned that this thread may not be of interest to the entire xmledi list, perhaps we should take this discussion off list.   Dick Brooks http://www.8760.com/           Dick Brooks http://www.8760.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