Messaging Protocols in IBM Sterling B2B Integrator -

Overview and Comparison

Aparna D Dhenge (aparna.dhenge@in.ibm.com) Kamalakannan R (rkamalakannan@in.ibm.com) Manoj Kumar Goyal (manojgoyal16@in.ibm.com)

Table of Contents:

1. Introduction 2. Who should read this document 3. Protocols

• AS2 • Connect:Direct • HTTP • HTTPs • SFTP • FTP • OFTP2 • Java Messaging Service (JMS)

4. Comparison Chart 5. References

Introduction

IBM Sterling B2B Integrator helps you securely integrate complex B2B processes with your partner communities. It provides a single, flexible B2B gateway that enables your organization to meet a wide range of B2B integration needs. IBM Sterling B2B Integrator can improve business processes beyond enterprise boundaries and increase visibility into and across supply and demand chains.

IBM Sterling B2B Integrator supports multiple communications protocols for File Transfer needs

• AS2 • Connect:Direct • HTTP • HTTPs • SFTP • FTP • OFTP2 • Java Messaging Service (JMS)

These are the user interfaces for File Transfer:

• Mailbox Browser Interface • Sterling File Gateway

Points to consider:

• The decision to select a communication protocol for file transfer depends on the requirements from your trading partner or the internal application or server IBM Sterling B2B Integrator is communicating with.

Example: If the trading partner uses Connect:Direct protocol for file transfer, then you have to implement communication with the trading partner using Connect:Direct protocol in IBM Sterling B2B Integrator.

• In order to implement communication, there are adapters and services in the product that you have to use.

• Certain adapters and services are capable of communicating with several vendor products.

Example: The JMS and JMS 1.1 Adapters and services can be used to communicate with JMS Servers from different vendors like ActiveMQ, JBoss, SonicMQ, Tibco etc.

However adapters like MSMQ adapter are specifically to communicate with Microsoft MSMQ.

• You are not limited to using adapters and services to implement your communication or file transfer needs. You can write your own Java communication program and execute in IBM Sterling B2B Integrator using Java Task Service.

This white paper provides you with the details on the basics of all the communication Protocols which can be configured in IBM Sterling B2B Integrator. This white paper also describes key difference between these protocols and how these protocols can be used in EDI (Electronic Data Interchange).

Who should read this document?

Read this document if you want to understand the different Protocols that can be used with IBM Sterling B2B Integrator and differences among these protocols.

Protocols

The following sections provide details about these messaging protocols, how they work, and their benefits and limitations.

• AS2 • Connect:Direct • HTTP • HTTPs • SFTP • FTP • OFTP2 • Java Messaging Service (JMS)

(1) AS2: Applicability Statement (AS)1 was developed by the IETF (Internet Engineering Task Force) to implement secure and reliable messaging over SMTP and S/MIME. It was the first AS protocol to be developed and uses signing, encryption and MDN conventions. MDN refers to Message Disposition Notifications or the ability to provide “Return Receipts”. As with any AS file transfer, AS1 file transfers typically require both sides of the exchange to trade SSL certificates and specific business partner names before any transfers can take place. The AS1 protocol really did not gain wide acceptance until AS2 was introduced; most people today use AS2 or AS3 instead of AS1.

AS2 (Applicability Standard 2) is an EDI specification intended to ensure the proper level of security for data transmitted over the Internet. Although it was developed specifically for EDI, it can be applied to virtually any type of file, including XML.

AS2 is a business communications standard that provides Secure/Multipurpose Internet Mail Extensions (S/MIME) and uses the Internet to transport data.

AS2 transports data using Hypertext Transfer Protocol (HTTP) or HTTP Secure (HTTP/S).

How AS2 Works:

AS2 addresses security for data transmitted via the HTTP (Hypertext Transfer Protocol) transport protocol (or its more secure version, HTTPS) over the Internet. It does this using encryption and digital signatures, using a format called S/MIME (Secure Multi-Purpose Internet Mail Extension), and the use of receipts called MDNs (Message Disposition Notifications).

One key, called the “Private” key, is used for both decryption and signing messages and should always be protected. A “Public” key, which is used for encryption and verifying the sender's signature, is intended to be shared with your trading partners so they can “encode” messages for you.

