In this information age, the need to share and exchange information between various platforms, locations, and business partners is becoming increasingly important. Electronic data interchange (EDI) technologies have been in use for over a decade, but the flavor and requirements for EDI have evolved beyond the original EDI offerings.

With the current pace expected in today’s e-commerce marketplace, trading partners must exchange transactional information in real time. Consider the situation shown in Figure 1. A customer for Trading Partner A is placing an online order on A’s Web site. The customer must be presented with immediate inventory and pricing information from A’s supplier (Trading Partner B). This can only happen if A’s computer can talk to B’s computer while the customer is waiting for the next page to appear! This requires immediate response.

Getting Down to Basics

Before relating some of the latest technologies for accomplishing electronic data interchange, I’ll focus on the fundamental concepts. The idea is interoperability between two disparate applications. These applications typically reside on separate platforms in different locations; although, they could even be distinct applications on the same physical box. For example, you may want to put a strategy in place for how your native RPG programs will talk to native Java applications. (Because Java runs in a different environment, which permits multi-threaded programs, it is difficult for Java Beans to directly call RPG programs and vice versa.)

In order to get the two applications talking to each other, the ability to perform some form of a Remote Procedure Call (RPC) must be set up between them. There are various standards, middlewares, products, and technologies that can be employed—and they all typically have a few things in common. The RPC method will either operate in a request/response manner or, asynchronously, via message passing. The concept of request/response is similar to calling a program with parameters and receiving parameters back. The program making the request is actually waiting for the response. Message passing, however, operates in a fashion akin to data queues on the AS/400. One program places information on the queue that the program on the other side will ultimately receive.

Daemon-style programs on each end must always be active, checking the queue and initiating appropriate programs.

Digging beyond the fact that some method of RPC is needed reveals three basic questions that must be answered to put a data interchange solution in place:

• How is the information going to travel from point A to point B? Or, what is the transport protocol?

• How is the information going to be formatted or packaged? Or, what is the message format?

• How will your application initiate (or respond to) the “conversation” with the remote application?

What technologies exist to help you accomplish this potentially complex task? Take a look at some definitions of industry standards and emerging technologies in the data interchange arena. An understanding of these fundamental concepts can help you meet your specific business needs and address these essential questions.

Electronic data interchange is a method for exchanging electronic data and documents among trading partners. EDI has been in use for some time, even before the days of widespread Internet use. Standardized EDI exchange formats and rules are used.

Traditional methods for EDI involve engaging the services of a value-added network (VAN). The VAN acts as the intermediary network and provides services for message translation and delivery between the trading partners. EDI translation software would have to be installed at each partner site, and implementation would involve integrating the line of business application with the EDI package so that standard format calls can be made and received.

Typically, the trading partners are in a buyer-supplier type of relationship. In order to do business with large corporations or the government, a supplier may be forced to set up EDI. In recent years, most VAN organizations are offering more flexible network options, including access via the Internet.

XML is a markup language for defining data using tags. It is called extensible markup language because, unlike HTML and other markup languages, XML can be extended via tags defined by the developer. Tags used in a particular XML document would be defined in a document type definition (DTD). Also, XML supports the use of style sheets that can be used by different interfaces to determine how the XML data should appear on a screen or browser. By applying different style sheets to the same document, the XML document can be rendered in different visual interfaces.

XML is becoming a standard message format for all kinds of data interchange, from sending transaction requests between applications to wireless application deployment. For the latter, a specialized version of XML, called Wireless Markup Language (WML) has been defined.

In order to use XML as a message format for data interchange, a common DTD or XML schema would be used by each application receiving or sending information. Receiving applications would need an “XML parser” to strip out the tags and convert the XML message back into data.

EDI

XML

SOAP

Simple Object Access Protocol (SOAP) is a data interchange protocol that was originally defined by Microsoft; however, IBM has since helped to influence its direction and is now a supporter of SOAP. Microsoft, IBM, Sun, and others have submitted SOAP to the World Wide Web Consortium (W3C) for consideration. SOAP uses XML for formatting information and HTTP for transporting the data. It provides a framework for exchanging information in a decentralized, distributed environment.

There are some key advantages to SOAP. Specifically, it uses XML for the message format. XML is quickly becoming the de facto standard within the industry for exchanging information in this manner. Also, because it uses HTTP as the transport mechanism, it is easy for most organizations to support. Firewalls can readily handle SOAP, and most companies have a Web-serving platform already in place that can be contacted via HTTP transactions. The SOAP standard can be used by a wide variety of back-end application architectures and languages.

