Companies who use EDI to communicate to their Trading Partners have long complained about the cost of using Public Value Added Networks (VANs) to communicate EDI data. They feel that VANs are costly and their do not provide the "bang for the bucks". With this in mind, large EDI users have eyed the Internet as the vehicle to reduce their EDI communications charges. Initially, there was a reluctance to use the Internet as a communications vehicle for sending critical business information due to concerns about reliability and security of data sent over the Internet. With this in mind, the Uniform Code Council (UCC) initiated a program called EDI over the Internet (EDIINT) which goal was to standardize the method to communicate EDI data over the Internet in 1996.
The meetings were facilitated by the UCC and included a number of software vendors and large users of EDI. The intent was to hammer out the communication protocols and the security standards for communicating EDI data over the Internet. The first standard, which emerged in 2000, was the AS1 standard which set out the rules to communicate EDI documents over the Internet using EMAIL (actually SMTP). The second standard, which was completed in 2001, was the AS2 standard which supported communication of EDI data using HTTP (although FTP is not specifically a part of AS2, the implementation of FTP using the AS2 standard seems to be the latest trend in this area).
Although AS1 was the initial standard defined, in practice most large implementations of EDI over the Internet have been using the AS2 standard.
As with EDI, there are two distinct markets for EDI over the Internet. The Hub Market and the Spoke Market. The Hub market is the most significant market as it drives the adoption of the spokes. The following companies have implemented (or will be implementing in the next while):
It is significant that retailing is leading the way in the move to EDI over the Internet but they are not the only ones. Boeing, Kraft Foods and Dole have also bought software to implement this as any user of EDI can dramatically save money by implementing an EDI over the Internet solution with their Trading Partners.
Retailers such as Linens and Things have already eliminated their cost of using Value Added Networks by insisting that suppliers who do not trade with them via the Internet pay for VAN charges for sending and receiving EDI documents. It is expected in the near term that Wal-Mart will announce that all of their worldwide suppliers (approximately 14,000) must trade with them via the Internet by this time next year.
For spokes, the enticement to communicate via the Internet and eliminate VAN charges will be very powerful. It is anticipated that all of the major hubs will use some form of EDI on the Internet within the next two years. Without the ability to send and receive EDI documents using the EDI over the Internet standard, suppliers will be prevented from selling goods to these retailers.
OpenEC® Trade Manager’s product vision is as a powerful Trading Partner Community Management product designed for mid-market companies to manage the electronic transfer of business documents between themselves and their trading community. It uses Business Activity Monitoring (BAM) and Business Process Management (BPM) to provide companies with real-time access to critical business process performance indicators to improve the speed and effectiveness of business operations. It lets a company manage the secure transfer of business documents internally and externally over the Internet, VANs or other specialized TCP/IP networks. “Written 100% in Java,” it can run on any Windows, Unix, or Linux system. Its immediate value proposition is to:
EDI over the Internet (EDIINT) is a Working Group of the Internet Engineering Task Force (IETF). Formed in February of 1996, EDI over the Internet was chartered by the IETF to create a set of secure protocols for conducting highly structured inter-organization exchanges. There are two current specifications, AS1 using SMTP and AS2 using HTTP to transport the data. The initial requirements are the same for both and revolved around RFC1767, which defined the method for packaging the EDI X12, UN/EDIFACT and mutually agreeable transactions sets in a MIME envelope. Several additional requirements were included for obtaining multi-vendor, interoperable service, over and above how the EDI transactions are packaged. These revolve around security issues, such as EDI transaction integrity, privacy, and confirmation of source and destination. Additional requirements that mimic many of the heading fields found in X.435 EDI messages (e.g., Interchange Sender, Interchange Recipient, Interchange Control Reference, Communications Agreement ID, and Syntax Identifier) are also needed to support exchanges by point-to-point, FTP and SMTP protocols. Many believe these heading fields are best described in XML. Standards in these and other areas are necessary to ensure inter-operability between EDI packages over the Internet. Various technologies already exist for these additional features, and the primary requirement is to review and select a common set of components for use by the EDI community when it sends EDI over the Internet. In effect, the effort is to provide EDI over the Internet to reduce EDI user cost while maintaining current functionality.
AS stands for Applicability Statement and uses existing well-known standards in a manner that facilitates product production. EDI over the Internet was never intended to be a new standard; rather, this IETF Working Group chose to combine existing specifications and show how they may be APPLIED together to enable secure reliable EDI transport over the Internet. There have been a very small number of additions to the standards mostly to resolve ambiguities between standards as they were combined (such as the From transport header, which is used differently in different standards). The use of existing standards has facilitated the release of supporting products in many ways, but has also hindered the release of these products in that developers must understand several standards well to ensure compatible, interoperable products. UCC has facilitated this learning and interoperable product release by sponsoring interoperability testing over the last year.
AS2 is an adjustment of AS1 so that it is capable of using HTTP instead of SMTP. It is not a replacement or a new specification as such. AS1 specifies the packaging of the data along with an initial transport mechanism (SMTP). AS2 extends the AS1 specification by adding another transport (HTTP). AS2 also broadens the specification by specifically acknowledging the usefulness of the specifications for alternate data types.
The AS2 specification supports EDI or any other data transmittals over the Internet using HTTP. AS2 is a specification about how to transport data, not how to validate or process data. AS2 specifies the means to connect, deliver, validate and reply to (receipt) data in a secure and reliable way. The data is then dispatched to the appropriate processor based upon its content-type. AS2 makes no specification about how that dispatch or subsequent processing is accomplished. Vendors who sell AS2 compliant software will also provide the correct processing packages to support these functions. AS2 is the means by which these processes connect and transport secure data.
In 1996, the IETF Working Group for EDI over the Internet was formed and initially focused on technologies needed to transfer existing EDI documents between existing EDI Trading Partners without the use of Value Added Networks (VANs) for the domestic and international user. The initial deliverable was a Requirements document (http://www.ietf.org/internet-drafts/draft-ietf-ediint-req-09.txt) detailing the needs of the EDI community. The second deliverable, in August of 1996, was an Applicability Statement (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as1-13.txt), showing how existing standards might be used and extended to give the required functionality. At this time, it was realized that these same processes might be even better utilized over HTTP and could be used for other Business-To-Business transactions as well (the development of the two AS# specifications was actually somewhat in parallel). The AS2 draft specification was first published in December of 1996 (http://www.ietf.org/internet-drafts/draft-ietf-ediint-as2-09.txt). Both draft AS# documents are still being tested and evaluated for RFC status. Interoperability testing was first tried with the AS1 standards in 1997 with follow-on testing conducted every 6-12 months. AS2 Interoperability testing began in the fall of 2000 and has since been repeated. As problems arise or as clarifications are needed, these documents are updated, although no major changes have been made in the last year. Now that the SMIME standards have achieved RFC status, it is time to actively pursue RFC status, first for AS1 and then for AS2.
AS1 and AS2 are DRAFT specifications in the IETF (Internet Engineering Task Force – www.ietf.org) standard's track. Several other standards had to be approved prior to AS1 (all the standards AS1 builds on – such as S/MIME v3). Once AS1 has achieved RFC status, AS2 will be submitted for RFC status as well (since AS2 references AS1). This is all governed by RFC2026. These are Applicability Statements as specified in section 3.2.
The AS1/AS2 standards benefit the user by significantly reducing traditional communications costs associated with EDI. A side benefit has also been the decrease in turn-around time for business transactions using AS1/AS2. With AS1, this centered on the transfer time for e-mail. With AS2, this time has been reduced to nearly instantaneous with direct HTTP transfers (depending upon file size). The cost of implementing AS2 is the cost of a Web server. Most AS2 applications can co-exist with other Web applications (depending upon load and transaction volume). Since ROI is tied to transaction volume or savings per transaction, higher volumes will show higher payback more quickly. In many cases for heavy EDI users, ROI can occur within a month of AS2 implementation.
AS1/AS2 has two security options: 1) Secure MIMEv3 or 2) PGPMIME. AS2 also supports the use of HTTPS (SSL/TLS) for secure channel connections. Documents sent using AS1/AS2 may use any combination of signed and/or encryption using standard PKCS#7 functions in a number of vendor libraries. AS2 testing has used up to 1024bit keys for Public Key encryption, 128bit keys for Symmetric encryption SHA1 and MD5 for hashing and Triple-DES (3DES) for encryption. AS2 will support larger keys and other algorithms as they become readily available. <\p>
If your trading partners are not AS2 compliant or are not connected to an AS2 compliant VAN, then AS2 might not be the best answer. If you do not have a web server, which can be used to host the AS2 software, or your server is not always accessible from the Internet due to your corporate firewall restrictions, then AS2 is not an option (use AS1 instead – most AS2 vendors also offer AS1 products). Most medium to large corporations are ideal candidates for AS2. Small companies may not be as able to deploy AS2 software since they may not have their own web server.
The Uniform Code Council (UCC) in concert with the Drummond Group, Inc. (DGI) sponsors a test program every six to nine months. This program reproduces the customer environment as closely as possible and allows many vendors to participate in a non-competitive, mutually supportive testing process to bring as many vendors as possible into full interoperability compliance. A report is released which shows the tests each vendor was able to perform with the other vendors.
Although the AS1/AS2 specifications were originally developed around EDI, they are not payload specific. This is a transport specification and ANY data may be transmitted using this framework as long as the appropriate MIME content-type is used. In many cases, this may literally be Plain Text.
As discussed above (FAQ#0), AS1/AS2 was developed for EDI data. The AS1 specification, while not ruling out other data, does not specify the data type. AS2 specifically includes XML data and testing, for both AS1 and AS2, have included a variety of data types (X12, EDIFACT, XML, MSword, etc.).
ROI is highly dependant upon transaction volume. For small vendors, AS2 may not be a matter of savings, but rather a way to interact with a larger supply chain. For larger enterprises, AS2 can have a significant ROI. Once AS2 is in place, the only cost to the enterprise is on going support costs (server maintenance, support personnel, etc.).
AS2 can seamlessly and transparently integrate into an existing system infrastructure in the same manner as adding a new VAN in historic EDI software. The details of this assimilation are very vendor dependent. Any of the tested product vendors can assist you in these details but it is a good idea to shop around for the best fit for your environment.
There is no more risk involved with transactions over AS2 then there would be with any form of normal e-Business transactions. If there is any risk with AS2, it is far outweighed by the cost savings implicit in its operation.
All software products have performance issues based upon the implementation design and platform specifications used. AS2 is not a new design. AS2 currently available specifications – all widely used in industry. These same specifications are used throughout the industry in almost all Internet related software.
One of the primary standards used with AS2 is S/MIME. S/MIME is the standard means of enveloping and transporting virtually all eMail on the Internet. Since AS2 is simply another application of S/MIME, there would be no more, or no less, performance for AS2 than for any other S/MIME related application.
There is no performance issue with AS2 above what would be associated with all Internet related products. This does not mean a particular vendor's implementation of AS2 would or would not have a performance issue. For instance, an implementation programmed in BASIC or JAVA might not perform as well as an implementation programmed in Assembler Language or C. However, performance is more than just programming language. Performance is also about Hardware platforms and queue lengths. Performance suffers whenever redundancy or backup is built into the system and increases whenever multiple paths/servers or large network connections are installed. Performance is about whether multiple data transfers may occur on a single connection or does each transfer have the overhead of remaking the network link? Performance, in the case of AS2, is all about implementation details, not about the specification itself. The AS2 specification just uses all the same old stuff in a new way for e-Commerce data transfer.
1-888-SOFTCARE info@softcare.com (604) 983-8083 © 2004-2005 SoftCare EC Solutions