Perfect Integration 7 - information exchange: transportation

[Image courtesy of Ferdinand Reus]

After creating and or choosing a common or generic format to exchange the information, there is one other field to explore: the facilitation of various communication protocols through which this information can be transported

What applies to messages, also applies to transport: a common language is to be advised as "main artery" for all the traffic. Besides that, each application must speak its own language here as well, and use its own infrastructure as much as possible. Adjusting applications for transport protocols can be even harder than doing so for messages: transport protocols are very, very static and rely on worldwide standards. Making your own version of it is highly unappreciated

Transportation of data is, like integration itself, a necessary evil. It doesn’t really matter how information gets from A to B, as long as it stays the same. Information exchange by letter, fax, phone, email, SMS, video etcetera, will always be in different formats, but the general contents will always be the same. It will be influenced by certain boundaries and limitations inherent to each protocol, but it won’t change in essence - fortunately!

The average opening scene of a James Bond movie sets a good example of the infrastructural variations one can encounter: almost all vehicles imaginable are used by Bond while "travelling from A to B" (usually that means escaping death from his pursuers). The same applies to a message that needs to be transported: on the enterprise level there's nearly all transport protocols one could think of, and ideally they should all be supported – within reason

A glance at all possible ways to get information across
The most widespread and easy to use communication protocol is via file systems. Usually, networks and applications within a company are "close enough" to find a mutual place where they can drop off and pick up files, just like one would at or from a post-office.
For intra-company transportation this might suffice, but inter-company information exchange calls for a protocol that can easily connect to and from different operating system 

In the old days, FTP (file transfer protocol) was the easiest and most widespread protocol. It is free, widely available, runs on all platforms, and capable of being a separate layer on top of entire applications, systems, enterprises. It is limited in its commands itself but allows for all the desired transportation methods.
Other common protocols are SMTP (the protocol used for email), and HTTP (the protocol used for web). JMS is quickly gaining grounds because it’s a queuing mechanism, and free. Queuing systems offer a high degree of reliability, with guaranteed delivery and retry-mechanisms built-in

There is a growing need for security in general, with inter-company communication spreading "around the world". Dedicated bilateral communication lines are no longer the default, communication is now largely based on transportation via internet.
AS1 and AS2 are secure applications of SMTP and HTTP, respectively. Both specifications were created by EDI over the Internet (EDIINT), a working group of the Internet Engineering Task Force (IETF) for developing secure and reliable business communications standards.
The added value of AS1, AS2 and AS3 is the fact that they offer so-called “non-repudiation”: on successful physical reception of a file a receipt is sent back in return, through which it is indisputable that the message has been sent and received. These work with certificates on both sides, so all parties can authenticate themselves in a trusted and secure manner

As security is a hot topic when it comes down to communication, guaranteed delivery is one when it comes to transportation.
The basic way to ascertain guaranteed delivery is to receive notifications for each message having been delivered, from the recipient. This way there's always proof that a message has been delivered. When e.g. an order appears to not have made it to the warehouse it saves a lot of time when the sender has a receipt of the actual message sent that contained the order

In the old days proof of delivery was given by keeping log files of messages sent and received, using checksums, etc. Proof of delivery was something that could be requested in exceptional situations, with manual intervention by people. With the use of a.o. queueing systems such mechanisms became built-in, and nowadays guaranteed delivery is something that has moved from being available in exceptions, to becoming part of the rule

Again, on the transportation level: a good diversity in between them all, and a common subset needed in order to be able to share the same means of information exchange. Next up: how to link messaging to transportation