We can help you achieve complete platform independence by integrating disparate systems and easily migrating data between application databases regardless of the format. TIE solutions also enable you to exchange data using virtually any communications protocol:

 

• AS2

 

The AS2 protocol is based on HTTP and SMIME. It was the second AS protocol developed and uses the same signing, encryption and MDN conventions used in the original AS1 protocol. In other words:

 

• Files are encoded as "attachments" in a standardized SMIME message (an AS2 message)

• AS2 messages are always sent using the HTTP or HTTPS protocol (Secure Sockets Layer — also known as SSL — is implied by HTTPS) and usually use the  "POST" method (use of "GET" is rare)
• Messages can be signed, but do not have to be

• Messages can be encrypted, but do not have to be

• Messages may request a Message Disposition Notification [MDN] back if all went well, but do not have to request such a message

• If the original AS2 message requested an MDN... 
•  Upon the receipt of the message and its successful decryption or signature validation (as necessary) a "success" MDN will be sent back to the original sender. This MDN is typically signed but never encrypted (unless temporarily encrypted in transit via HTTPS). 
•  Upon the receipt and successful verification of the signature on the MDN, the original sender will "know" that the recipient got their message (this provides the "Non-repudiation" element of AS2)
•  If there are any problems receiving or interpreting the original AS2 message, a "failed" MDN may be sent back. However, part of the AS2 protocol states that the client must treat a lack of an MDN as a failure as well, so some AS2 receivers will simply not return an MDN in this case.

 

Like any other AS file transfer, AS2 file transfers typically require both sides of the exchange to trade SSL certificates and specific "trading partner" names before any transfers can take place. AS2 trading partner names can usually be any valid phrase.

 

• FTP

 

File Transfer Protocol (FTP) is a standard network protocol for copying a file from one host to another over a TCP/IP-based network. FTP is used with user-based password authentication or with anonymous user access. FTP has no encryption tools meaning all transmissions are in clear text; user names, passwords, FTP commands and transferred files

 

The original FTP specification has many security concerns

 

•    Bounce Attacks
•    Spoof Attacks
•    Brute Force Attacks
•    Sniffing
•    Username Protection
•    Port Stealing

 

Most recent web browsers can retrieve files hosted on FTP servers, although they may not support protocol extensions such as FTPS. When an FTP—rather than HTTP—URL is supplied, the accessible contents of the remote server is presented in a manner similar to that used for other Web content. Fire fox has a full-featured FTP client in the form of an extension called FireFTP

 

HTTP/S

 

HTTP is the foundation of data communication for the World Wide Web. It is a networking protocol for distributed, collaborative, hypermedia information systems.

 

HTTP functions as a request-response protocol in the client-server computing model. In HTTP, a web browser, for example, acts as a client, while an application running on a computer hosting a web site functions as a server. The client submits an HTTP request message to the server. The server, which stores content, or provides resources, such as HTML files and images, or generates such content on the fly, or performs other functions on behalf of the client, returns a response message to the client. A response contains completion status information about the request and may contain any content requested by the client in its message body.

 

HTTP is an Application Layer protocol designed within the framework of the Internet Protocol Suite. The protocol definitions presume a reliable Transport Layer protocol for host-to-host data transfer.[2] The Transmission Control Protocol (TCP) is the dominant protocol in use for this purpose. However, HTTP has found application even with unreliable protocols, such as the User Datagram Protocol (UDP) in methods such as the Simple Service Discovery Protocol (SSDP).

 

HTTP defines nine methods (sometimes referred to as "verbs") indicating the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. HEAD, GET, POST, PUT, DELETE, TRACE, OPTIONS, CONNECT, PATCH.

 

HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests. For example, when a web server is required to customize the content of a web page for a user, the web application may have to track the user's progress from page to page. A common solution is the use of HTTP cookies. Other methods include server side sessions, hidden variables (when the current page is a form), and URI-encoded parameters.

 

