Electronic Data Interchange: An Overview of EDI Standards for Libraries (1993)

3. SUPPORTING SERVICES FOR EDI

The goal of communication across diverse computing platforms, is central to the development of the standards for "Open Systems Interconnection" developed by the International Standards Organization, and of parallel efforts by the Internet community to develop the TCP/IP set of standards.

The following section will provide an overview of the networking options that can be used to support EDI operations. These options include either the use of products based on the OSI protocol suite, the use of the TCP/IP based Internet or the use of value-added networks or VANs.

3.1 Open Systems Interconnection

The Reference Model tackled the problem of interconnection between computers by dividing it into a number of layers, each of which could be addressed independently from the other layers. Each layer communicates with the equivalent layer in another system by using services provided by the layer below. Each of these layers in turn provides services to the layer above (see Figure 3.1).

Figure 3.1 - The OSI Reference Model (252K)

There are seven of these layers in the Reference Model:

1. The physical layer provides the physical means of sending and receiving data over a communication channel, such as a copper wire or a satellite link. The RS232 standard for serial connectors and pin assignments is an example of a physical layer standard.

2. The data link layer reliably transfers data between two communicating systems. It shapes the data into appropriately sized blocks, or "frames" and detects and possibly corrects errors in transmission. The Ethernet CSMA/CD protocol is an example of a data link layer standard.

3. The network layer relays and routes data amongst multiple communicating systems, both within and between individual networks, to ensure that it correctly and efficiently gets from the sender to its destination. X.25 is an example of a network layer standard.

4. The transport layer provides transparent movement of data between end systems. It shields communicating systems from all the complexity of the lower layers. The OSI transport protocol is the primary transport layer standard.

5. The session layer establishes and manages communication sessions between systems. It permits systems to synchronize their operations, to transfer data and to open and close dialogues. The OSI session protocol is the primary session layer standard.

6. The presentation layer ensures that the information communicated is meaningful to the communicating parties. It provides for the representation of information in a format that is independent of any particular computer system or language. The OSI presentation protocol is the primary presentation layer standard.

7. The application layer is where the actual communication services required by the user are provided to the end user's system. These services include message transfer and delivery, file transfer, transaction processing, remote operations, and directory services. Individual application layer services can and do make use of other application layer services in order to accomplish their tasks.

At each layer, the data required for use by the corresponding layer in the remote system is structured into a "protocol data unit". This is passed to the layer below, where it becomes "user data" in the lower layer's protocol data unit. User data may be broken up into smaller pieces, but is otherwise unexamined and unaltered. Eventually the data is passed to the physical layer as a series of bits, where it is given a physical representation and transferred over a channel to another system and passed up the higher layers. At each layer, relevant information is processed, previously broken up data is recombined, and user data is passed up to the next layer. Eventually the data reaches the application layer, at which point the user is informed of the receipt and nature of the received data and takes appropriate action (Turner, Tallim and Zeeman, 1992).

The user need not be aware of the layered structure of this communication. As far as the user is concerned, their application process is communicating directly with the application process of the other system.

3.1.1 OSI and EDI

In this sense, these standards are similar to the Office Document Architecture (ODA) standard for describing document content and formats. Both standards define a generic means of specifying document structure and contents independent of specific application layer services. Both require the use of an additional supporting service that provides some form of connectivity between communicating partners and specify an abstract syntax for document structure and one or more transfer syntaxes for communicating document structure and contents.

There are two levels of support services needed to allow widespread implementation of EDI. There is a need to specify procedural rules for parties engaging in EDI and to specify communications support at the application layer. One option for providing this communications support is the use of the X.400 electronic messaging protocol.

3.1.2 EDI and Electronic Mail

The advantages of using a store-and-forward system for supporting EDI transactions are:

• It allows the various parties to interact asynchronously. There is no need to schedule "EDI time slots" which facilitates operation over different time zones.

• It does not require that the two parties be able to connect to each other. This allows each to seek the maximum economy in its network communications.

• It provides each party with the possibility of enhanced security and an audit trail. If the store-and-forward network is provided by a value-added service vendor, this vendor can act as a certification agent, ensuring that many of the potential threats, such as possible repudiation of message, are guarded against.

• It allows the implementation of EDI communication as a batch process, with possibly a day's worth of messages being sent and received at cheaper communications periods or when the computer system is otherwise idle.

