Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: Distributed and concurrent processing of business object documents in support of e-enterprise integration
Full Citation
Permanent Link:
 Material Information
Title: Distributed and concurrent processing of business object documents in support of e-enterprise integration
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Su, Stanley Y.W.
Publisher: Department of Computer and Information Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 2000
 Record Information
Bibliographic ID: UF00095467
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

file_401 ( PDF )

Full Text

Distributed and Concurrent Processing of
Business Object Documents in Support of e-Enterprise Integration

Stanley Y. W. Su, Fellow, IEEE, Youzhong Liu, Jie Meng
Minsoo Lee and Herman Lam, Member, IEEE
Database Systems R&D Center, University of Florida, Gainesville, Florida 32611
{ su, yoliu, jmeng, mslee, hlam

Internet and distributed object technologies have
made it possible for different business enterprises to
draw upon the best of their resources for conducting
joint business as a virtual e-enterprise (VEE). To enable
virtual e-enterprises, the integration of legacy
applications and the modeling and enactment of
concurrent business processes are necessary. In this
work, we combine the features of the messaging
approach and the distributed object approach to system
integration. Business Object Documents (BOD) are used
for transmitting business operations and data among
application systems. Message transmission is supported
by two underlying communication infrastructures:
CORBA and Java RMI. The separation of messaging
from communication infrastructure allows the
underlying infrastructure to be changed without
impacting application systems. Also, business processes
are modeled as sequences or network structures of BOD
transmissions. The process models are replicated at all
sites and used by an extended information infrastructure
to enable distributed, concurrent enactment of

1. Introduction

A key requirement for enabling e-enterprise is the
integration of heterogeneous application systems, which
can be either tightly coupled or loosely coupled. In
tightly coupled integration, heterogeneous applications
are homogeneously modeled and encapsulated as
distributed objects using a common interface definition
language and a common communication infrastructure.
Application systems are "wrapped" by their proxy
objects, which communicate with one another by remote
method invocations. This approach is exemplified by
distributed object technologies like CORBA [COR98],
Java RMI [JAV], and DCOM [MIC], etc. It is an
effective and efficient method of application integration
in an intranet environment.

On the other hand, in loosely coupled integration,
heterogeneous application systems communicate with
one another through message passing. The content of a
transmitted message specifies the requested business
operation and the data needed to perform the operation.
The receiving applications) interprets the message,
performs some actions based on the message, and, in
some cases, responds by sending out a message. The
information infrastructure takes care of the delivery of
the reply message to the proper receiverss. Generally
speaking, this approach is less efficient than the tightly
coupled approach since messages need to be interpreted
at run-time. However, it is more suitable for e-
enterprises for which the use of a common interface
definition language and a common communication
infrastructure is not technically or politically viable.
In this paper, we present an approach to
heterogeneous application integration which leverages
the strengths of both tightly coupled and loosely coupled
approaches by building a messaging infrastructure on
top of distributed object communication infrastructures
offered by CORBA [COR98] and Java RMI [JAV]. In
our approach, a business process is modeled by a
structure of business object document (BOD) transfers,
which specifies the exchanges of business operations
and business data among heterogeneous applications
needed in a business scenario. Process models are stored
in Scenario Tables, which are replicated in all the sites
of an integrated network that constitutes an e-enterprise.
At run-time, the Scenario Table at each site is used to
direct the infrastructure middle-ware where to transfer
the BODs generated by various application systems,
providing distributed control of concurrent processing
of business process models. Also, registration pools are
used for validating the semantic consistency of BOD
pairs and local logs are used for the synchronization of
process steps.
The approach taken in this work is different from the
approach taken by the traditional process automation
[VIT] and workflow management systems [ULT]. In
traditional systems, a process/workflow model is defined
by a structure of activities and conditional transitions.

0-7695-0865-0/00 $10.00 2000 IEEE