MDNs contain information about the delivery status of the message. In this way, MDNs allow for a particular benefit called “non repudiation,” which means the recipient of a message cannot deny having received it.

To configure AS2 Organization and Partner you need to have the following information:

• Certificates • Name and address information • AS2 identifiers • Server names or IP addresses • Server ports • Server URLs (URI) • Agreed on algorithms for signing and encryption • Passwords • MDN Options

Why to use MDN:

The Message Disposition Notification process is initiated by the EDI message sender and is usually concluded once the sender receives the requested MDN.

The following diagram illustrates a typical AS2 transmission that utilizes this process.

Steps in this flow:

1) The sender encrypts the EDI message, attaches its digital signature, and specifies an MDN option. Assume the option amounts to a request for the return receipt.

2) The EDI message is transmitted over the Internet via AS2. 3) Receiver decrypts the message and validates the sender's digital signature.

4) The receiver recognizes the request for an MDN, prepares the MDN, attaches its own digital signature to it, and then sends it back to the original

sender. 5) Finally, the sender receives the MDN, validates the receiver's digital signature, and then closes the connection.

Hence, MDN serves to tell the sender about two things:

1) That the AS2 transmission completed successfully. 2) That the EDI message was received by the intended recipient devoid of any unauthorized modifications.

Advantages:

• A more secure environment in that AS2 uses digital certificates, encryption, and non-repudiation when transporting data. • A reduction in cost in that a Value-Added Network is not needed to transport data to and from businesses. • AS2 is a standard; it eliminates cost of configuring and maintaining different transfer protocols for each trading partner.

• An increase in the number of business transactions completed. Data is transported synchronously (real time) allowing businesses to complete

business transactions more quickly. • Small businesses trading with large business can use AS2 to transmit data.

• Long term benefit in using AS2 is to significantly reduce and in some cases, eliminate the traditional communication costs associated with VANs. A

secondary benefit is in the decreased “turn-around” time for business transactions. Traditional EDI is “batch” processed in that messages are grouped together and sent/received at intervals throughout the day.

Limitations:

You need an expert to look at setting error messages for expired certificates and training the firewall administrator to avoid accidental closures and IP address change.

(2) IBM Sterling Connect:Direct :

Connect:Direct is a point-to-point (peer-to-peer) file transfer solution which optimizes high-volume and secure data exchange within and between enterprises. It manages file transfers between business-critical applications. It is designed to move large volumes of data of any data type (for example text, EDI, binary, digital content, or image) across multiple platforms and disparate file systems to connect to remote offices.

Sterling Connect:Direct eliminates the need for manual intervention in data delivery, improving personnel productivity and the reliability of business processes.

Requirements:

The following versions of Sterling Connect:Direct support interoperability with Sterling B2B Integrator:

Sterling Connect:Direct for z/OS 4.6 or later

Sterling Connect:Direct for Microsoft Windows 4.4 or later

Sterling Connect:Direct for UNIX 3.8 or later

Sterling Connect:Direct for HP NonStop 3.4 or later

Sterling Connect:Direct for i5/OS 3.6

Sterling B2B Integrator versions 4.2 or later support interoperability with Sterling Connect:Direct

Benefits:

Ensuring Reliable File Delivery: Files can be sent using assured delivery through automated scheduling, checkpoint restart, and automatic recovery

or retry. If a file transfer is interrupted Connect:Direct attempts to resume the transfer at a predefined interval for a configured duration of time.

Security: The Sterling Connect:Direct proprietary protocol and user authentication through user proxies allow customer information to remain private

during the file transfer. Featuring security options to control data access, network access, or access to system resources, Sterling Connect:Direct can

interface with operating system and vendor-supplied access control and security software.

Performance: Sterling Connect:Direct can handle demanding file transfer workloads, including high volumes of small files and transmission of large, terabyte size files. Additionally, Sterling Connect:Direct provides optional data compression.

Improving Your Business Processes – Connect:Direct offers automation, scheduling and management capabilities that support 24X7 unattended operations.

Supporting Multiple Platforms and Protocols –The solution runs on every major platform. It supports multiple operating systems (z/OS, OpenVMS, i5/OS, UNIX and Linux, Windows, and HP Nonstop) and network protocols (TCP/IP, SNA, and UDT). Its well defined APIs, SDKs and User Exits make it easy to connect the solution with your back end systems.