However, the use of EDI can lead to greater synchronicity, along the lines of "just-in-time" ordering, which relies on the rapid delivery of electronic mail (minutes or hours vs. days or even weeks by regular mail) to the supplier. The rapid processing enabled by computer-to-computer communications, reduces the inventory required, thereby reducing capital investment and warehousing costs.

The first generation of electronic mail systems, however, offer only limited support for EDI messaging. This is because they are based on the premise that a human operator will be using the system. Using electronic mail systems for direct computer-to-computer communication requires the development and maintenance of complex scripts that mimic operator interaction with the system.

3.1.3.1 The X.400 Message Handling Protocols

• there is no need for a direct connection between the parties exchanging messages; both could have a mutual connection to a third, or possibly more remote partner

• there is no need for simultaneous operation by the parties exchanging messages

• messages can be addressed to many parties.

X.400 defines a number of inter-related services provided by "agents". The ultimate user of the messaging service, which may be a human operator or another computer application, interacts with a User Agent (UA) to prepare a message. The User Agent then interacts with a Message Transfer Agent" (MTA) to submit the message to the Message Handling System. Message Transfer Agents interact with each other to transfer the message to its ultimate location. A Message Transfer Agent at the destination interacts with a User Agent to deliver the message. A Message Transfer Agent may also interact with a Message Store (MS) to place the message into short- or long-term storage. A User Agent interacts with a Message Store to retrieve and manage messages.

Interacting Message Transfer Agents comprise the Message Transfer System (MTS). User Agents and Message Stores are outside the Message Transfer System, but within the Message Handling System (MHS). Indirect access to and from other systems, such as the Telex network, is provided by means of "Access Units".

The primary purpose of the Message Transfer System is to convey "messages" from one User Agent to another. Figure 3-2 illustrates how the various components interact with one another in order to deliver messages to one another. A message conveyed by the Message Transfer System is made up of an "envelope" and its "content". The envelope carries information used when transferring the message within the MTS (i.e. between MTAs). The content is the information that the User Agent wishes to have delivered to one or more other User Agents. The Message Transfer System does not examine or modify the content of a message, except possibly to convert it from one "encoded information type" to another.

The Message Transfer Systems can also convey "reports" to users. A report is generated by the MTS and relates the outcome or progress of a message's delivery to one or more potential recipients. A report may be a delivery report or a non-delivery report. The MTS can also provide a distribution list capability. This allows a user to have a message delivered to a group of recipients by naming the group instead of having to enumerate each of the final recipients (Swain, 1990).

Figure 3.2 - The Model of the X.400 Message Handling System (63K)

The interactions between a User Agent, a Message Transfer Agent or a Message Store are defined in the X.400 series.

The defined interactions are:

• submission: a User Agent or Message Store submits a message (both the content and its delivery envelope) to a Message Transfer Agent. Responsibility for the message is passed from the User Agent or Message Store to the Message Transfer Agent.

• delivery: a Message Transfer Agent delivers the message (both the content and its delivery envelope) to a User Agent or Message Store. Responsibility for the message is passed from the Message Transfer Agent to the User Agent or the Message Store.

• transfer: starting at the originator's Message Transfer Agent, each Message Transfer Agent transfers the message to another Message Transfer Agent until the message reaches the recipient's Message Transfer Agent, which then delivers it to the User Agent or Message Store.

The 1984 and 1988 versions of the X.400 standards define a single class of co-operating User Agent, the Interpersonal Messaging (IPM) User Agent. IPM User Agents create messages containing a content specific to the IPM service. This content consists of a heading portion and a body portion, analogous to the structure of an office memo. Figure 3-3 illustrates this structure.

In the Interpersonal Messaging service, a user can request a notification of receipt or non-receipt of a message. These notifications are requested by an originator and are generated as the result of some action by the recipient (e.g. reading the message). In certain cases, the Non-receipt notification will be generated automatically by the recipient's User Agent. This service goes beyond the notification service provided by the Message Transfer Service.

Figure 3.3 - Structure of an X.400 IPM Message (167K)

3.1.3.2 X.435