Manual or automated tasks are enacted by the
"process/workflow engines" of these systems.
Application systems play a passive role (i.e., perform
operations when they are called upon to do so). In our
approach, application systems play an active role in the
enactment of business processes. A process is started by
an application when it sends out a BOD to the
information infrastructure. The infrastructure delivers
the BOD to the appropriate target applications) by using
the process model information (i.e., the Scenario Tables)
replicated in all the activity managers to which
application systems are connected. The target
application system receives and processes the BOD and,
in some cases, generates a BOD in return. It reacts to the
BOD it receives and has no knowledge where the return
BOD should go. The task of BOD delivery is completely
handled by the infrastructure as directed by the Scenario
Tables. Thus, the approach taken is the least invasive
and requires the least amount of change to the existing or
legacy application systems. Being table-driven, Scenario
Tables can be dynamically modified at run-time using
events, triggers and rules [LAM98] to capture the
changing business scenarios. Thus, it is more suitable for
inter-enterprise communication and collaboration for
virtual e-enterprises.
In our implementation, we separate the messaging
layer from the underlying communication infrastructure.
The messaging layer is founded on BODs and the
underlying communication infrastructure makes use of
the distributed object technologies provided by Java's
RMI and CORBA's ORB. Messages in BOD format are
transmitted among distributed objects by passing them
as parameters of remote method calls. Status of a
business operation and return value can be returned to
the caller object directly without having to convert them
into messages. Thus, some messaging overhead can be
avoided. A technical report, which more thoroughly
documents our work, can be found in [SU99].

2. Business object document transfer
The Open Application Group (OAG) has proposed the
use of Business Object Documents as a standard
business data interchange format [OAG]. A business
object document (BOD), among other things, specifies
an action to be taken (Verb) and the data (Noun) to be
used for performing the operation by the recipient.
Different modes and types of BOD transfers have been
found useful in business. Two modes of BOD transfers
can be distinguished. A BOD can be transferred in either
asynchronous (ASYNC) mode or synchronous (SYNC)
mode. In a SYNC mode BOD transfer, the sending
application is blocked after it sends out a BOD and waits
until the reply BOD comes back. For an ASYNC mode
BOD transfer, the sending application is not blocked. It

continues its processing even though it may be expecting
a reply BOD to return.
There are two types of BOD transfers: paired BOD
transfer and one-way BOD transfer. Paired BOD
transfers are composed of two BOD transfers. The first
BOD is sent out with the expectation that another BOD
will be returned as the reply of the first BOD. For
paired BODs. One-way BOD transfers are single,
independent BOD transfers. BODs are sent out without
the expectation of a reply BOD. For example, for an
ERP application to create a journal entry in a general
ledger application, the source application can send a
one-way BOD called POST JOURNAL to either single
or multiple receivers (i.e., either one-to-one or one-to-
many transfer). The asynchronous mode of BOD transfer
can be applied to both one-way and paired BODs;
whereas, the synchronous mode of BOD transfer can be
applied only to paired BODs.

3. Modeling of business processes

3.1. Scenario table
To model a business process is to identify all the
business steps that are involved in a business scenario
and to determine the dependencies among these steps. In
this work, each step is represented by a BOD transfer
from a specific sender to one or more receiver and the
operation performed by the receiverss.
In our system, the result of the modeling of business
processes are represented and stored in a table structure
called a Scenario Table. A Scenario Table contains
information about the steps of each scenario. A row in
the Scenario Table is referred to as a scenario record. As
shown in Table 1, it includes the fields SCEN_ID,
specify the scenario number and the step number within
the scenario, respectively. The VERB and NOUN fields
identify the type of the BOD that is being transferred in
a particular step. The SENDER is the name of the
application instance that sends out the BOD. Here, an
application instance is a particular activation of an
application system. The RECV_LIST specifies the list of
the names of the application instances, which should
receive the BOD. It is possible to have multiple receivers
in a one-way BOD transfer. For paired BOD transfers,
there is only one receiver for each transfer. The
SYNC_STEP is used for controlling network-structured
scenarios, which will be explained in the next section.
Some example entries in the Scenario Table are shown
in Table 1. We can see that scenario 1, step 3, sends the
PROCESS PO BOD from Appa to Appb, and step 4
replies with the ACKNOWLEDGE PO BOD from Appb
to Appa.

