EDI Through A Distributed Information Systems Approach
Nabil R. Adam Igg Adiwijaya Vijay Atluri
Center for Information Management,
Integration and Connectivity (CIMIC)
MS/CIS Department, Rutgers University
180 University Ave, Newark, NJ 07102
fadam,atluri,gusadig@adam.rutgers.edu
Abstract
The model of Electronic Commerce (EC) envisions
the ability to send electronically large quantities of
business transactions to a large number of sometimes
anonymous parties. The EDI standards (ANSI X12
and EDIFACT) provide a framework for formatting a
given EDI message, called an EDI transaction. Al-
though the EDI paradigm provides an obvious im-
provement over the paper world, it suers from sev-
eral problems; a major one being lack of
exibility. deliver an EDI message: mapping, extraction, trans-
Introducing a new EDI transaction, or making a sim-
ple change to an existing transaction is complex, te-
Yelena Yesha
Department of Computer Science
University of Maryland and
Baltimore County
Baltimore, MD 21228
yeyesha@cs.umbc.edu
ploying translation software. Exchanging documents
electronically has been proven to be cost eective in
terms of shortening lead times and reducing labor
and document handling costs as well as error reduc-
tion [13, 7, 9]. This is especially true in cases where
high volume of transactions are exchanged between
few trading partners.
EDI is an application-to-application layer protocol.
There are four tasks that are required to create and
lation and communication. Of these four tasks, three
of them are performed by software utilities: Extrac-
dious and time consuming as it has to be rst ap-
proved by ANSI ASC X12 committee and requires
updating of the EDI translation software. In this
paper, we propose a simple and straightforward ap-
proach based on the distributed database concepts
that can eliminate the tedious process of standardiza-
tion. EDI messages are exchanged through database
transactions via a database-to-database communica-
tion rather than application-to-application. The most
tion software, translation software, and communica-
tion software.
In 1979, the American National Standards Institute
(ANSI) charted the ANSI X12 Accredited Standards
Committee to develop national EDI standards. In
1985, the United Nations established the EDIFACT
[3, 14] Committee to develop a world wide EDI stan-
dard. The EDI standards provide the framework for
how a given EDI message should be formatted. The
signicant outcome of this approach will be that EDI X12 committee is responsible for approving the EDI
will be transformed from an electronic analog of a busi- standards [in the US] and for processing any request
ness process in the paper world to a process supporting from business for modications, e.g., adding a new
Electronic Commerce. eld. The ASC X12 [6] standard has over 90 trans-
action sets that support the EDI needs of the U.S.
1 Introduction
The traditional model of Electronic Data Interchange
(EDI) facilitates the electronic exchange of business
documents (such as purchase orders, shipping man-
ifests, invoices and receipt notices) among trading
government, education, and specic industries such as
insurance and banking. Over 100 additional standards
and guidelines are currently in development.
The current model of EDI provides an obvious im-
provement over exchanging paper documents. How-
partners (e.g. a parts supplier and a nished prod-
uct manufacturer). These exchanges may take place
across incompatible hardware and software platforms
by embracing standard transaction sets and by em-
 The work of V. Atluri was supportedin part by the National
Science Foundation under grant IRI-9624222.
ever, the model of Electronic Commerce (EC) es-
poused by many, e.g. [5, 1], includes the ability to
send large quantities of business transactions to a large
 Based on personal communications with the Chair of the