Like all X.400 messages, an EDI message consists of an "envelope" and its "content". X.435 specifies the structure of the content of a message submitted by and delivered to EDI users. Just as in the Interpersonal Messaging service, the content of an EDI message is divided into a heading portion and a body portion. The heading portion consists of a number of information fields, and the body portion consists of one or more body "parts". One body part, the "primary body part", contains a single EDI interchange (which may be multiple EDI messages, functional groups or transaction sets). Other body parts may contain associated information, such as drawings and explanatory text. As X.435 does not enforce any particular EDI syntax or standard, the primary body part may contain an EDIFACT, ANSI X12, UNTDI or privately defined EDI interchange.

The following lists some of the main features of X.435 (Lyons, 1991).

Forwarding

X.435 provides a forwarding mechanism that allows an EDI user to forward an EDI message to another user. Related to EDI forwarding is the concept of EDI responsibility. Taking EDI responsibility for the message means that the recipient's X.435 software has examined the message and has determined that it can pass the message to the recipient's EDI application. The sender of an EDI message therefore has some certainty as to whether or not a message has been received, and can confidently make further business decisions on the basis of this knowledge.

EDI Notifications

An EDI messaging user can request that a recipient return a notification indicating the status of the EDI message received. EDI notifications provide an additional level of message tracking over that provided by the delivery notification features provided by generic X.400. X.400 delivery notifications tell the sender if and when a message is delivered but it does not indicate whether the contents can be read by the recipient system.

A positive EDI notification tells the sender that the X.435 software has examined the message and has determined that the recipient's EDI application should be able to process it. A negative EDI notification indicates that the EDI message cannot be passed on to the recipient's EDI application. The forwarding EDI notification indicates that the message has been sent to another EDI user.

Enhanced Security

A messaging environment to support business transactions has more stringent security requirements than a general-purpose interpersonal messaging service. Business communication, such as purchase orders, commonly involves entering into legally binding commitments, and is often sensitive to unauthorized disclosure. Businesses must therefore have confidence that their messaging system will reliably and securely deliver their mail. Therefore, in addition to the general security capabilities defined in X.400, security extensions specific to EDI messaging are defined in X.435:

• proof of EDI notification - enables the recipient of an EDI message to create an EDI Notification which may be used by the recipient to authenticate the originator of the notification.

• non-repudiation of the EDI notification - provides the recipient of an EDI notification with proof of its origin and thus protects against any attempt by the originator of the notification to falsely deny sending it.

• proof of content received - enables the originator of an EDI message to verify that the message content received by the recipient was the same as the message content as originated.

• non-repudiation of content originated - provides the recipient of an EDI message with proof that the message content received was the same as the original message content. This protects against any attempt by the originator to falsely deny originating the message content

• non-repudiation of content received - provides the originator of the EDI message with proof that the message content received was the same as the message content originated. This protects against any attempt by the recipient to falsely deny the content of the message received.

Message Store

An EDI User Agent may use features of the Message Store as described in other MHS standards. The Message Store is a mailbox that has database functions allowing the user to list, delete and retrieve messages based on selection criteria. The Message Store was designed for small users who do not want a full-blown, private X.400 network on their computer or a full-blown implementation of X.435 on their computer. In these cases, the Message Store would reside on the user's X.400-based Value-added Network (VAN).

3.1.3.2.1 Implementation

3.1.4 The OSI Directory and EDI

A primary function of the Directory is to permit the use of "user-friendly" names in message handling systems and other application layer services: the message sender supplies the user friendly name and the message handling system uses the Directory to translate this into the formal address required for delivery.

A Directory name consists of values of one or more attributes. A unique identifier in the Directory is also structured in a strongly hierarchical manner, like an X.400 mnemonic O/R address. The advantage of using the Directory, however, is that it permits the use of nicknames, or "aliases", that need not have the formal structure of a Directory "distinguished name". Thus, a previously existing EDI name could be used as an alias for a company's full Directory name. Numerous other naming conventions could also be supported, such as stock exchange abbreviations or registered trademarks.

In order to support the processing of business transactions in an OSI environment, a Directories application is required to allow users to locate the electronic addresses of their partners and store information such as delivery addresses, credit policies and language preferences.

3.1.5 X.25

3.2 Other Networking Options

3.2.1 The Internet

Communications over the Internet are based on the TCP/IP suite of protocols (Transport Control Protocol/Internet Protocol). The TCP/IP protocols are based on a layered approach, in which the lowest layers, the physical and data link layers, are identical to the OSI protocols. The principal differences in layering are at the upper layers, where the functionality of the OSI session and presentation protocols (layer 5 and layer 6) are managed by the communicating applications themselves.