Table 1. An example of Scenario Table
1 3 Process PO Appa (Appb) Null
1 4 Acknow PO Appb (Appa) 1, (2
ledge or 3)

6 4 Post Jour Appc (Appa, Null
nal __ Appb)

3.2. Network-structured scenario

A scenario can be linear, tree-structured or network-
structured. Among them, the network-structured
scenario is the most general; the first two structures are
special cases of the third. In a network-structured
scenario, a scenario step can branch to multiple scenario
steps (fan-out) and multiple scenario steps can lead to
(fan-in) and synchronize at a single scenario step.
The SYNC_STEP attribute in a Scenario Table is
used to synchronize fan-in steps. Complex
synchronization condition can be specified in this field
to support AND-join and OR-join as in most workflow
systems. The expression in SYNCSTEP is a list of
integer values separated by commas and the keyword
OR. Each integer value is a step number within the same
scenario. The condition specified in the SYNC_STEP
field must be true before the step represented by the
scenario record can be executed. In Table 1, step 4 of
scenario 1 can be executed only after steps 1 and either
step 2 or 3 have been carried out. Note that the STEP_ID
in a Scenario Table is only used to uniquely identify a
step. The execution of a scenario does not necessarily
follow the order of the STEP_IDs. The dependencies of
the steps expressed by SYNC_STEP dynamically
determine the execution sequence. At run-time, the flow
controller will determine the eligibility of a step to be
executed based on the information in the SYNC STEP
field and the step execution status information.

4. Information infrastructure
4.1. General architecture
The general architecture of the information
infrastructure for BOD creation, transfer, and processing
is shown in Figure 1. In this architecture, two
components, an Application Adapter and an Activity
Manager, are added to the ORB and RMI
communication infrastructures. The former is for each
application system and the latter can be shared by
multiple Application Adapters and their corresponding
application systems running at each site. When a source
application wants to send a BOD to a target application,
it uses the services of its Application Adapter to build
the BOD in a character string format based on the OAG
specification. The created BOD is then given to the

Activity Manager, which determines where to send the
BOD based on the contents of the replicated Scenario
Table and the step execution status information.
Once the BOD is received by the target Activity
Manager, the BOD string is converted into a data format
suitable for the target application system. The target
Application Adapter then moves the converted data into
the target application system by calling its APIs. The
same procedure is followed for the returning BOD. The
scenarios are transparent to application systems. The
applications take actions based only on the contents of
the incoming BODs. They do not have to be concerned
about which scenario the current action belongs to, who
the receiver is, or where the receiver is. Each application
can be involved in multiple network-structured
scenarios, which are running concurrently to enact
different business processes. A higher degree of
parallelism can be achieved in processing a network-
structured scenario because of its distributed flow
control. Thus, good performance can be achieved by
exploiting both inter-scenario and intra-scenario
The Activity Manager is replicated on each site to
provide both the source and target systems' BOD
processing and transfer functions. We shall describe its
components and their functions in the next subsection.
Details on the BOD building, transformation and
mediation functions and the application adapters are
reported in [LI98].

uid BOD
roam data
ApplIcation Adapter

adety Managerl

R emote method
nall thru CORBAIRMI


.Ae1~. I U.anag ]

Appllcatlon Adapter
xtract data
f-om BOD

Figure 1. BOD transfer through replicated Activity

4.2. Activity Manager

The Activity Manager consists of a pair of adapters
(ORB and RMI Adapters), a Flow Control Module and
two supporting software modules named BOD Service
Agent and Metadata Manager. The ORB Adapter
supports BOD transfers in the CORBA environment and

can send/receive BODs to/from other ORB Adapters.
The RMI Adapter supports BOD transfers in the RMI
environment and can also send/receive BODs to/from
other RMI Adapters. Thus, a BOD can be transferred
through either RMI or ORB communication
infrastructure. The Flow Control Module, which
maintains a replicated Scenario Table, provides the
routing information to the source adapters in order for
them to deliver BODs to the proper target adapters. The
BOD Service Agent provides BOD specific services,
such as BOD parsing and extracting the contents of a
BOD. The Metadata Manager stores the meta
information of BODs used by the BOD Service Agent. It
verifies if the request for data extraction made by the
BOD Service Agent is valid (e.g., the attribute and its
path satisfy the specification of an OAG BOD).

