The Internet Encyclopedia (Volume 3)

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

CREATION OFVIRTUALENTERPRISES 573

Internet

VE site 1 VE site 2

stub ORB mechanism

client server

Skeleton AdapterObject

Figure 5: Linking in a VE using stubs and skeletons.

ORB environment the client is implemented in). These

stubs convey this information to the target object via the

ORB (Figure 5). From the client’s perspective, the stub

acts like a local function call. After the stub interfaces

with the ORB, the ORB encodes and decodes the opera-

tion’s parameters into formats suitable for transmission

(this is termed “marshaling”). On the server object side

(the server may be a manufacturing analysis object or any

other application object located in another VE site 2), the

information is “unmarshaled” and a skeletal program in-

terfaces with the ORB through an object adapter. This

skeleton can map the request back to the implementation

language of the server object (the skeletal program is ob-

tained using an IDL compiler the server is running on).

When the ORB receives a request, the skeleton in essence

performs a call-back to the server object. After the server

completes processing the request, the results are returned

to the client via the skeleton/stub route (along with any re-

ported errors or problems encountered).

The static interface approach does not support the

dynamic use of newly created objects once they are in-

troduced into the VE’s network. The dynamic invoca-

tion interface provides this function and enables a client

to discover new objects and their interfaces, retrieve

their interface definitions, construct and send requests,

and receive the associated response from objects on the

Internet.

In CORBA, the encapsulation properties of the vari-

ous software objects enable location transparency in the

VE. In an encapsulated component, there are two parts:

thepublicinterface (presented to the outside world) and

theprivateimplementation (which is appropriately hid-

den from view). When a client sends a message, the in-

vocation is sent to the ORB (and not the target server

object); the ORB routes the message to the destination

or server object. Consequently, the location of the object

within the virtual enterprise does not matter. How the re-

sults were obtained is of concern only to the server com-

ponent (or object) and the client need not know how the

server processed its request. The interfaces can be viewed

as contracts by an object. By using IDL, which allows the

interfaces to be specified in a neutral language, it is pos-

sible to separate interfaces from the implementation. The

mapping from IDL to languages such as C, C++, Java, and

Smalltalk (among others) can be achieved by enabling var-

ious resources in a VE to be implemented in a variety of

programming languages running on heterogeneous plat-

forms ranging from UNIX to Windows. By using IDL to

specify interfaces, different VE partners and team mem-

bers can independently implement different parts of a dis-

tributed system, which can be used to accomplish target

Client

Server Object

Client

Internet

IIOP

Server

ORB 1

ORB 2

Figure 6: Clients and server objects communicating via the

Internet using IIOP.

life-cycle activities (ranging from design through testing

of a product). When application objects in a VE are moved

from one site to another in a VE, the ORBs can use the ob-

ject references to locate them. In general, the client does

not know whether a target server object is local or dis-

tributed (and linked using the Internet).

In any typical VE-oriented implementation, each Web

site of a company partner will have an ORB. ORBs

(whether implemented in the same language or in differ-

ent languages at each site) can communicate to each other

using the Internet Inter-ORB protocol (IIOP) (Figure 6).

The IIOP is the general inter-ORB protocol (GIOP) over

the TCP/IP, which is mandatory for CORBA 2.0 compli-

ance. The IIOP is based on the TCP/IP, which is the most

popular transport mechanism available today and is the

protocol of the Internet. Interoperable object references

enable invocations to pass from one (language) ORB to

another.

Security is an important issue in any distributed ap-

proach; use of various computers introduces issues of con-

sistency and trust between them. In a distributed system,

information is in transit and is more vulnerable to out-

side “attacks.” CORBAsecurity is part of the CORBAser-

vices and is flexible and can be modified to suit differ-

ent security needs (Seigel, 2000). The building blocks

of CORBAsecurity include identification and authentica-

tion of principals, authorization and access control, del-

egation, non-repudiation, cryptography and maintaining

availability, and performing security auditing to maintain

user accountability.

Personal computers (PCs) constitute the major seg-

ment of desktop computer systems used in industry today.

Using OMA/CORBA, PCs can become powerful partici-

pants in the design and functioning of VEs linked using

the Internet. Each ORB can be from a different vendor and

implemented in diverse programming languages. ORB

products can differ greatly yet conform to the OMG speci-

fications and guarantee interoperability over the Internet.

Some of the ORB products include ObjectBroker (from

the formerly known Digital Equipment Corporation), the

SOM product set (from IBM), the DAIS product set

(from ICL), Orbix (from Iona Technologies), Distributed

Smalltalk and ORB Plus (from Hewlett–Packard), and the

NEO product family (from SunSoft, Inc.). Additional in-

formation on CORBA and its specifications can be ob-

tained from the OMG Web site (OMG, 2002).