Question to Todd
It really depends on what competencies you have in house and what “value added” services you require. Since your question only seems to include the actual transport of the data, then I will assume you are looking at plain VAN Mailboxing vs. AS2. The VAN as a message broker: With a VAN you set up a single communications channel to the VAN for uploading and downloading your data. All the routing both to other trading partners on the same VAN and to others over Interconnects are handled for you by the VAN. Additionally, you would likely need a VAN that can also hand AS2 on your behalf since these days there are a number of major trading partners that only have AS2 connectivity. Every communication channel with your trading partners is handled by someone else, just like your phone service and your Internet service. You pay for your connection and have the expectation that your provider, the VAN will respond to your needs and issues since you are paying them. In practice, the VANs never cooperated very well with each other. There is no shared routing table, no concept of DNS and no automation or standard for migrations. It mostly works, but not nearly as well as it could. This lack of cooperation and standardization contributes to the high cost of VAN services. A modernized VAN architecture could greatly reduce the costs of delivering the services while maintaining profit margins. AS2 requires more in-sourcing: With AS2 you become the message broker and the communications expert. You have to manage every one of your trading partner communications channels, make certificate changes whenever they dictate and deal with any outages, incompatibilities, etc. You manage your own routing tables in order to tell the AS2 system where to send each interchange. Depending on the AS2 software license you may have to keep paying for more trading partner licenses as you expand in addition to annual support agreements. There are implementation issues, test configurations, production configurations and various data gymnastics that must be performed in order to get your data to route to the right AS2 configuration. Every time I think I’ve seen it all, someone creates something new and very special. There are also firewall issues. For whatever reason, the writers of the AS2 RFC did not see a need to specify a commonly used port, so it seems that ever implementation of AS2 is set up on a different port. Depending on your firewall administrator, you may be in for a number of “discussions.” There is no central AS2 directory service, so you will need to manual enter and configure every single one of your trading partner profiles and manually update them as they change. Changes tend to be hard cutovers, so be prepared to show up at any hour on any day of the week to change your system exactly the same time your trading partner changes theirs. For each organization there is this magic number of AS2 trading partners where the system becomes a burden. For some it may be 10, for others it may be 50, 100 and certainly by 500 AS2 trading partners, this has become a full time support position that must be monitored 24x7x365. While I think that AS2 is actually a pretty nifty communications protocol with encryption, digital signatures, and delivery notices (MDNs), I think the current options for software are only adequate. A global registry for AS2 configuration information, along with an API, that software packages could use to automatically update trading partner configurations would go a long way to making AS2 a vastly superior choice for B2B communications than it is today. With all this said, I would think that any company that is handling its own EDI mapping and translation would tend to run its largest EDI trading partners over AS2 and then outsource to a VAN to handle the smaller trading partners and those not AS2-enabled, getting the best of both worlds…until something better comes along.