The optional implementation of IBM Sterling Connect:Direct Secure Plus gives organizations the ability to use a comprehensive cryptographic solution for strong mutual authentication using X.509 certificates, SSL and TLS data encryption, and data integrity checking.

Limitations:

Need to have broad and deep technical expertise to ensure your Connect:Direct implementation is configured correctly and reliably from servers and networking to remote connectivity, file routing, volume analysis, and security.

(3) HTTP & HTTPs:

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content over a connection with a server. The server responds with a status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity meta information, and possible entity-body content.

Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection between the user agent and the origin server.

There are three common forms of intermediary: proxy, gateway, and tunnel.

A proxy: is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or part of the message, and forwarding the reformatted request toward the server identified by the URI.

A gateway: is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol.

A tunnel: acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.

HTTP Methods

The HTML specifications technically define the difference between GET and POST:

GET means that form data is to be encoded (by a browser) into a URL, it creates a query string of the name-and-value pairs and then appends the query string to the URL of the script on the server that handles the request. While the POST means that the form data is to appear within a message body, it passes the name-and-value pairs in the body of the HTTP request message

HTTP is insecure and is subject to man-in-the-middle and eavesdropping attacks which can let attackers gain access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is secure. It can create a secure channel over an insecure network.

HTTP Server Adapter ■ It provides a URI based configuration for routing data

– The adapter listens on a configured port and can accept simple TCP or secure SSL/TLS connection based on how it is configured.

– The incoming HTTP request is routed to configured BPs or WAR applications based on URI

Procedure

• From the Sterling B2B Integrator Admin Console, select Deployment >Services>Configuration. • On the Services Configuration page, select HTTP Server Adapter from the Search by Service Type. • From the list of search results, enable the SOA SSL Http Server Adapter and click Next.

