Compaq do a certified connector that allows you to do AS1 and AS2 called
CATS (Compaq ASx Transport Service) that runs under NT/2000. You set up your
trading partner's e-mail (AS1) or web server (AS2) address and the
associated certificates and then associated that with a in and out
directory. You can then use FTP or your favorite file transfer protocol to
move EDI, XML or any other kind files to the out directory where CATS will
encrypt, sign and send the files to your partner and any files your trading
partner sends end up in the in directory where you can grab them.
Not as all encompassing as IPNet's solution but allows you to get into
EDIINT without too much hassle. Runs about 10% of the price too depending on
your company's contract discounts with Compaq.
And, yes, I work for Compaq but I sure don't get commission; just think its
a neat idea worth knowing about if your at the receiving end of an 800lb
EDIINT hungry gorilla.
For more info, contact myself or Gordon Albury (the utility's author) at
[EMAIL PROTECTED]
Andy
Andy Brunnock
Senior eBusiness Consultant
COMPAQ Global Services
5310 Harvest Hill Road
Suite 200
Dallas, TX 75230 USA
Phone: +1 972-702-4237
E-mail: [EMAIL PROTECTED]
-----Original Message-----
From: Michael Burbury [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 15, 2001 6:31 PM
To: [EMAIL PROTECTED]
Subject: Re: JB Hunt and EDI to XML (and more) conversion
Hi there all,
I would like to offer some alternate thinking of this item by offering the
NULL and ALTERNATIVE Hypothesis.
The Null Hypothesis:
"Using the Internet to transact business documents is cheaper than using a
VAN."
Of which the Alternate Hypothesis is:
"Using a VAN is cheaper than using the Internet to transact business
documents."
Now, the discussion begins.
Assuming I already use a VAN, $200K can get me ALOT of transactions (about 6
years worth on an average 800lbs gorilla). Remember I am only looking at
the cost associated with the price of the actual transaction, not what it
costs me to build the transaction or to communicate the transaction. If I
use the Internet, I still need to build the transaction and still need to
communicate it. So the cost associated with making and communicating the
transaction will roughly be the same. IE: the software that maps the data
to a transaction and the communications links to move the data to/from
trading partners.
Now, using the Internet, I would need a dedicated communications server that
is capable of delivering the transactions reliably to my trading partners
(using whatever technology). Using a VAN, the dedicated communications
server is provided (your transaction fees). Now if I have my own
communications server, where do I host it? I need to have dual redundant
Internet connections and if my community is large, I will need a load
balance device and several servers clustered together. Where would I host
this? It would be difficult and not cost effective to do this in-house, so
I go to a hosting provider. What are the costs associated with hosting this
with a hosting provider? How do I recover my costs for hosting this
service? Do I charge my trading partners fees to connect to my newly
established service to lower my costs?
My argument here is that when an 800lb gorilla takes this in house to
provide the service, the costs associated with provision of the service
makes them become a VAN or they wear it. If they wear the costs, are those
costs higher or lower than the VAN service (that has dedicated systems that
are shared by several 800lb gorillas so each are only paying a "share" of
the service provision).
Feel free to continue the argument as I'm sure there will be many NULL
supporters and few ALTERNATIVE supporters, but what we are aiming for is to
disprove one of the Hypothesis statements.
Best Regards,
Michael Burbury
GE ecXpress
System Administration
My views are not those of the company I work for and are purely my own views
on this subject. Please do not think that because I work for a VAN, I might
be biased towards the ALTERNATE Hypothesis. I take a passive stance that
states that both Hypothesis are equal in costs and there are no savings
associated with either method.
----- Original Message -----
From: "jwells123" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 15, 2001 9:49 AM
Subject: Re: JB Hunt and EDI to XML (and more) conversion
> Question: does IPNet provide all the traditional VAN services like
> transaction control, store-and-forward/guaranteed message delivery, and
> archiving/auditing?
>
> Also, how is non-repudiation handled without the VAN?
>
> Regarding the article:
>
> "Later, smaller trading partners will be moved onto the network, though
some
> customers want to keep their EDI links in place because they don't want to
> walk away from the managed services a good VAN network can provide,
Mangold
> admitted."
>
> I can't see why companies would want to take on the role of VAN
themselves.
> If the services provided by VANs really can be done much more
inexpensively,
> I'd think the VANs themselves would be doing so to stay competitive.
>
> "Today, integrating with trading partners is a laborious process that
> requires J.B. Hunt developers to write CICS Cobol code and tap an EDI
> translator to move data out of its IBM DB2 back-end databases."
>
> And how does XML make it easier to move data out of an IBM DB2 database?
> That data isn't going to morph into XML on its own.
>
> One other thing I don't understand: why is it supposedly necessary to
> perform application-specific development every time a new trading partner
is
> added? Can't an EDI mapper just map the existing proprietary data format
to
> the EDI format used by the trading partner?
>
> Sorry if these questions are naive, I don't work in this industry but I'm
> trying to deconstruct all the "XML kills EDI" hype.
>
> Thanks!
> Jason
>
> ----- Original Message -----
> From: "Leah Closson" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, August 15, 2001 12:57 PM
> Subject: Re: JB Hunt and EDI to XML (and more) conversion
>
>
> > In a previous position (2 years ago), I had a chance to evaluate IPnet's
> > "solution" and it is, indeed, a rather slick message
> > management/communication package, very flexible and robust, I thought.
> > I didn't take a look at the translation portion, as we weren't going to
> > switch translators, but what I saw was pretty neat (although for budget
> > reasons, not purchased) and was most definitely a VAN replacement, first
> > and foremost, I'd say. It would be nice to get some solid info, because
> > I am sure the business people who read this article will now be
> > expecting even faster monkeys pulled out of ever tighter behinds ;)
> >
> > Just my 2 cents.
> >
> > Leah
>
> =======================================================================
> To contact the list owner: mailto:[EMAIL PROTECTED]
> Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
=======================================================================
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
