If we consider the poll presented on this article, 33% think SOA's objective is to integrate legacy applications. And how did we do that for the last 30 years? File transfer. It is and it will always be a way of integrating legacy applications. Or, doing SOA, if you are one of those 33%. But, FTP (or SFTP or FTP over SSL; does not matter) or HTTP aren't protocols designed by nature for B2B transactions. They were designed for general-purpose data exchange. And that's why there exist OFTP.

The Odette International organization has come with OFTP long time ago, but the protocol doesn't hit even 5% of awareness if you consider the whole developer's community. It is often miscompared to FTP, due to the "ftp" suffix. Actually, it is better compared to HTTP where it transfer files with no concern of where or how that file is going to be stored. But due to the nature of HTTP, and how files can get big specially on B2B transactions, ain't might be the best approach to do "FT-OA" over WebServices, XML or RPC. Detailed aspects of the protocol can be found at the specification - RFC 5024 - or on the Accord Odette webpage.

Now, if you take a deep look at OFTP vendors, you will mostly find proprietary solutions. AxWay and SeeBurger are one of them. It is possible to find some *nix software that might be open source, but most aren't end-user or production-ready products. Ironically, there wasn't a single Open Source Java library or tool that implemented this protocol, until now.

Right now, there are only two Java alternatives that fully implement OFTP 2. One is the mendelson OFTP2 which is a Java desktop client. The other one is a Java library that is part of a project aimed at Managed File Transfer solutions.

The Accord MFT suite is an Open Source project being developed to bring File Transfer solutions for B2B transactions. And as one of its core components, it is the Accord Odette. The library allows developers and companies to embed OFTP2 support within their own products, or build their own client/server. The Accord project is developed, maintained and supported by Neociclo.

Considering how big are the companies already in this market, makes sense that both alternatives are GPLv3. But obviously, both offer commercial license if you consider the support subscription.

OFTP has been around as long as EDI, it is most common across Europe where a lot of companies run their own OFTP servers, often using X25 as the network layer beneath it. I am not convinced on its suitability for large file transfers though, having worked with the original OFTP since 1994 often over dialup modems.

The key to SOA and B2B is leave and layer, working with existing protocols like OFTP rather than trying to rebrand them as something new. OFTP has been known for a long time for reliable transmission and handling of business critical data. I personally prefer to use adapters to handle the different protocols while retaining a core set of internal integration protocols and standards.

How you can compare OFTP to HTTP is beyond me quite frankly, HTTP is a stateless protocol, whereas OFTP has a set of acknowledgements and mechanisms for ensuring complete files are transferred and acknowledged. It would be better compared to something like AS/2, since that is a closer match in terms of use case.

One of the advantages of Accord OFTP2 library is that it enables any Java software to understand OFTP protocol and then exchange data with it. This is not a replacement for SOA as we know it (WebServices, SOAP, RPC, whatever you use). But in fact, is a plus. It can be transacted and still support transfer resume. And of course connect to any other OFTP2 implementation, as this is a protocol, not a business-layer specification (RESTful anyone?)

The Accord OFTP2 now has an Apache Camel component to support OFTP2 file transfers within Camel routes. Which brings us to the next question: will we leverage the usage of Enterprise Integration Patterns on B2B file transfer scenarios?