Services available over the Internet include remote log-in, file transfer, and electronic mail. TCP/IP application protocols tend to be less complex and in some ways less functional than their OSI counterparts. The electronic mail protocols, for instance, support only a basic ASCII text character set and permit only rudimentary structuring, whereas X.400, the OSI protocol for message handling, supports a wide range of data in messages and permits structured messages of considerable complexity. However, the Internet community is developing a new message handling protocol known as the MIME (Multipurpose Internet Mail Extensions) protocol that will provide the functionality required to transmit EDI-structured messages over the Internet. MIME will allow mail messages to contain:

• multiple objects in a single message

• text of unlimited length

• character sets other than ASCII

• multi-font messages

• binary or application specific files

• images, audio, video or multi-media messages. (Borenstein, 1993)

As the Internet was initially developed as a publicly-funded research and academic network, commercial use of the Internet was not permitted. However, this situation is currently changing as commercial networks become interconnected with the Internet (Collet, 1993). A number of companies are now providing commercial access to the Internet. Collectively, these commercial networks can be described as the public data Internet or PDI. With no restrictions on their use, the PDI offers corporations and the "general public" access to the Internet. However, as many of the networks to which the PDI has connections have restrictions on their use, the widespread use of the Internet to support EDI transactions is not yet possible. However, using EDI to do business over the Internet was discussed by the Internet Engineering Task Force during their July 1993 meeting in Amsterdam (Lynch, 1993). While no firm decisions regarding EDI and the Internet was reached, it does indicate the direction in which the Internet policy and standards developers are moving.

The Internet does, however, offer the advantages of near universal presence in the academic community, a simple addressing scheme (e.g. ill-EDI@library.AnyU.edu) and easily-parsed message structures. As more commercial organizations obtain Internet connections, its use for EDI-based messaging will likely increase.

3.2.2 Value-Added Networks

• the VAN provides easy connectivity by offering a single access point, rather than multiple accesses to many different trading partners; only a single connection, and destination address, need be processed by the local systems

• only low-level protocols, such as terminal emulation, are normally required, thereby minimizing the effort and/or expense of developing or acquiring appropriate communication software and applications.

• connection is normally provided using a public data network, which has the advantage of a low start-up cost and usage costs proportionate to the amount of data transferred

• the VAN provides facilities for sending and receiving and probably for storing and manipulating mail, obviating the need for these to be implemented locally

• the VAN often provides conversion services of varying complexity, ranging from conversion of internal data formats and structures to standard messages such as X12, to conversion of encoding standards, such as EBCDIC to ASCII and vice versa.

Using the services of a VAN for EDI communication is often appropriate for users that have a low level of networking capability and/or knowledge locally. It does, however have some drawbacks:

• the communication protocols and services are often proprietary

• there is often poor connectivity between different VANs, which reinforces closed user groups.

Much of the current EDI messaging is provided by centralized server systems or value-added networks, often catering to specific industries. They act as EDI forwarders, providing mailboxes, format checking and validation. They also offer translation services, mapping a business's internal data structures into EDIFACT or, more commonly, into X12 segments and data elements (e.g. GEISCO, Telenet). Such services have provided many businesses with their initial experiences in EDI. However, VANs are generally provided over private data networks, which offer little or no connectivity to other remote services.

3.3 Translation Software

In order for a library to use either ANSI X12 or EDIFACT standards, library systems must be able to generate data that can be translated into the appropriate standardized format. As well, the library must own or have access to compatible translation software for taking the data from a proprietary format and converting it into X12 or EDIFACT. In general, it is more practical to use translation software rather than store or output the data in X12 or EDIFACT format because the formats tend to change as each new version is released. The use of translation software means that only the translation software has to adapt to the changes imposed by new versions of the transactions sets. Within business and industry, most existing EDI implementations use translation software to format the data.

The cost of translation software ranges from around $1000 for a microcomputer application to $30,000 or more for a mainframe application (Cline MacKay, 1991). Depending on the volume of transactions. a microcomputer can be used for transmitting X12 data from a mainframe-based system. Also, if a library is associated with a university, corporation or government department, the translation software may be accessible through the organization's computer center, accounting department or other unit associated with the parent institution. As well, library consortia sharing an automated system would only need one translation software package for all participants.