• Select the System Certificate you want to use. (This certificate must be the same root certificate that is in the trust store on the "IBM Control Center"

(formerly “Sterling Control Center”). • Select a Cipher Strength. • For client authentication, select the CA Certificate that contains the client authentication information. • Save the changes. • To configure the SCCInteropService, select Deployment > Web Services > Manager. • On theS CCInteropService: SOAP Transport Binding Settings page, click Use HTTPs as SOAP transport. • Click Save.

Advantages:

• Can be tied to specific user accounts and require user authentication, can allow anonymous access if desired.

• Transfers with HTTP always also include a set of headers that send meta data (HTTP headers contain info about things such as last modified date, character encoding, server name and version and more).

• HTTP transfers are primarily just one request and one response (for each document) for communication (a client can maintain a single connection to a server and just keep using that for any amount of transfers).

• Can handle demanding file transfer workloads in short period due to concept of pipeline. • HTTP supports resumed transfers in both directions.

Disadvantages:

• Easy target for hackers.

• A problem can occur when the file size is larger than 2GB, but this problem rarely occurs with modern clients and servers on modern operating systems.

(4) SFTP:

SFTP stands for SSH (Secure Shell) File Transfer Protocol and is also known as Secure File Transfer Protocol. It is a communication protocol that provides computer file transfer and access over a reliable data stream to provide secure file transfer capabilities.

SFTP is an interactive file transfer program that uses SSH to transfer files which encrypts both commands and data, preventing passwords and sensitive information from being transmitted as clear text over the network. Default port of SFTP is “22”.

Requirements:

- SFTP client - SFTP server Additional requirement for security and administration: - Host Identity Key - Known Host Key - Remote server IP - Remote Port - Username and password

• SFTP Server Software:

OpenSSH, GlobalSCAPE, IBM Sterling B2B Integrator SFTP Server etc. • SFTP Client Software:

OpenSSH, FileZilla FTP Client, coreFTP, IBM SI SFTP Client etc.

• SFTP Key Generation Software:

Puttygen, IBM SI’s SSH Host Identity Key wizard etc.

The following keys are used to allow an SFTP Client adapter to connect with a remote SFTP server.

Host Identity Key –

Private/Public key pair used to identify the Sterling B2B Integrator SFTP Server adapter to remote clients. Generate this key within Sterling B2B Integrator.

Known Host Key –

A public key used to authenticate remote SFTP servers to Sterling B2B Integrator's SFTP Client adapter. Request this key from your trading partner.

User Identity Key –

Private/Public key pair used to identify Sterling B2B Integrator as a user on a remote server. Generate this key within Sterling B2B Integrator and provide the public part of the key to your trading partner.

Authorized User Key –

A public key used to authenticate remote users to Sterling B2B Integrator SFTP Server adapters. One or more Authorized User keys can be associated with

a user account. Request the key(s) from your trading partner and include the key(s) in their Sterling B2B Integrator user account.

SI implementation of SFTP:

➢ SFTP Client Adapter:

SFTP Client adapter to connect to a trading partner’s SFTP server, for which it makes use of the other services like

SFTP Client Begin Session Adapter

SFTP Client CD service

SFTP Client Put

SFTP Client Get

SFTP Client List

SFTP Client Move

You can: Establish and terminate sessions, identify, navigate, and list the contents of directories. Move files to, from, and within directories and delete files.

➢ SFTP Server Adapter:

SFTP Server adapter is configured in order to allow external SFTP clients to access mailbox

Advantages:

• Only one connection (no need for DATA connection).

• The directory listing is uniform and machine-readable.

• The protocol includes operations for permission and attributes manipulation, file locking and more functionality.

• The connection is always secured due to SSH keys.

Disadvantages:

• The communication is binary and can't be logged "as is" for human reading.

• SSH keys are harder to manage and validate (due to key or certificate expiring).

• The standards define certain things as optional or recommended, which leads to certain compatibility problems between different software titles from different vendors.

• No server-to-server copy and recursive directory removal operations.

• Need expert to maintain SSH key, remote connectivity and security.

(5) FTP:

FTP stands for File Transfer Protocol and is a communication protocol which is used to transfer computer files from one host to another host over a TCP-

based network, such as the internet. FTP is built on a client-server architecture which means one party is the FTP client and the other is the FTP server. The

FTP client connects to the FTP server using the server address and authenticates using a designated username and password.

FTP does not encrypt its traffic. For secure transmission that protects the username and password and encrypts the content, FTP is secured with SSL/TSL and known as FTPS. SFTP (which stands for SSH File Transfer Protocol) is also used but is technologically different.

Requirements:

FTP client

FTP server FTP Server adapter provides support for sending/receiving files using the FTP protocol

• Exposes a Mailbox or an actual (native) file system directory as the FTP file system to the connected user

• Supports a large set of FTP commands (rfc 959)

• Supports secure SSL/TLS connections (FTPS)

• Supports restrictions via Virtual Roots and adapter policies (more on this later)

• Supports User Exits (custom code execution on FTP events)

Advantages:

Provides services for server-to-server file transfer.

SSL/TLS has good authentication mechanisms (X.509 certificate features).

TP and SSL/TLS support is built into many internet communication frameworks.

Disadvantages:

• Requires a secondary DATA channel, which makes it hard to use behind the firewalls.

• Doesn't define a standard for file name character sets (encodings).

• Doesn't have a standard way to get and change the file and directory attributes.

• FTP involves the client sending commands to which the server responds. A single transfer can involve quite a series of commands. This of course

has a negative impact since there's a round-trip delay for each command. Retrieving a single FTP file can easily get up to 10 round-trips.

• FTP alone does not provide encryption. Files are sent as is and the content and FTP usernames and passwords are transmitted in clear text, all of which can be intercepted by someone eavesdropping on a communications link.

(6) OFTP2 :

• OFTP2 Stands for Odette File Transfer Protocol v2.

• OFTP2 protocol is a more secure way to transfer business documents over the Internet.

• OFTP2 can work point-to-point or indirectly via a VAN (Value Added Network). A single OFTP2 entity can make and receive calls, exchanging files in

both directions. This means that OFTP 2 can work in a push or pull mode, as opposed to AS2, which can only work in a push mode.

• OFTP2 is the most prolific protocol inside Europe for the exchange of EDI data, in particular for the automotive industry, and was initially designed

to work over an X.25 network. The historical use of this protocol has been over ISDN networks that are/were popular in Europe, but now this

protocol is migrating to communication over the Internet with the implementation of OFTP2.

• OFTP2 enhances security via encryption methods and uses digital certificates — expanding what OFTP offers. Recent mandates issued by Volkswagen and Volvo are increasing the demand to quickly implement OFTP2.

• OFTP2 provides flawless and secure transmission between organizations which use a wide range of different communication software systems, ensuring that confidential and sensitive information is transmitted quickly and in complete safety.

• OFTP2 was developed with active participation by the majority of key players in the automotive industry, including large IT providers. Companies supporting OFTP2 from the beginning include

Data Transmission flow in OFTP2:

To achieve the high level of security, OFTP2 uses X.509v3 certificates and Certificate Evolution Lists (CRL).

Features:

• Multi-function: The protocol supports the transfer of both engineering data and commercial information (for example: EDI).

• Large file size: Transmitting large volumes of data, such as engineering designs or large EDI interchanges (for example: delivery schedules), is straightforward with OFTP2 which includes file compression and check point restarts as a standard feature.

• Network-independent: OFTP2 works over any IP-based network including the public internet, the foundation of all business-to-business communication.

• Traceability: follow up, receipt and non-repudiation functions across any network allow continuous open communication.

• Low cost solution: OFTP2 is inexpensive to implement and use; it delivers significant cost-savings by providing quick, easy and secure exchange of large volumes of sensitive information.

Advantages:

• File restart • Push / pull operation • Peer-to-peer or indirect communications • File compression • Operates over TCP/IP, X.25/ISDN, native X.25 • Maximum file size of 9PB (Petabytes) • SHA-256 and PFS Security

How Does OFTP2 Work?

The OFTP protocol is aimed at executing and monitoring data exchanges between trading partners. Some of the most useful functions in OFTP are the ability to:

• Establish a direct communication link between trading partners, after initial negotiation.

• Create acknowledgement of receipt

• Restarts file transfers.

• Automatic information exchange without any manual intervention.

• In addition to the above, OFTP2 brings several improvements and new functions:

• Data Compression

• Establishment of trust and facilitation of secure communication over the Internet between trading partners (SSL/TLS, authentication, signing, encryption, etc)

• Handling of very large files (> 500 GB)

• Longer file description

• Availability of additional character sets (for example : Chinese or Japanese)

• OFTP2 is backwards compatible with earlier versions of OFTP for X.25/ISDN connections.

(7) Java Messaging Service (JMS):

The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is part

of the Java Platform, Enterprise Edition, and is defined by a specification developed under the Java Community Process as JSR 914. It is a messaging

standard that allows application components based on the Java 2 Platform, Enterprise Edition (J2EE) to create, send, receive, and read messages. It allows

the communication between different components of a distributed application to be loosely coupled, reliable, and asynchronous.

The JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations.

• Asynchronous. A JMS provider can deliver messages to a client as they arrive; a client does not have to request messages in order to receive them.

• Reliable. The JMS API can ensure that a message is delivered once and only once. Lower levels of reliability are available for applications that can afford to miss messages or to receive duplicate messages.

JMS elements

The following are JMS elements:

JMS provider: An implementation of the JMS interface for a Message Oriented Middleware (MOM). Providers are implemented as either Java JMS implementation or an adapter to a non-Java MOM.

JMS client: An application or process that produces and/or receives messages.

JMS producer/publisher: A JMS client that creates and sends messages.

JMS consumer/subscriber: A JMS client that receives messages.

JMS message: An object that contains the data being transferred between JMS clients.

JMS queue: A staging area that contains messages that have been sent and are waiting to be read. Note that, contrary to what the name queue suggests, messages do not have to be delivered in the order sent. A JMS queue only guarantees that each message is processed only once.

JMS topic: A distribution mechanism for publishing messages that are delivered to multiple subscribers.

Point-to-Point Messaging Domain

A point-to-point (PTP) product or application is built around the concept of message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from the queue(s) established to hold their messages. Queues retain all messages sent to them until the messages are consumed or until the messages expire.

PTP messaging has the following characteristics and is illustrated below

Point-to-Point Messaging

• Each message has only one consumer. • A sender and a receiver of a message have no timing dependencies. The receiver can fetch the message; irrespective of its status

when the client sent the message. • The receiver acknowledges the successful processing of a message.

Use PTP messaging when every message you send must be processed successfully by one consumer.

Publish/Subscribe Messaging Domain

• In a publish/subscribe (pub/sub) product or application, clients address messages to a topic. Publishers and subscribers are generally anonymous and may dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.

• Pub/sub messaging has the following characteristics.

• Each message may have multiple consumers.

• Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.

• The JMS API relaxes this timing dependency to some extent by allowing clients to create durable subscriptions. Durable subscriptions can receive messages sent while the subscribers are not active. Durable subscriptions provide the flexibility and reliability of queues but still allow clients to send messages to many recipients.

• Use pub/sub messaging when each message can be processed by zero, one, or many consumers. Below figure illustrates pub/sub messaging.

Publish/Subscribe Messaging

1) Message Consumption