There are currently two methods of establishing a secure HTTP connection: the https URI scheme and the HTTP 1.1 Upgrade header, introduced by RFC 2817. Browser support for the Upgrade header is, however, nearly non-existent, so HTTPS is still the dominant method of establishing a secure HTTP connection. Secure HTTP is notated by the prefix https:// instead of http:// on web URIs.

 

FTP/S

 

FTPS (also known as FTP Secure and FTP-SSL) is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and the Secure Sockets Layer (SSL) cryptographic protocols.

 

FTPS should not be confused with the SSH File Transfer Protocol (SFTP), an incompatible secure file transfer subsystem for the Secure Shell (SSH) protocol. It is also different from Secure FTP, the practice of tunneling FTP through an SSH connection.

 

Two separate methods were developed to invoke client security for use with FTP clients: Explicit or Implicit. The explicit method is a legacy compatible implementation where FTPS aware clients can invoke security with an FTPS aware server without breaking overall FTP functionality with non-FTPS aware clients. The implicit method requires that all clients of the FTPS server be aware that SSL is to be used on the session, and thus is incompatible with non-FTPS-aware clients.

 

Much like HTTPS, but unlike SFTP, FTPS servers may provide a public key certificate. These certificates can be created using Unix tools such as OpenSSL's ssl-ca.

 

This certificate should be signed by a certificate authority, or the FTPS client may generate a warning stating that the certificate is not valid.

 

Direct Connect

 

Unlike the VAN, a direct connection allows you to pass the data straight to the receiving party.

 

Types of direct connection include VPN (Virtual Private Network), FTP (File Transfer Protocol), and EDIINT (EDI over the Internet). Usually EDIINT is done in conjunction with AS2 software, which encrypts the data before sending it over the Internet.

 

Async

 

Asynchronous transmission is defined as a transmission that is synchronized by the sending and receiving Data Transmission Equipment (DTE) before each character is sent. Each character has a start and stop bit to indicate beginning and end of each/character. The start and stop bits are the mechanism by which synchronization is established. Typical asynchronous communications accommodated by microcomputers transmitted at a baud rate ranging between 300-4800 bits per second (bps). See ASC X12S/89438 July 1989 draft publication: "EDI Asychronous Guideline / UNSM Purchase Order Message" Asynchronous transmission is defined as a transmission that is synchronized by the sending and receiving Data Transmission Equipment (DTE) before each character is sent. Each character has a start and stop bit to indicate beginning and end of each/character. The start and stop bits are the mechanism by which synchronization is established. Typical asynchronous communications accommodated by microcomputers transmitted at a baud rate ranging between 300-4800 bits per second (bps). See ASC X12S/89438 July 1989 draft publication: "EDI Asychronous Guideline / UNSM Purchase Order Message"

 

Bisync 

 

Binary-synchronous transmission is different from asynchronous in that bit synchronization is established for a much longer duration, usually for the time it takes to transmit several thousand bits. This results in less transmission overhead but requires more complex circuitry. Typical binary synchronous communication is supported by a mainframe or communications front end processor transmitted at a baud rate ranging between 2400-9600 bps. See ASC Xl 2/88035 May 1987 guideline: "Transfer of ANSI Xl 2 Data Using Asynchronous or Binary Synchronous Communication Protocol". Binary-synchronous transmission is different from asynchronous in that bit synchronization is established for a much longer duration, usually for the time it takes to transmit several thousand bits. This results in less transmission overhead but requires more complex circuitry. Typical binary synchronous communication is supported by a mainframe or communications front end processor transmitted at a baud rate ranging between 2400-9600 bps. See ASC Xl 2/88035 May 1987 guideline: "Transfer of ANSI Xl 2 Data Using Asynchronous or Binary Synchronous Communication Protocol".

 

A bit-oriented protocol is independent of any particular code set, and no character codes are reserved for control functions. High Level Data Link control (HDLC) and Advanced Data Communication Control Procedures (ADCCP) are examples of this protocol. The major advantage is in speed and standardization.