Common Object Request Broker Architecture (CORBA) is essentially a standard type of middleware that can be used for programs to communicate in a distributed environment. It was developed by Object Management Group (OMG). The protocol for transporting is called Internet Inter-ORB Protocol (IIOP), and the information to be sent is constructed in a format called Common Data Representation (CDR). An important concept is the Object Request Broker (ORB), which is the interface on each platform to facilitate remote object invocation.

Component Object Model/Distributed Component Object Model (COM/DCOM) is another standard for object RPC developed by Microsoft and used heavily with its solutions. It has many similarities to CORBA and some differences. In this case, the format of the information passed between applications is called Network Data Representation (NDR).

Both CORBA and COM have gained a certain amount of industry acceptance, and there are a number of products that use these standards (largely in the NT and UNIX space). However, there has been criticism with regard to their effectiveness over the Internet. While CORBA and COM solutions have been successfully implemented for use among server farms where the same vendor product is implemented on all servers, they are more difficult to implement in a distributed multiorganizational environment with mixed servers and clients, as in a typical Internet data interchange scenario. Implementation over the Internet can sometimes be problematic due to firewalls that reject a non-HTTP protocol request.

Standards Organizations and Consortia

Internet Engineering Task Force (IETF) is an international organization concerned with the “evolution of the Internet architecture and the smooth operation of the Internet” (as described on its site at www.ietf.org).

The W3C “develops inter-operable technologies (specifications, guidelines, software, and tools) to lead the Web to its full potential as a forum for information, commerce, communication, and collective understanding” (as described on its site at www.w3.org).

OMG is “setting vendor-neutral software standards and enabling distributed, enterprise-wide interoperability” at www.omg.org. OMG is “an open-membership, notfor-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications.”

CORBA

COM/DCOM

Related Technologies

MQSeries is a middleware product sold by IBM for communicating between applications on various platforms via message queues.

Applications must be constructed to use the MQSeries APIs. The applications would interact in an asynchronous fashion because the messages are placed in queues so the application on the other end can retrieve and process it whenever it is ready. The sending application does not have to wait for a response before proceeding. FTP is a protocol that operates over TCP/IP for sending and receiving files between various platforms. HTTP is the protocol over which Web clients and servers communicate via a TCP/IP network. HTTP has standard request and response formats.

Sockets level calls can be used to initiate data interchange requests via HTTP.

The Pressure Is On

Many Web initiatives require integration with partner sites or information sharing between multiple platforms. E-commerce data interchange can involve anything from simply sending out a back-end inquiry to UPS so your site can give your customers the latest shipping status of their orders to integrated order processing between two partner sites. Sometimes it’s strictly an internal requirement for which you need to define methods for sending messages and inquiries between different hardware platforms or environments.

The SOAP architecture is an exciting new invention by Microsoft, IBM, and other industry giants. Using the SOAP standard for messaging between applications makes use of two key technologies—XML for the information formatting and HTTP for transporting the information. Many vendors offer solutions that can help you implement your data interchange strategy. Ideally, you will select a method that will facilitate communications with your trading partners and not force them to install foreign software within their environment.

The idea behind all of these technologies is to ease interoperability between applications that may reside on different platforms, possibly in different locations, and even between different organizations.

This advanced age of computing will continue to evolve business processes and produce streamlined supply chain relationships. And the pressure will continue to be on information technology groups to implement these complex environments.

REFERENCES AND RELATED MATERIALS

• “XML Today,” Don Denoncourt, MC, July 1999

• “Cleaning Up the Web with SOAP,” Don Denoncourt, MC, September 2000 (Also available on the Web at www.midrangecomputing.com/mc/article. cfm?titleid=b1499&md=20009)

• “Doing E-business with XML Schemas and SOAP,” Eduardo Ross, MC, September 2000

• Microsoft Web site: www.microsoft.com

• IBM Web site: www.ibm.com

Reseller receives inventory information

and order confirmation upon request

Web customer inquires on product availability and places orders

End Customer

Figure 1: A typical electronic data interchange scenario can be illustrated like this.

Distribution or manufacturing organization (Trading Partner B)

Reseller (Trading Partner A)

Internet