Messaging products are inherently asynchronous with no fundamental timing dependency between the production and the consumption of a message. However, the JMS Specification uses this term in a more precise sense. Messages can be consumed in two ways:

• Synchronously. A subscriber or a receiver explicitly fetches the message from the destination by calling the receive method. The receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit.

• Asynchronously. A client can register a message listener with a consumer. A message listener is similar to an event listener. Whenever a message arrives at the destination, the JMS provider delivers the message by calling the listener's onMessage method, which acts on the contents of the message.

2) Message Constituents

A JMS message has three parts: a header, properties, and a body. Only the header is required. The following sections describe these parts:

• Message Headers • Message Properties (optional) • Message Bodies (optional)

Message Headers

A JMS message header contains a number of predefined fields that contain values that both clients and providers use to identify and to route messages. The following table lists the JMS message header fields and indicates how their values are set.

Table: How JMS Message Header Field Values Are Set

Header Field Set By

JMSDestination send or publish method

JMSDeliveryMode send or publish method

JMSExpiration send or publish method

JMSPriority send or publish method

JMSMessageID send or publish method

JMSTimestamp send or publish method

JMSCorrelationID Client

JMSReplyTo Client

JMSType Client

JMSRedelivered JMS provider

For example, every message has a unique identifier, which is represented in the header field JMSMessageID. The value of another header field, JMSDestination, represents the queue or the topic to which the message is sent. Other fields include a timestamp and the priority level.

