The AS2 standard defines an envelope for data that enables it to be sent over the Internet using the HTTP protocol. AS2 can handle any kind of document but is ideally suited to the kind of transactions that have traditionally made up the bulk of EDI exchanges. Just as with EDI, you can extract data from internal systems and use a translator to transform it into the appropriate standard before dispatching it. You can then process the data you send and receive in the same way (for example, sending acknowledgement that a message has been received).
Figure 1: “Traditional” B2B Implementation (simplified)
In the above picture depicting a simplified traditional B2B program, only the area within the red oval—the communications gateways—is affected by the AS2 implementation. The areas outlined in green may continue to work in the same way. The limited change required is part of the reason AS2 has been adopted so quickly by many organisations.
There are two key differences between traditional EDI and AS2, however. The first is that AS2 operates only over networks running the TCP/IP protocol—which actually makes it ideal for situations in which you do not have a private network in place with trading partners and want to work through a public network like the Internet. However, it does mean that—as with the introduction of any new standard—you will probably need to continue to support transactions flowing over networks that are not Internet-based, using protocols that are not AS2, for some time to come.
The second difference is that the receiving computer must be connected to the Internet at the time the document is sent. It is like a phone with no answering machine: if you do not answer it, you miss the call. You need to have a server constantly listening for inbound documents and inbound HTTP connections, just as a web server does.
While many people use web browsers to access content on the Internet, very few of us actually run web servers offering content to the general public. Most businesses turn to dedicated service providers to host their websites, taking advantage of the cost benefits of shared infrastructure, the skills offered by the service provider’s team and the higher levels of security which service providers are able to develop as a result of their expertise and ability to spread costs over multiple clients.
Together, these factors mean that if you decide to develop an AS2 capability in-house rather than work through a service provider, both you and your trading partners must use AS2 and both of you must be communicating over TCP/IP-based networks such as the Internet.
One option for implementing AS2 is to outsource your e-commerce connectivity to a service provider. The service provider will typically support all the protocols used by trading partners and will also implement new protocols, such as AS3 or AS4, as they are developed. Your organisation can send all its messages to the service provider using a single protocol (whether that’s AS2, FTP or something else) and leave it up to the service provider to handle the translation needed to deliver it to trading partners using the standards they prefer.
Alternatively, you may choose to use a hybrid approach in which you connect directly via AS2 with those trading partners for whom that make sense and also use AS2 as your connectivity method to a service provider. It will then be up to your service provider to handle connectivity to other kinds of networks and translation to other protocols as needed by the rest of your trading partners. This greatly simplifies your internal operations for several reasons:
- Your company has only a single protocol to manage;
- It enables you to leverage the value-added services of a service provider, including helping to get your trading partners online and providing ongoing support, and;
- It positions you to easily react to constant change that takes place in the IT industry and thus avoid the complexity and management headaches associated with those changes.