4.3. Data structures: Scenario Table, local step
log and registration pool
The data structures used by the Flow Control Module
are the Scenario Table, Local Step Log, and the
Registration Pool. They are replicated in all the nodes
to support distributed flow control. The Scenario Table
has already been explained in Section 3. We describe the
Local Step Log and Registration Pool in this section.
The Local Step Log records all the steps of a
business process that have been executed. There are four
fields in the Local Step Log: Scenario ID, Instance ID,
Step ID, and Application ID. They are used to resolve
any ambiguity resulting from the dependencies among
the steps. We include Application ID in the log to allow
those co-located application systems to send messages to
each other.
In paired BOD transfers, it is possible for more than
one application to send the same BOD to a receiver and
wait for its replies in the same scenario instance. The
Registration Pool is used by the Activity Manager to
determine which sender should receive the reply. We
observe that the first BOD and the reply BOD share the
same key value. When the first BOD of a BOD pair
arrives at the adapter of the receiver, its key value is
extracted by the BOD Service Agent and stored in its
local registration pool. When the reply BOD comes out,
its key value is matched against the key values stored in
the Registration Pool to identify the record that contains
the matched key value. Once such a record is identified,
the sender of the first BOD, now the receiver of the reply
BOD, can be identified.

4.4. Algorithms for asynchronous and
synchronous BOD transfer
Asynchronous BOD transfer can be applied to both
one-way BODs and paired BODs. In the asynchronous
BOD transfer, the application does not want to be

blocked to wait for a reply BOD, after sending out the
first BOD of a BOD pair. Thus, the source ORB/RMI
adapter needs to immediately return to the Application
Adapter once the BOD is sent out to the target
ORB/RMI adapter. Subsequently, when the reply BOD
comes back to the adapter that sent out the first BOD, it
will be moved into the application. The synchronous
BOD transfer can be applied only to paired BODs. In
this type of transfer, the ORB/RMI Adapter does not
immediately return to the Application Adapter. After the
first BOD is sent out, a new thread is created to wait for
a reply BOD to come back. Once the reply BOD is
received, the ORB/RMI Adapter moves it into the
Application Adapter that has been waiting for the BOD.
Null is returned to the waiting application when a
timeout occurs. Detailed asynchronous and synchronous
BOD transfer algorithms are presented in [SU99].

4.5. Distributed flow control
To ensure scalability and reduce a potentially major
bottleneck, we have designed and implemented a
distributed flow control mechanism instead of using a
centralized one. The idea is to replicate the Scenario
Table, which contains the process steps of different
business scenarios at all the sites, and let the Flow
Control Module at each site make the decision on where
to deliver a BOD using local information only. Thus,
concurrent BOD transfers among application systems
can be carried out simultaneously. However, there is a
problem with this distributed flow control approach. The
problem is, "How does a Flow Control Module decide
which step of a scenario among many concurrent
scenarios that this BOD transfer belongs to, when
multiple scenarios may be involved in the transfer of the
same BOD with the same name and from the same
application system?" Even within a scenario, there may
be steps that call for the transfer of BODs with the same
BOD name by the same application system. To solve
this problem, upon the creation of a new scenario
instance, a new instance ID is created by the activity
manager. The instance ID together with the scenario ID
are passed into the application through its API to inform
the application to start the first step of the scenario. The
application does not process the scenario ID field in the
BOD. It simply copies the scenario ID from the
incoming BOD to the outgoing BOD that it generates.
When a BOD is sent out by the application, the NOUN
and VERB of the BOD and the application name of the
sender are known. Together with the scenario ID, they
can be used to match with the records of the Scenario
Table, which contains the process steps of all the
scenarios. Since the scenario ID and instance ID are used
in the matching, the Flow Control Module can always
find the right record in the scenario that represents the