Each header field has associated setter and getter methods, which are documented in the description of the Message interface. Some header fields are intended to be set by the client, but many are set automatically by the send or the publish method, which overrides any client-set values.

Message Properties

You can create and set properties for messages if you need values in addition to those provided by the header fields. You can use properties to provide compatibility with other messaging systems, or you can use them to create message selectors (see Message Selectors).

The JMS API provides some predefined property names that a provider can support.

Message Bodies The JMS API defines five message body formats, also called message types, which allow you to send and to receive data in many different forms and provide compatibility with existing messaging formats. JMS Message Types:

• Text Message • Map Message • Bytes Message • Stream Message • Object Message

Advantages:

• NSAPI/ISAPI modules are written in native C/C++, which is very fast. • The system leverages existing web server software for port, socket, and thread management to improve performance (for example: able to

maintain 50k simultaneous connections). • ISAPI/NSAPI modules are relatively simple and lightweight (read: not very much code). • Can throttle traffic out of database, as connection pool is configurable. • Can maintain many records in memory (O[100k..1m] ] (read: not limited by JVM memory). • Easy to make data access thread safe using mutexes, semaphores, and critical sections. • Uses HTTP, so any client can connect and client/server implementation is decoupled. • Simpler rollout and configuration than JMS servers. • Uses existing database connectivity technologies (ODBC, Oracle DB connectivity, etc). • ODBC is relatively fast (read: it's native). • Asynchronous data collection for Internet traffic surges. • Choice of either periodically writing data to disk in BCP format for bulk insert into database, or single INSERTs and/or groups of inserts over ODBC,

etc (single inserts are O[500/sec] or more ... bulk inserts are O[10k/sec] or more). • Queuing of data is limited by local disk space, not RAM.

Disadvantages:

Custom code means development time.

C++ is generally more difficult to write than Java.

Single point of failure (if a single web server is used).

No reporting/updating of data cached within ISAPI/NSAPI module without custom code.

Messaging between client and server is asynchronous (this is possibly desired).

Messages are not persistent in a relational database server that supports transactions.

Comparison Chart:

References:

• Sterling B2B Integrator

• HTTP and HTTPS protocols in EDI • Secure Data Exchange Protocols • EDI via FTP/VPN, SFTP, FTPS • Preparing communications adapters for use with Sterling File Gateway