X12 committee, the committee's working budget is approxi-
mately $3 million.

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
number of sometimes anonymous parties through elec- tics of business transactions. In [2] we have proposed
tronic means. With regard to this vision, EDI as it a suitable transaction model that can capture the se-
is practiced today has the following main drawback. mantics of business transaction and developed a sys-
The complexity involved in making a simple change tem that maintains the history of negotiations; due
such as adding or deleting a eld to a transaction is
quite high. Currently, such a request has to be sub-
mitted to the ANSI ASC X12 committee. If approval
is granted, the EDI translation software must be up-
dated accordingly. As EDI is used by more diverse
to space limitations, we do not include this in this pa-
per.) This results in simpler application programs and
avoids the situation where multiple applications doing
essentially the same. Third, unlike EDI, DBMS tech-
nology is well advanced and more commonly used. For
applications, some of the benets of standardization
may even be lost due to the diversity of implementa-
tion conventions.y
In this paper, we develop an approach that eliminates
the tedious process of standardization. We propose
a distributed database (DDB) approach where the
EDI messages are exchanged through simple database
transactions through a database-to-database commu-
EDI to play a major role in Electronic Commerce it
must take advantage of the current advances in DBMS
technology.
2 EDI
Below are the major components of EDI standards.
1. Data Element: A data element is an individual
piece of data such as a date, a price or an organi-
nication rather than application-to-application. As a zation's name. Each data element is identied by a
matter of fact, although an EDI transaction is initi- reference number. For each data element, the dictio-
ated by an application program at the sender's end
and received by another application program at the
receiver's end, the data being sent is from a sender's
database to that of receiver database. Therefore, it
makes perfect sense if the sender's database manage-
ment system (DBMS) can directly send the desired
data to the receiver's DBMS. For example, the pur-
nary species the title, description, type, number, and
minimum/maximum length.
2. Data Segment: In the ASC X12 format, each line
is referred to as a segment and each item within the
segment represents an element. For example, a pur-
chase order line item segment is made up of a part
number, a part description, a quantity, a unit of mea-
chase order transaction initiated from the customer's sure and an item cost. Each segment has an identier,
purchasing database updates the supplier's order re- a data element delimiter, element diagrams, data seg-
ceiving database instead of customer's purchasing ap- ment terminator and notes.
plication sending it to the supplier's order receiving
application.
The above approach has several advantages. First,
since this approach establishes a direct link between
the sender's database and the receiver's database,
it eliminates the tedious and expensive process of
translation.z Second, it allows the database transac-
3. Transaction Set: A transaction set is a specic
document, such as a purchase order. Within a trans-
action set, there are three main areas: header area,
detail area and summary area.
4. Functional Group: This is a group of similar trans-
action sets. Transaction sets within a functional group
tions to capture the semantics of the business trans-
actions through the DBMS. A typical business trans-
action involves a series of negotiations among trading
partners; for example, a purchase order may consist
of a series of negotiations, such as the generation of
the purchase order at the customer site, copying it
into the supplier's database, the supplier's acknowl-
edgment of the message and supplier's functional ac-
knowledgment. Currently, it is the responsibility of
are assigned the same functional identier.
For example, the ASC X12 set number 810 is a
transaction set for invoice. It has 50 segments with
each segment containing information that is needed
to make a complete transaction.
Figure 1 depicts the architecture for EDI consider-
ing two trading partners { a customer and a sup-
plier. To send a customer EDI-transaction, four ba-
sic tasks are performed: Mapping the elements in
the application program to keep track of the seman-
y The Federal Government's Electronic Commerce Acquisi-
tion Team (ECAT) has recognized this fact and is moving
toward harmonizing the implementation conventions (broad-
casted in the edi-new-request).
z EDI software prices range from $5,000 for PC-based systems
to $250,000 for mainframe applications as stated in 1997 CMP
Media publications: \New Life for EDI?".
the database, Extraction of pre-identied data from
the database, translation of extracted data into EDI
format, and transmission of EDI-formatted message
through a communication medium. Below is a brief
discussion of each of these four tasks.
Mapping: Is the process of identifying the elements
within the database that are needed to create an

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
 Customer’s site
EDI messages Supplier’s site

Communication Communication
Softwre Softwre

EDI Translation Translation

Software EDI
Software Software Software
Extraction Extraction
Software Software

Purchasing Quotation
application Processing
application

Purchasing Request for Quotations

database database

Figure 1: The EDI Architecture

EDI message. Mapping is a one-time task that 3 Related Work

is done only once when a new EDI transaction Recently, several researchers have addressed the prob-
type needs to be added. EDI software does not lem of reducing the rigidity of the EDI paradigm. In
perform this task. [12], Steel proposes an approach that relaxes the rigid
Extraction: Is the process of collecting the pre- standards of the current EDI, where data can be di-
identied data and placing it into a usable for- rectly transmitted without having it to conform the
mat. Generally, the data are extracted from the EDI standards. This approach would reduce the num-
database and restructured into a
at le. The ex- ber of segments in a purchasing interchange structure
act structure of the
at le is normally specied from the maximum of 157 used in the EDIFACT mes-
by the translation software developer. sage to a maximum of 12. To combat the variations in
the labeling and descriptions, Steel maintains a Basic
Translation: For outgoing messages, once the neces- Semantic Repository (BSR), which is a standard dic-
sary data are in a
at le, generation of an actual tionary that maintains the appropriate mapping of the
EDI message can be achieved using translation labels and descriptions.
or formatting software. Translation software ar- In [8], Lehmann proposes an ontology-based EDI,
ranges the data in the exact structure necessary which uses a concept dictionary that is similar to the
to meet the EDI standards requirement. BSR described above. The concept dictionary stores
Communication: The actual transmission of the the semantic denition of the meaning of each EDI
EDI message is controlled by communication soft- element, which can be expressed in a semantic net-
ware, which manages and maintains phone num- work or a standard logic format. This approach to
bers of trading partners, performs automatic di- EDI is done in two phases. In the rst phase, the
aling and up/downloading, and also produces an trading partners negotiate by exchanging the ontolo-
activity log. Each EDI message is enclosed in an
envelope that contains the message's destination
address and EDI transaction type as a header and
exibility. The second phase is the actual inter-
error checking codes (such as a check-sum) as a
trailer. For incoming EDI messages, the reverse
process occurs.
gies, and type-denitions and synchronize their con-
cept dictionaries. This negotiated ontology is the key
to
change of transactions. This approach, like the cur-
rent EDI protocols, will not specify the form of the
actual commercial transactions, but will prescribe the
means by which two trading partners' computer sys-
In [2], we present a simplied purchasing scenario to tems will reach an agreement on the common terms
illustrate how EDI works. and concepts and the set of data needed for a trans-

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
action.
In the area of heterogeneous databases, Papakon-
stantinou et al. [10] address the problem of provid-
ing integrated access to diverse information sources,
such as SQL databases, object repositories, knowledge
[11, 4]. The second category of heterogeneity occurs
when there is a disagreement about the meaning, in-
terpretation, or intended use of related data. In this
paper, we concentrate our attention on the second cat-
egory.
bases, le systems and document retrieval systems.
They propose an object-based information exchange
model that enables information exchange in a hetero-
geneous environment. In this model, every data object
is associated with a self-describing label.
4.1 Architecture
Figure 2 depicts our distributed system architecture
for EDI. It consists of a communication module to fa-
cilitate exchange of messages among the trading part-
ners. When a trading partner sends an EDI mes-
Among the three approaches described above, the rst sage, the communication module assigns the destina-
two require that the trading partners exchange their tion address for routing this message. In addition,
semantic dictionaries (BSR in the rst case and con- the communication software may provide security ser-
cept dictionary in the second case), and thus prohibit
their use when two new partners wish to exchange
messages. On the other hand, if we adopt the third
approach to EDI, although it does not require such
a prior exchange of semantic data, it results in very
long messages. In the following section, we present
our distributed systems approach.
4 Distributed Systems Model
vices such as condentiality and integrity of the mes-
sage as well as authentication of the sender and non-
repudiation of the receiver. The details are provided
in Subsection 4.2.
When two trading partners start transacting with each
other, they have to resolve the semantic heterogeneous
issues. In other words, to interpret the sender's trans-
action correctly, the receiver's database has to main-
Our distributed systems approach re-denes EDI from tain the necessary translation information at its site.
an application-to-application level to a database-to- To accomplish this, we use a prole manager at each
database level. In particular, the database manage- trading partner's site. For each type of transaction,
ment systems at the various trading partners will co- the prole manager maintains a prole for every one
operate while remaining autonomous and allow only of its trading partners in its prole base. After resolv-
partial and controlled access to their local data. The ing the semantic heterogeneity issues by comparing its
business transaction can be treated as a database own prole with that of the sender's, the prole man-
transaction issued by a user from the sending trading ager hands over the message to the DBMS, which is
partner which will be received by the DBMS at the now in the form of a local database transaction. In the
receiving trading partner. Specically, we allow the remainder of this section, we explain each component
exchange of messages from one database to another of our architecture in detail.
rather than from an application-to-application. In or- 4.2 Communication Module
der to apply our approach, we rst need to resolve the
heterogeneity issues among the trading partners since
the DBMS at each trading partner's site may be dif-
ferent because of one or more of the following reasons
| dierent underlying data models, various DBMS
products, variety of platforms, and dierent database
schema.
Traditionally EDI has been done via value added net-
works (VANs) that provide dial up access to a desig-
nated mailbox for trading partners to send each other
business transactions. VAN acts as a trusted third
party to insure that EDI sent via the VAN are not
compromised in any way. VANs provide, integrity, au-
thentication and acknowledgment services. Moreover,
In such a federated environment, issues such as con- since it is a private network, it provides condentiality
currency control, failure and recovery, and database of the message as well. However, message exchanges
schema become complicated to handle because indi- via the VAN are not only slow but quite expensive.x In
vidual DBMSs do not wish to sacrice their auton-
omy; several researchers have addressed these issues,
e.g. [11] and we plan to take advantage of this work.
The various aspects of heterogeneity can be divided
primarily into two categories: those due to the dier-
contrast, users can make use of the high speed TCP/IP
networks like the Internet. Before we adapt to this ap-
proach, security must be provided at dierent levels:
(1) Must ensure secure communication of the transac-
ences in DBMSs and those due to the dierences in tion: This includes condentiality and integrity of the
the semantics. The former category includes dier- x Mobil reports that VAN costs exceed $100,000 per year
ences in structure, constraints, and query languages (http://www.pcweek.com/archive/1415/pcweek0081.html).

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
 Customer’s site Supplier’s site

Communication Communication
Module Module
Profile Base
Profile Base

Profile Profile
Manager Manager
Purchasing Order Processing
application application

DBMS DBMS

Purchasing customer orders

database database

Figure 2: The Distributed System Architecture for EDI

data. other. After this is accomplished, the trading part-

(2) Must support non-repudiation of receipt: That is,
the intended recipient of the transaction has received
the transaction.
(3) Must support digital signature: This ensures the
authenticity of the sender.
ners simply exchange data, i.e., the instance transac-
tion. On the other hand, if there is only a sporadic
exchange of EDI messages among the trading part-
ners, then they do so by the complete transaction. In
the following, we present the three transaction types.
Commercial systems such as Templar can be used to 4.3.1 The denition Transaction
provide secure communication between trading part-
ners using RSA encryption techniques to guarantee Each denition transaction consists of
condentiality and integrity of data, digital signatures a definition_name, a set of objects where each ob-
and non-repudiation.{ ject in turn is of the form object_id, object_name,
4.3 Transaction Types which the name used to store the object (typically the
eld name), object_type, which is the type of the
Our approach relies on three new transaction types { object such as string, number etc., object_units, the
the denition, the instance, and the complete transac- default units in which the object can be measured, and
tions. Although these transactions types are similar
to the OEM model in [10], they dier from the OEM
in a number of ways. First, in OEM each object is
associated with a self describing label. While it is
essential in case of OEM since it has been proposed
object_default, which is the specied default value.
Formally Tdef = < name; (o1 ; o2; : : :; on) >.
An object oi in Tdef may consist of other objects, thus
giving a nested structure to Tdef . The typical struc-
for a heterogeneous database environment, it is ex-
pensive, and moreover, not necessary to include a self
describing label in each EDI message. This is because,
unlike database transactions, the EDI messages are ex-
changed among known and limited trading partners in
most cases. Thus according to our approach, the def-
inition transaction is exchanged among the new trad-
ture of the denition transaction is given in Figure
3.k
4.3.2 The instance transaction
The instance transaction (Tinst) comprises of the the
name of the corresponding Tdef and the values of each
object in Tdef . The structure of instance transaction
ing partners and is used to build the proles of each is shown in Figure 4.3.1. Each row in this gure cor-
{ Information
responds to an instance of the denition transaction.
on Templar can be obtained at
http://www.edm.co.nz/product/premenos/templar.html and k list indicates that the type of denition-name is an ordered
http://www.templar.net/ set of objects (i.e. object1, object2, ... objectn).

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
<definition-name, list, {object1, object2, ... objectn}>
object1 is <object1-name, object1-type, object1-units, object1-default>
object2 is <object2-name, object2-type, object2-units, object2-default>
...........................................
objectn is <objectn-name, objectn-type, objectn-units, objectn-default>

Figure 3: The Structure of the denition Transaction

<definition-name, "{value1, value2, ... valuen}"
"{value1, value2, ... valuen}"
.............................
"{value1, value2, ... valuen}">

Figure 4: The Structure of the instance Transaction

4.3.3 The complete transaction assigned to a real world object may dier at both the
trading partners, such as clothes in one end and gar-
The complete transaction (Tcomp ) is in fact a combina- ments at the other end. Such mismatches are resolved
tion of both the denition and instance transactions. using personal negotiations or using an ontology. Af-
It comprises not only of the description of each ob- ter resolving these mismatches, an object-name tuple
ject, but also of the actual values of the objects. The is constructed and maintained for this trading partner
structure of the complete transaction is given in Fig-
ure 4.3.1. We explain in Section 5 how each type of
transaction is used in our approach.
4.4 Ontology
Ontology, in a database sense, is a complete concep-
in the prole base.
2. Object-format mismatch: Object format describes
the data type of the object. An object may have a data
format of a string, number, or date. Two trading part-
ners may maintain the same objects (e.g. part no),
but having two dierent formats (i.e. one partner
tual schema of a specic or broad domain. It also maintains the part no as number while the other uses
includes a conceptual schema of relations and con- string). Such mismatches can be resolved by utilizing
straints [8]. In carrying out the EDI transaction, the a format reference list and ontology as part of the pro-
meaning of terms used in the EDI transaction needs le base. After resolving the mismatches, an object-
to be formally specied. This is particularly impor- format tuple is constructed and stored in the prole
tant in the mapping process. The traditional approach base.
of specifying the term used in the EDI transaction is 3. Object-sequence mismatch: Object sequence iden-
through personal negotiation. This is time consum- ties the sequence of objects in an EDI transaction.
ing, in
exible and very costly. The new approach to In sending RFQ (Request For Quotation), one trad-
formally specify the terms used in EDI transactions is ing partner may format object name to appear rst
through the use of ontology which functions as the- in the EDI message, object quantity second, and ob-
sauri. The ontology used here is domain-specic to ject date last, while its trading partner sends its EDI
business transactions and applications. message with the sequence of object name, object date
The use of ontology in EDI has been discussed in a and object quantity. In order to evaluate the content of
great detail and presented in some of the papers on trading partner EDI messages, this mismatch needs to
EDI. In this paper, we are not going to discuss ontol- be resolved. An object sequence prole may be main-
ogy in detail nor describe how ontology is implemented tained for each trading partner in order to resolve this
for our database-to-database approach. A detail dis- mismatch. An object-sequence tuple is maintained in
cussion on ontology and its use in EDI can be obtained the prole base.
from [8]. 4. Object-units mismatch: An object in an EDI trans-
4.5 Prole Base
The two trading partners' databases may dier in a
number of ways as follows:
1. Object-name mismatch: Object names are nothing
but labels associated with each object which are as-
signed based on the semantics of the object. The label
action may be associated with a unit, such as an object
garment may have a unit of yard or meter. One sup-
plier may use yard as the unit for garment while its
trading partner may use meter. Resolving unit mis-
matches is not as straightforward as resolving any of
the previous mismatches. To convert yard into meter,
the quantity value of the object needs to be adjusted

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
<name, set, {object1, object2, ... objectn}>
object1 is <object1-name, object1-type, object1-units, object1-value>
object2 is <object2-name, object2-type, object2-units, object2-value>
...........................................
objectn is <objectn-name, objectn-type, objectn-units, objectn-value>
Figure 5: The Structure of the complete Transaction
(i.e. multiplied by three) to arrive at the appropri-
ate unit for meter. This mismatch problem can be
more complex than simply converting yard into meter
or vice versa. A more dicult problem can be illus-
trated by the following example. Let assume that a
supplier sells apples in boxes where each box consist
of 20 lb of apples. This supplier maintains units only
in 20-lb boxes. Now, let say, a customer maintains
its own unit for apples also in boxes. Each box may
weight between 5 to 8 lb. and let assume that this
customer would like to purchase 15 boxes of apples. A
more complex unit-conversion needs to be performed
for this case. Formulas may also be used to resolve
unit mismatches. The formulas used may range from
easy to dicult formulas. After such mismatches have
been resolved, an object-units tuple is constructed and
transaction message. The order of the object name
is maintained since each sequence corresponds to the
corresponding sequence in other tuples (object-format,
object-unit and object-default tuples). For example,
the tuple (product no, quantity, date) indicates that
there are only three objects, product no, quantity, and
date, in the transaction.
2. Object-format tuple: This tuple maintains the for-
mat of all the dierent objects in the transaction. In
this tuple, the format appear with the same sequence
as its object name sequence in the object-name tu-
ple. For example, having the previous object-name
tuple example, (product no, quantity, date), an object-
format tuple would look somewhat like (string, num-
ber, DD-MON-YYYY). This depicts that the type for
maintained in the prole base.
5. Object-defaults substitution: Object default is used
when the object value contains no data (or the value
is null). One trading partner may have a default value
of, let say, 100 for a particular object while its trading
partner has a default value of 50 for the same object.
Even though, two trading partners may use dierent
default values, no default mismatch needs to be re-
product no is string, for quantity is number and for
date is DD-MON-YYYY.
3. Object-sequence tuple: Object-sequence tuple stores
the order of all objects as they appear in an EDI trans-
action. The sequence of the value in this tuple does not
have any relation with the sequence of values of any of
the other tuples. A sequence-tuple (product no, date,
quantity) indicates that the object product no appears
solved. As long as one trading partner maintains the rst in an EDI transaction, object date appears sec-
default value used by the other partner, any empty ond, and object quantity appears last.
(null) value can be substituted by the default value
maintained in the prole base. If the trading partner 4. Object-units tuple: This tuple maintains the unit
sends some null values along with some default val- used for each object in the transaction (if any). In this
ues, the default values stored in the prole base should tuple, the unit value appear with the same sequence
be ignored and the default values sent along with the as its object name sequence in object-name tuple and
transaction should be used instead. An object default its object format sequence in object-format tuple. For
tuple is also maintained in the prole base.
As described previously, after resolving all the above
mismatches, object-name tuple, object-format tuple,
object-sequence tuple, object-unit tuple, and object-
default tuple are created and maintained for each trad-
example, having the previous object-name tuple ex-
ample, an object-unit tuple would look somewhat like
( , meter, ). This depicts that there is no unit for ob-
ject product no, the unit for object quantity is meter
and there is no unit for object date.
ing partner in their prole base. Thus each site main- 5. Object-default tuple: Default tuple stores the de-
tains a prole for each trading partner as well as its fault value for each object (if any). Similar as the
own prole. The prole consists of the following infor-
mation for each transaction: the name of the trans-
action, object-name, object-format, object-sequence,
object-units and object-default tuples.
1. Object-name tuple: Object-name tuple stores the
names of all objects in the order they appear in an EDI
other tuples, the default values for the dierent ob-
jects appear with the same sequence as their object
name sequence. The default tuple is used whenever a
trading partner sends a null values. For such case, the
appropriate default values from the default tuple are
extracted and later substitute the null values.

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
4.6 Prole Manager table, object-format table, object-value table object-
When a prole manager receives a transaction, it is default table, and the object reference table as follows.
responsible for executing the following. These tables need to be constructed at both the trad-
ing partners' sites; however, we elaborate it in the case
1. Identies the type of transaction. of the S site.
2. If it is Tdef , updates the prole base Now we will describe how the C's RFQ updates the
3. If it is Tinst, uses the two-phase strategy (ex- S's received-request-for-quotations database. For the
plained in Subsection 5.1 and generates a sake of explanation, we assume the S's database is re-
database transaction. lational. During the negotiation phase, the denition
4. If it is Tcomp , uses the single-phase strategy transaction for request for quotation from C to S is
(explained in Subsection 5.2 and generates a rst initialized by C and sent to S, which may be as
database transaction. shown in Figure 5.1. Upon receiving the denition
The database transaction thus generated by the prole transaction, S constructs the prole of C as follows.
manager is consistent with the object names, formats, S Prole for RFQ:
and units used in the local database. In the following Object-name tuple:
section we provide details of the prole base. <part No.,description,qty,RFQ no.,date,unit of measure>

5 Processing Strategies Object-format tuple:

<text,text,number,text,MM-DD-YY,text>
Below, we present our approach to construct and Object-units tuple: < , ,yards, , , >
maintain the proles. In our approach, we proposed
the following two strategies: (1) two-phase and (2) Object-defaults tuple: < , ,100, , , >
single-phase. Object-sequence tuple:
5.1 The two-phase strategy <part No.,description,qty,RFQ no.,date,unit of measure>

Phase 1 - The Negotiation Phase: In the two-phase C Prole for RFQ:

strategy, prior to sending a business transaction, the Object-name tuple:
two partners must negotiate on the transactions, their <product code,description,quantity,RFQ number,date,
semantics including its name, object names, format measured in>
etc. During the negotiation phase, the partners ex- Object-format tuple:
change denition transactions. The prole manager <text,text,number,text,DD-MM-YY,text>
uses the above denition transaction to build the pro- Object-units tuple: < , ,meters, , , >
le for the corresponding trading partner. Essentially,
according to this strategy, there will be a prole for Object-defaults tuple: < , ,100, , , >
each trading partner. It is important to note that this Object-sequence tuple:
transaction is issued only in the early stages of trad- <product code.,description,RFQ no.,date,qty,unit of
ing among the partners or whenever a change in the measure>
earlier denition has to be made. We describe below During the transacting phase, assume the following
the various types of information extracted from the request for quotation transaction is sent:
denition transaction.
Phase 2 - The Transacting Phase: The prole thus <RFQ, REQUEST, "912-111", "03-01-95", "{524-32,
Terrycloth, 1000,yd} {524-31, Linencloth, 2000, yd}",
constructed during the negotiation phase will be used "FOB port of call", "David Richmond", "(201)222-4444">
during the transacting phase to interpret the trans- At this point, the object sequence tuple of C at S is
action and to invoke the appropriate application pro- used to assign the led names to the values. Then the
grams. The prole can be revised by sending a new led name tuple of C is compared to that of S and
denition transaction. the led names of each value are changed if necessary.
Example 5.1 To illustrate our approach, we use a Note that while making object name transformations,
Request for Quotation (RFQ) an example between two
trading parties, Clothes R Us, the customer (C) and
Fabric City, the supplier (S). Before any transaction
can be transmitted, both C and S need to work on the
mapping of dierent terms and build the object-name
the prole manager consults the ontology base. Then
the object default tuple of C is used to insert the miss-
ing values, object unit tuple of C to covert the units to
those of S, and the object format tuple of C to assign
the format. 2

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
<definition-RFQ, list, {object1, object2, object3, object4, object5, object6}>
object1 is <RFQ no., alphanumeric, , F-000000>
object2 is <date, date, , null>
object3 is <product line, any, {products}>
products is <product, list, {subobject1, subobject2,subobject3, subobject4, subobject5}>
subobject1 is <part no., alphanumeric, , null>
subobject2 is <description, alphanumeric, , null>
subobject3 is <qty, integer, , null>
subobject4 is <unit of measure, alphanumeric, , feet>
subobject4 is <unit price, currency, dollars, null>
object4 is <FOB term, alphanumeric, , null>
object5 is <contact person, alphanumeric, , null>
object6 is <contact number, alphanumeric, , null>

Figure 6: The denition Transaction of Clothes R Us

5.2 The single-phase strategy After a security check and a decode and translation
On the other hand, in the single-phase strategy, all steps, the EDI message is converted into a
at le,
transactions are self-descriptive and are in the form which is then passed on to the Prole Manager. The
similar to the denition transaction. Under this strat- prole manager consists primarily of a collection of
egy, no prole need to be maintained by the trading Perl and PL/SQL programs comprising of the follow-
partners, however, every transaction need to be inter- ing modules.
preted by the prole manager. 1. Driver module: A driver module, written in Perl,
It is meaningful to use the two-phase strategy when accepts and processes the transaction (in a
at-le for-
the trading partners are limited and the frequency of
transactions is large. The single-phase strategy is use-
ful in cases where the number of trading partners is
large but the frequency of transactions is less. Thus,
one may use a dierent strategy for each trading part-
ner.
mat), determines the sender and the type of the EDI
transaction (i.e., whether Tdef , Tinst, or Tcomp ). Based
on the type, the driver module executes the appropri-
ate external module, described below.
2. Tdef module: This module, primarily a collection
of Perl programs and PL/SQL scripts, processes Tdef .
The functions of this module are to extract the ap-
6 Implementation propriate prole from the prole base, compare and
For implementingour approach, we have employed Or- evaluate the extracted prole and the new prole, ex-
acle7.x as the underlying database to store the actual tract necessary information from the dictionary of the
data and have used the Internet as the medium of EDI-
message transfer. In this paper, we do not discuss how
we transmit EDI-messages on the Internet nor how we
impose security on EDI messages. Instead, we concen-
trate on how to handle the dierent types of transac-
underlying database, update the prole in the prole
base, and send status of task completion to the task-
completion module.
3. Tinst module: Tinst module, which processes Tinst,
performs the following functions: extracts the appro-
tions mentioned earlier and how to maintain the pro- priate prole from the prole base, evaluates and maps
le base. For this implementation, we have chosen the the content of the transaction with the extracted pro-
Perl programming language because of its ease of use, le, composes the appropriate database transaction as
its capability in manipulating data, text and les, and a PL/SQL script, executes the database transaction
its portability since processing the dierent transac- against the underlying database, and sends the status
tion types and maintaining the prole base requires of task completion to the task-completion module.
the capability to manipulate text and les. We also
have chosen Oracle procedural extension to the SQL
programming language (also known as PL/SQL) to
execute the necessary database transaction against the
underlying database.
Processing of an EDI-transaction is initiated when a
trading partner receives an EDI-transaction message.
 Other database procedural and sequential languages can
also be used.
4. Tcomp module: Tcomp module, which processes
Tcomp , composes the appropriate database transaction
as a PL/SQL script, executes the database transaction
against the underlying database, and sends the status
of task completion to the task-completion module.
5. Task-Completion module: Upon completion of
any of the previous transaction modules, the Task-
Completion module is executed, which checks on the
status of the task. If the task is not successful, a failure

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE
message is composed and passed on to a higher level
(i.e. to the communication module). If the task is
successful, a success message is composed and passed
on to a higher level.
For simplicity reason, we have focused our implemen-
tation only on one functional transaction, Purchase
Order in which we have considered the part of the
data pertaining to purchase order and used the dictio-
nary information and relational tables that are needed
for processing a purchase order.
7 Conclusions
Over the past few decades, U.S. and international
businesses have invested large sums of money in EDI
software and hardware. Systems that can capitalize
on the installed base while oering improved services
to new adopters will more easily gain acceptance. His-
torically, EDI has represented a dramatic change for
businesses. Small businesses in general are reluctant
to move to new technologies because of the learning
curve and potential maintenance costs. In the auto-
motive industry, the electronic transfer of orders and
shipping notices became so important that the big
three auto makers installed EDI compatible systems
on-site at their major parts suppliers. This ensured
the compatibility of the systems and gave the suppli-
ers the help they needed to embrace the new technol-
ogy. A similar adoption of the distributed database
approach would not be unreasonable to expect.
Additionally, the technological advances to support
multimedia transactions in distributed databases can
be directly adapted in EDI systems. Again, the his-
tory of EDI stems from the exchange of character and
numerical data on business forms. CAD drawings,
bit-mapped pictures, audio samples and video clips
were never considered as viable forms of business doc-
uments suitable for exchange. Support of multimedia
data types is especially useful in exchanging patients'
medical record among healthcare providers. Currently
EDI is being used for exchanging commercial informa-
exible EDI
tion such as verifying eligibility, getting informationon
a subscriber and/or dependents, coordination of ben-
[2] N. R. Adam and V. Atluri. EDI Through A Dis-
tributed Information Systems Approach. Techni-
cal report, Center for Information Management,
Integration and Connectivity, Rutgers University,
1997.
[3] John Berge. The EDIFACT Standards. Technical
report, NCC Blackwell, 1991.
[4] Ahmed K. Elmagarmid and Calton Pu. Guest
editors' introduction to the special issue on het-
erogeneous databases. 22(3):175{178, 1990.
[5] L. Gebase and S. Trus. Analyzing electronic com-
merce. Technical report, National Institute of
Standards and Technology, 1994.
[6] Walter P. Hamilton III and Morey M. Henderson.
Forging a partnership through EDI. Technical
report, A handbook for DoD and Small Business,
Logistics Management Institute, 1993.
[7] Paul Kimberley. Electronic Data Interchange.
McGraw-Hill, 1991.
[8] Fritz Lehmann. Machine-negotiated ontology-
based EDI Electronic Data Interchange. In Elec-
tronic Commerce: Current Research Issues and
Applications. Springer-Verlag, 1996.
[9] James McGee. A note on Electronic Data In-
terchange. Technical report, Harward Business
School, 1989.
[10] Yannis Papakonstantinou, Hector-Garcia Molina,
and Jennifer Widom. Object exchange across het-
erogeneous information sources. In Proc. 20th
Int'l. Conf. on Very Large Data Bases, 1994.
[11] A. Sheth and J. A. Larson. Federated database
systems for managing distributed, heterogeneous,
and autonomous databases. 22(3):183{236, 1990.
[12] Ken Steel. The standardization of
messages. In Electronic Commerce: Current Re-
search Issues and Applications. Springer-Verlag,
ets with other payers(insurers), type of plan or pro- 1996.
gram, primary care physician elections, etc. Although [13] P. M. C. Swatman and P. A. Swatman. EDI sys-
a data segment currently exists for transmitting binary tem integration: A denition and literature sur-
data, its denition is too general to be used eciently vey. 8(3), Summer 1992.
for such a wide variety of data types.
[14] Adrian Tang and Sophia Scoggins. Open network-
References ing with OSI. Prentice Hall, 1992.
[1] N. Adam and Y. Yesha. Electronic Com-
merce: Current Research Issues and Applications.
Springer-Verlag, 1996.

10

Authorized licensed use limited to: Universidad del Valle. Downloaded on March 07,2021 at 03:02:55 UTC from IEEE Xplore. Restrictions apply.
1060-3425/98 $10.00 (c) 1998 IEEE