P1: IML/FFX P2: IML/FFX QC: IML/FFX T1: IML
WL040C-192-Cecil WL040/Bidgolio-Vol I WL040-Sample.cls September 14, 2003 18:14 Char Count= 0
572 VIRTUALENTERPRISESCORBA Services
(Object Services)CORBA facilities
(Common Facilities)Object Request Broker
Application ObjectsFigure 4: The object management architecture.and programming languages (used for implementing
objects). CORBA supports interoperability by using a
well-defined set of interface specifications (Mowbray &
Zahavi, 1995).
CORBA is a specification for an application level com-
munication infrastructure. It can be viewed as a peer-to-
peer distributed computing facility capable of support-
ing seamless communication and information exchange,
which is the cornerstone of VE implementation. In a
CORBA context, all applications are viewed as objects.
These objects are capable of assuming dual roles as a
client and a server. A client invokes a service to which
another object (referred to as the server) responds. In gen-
eral, CORBA allows more flexibility from a computer ar-
chitecture point of view when compared to pure client–
server frameworks allowed by remote procedure calls
(RPCs).
While CORBA connects objects, the realization of a VE
requires any supporting computer architecture to support
enterprise integration. The object management architec-
ture (OMA) seeks to address this VE requirement (Fig-
ure 4) and is based on CORBA. The major components
of OMA include the object request broker, CORBAfacili-
ties, CORBAservices, and application objects. The object
request broker (ORB) can be viewed as a communication
infrastructure capable of relaying object requests and re-
sponses transparently across distributed computing envi-
ronments such as the Internet. The CORBAservices (also
referred to as object services) provide lower level function-
ality such as life-cycle services (such as object creation and
notification) and include providing access to online trans-
action processing (OLTP, the widely used application for
business accounting) and a “yellow pages” type of trader
service (where objects can offer their services at specified
costs).
The CORBA facilities (referred to as common facilities)
provide services for applications and have two major seg-
ments, horizontal and vertical. The horizontal facilities
can be widely used in a variety of industrial domains and
markets and include user interface, task management, in-
formation management, and systems management. The
vertical facilities deal with standardizing management
of information pertaining to specific industrial domainssuch as healthcare, manufacturing, and financial. An ex-
ample of the horizontal facility is the compound docu-
ment management facility, which allows applications a
standard way to access the various parts of a document.
Using this, a vendor can build tools for manipulation of
a part of the document (for instance, a three-dimensional
image), which can then be marketed without having to
develop the functionality from scratch.
The OMA and CORBA both facilitate the creation and
management of Internet-based software tools used in a
typical VE-oriented product development cycle. They al-
low engineers and managers in design, manufacturing,
and other areas to take advantage of a wide variety of
software tools implemented in various programming lan-
guages and on diverse operating systems (from a Macin-
tosh to a UNIX system). IT specialists and software pro-
grammers especially will benefit from using OMA/CORBA
because they provide a sophisticated mix of easy com-
ponent accessibility and transparent distribution; further,
code can be reused in new applications or can be modified
incrementally to suit the increasing scope of applications
in a VE. Tools and modules can be developed in a variety
of languages. For example, a Java-based program can be
used to perform a manufacturing optimization task (in
your VE) while a C++ module can be built to create a user
interface that is accessible to everyone in a VE.
The key to object interoperability in CORBA depends
on the definition of contracts termed “interfaces.” Each
object has an interface (which is public) and an implemen-
tation (which is private). The services of each object are
expressed as a type of contract in this interface, which pro-
vides two very important functions: (a) it informs other
client objects in the VE of the services it provides as well
as specifies how to be “called” (or invoked); and (b) it al-
lows the IT infrastructure to understand the specific man-
ner in which it will send and receive messages. The latter
allows for data translation between client and server ob-
jects. Each object in the VE also requires a unique identi-
fier or handle, which can be used to direct messages. The
interfaces of all the objects can be expressed in a neutral
language called the interface definition language (IDL). In
CORBA, the IDL definition for all objects is stored in an
interface repository. This repository is useful to achieve
object interoperability, which is a key issue in the cre-
ation of systems supporting the functions in an Internet-
based VE.
In CORBA, IDL is the means by which a particular ob-
ject implementation tells its potential clients what opera-
tions are available and how they should be invoked.When
an application object is created in a specific language such
as C or C++ (or any other language that can be mapped
to IDL), each object’s interface can be defined in IDL.
There are two ways for distributed objects to be linked
in CORBA: using static IDL interfaces or using the dy-
namic invocation interface (DII). When using static in-
terfaces (during implementation), the IDL specifications
are compiled for each interface into header, skeletal, and
stub programs for linking the Internet-based distributed
applications. When a client object (such as a task man-
ager located in VE site 1) invokes an operation on an ob-
ject reference, it links usingstubs(which are generated
automatically from an IDL compiler for the language and