BOD transfer. From this record, the receiver of the BOD
can be identified. SYNCSTEP information associated
with each of these matched records and the local Step
Log are used to determine whether the step is ready for
The above scheme works well if the BOD being
transferred is either the first BOD of a BOD pair or a
one-way BOD. If the transfer is the second BOD of a
BOD pair, the Registration Pool is used to aid the
resolution process, as described in Section 4.3

5. Implementation
The implemented ORB and RMI Adapters and their
supporting software modules form the Activity Manager,
which can operate both as a CORBA server and as an
RMI server.

Mleadata' MeTadalal
Manager Mariager'

S.. ...d- -

". .ORBAdpter ,-ORB Adapter I
reply BODAd pe t ,--- .. "*JA -) RB o a
"_ /!^ eq P, Oz 1

Adapter Adapter

Figure 2. BOD transfer through CORBA

The mechanism to send a BOD from one application
to another application through a CORBA infrastructure
is shown in Figure 2. The ORB Adapter of the Activity
Manger is operating as a CORBA server to remote ORB
Adapters, but it is also running as an RMI server so that
local modules (in particular, the Application Adapter)
can interact with the ORB Adapter through RMI. Thus,
the ORB Adapter at each site can service many
Application Adapters at the same site. When an
Application Adapter needs to send out a BOD, it will
dynamically load the RMI Client through the
configuration file to contact with the ORB Adapter. By
doing this, the Application Adapter can be further
decoupled with the ORB Adapter. Our implementation
of the ORB Adapter makes use of the commercial
product, lona's OrdixWeb [ION97].
In addition to supporting the CORBA environment,
the Activity Manager can also send and receive BODs

using Java's RMI. The mechanism of transferring BODs
through the RMI infrastructure is similar to that through
CORBA infrastructure. The main difference is the use of
an RMI Naming Server, which maintains a mapping
table for mapping Activity Manager names to the IP
addresses of the computers where they are running. It is
used to locate Activity Managers over the network.
Every RMI Adapter of the Activity Manager is an RMI
server as well as an RMI client. As an RMI client, it
registers itself with the RMI Name Server when it starts
up. After getting the RMI remote reference to the RMI
Adapter on the target side, the source side RMI Adapter
can connect to the remote RMI Adapter as an RMI client
and call the Receive method of the target RMI Adapter
to transfer the BOD. As an RMI server, the RMI Adapter
provides BOD transfer functions to both local
applications and remote RMI Adapters.

7. Acknowledgement

This project was supported by the Advanced Technology
Program of the National Institute of Standards and
Technology. It was a part of a consortium effort led by
IBM, Atlanta, which subcontracted the R&D task
reported in this paper to the University of Florida under
Contract Number CLT-H96227-00.

8. References

[COR98] Object Management Group. The Common Object
Request Broker: Architecture and Specification, 2.2 edition,
Feb. 1998.
[ION97] IONA Technologies PLC, OrbixWeb Programmer's
Reference, Dublin, Ireland, 1997.
[JAV] Sun Microsystems,
[LAM98] H. Lam and S. Y. W. Su, "Component
Interoperability in a Virtual Enterprise using
Events/Triggers/Rules," Proc. of OOPSLA '98 Workshop on
Objects, Components, and Virtual Enterprise, Vancouver, BC,
Canada, Oct. 18-22, 1998, pp. 47-53.
[LI98] H. Li, "Modeling and Validation of Business Object
Documents for Application System Integration", University of
Florida Master's thesis, Aug. 1998.
[OAG] OAG, "Open Applications Group Integration Spec.,"
[SU99] S. Y. W. Su, Y. Liu, J. Meng, M. Lee, and H. Lam,
"CORBA and RMI Infrastructures for Concurrent Synchronous
and Asynchronous Transfers of OAG's Business Object
Documents", CIMPLEX Consortium technical report,, 1999.
[ULT] Ultimus workflow, http://www.ultimus .com/.
[VIT1 Vitria BusinessWare Automator,

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs