59

COMMON OB1ECT REQUEST BROKER ARCHITECHTURE

(CORBA)
REMOTE METHOD INVOCATION
RMI (Remote Method Invocation) is a way that a programmer, using the Java
programming language and development environment, can write object oriented programming
in which objects on different computers can interact in a distributed networ! RMI is the Java
version of what is generally nown as a remote procedure call (R"#), but with the ability to pass
one or more objects along with the re$uest! %he object can include information that will change
the service that is performed in the remote computer! &hen a user at a remote computer fills out
an e'pense account, the Java program interacting with the user could communicate, using RMI,
with a Java program in another computer that always had the latest policy about e'pense
reporting! In reply, that program would send bac an object and associated methods information
that would enable the remote computer program to screen the user(s e'pense account data in a
way that was consistent with the latest policy! %he user and the company both would save time
by catching mistaes early! &henever the company policy changed, it would re$uire a change to
a program in only one computer!
)n RMI re$uest is a re$uest to invoe the method of a remote object! %he re$uest has
the same synta' as a re$uest to invoe an object method in the same (local) computer! In general,
RMI is designed to preserve the object model and its advantages across a networ!
RMI is implemented as three layers*
) stub program in the client side of the client+server relationship, and a corresponding
seleton at the server end! %he stub appears to the calling program to be the program
being called for a service!
) Remote Reference ,ayer that can behave differently depending on the parameters
passed by the calling program! -or e'ample, this layer can determine whether the re$uest
is to call a single remote service or multiple remote programs as in a multicast!
) %ransport #onnection ,ayer, which sets up and manages the re$uest!
CORBA
#ommon .bject Re$uest /roer )rchitecture (#.R/)) is a competing distributed
systems technology that offers greater portability than remote method invocation! 0nlie RMI,
#.R/) isn(t tied to one language, and as such, can integrate with legacy systems of the past
written in older languages, as well as future languages that include support for #.R/)! #.R/)
isn(t tied to a single platform (a property shared by RMI), and shows great potential for use in the
60
future! %hat said, for Java developers, #.R/) offers less fle'ibility, because it doesn(t allow
e'ecutable code to be sent to remote systems!
#.R/) services are described by an interface, written in the Interface 1efinition ,anguage
(I1,)! I1, mappings to most popular languages are available, and mappings can be written for
languages written in the future that re$uire #.R/) support! #.R/) allows objects to mae
re$uests of remote objects (invoing methods), and allows data to be passed between two remote
systems! Remote method invocation, on the other hand, allows Java objects to be passed and
returned as parameters! %his allows new classes to be passed across virtual machines for
e'ecution (mobile code)! #.R/) only allows primitive data types, and structures to be passed 2
not actual code!
0nder communication between #.R/) clients and #.R/) services, method calls are passed to
.bject Re$uest /roers (.R/s)! %hese .R/s communicate via the Internet Inter2.R/ "rotocol
(II.")! II." transactions can tae place over %#" streams, or via other protocols (such as
3%%"), in the event that a client or server is behind a firewall! %he following diagram shows a
client and a server communicating!
RMI vs CORBA
#omparing RMI and #.R/) doesn(t reveal an optimum solution 2 one is not 4better4 than the
other! %he properties of these two technologies lend themselves to different situations! )
comparison of RMI and #.R/) helps to highlight individual strengths and weanesses, but the
applicability of one technology over the other depends largely on the purposes for which it is to
be used, the e'perience of the developers who will design, implement and maintain the
61
distributed system, and whether non2Java systems are intended to access the system now or in
the future!
RMI pros and cons
Remote method invocation has significant features that #.R/) doesn(t possess 2 most notably
the ability to send new objects (code and data) across a networ, and for foreign virtual machines
to seamlessly handle the new objects! Remote method invocation has been available since J15
6!78, and so many developers are familiar with the way this technology wors, and organi9ations
may already have systems using RMI! Its chief limitation, however, is that it is limited to Java
:irtual Machines, and cannot interface with other languages!
Advantages
"ortable across many platforms!
#an introduce new code to foreign J:Ms!
Java developers may already have e'perience with RMI (available since J156!78)!
;'isting systems may already use RMI 2 the cost and time to convert to a new technology
may be prohibitive.
Disadvantages
%ied only to platforms with Java support
<ecurity threats with remote code e'ecution, and limitations on functionality enforced by
security restrictions
,earning curve for developers that have no RMI e'perience is comparable with #.R/)
#an only operate with Java systems 2 no support for legacy systems written in #==, )da,
-ortran, #obol, and others (including future languages)!
CORBA pros and cons
#.R/) is gaining strong support from developers, because of its ease of use, functionality, and
portability across language and platform! #.R/) is particularly important in large
organi9ations, where many systems must interact with each other, and legacy systems can(t yet
be retired! #.R/) provides the connection between one language and platform and another 2 its
only limitation is that a language must have a #.R/) implementation written for it! #.R/)
also appears to have a performance increase over RMI, which maes it an attractive option for
systems that are accessed by users who re$uire real2time interaction
Pros
It is a open source component technology!
62
<ervices can be written in many different languages, e'ecuted on many different
platforms, and accessed by any language with an interface definition language (I1,)
mapping!
&ith I1,, the interface is clearly separated from implementation, and developers can
create different implementations based on the same interface!
#.R/) supports primitive data types, and a wide range of data structures, as parameters
#.R/) is ideally suited to use with legacy systems, and to ensure that applications
written now will be accessible in the future!
#.R/) is an easy way to lin objects and systems together
#.R/) systems may offer greater performance and rich set of services!
Cons
1escribing services re$uire the use of an interface definition language (I1,) which must
be learned! Implementing or using services re$uire an
I1, mapping to your re$uired language 2 writing one for a language that isn(t supported
would tae a large amount of wor!I1, to language mapping tools create code stubs
based on the interface 2 some tools may not integrate new changes with e'isting code!
#.R/) does not support the transfer of objects, or code!
<ome #.R/) specifications are still in a state of flu'!
>ot all classes of applications need real2time performance, and speed may be traded off
against ease of use for pure Java systems!
EVOLUTION OF CORBA
1istributed applications cause a lot of problems
? "articipating systems may be heterogeneous
? )ccess to remote services has to be location transparent
? Remote objects have to be found and activated
? <tate of objects has to be ept persistent and consistent
? <ecurity has to be dealt with
<o, to overcome these problems, we go for an architecture that supports a remote method
invocation paradigm, provides location transparency, allows adding, e'change, or remove
services dynamically hides system details from the developer!
CORBA CONCEPTS AND TERMINOLOGIES
#.R/) provides platform2independent programming interfaces and models for portable
distributed object2oriented computing applications! Its independence from programming
languages, computing platforms, and networing protocols maes it highly suitable for the
development of new applications and their integration into e'isting distributed systems!
Important terminologies available with #.R/) are*
63
) CORBA object is a 4virtual4 entity capable of being located by an .R/ and having
client re$uests invoed on it! It is virtual in the sense that it does not really e'ist unless it is made
concrete by an implementation written in a programming language! %he reali9ation of a #.R/)
object by programming language constructs is analogous to the way virtual memory does not
e'ist in an operating system but is simulated using physical memory!
) target object, within the conte't of a #.R/) re$uest invocation, is the #.R/) object
that is the target of that re$uest! %he #.R/) object model is a single-dispatching model in
which the target object for a re$uest is determined solely by the object reference used to invoe
the re$uest!
) client is an entity that invoes a re$uest on a #.R/) object! ) client may e'ist in an
address space that is completely separate from the #.R/) object, or the client and the #.R/)
object may e'ist within the same application! %he term client is meaningful only within the
conte't of a particular re$uest because the application that is the client for one re$uest may be
the server for another re$uest!
) server is an application in which one or more #.R/) objects e'ist! )s with clients,
this term is meaningful only in the conte't of a particular re$uest!
) request is an invocation of an operation on a #.R/) object by a client! Re$uests flow
from a client to the target object in the server, and the target object sends the results bac in a
response if the re$uest re$uires one!
)n object reference is a handle used to identify, locate, and address a #.R/) object! %o
clients, object references are opa$ue entities! #lients use object references to direct re$uests to
objects, but they cannot create object references from their constituent parts, nor can they access
or modify the contents of an object reference! )n object reference refers only to a single #.R/)
object!
) servant is a programming language entity that implements one or more #.R/)
objects! <ervants are said to incarnate #.R/) objects because they provide bodies, or
implementations, for those objects! <ervants e'ist within the conte't of a server application!
CORBA ARCHITECTURE
%he important functional units available with #.R/) architecture*
ORB interface* contains functionality that might be re$uired by clients or servers! It is the
highway on which all #.R/)2communications tae place! It is responsible for data marshaling,
.bject location management, 1elivering re$uests to objects and returning output values bac to
clients!
Marshaling: )fter an application component has obtained a reference to an object whose
services the component wants to use, that component can invoe methods of that object!
@enerally, these methods tae parameters as input and return other parameters as output!
)nother responsibility of the .R/ is to receive the input parameters from the component that is
calling the method and to marshal these parameters! &hat this means is that the .R/ translates
the parameters into a format that can be transmitted across the networ to the remote object! %he
64
.R/ also unmarshals the returned parameters, converting them from the on2the2wire format into
a format that the calling component understands!
Dynamic Invocation Interface (DII)* used for dynamically invoing #.R/) objects that were
not nown at implementation time servers!
ORB interface * contains functionality that might re$uired by clients and servers!
%he client ORB core transmits the re$uest to the .R/ core lined with the server application!
%he server ORB core dispatches the re$uest to the object adapter that created the target object!
Dynamic Skeleton Interface (DSI)* helps to implement generic #.R/) servants!
Basic Object Adapter (BOA)* )"I used by the servers to register their object implementations!
%he object adapter further dispatches the re$uest to the servant that is implementing the target
object!
Interface Repository* Registry of fully $ualified interface definitions and it provides type
information necessary to issue re$uests using the 1II!
)fter the servant carries out the re$uest, it returns its response to the client application!
ID Interface 1efinition ,anguage! %his specifies interfaces and is programming language
independent and does only contain data descriptions!
OMG's Object Management Architecture (OMA):
%he OMA 2 Object Management Architecture 2 categori9es objects into four categories* the
#.R/) services #.R/) facilities #.R/) domain objects, and )pplication .bjects! 3ere is
the classic .M) diagram*
65
)pplications benefit three ways from using the .M)*
6! #oding is $uicer, so applications can be deployed sooner!
8! )pplications designed around discrete services have better architecture!
A! Many .M) implementations have enterprise characteristics built in, they(re robust, and
they scale!
The Object Request Broker (ORB)
%he central component of #.R/) is the .bject Re$uest /roer (.R/)! %his component
provides all the communication infrastructure needed to identify and locate objects, handle
connection management, and deliver data and re$uest communication! .ne #.R/) object
never tals directly with another! Instead, the object re$uests for an interface to the .R/ running
on the local machine! %he local .R/ then passes the re$uest to an .R/ on the other machine!
%he remote .R/ then locates the appropriate object and passes bac an object reference to the
re$uester!
%he functions of the .R/ are as follows*
,ooup and instantiate objects on remote machines
Marshal parameters from one application object to the other
3andle security issues across machine boundaries
Retrieve and publish data on objects on the local machine for another .R/ to use
Invoe methods on a remote object using static method invocation
Invoe methods on a remote object using dynamic method invocation
)utomatically instantiate objects not currently running
Route callbac methods to the appropriate local object being managed
#ommunicate with other .R/s using the Internet Inter2.R/ "rotocol (II.")
CORBA Services
66
%he .bject Management )rchitecture (.M)), of which #.R/) is a part, defines a
number of services that are useful to applications in general! %hese services range from the
nearly indispensable >aming <ervice to higher level services such as the %ransaction <ervice!
Concurrency Control Service
%he #oncurrency #ontrol <ervice provides an interface for managing concurrency in shared
#.R/) objects! %his is done through the use of locs, several types of which are supported by
the service!
Event Service
%he ;vent <ervice provides a mechanism through which #.R/) objects can send and
receive events! %he service includes such features as these*
Reliable delivery, which (simply put) ensures that an event will reach its
destination(s)!
<upport for push and pull models of event delivery
)nonymous messaging, when suppliers need not now the identities of event
consumers, or vice versa
;vent channels, a mechanism similar to publish+subscribe, through which consumers
can subscribe to certain types of events
Externalization Service
%he ;'ternali9ation <ervice provides interfaces for e'ternali9ing (that is, seriali9ing) and
internali9ing objects! &hen an object is e'ternali9ed, it can be internali9ed within the same
process or a different process! In addition, objects can be e'ternali9ed into a portable file format
(one that is defined with the ;'ternali9ation <ervice <pecification)! .ne possible application for
the ;'ternali9ation <ervice is in a pass2by2value mechanism for #.R/) objects!
Licensing Service
%he ,icensing <ervice enables the provider to define policies that control the use of services!
%he service supports three types of licensing policies*
Time enables a license to set a start date, e'piration date, and duration!
67
Value mapping enables licensing based on units (resource usage metering, number of
concurrent users, and so on)!
Consumer assigns services for use by a particular user or machine!
Life Cycle Service
%he ,ife #ycle <ervice offers facilities for creating, deleting, copying, and moving
#.R/) objects! %he service also supports the notion of an object factory, which is a #.R/)
object that creates other #.R/) objects!
Naming Service
%he >aming <ervice enables #.R/) objects to register and be located by name! %his
service uses the notion of a naming context, which contains a set of uni$ue names! %he >aming
<ervice also supports a federated architecture, meaning that name servers can be distributed
across the networ and wor in conjunction with each other!
Object Trader Service
%he %rader <ervice, lie the >aming <ervice, enables other objects to locate #.R/)
objects! Rather than use a name to locate an object, a client object loos for services based on
operation names, parameters, and result types!
Persistent Object Service
%he "ersistent .bject <ervice provides a set of interfaces for managing the persistence of
objects! %ypically, implementations for this service are provided by database vendors!
Property Service
%he "roperty <ervice enables objects to define sets of properties, which are name+value
pairs! %he name in a pair is simply a #.R/) stringB the value is a #.R/) any! )ccess to
properties can be restricted! -or e'ample, a property can be read2only or fi'ed!
Query Service
%he Cuery <ervice supports the use of $ueries on objects! Cueries can contain predicates
that specify objects to act on, based on attribute values! %he service also supports object inde'ing
as well as nested $ueries! Cuery capability provides database2lie semantics to #.R/) objects!
Just as an application can perform $ueries on tables and rows in a relational database, the Cuery
<ervice allows an application to perform $ueries on #.R/) objects!
Relationship Service
68
%he Relationship <ervice enables the representation of relationships between objects! It
provides for full constraint checing of relationship type and cardinality (one2to2many, one2to2
one, and so on) and also wors in conjunction with the ,ife #ycle <ervice to copy, move, and
remove related objects! Managing relationships between objects is, of course, possible without
the Relationship <ervice, but this service reduces the comple'ity of managing comple'
relationships!
Security Service
%he <ecurity <ervice specifies the interfaces for security features*
Identification and authentication of users, which verify that a user is who he or she
claims to be!
Authoriation and access control determine which users are enabled access to which
services or objects!
!ecurit" auditing, which provides records of users( actions!
!ecurit" of communication, which includes authentication of users to services (and
vice versa), integrity protection, and confidentiality protection!
#on-repudiation, which provides capabilities similar to those offered by digital
signaturesB that is, the origin of data or the receipt of data can be proven irrefutably!
Administration of various security policies!
Time Service
%he %ime <ervice enables a user to obtain the current timeB it can determine event
ordering and can generate events based on timers!
Transaction Service
%he %ransaction <ervice provides the interfaces to support transaction capabilities! It
supports flat and nested transaction models as well as e'ternal %" monitors! %ransaction services
can also interoperate with each other!
Horizontal CORBAfacilities
%hese facilities sit between the #.R/)services and )pplication .bjects ! 0nlie the 1omain
#.R/)facilities , these facilities are potentially useful across business domains! %here are only
four hori9ontal #.R/)facilities*
%he "rinting -acility
%he <ecure %ime -acility
69
%he Internationali9ation -acility
%he Mobile )gent -acility (%he only category in the .M) that lacs a %as -orce of its
own at the .M@)!
Vertical CORBAfacilities
In addition to the hori9ontal services and facilities offered by the .M), there are also a
number of vertical #.R/)facilities22facilities intended for the uni$ue re$uirements of
specific marets! )lso, the .M@ continually adds new :ertical Maret -acilities, depending
on the interest in a particular specialty area! <ome of the :ertical Maret -acilities
specifications available are listed below*
Imager" supports the access and interchange of imagery and related data!
Information !uperhigh$a"s consists of a set of networs, protocols, and rules,
information repositories connected through these networs, and a collection of tools for
transparent access to this information!
%anufacturing represents the integration of manufacturing functions and resources with
other aspects of the business enterprise!
&istri'uted !imulation supports distributed simulations of air traffic control, video games
and entertainment, and other needs!
Oil and (as Industr" )xploration and *roduction provides a foundation for defining
specifications for e'ploration and production (;D")! Re$uirements for ;D" include
dealing with large $uantities of data, comple' algorithms, and long2term data storage!
Accounting provides an interoperable approach to accounting interfaces and sees to
remove the comple'ity from accounting service providers and end users!
Application &evelopment covers the selection, development, building, and evolution of
the applications needed to support an enterprise(s information systems strategy! %apping
provides a cohesive means of manipulating the flow of data from databases through
constructed analysis modules into either presentation tools or secondary data
applications!
Application objects
%hey are at the topmost part of the .M) hierarchy! <ince they are typically customi9ed for an
individual application and do not need standardi9ation, this category identifies objects that are
not affected by .M@ standardi9ation efforts!
CORBA and the Networking Model
;ssentially, #.R/) applications are built on top of @I."2derived protocols such as
II."! %hese protocols, in turn, rest on top of %#"+I", 1#;, or whatever underlying transport
70
protocol the networ uses! #.R/) applications aren(t limited to using only one of these
protocolsB an application architecture can be designed to use a bridge that would interconnect, for
instance, 1#;2based application components with II."2based ones! Eou can see, then, that
rather than supplant networ transport protocols, the #.R/) architecture creates another layer22
the inter2.R/ protocol layer22which uses the underlying transport layer as its foundation! %his,
too, is a ey to interoperability between #.R/) applications, as #.R/) does not dictate the
use of a particular networ transport protocol!
)side from ;<I."s, all #.R/) protocols are based on the (eneral Inter-ORB *rotocol
(@I.")! %his protocol defines the different message types (such as re$uest and reply messages)
that can be e'changed between client and server applications and also specifies a binary format
for the on2the2wire representation of I1, types (boolean, long, string, enum, struct, se$uence,
union and so on)!
General InterORB Protocol (GIOP)
%he @I." is an abstract protocol by which .bject re$uest broers (.R/s) communicate!
<tandards associated with the protocol are maintained by the .bject Management @roup
(.M@!)! %he @I." architecture provides several concrete protocols*
6! Internet Inter.R/ "rotocol (II.") F %he Internet Inter-Orb Protocol is an
implementation of the @I." for use over an internet, and provides a mapping between
@I." messages and the %#"+I" layer!
2. <<, Inter.R/ "rotocol (<<,I.") F <<,I." is II." over <<,, providing encryption
and authentication!
3. 3yper%e't Inter.R/ "rotocol (3%I.") F 3%I." is II." over 3%%", providing
transparent pro'y bypassing!
G! and many more!!!
71
CORBA specification is neutral with respect to network protocols
the #.R/) standard specifies what is nown as the @eneral Inter2.R/ "rotocol
(@I.")
@I." is a high2level standard protocol for communication between .R/s
not used directlyB instead, it is speciali9ed by a particular protocol that would then
be used directly
Internet Inter-ORB Protocol (IIOP)
II." is the @I."2based protocol for %#"+I" networs
)s of the 8!7 version of the #.R/) specification, vendors are re$uired to
implement the II." protocol
CORBA Networking Model
72
#.R/) applications are built on top of @I."2derived protocols such as II."!
these protocols, in turn, rest on top of %#"+I", 1#;, or other underlying transport
protocol the networ uses
STATIC INVOCATION
&hen using static invocation, the #.R/) client application invoes operations directly on the
client stubs! <tatic invocation is the easiest, most common type of invocation! %he stubs are
generated by the I1, compiler! <tatic invocation is recommended for applications that now at
compile time the particulars of the operations they need to invoe and can process within the
synchronous nature of the invocation! /elow figure illustrates static invocation!
-igure 6<tatic Invocation
<tatic interfaces are generated in form of client stubs by the I1, (pre2) compiler!
%his means that the structure of the object has to be nown before hand (at
compile time)!
)llows for better type checingB less runtime overheadB self2documentation
DYNAMIC INVOCATION
&hile dynamic invocation is more complicated, it enables your #.R/) client application to
invoe operations on any #.R/) object without having to now the #.R/) object(s interfaces
at compile time! &hen using dynamic invocation, the #.R/) client application can
dynamically build operation re$uests for a #.R/) object interface that has been stored in the
Interface Repository! #.R/) server applications do not re$uire any special design to be able to
receive and handle dynamic invocation re$uests! 1ynamic invocation is generally used when the
#.R/) client application re$uires deferred synchronous communication, or by dynamic client
73
applications when the nature of the interaction is undefined! /elow figure illustrates dynamic
invocation!
-igure 8 1ynamic Invocation
1ynamic Invocation Interface (1II) allows clients to invoe operations on remote
objects without having access to object stubs (another way to do this without
dynamic invocation is to download static client stubs via a Java applet)!
#lients must discover interface2related information at runtime (e!g!, using the
interface repository)
<ervers can offer new services anytime without the need for recompilation on the
client side!
Steps for using DII:
6! .btain an object reference!
8! #reate a Re$uest object using the object reference!
A! "opulate the Re$uest object with the parameters to the operation!
G! Invoe the re$uest!
H! .btain the result, if necessary!
1.Obtaining an Object Reference:
obtain an object reference of interface type .bject (defined in pacage org!omg!#.R/)) that
references the target object!
74
If the full object reference of the target object is nown in character string format, an object
reference, of a type that implements org!omg!#.R/)!.bject, can be constructed to facilitate
maing a dynamic invocation on it! -or e'ample, you can invoe the method stringItoIobject()
on the org!omg!#.R/)!.R/ object as follows*
++ Java
import org!omg!#.R/)!.bjectB
import org!omg!#.R/)!.R/B
.R/ orb J .R/!init(args, null)B
.bject o J orb!stringItoIobject (ref<tr)B
2.Creating a Request:
#.R/) specifies two ways to construct a Request object!
_request()
%he method Ire$uest() is defined in interface org!omg!#.R/)!.bject It is declared as*
++ Java
++ in pacage org!omg!#.R/),
++ in interface .bject
import org!omg!#.R/)!Re$uestB
public Re$uest Ire$uest(<tring operation)B
%his method taes a single parameter which specifies the name of the operation to be invoed on
the target object!
_create_request()
%here is also a IcreateIre$uest() methods defined in interface .bject! It is declared as*
++ Java
++ in pacage org!omg!#.R/),
++ in interface .bject
import org!omg!#.R/)!Re$uestB
import org!omg!#.R/)!#onte'tB
import org!omg!#.R/)!>amed:alueB
import org!omg!#.R/)!>:,istB
Re$uest IcreateIre$uest(#onte't ct', <tring operation,
>:,ist argIlist,>amed:alue result)B
75
3.Setting up a Request Using _request()
Eou can set up a re$uest by invoing Ire$uest() on the target object, and specifying the name of
the operation that is to be dynamically invoed
%he following steps are re$uired in setting up a Re$uest using the Ire$uest() method*
6! .btain an object reference to the target object! %he stringified object reference obtained
earlier is used*
++ Java
import org!omg!#.R/)!.bjectB
import org!omg!#.R/)!.R/B
import org!omg!#.R/)!Re$uestB
.R/ orb J .R/!init(args, null)B
.bject o J orb!stringItoIobject (ref<tr)B
6! #onstruct a Re$uest object by calling Ire$uest() on the target object, as follows*
Re$uest re$uest J o!Ire$uest(4new)ccount4)B
6! "opulate the Re$uest! %he most efficient and straightforward approach to populating a
1II Re$uest is the one used by the .rbi' Java I1, generated stubs! %his approach taes
advantage of the following methods in the org!omg!#.R/)!Re$uest class*
import org!omg!#.R/)!)nyB
import org!omg!#.R/)!%ype#odeB
!!!
)ny addIinIarg()B
)ny addIinoutIarg()B
)ny addIoutIarg()B
void setIreturnItype(%ype#ode tc)B
)ny returnIvalue()B
4.Invoking a Request
.nce the parameters are inserted, you can invoe the re$uest as follows*
++ Java
++ <end Re$uest and get the outcome
import org!omg!#.R/)!<ystem;'ceptionB
!!!
try K
re$uest!invoe ()B
if ( re$uest!env()!e'ception() LJ null )
throw re$uest!env()!e'ception()B
M
catch (<ystem;'ception e') K
76
!!!
M
catch ( java!lang!;'ception e' )K
!!!
M
5.Operation Results
.nce the invocation has been made, the return value and output parameters can be e'amined! If
there are any out or inout parameters, then these parameters would be modified by the call, and
no special action is re$uired to access their values! %heir values are contained in the >:,ist
argument list which can be accessed using the method Re$uest!arguments()!
%he operation(s return value (if it is not void) can be accessed using the method Re$uest!result()
which returns a >amed:alue!
INTEROPERABILITY ISSUES
1. OMG INTERFACE DEFINITION LANGUAGE
%he Interface &efinition +anguage ,I&+- is a standard language used to define the
interfaces used by #.R/) objects! 3owever, it is not a procedural languageB it can define only
interfaces, not implementations! %he I1, specification is responsible for ensuring that data is
properly e'changed between dissimilar languages! %he I1, language is part of the standard
#.R/) specification and is independent of any programming language! It achieves this
language independence through the concept of a language mapping!
%he clientNs interface to a remote object is defined using Interface 1efinition ,anguage!
%his definition is placed in a interface definition file, which is then compiled using idlj compiler
that translates the I1, interface into a java interface and generates other files that contain the
class code for stubs and seleton code that enables lining application into .R/! %he .R/
provides the >)M; <;R:I#; that is necessary to locate the server and reference the object on
the server! %he client then can use the reference and the stub to called methods of the object! .n
the server side, the seleton code that is produced by the idlj compiler is used to implement
objectNs methods! %he seleton code is used to start .R/ and wait for a re$uest from the client!
IDL COMPILER
77
1uring compiling, I1, conventions are mapped to java conventions and the following
helper and holder files (supporting files) are created*
myAppPOA.java * %his is an abstract class that contains the server seletons and is used to
provide #.R/) functionality to the server!
myAppStub.java * %his is the stub used by the client and implements the my)pp!java interface!
myApp.java * %his is the java interface of the I1, interface!
myAppHelper.java * %his final class casts #.R/) object references to their proper type!
myAppHolder.java* %his final class provides public instance members for out and inout
arguments!
myAppOperations.java * %his file contains the mapping of operations that are defined in the
I1, interface! <tubs and seletons share this file!
LANGUAGE MAPPING
) language mapping is a specification that maps I1, language constructs to the
constructs of a particular programming language! /ecause .M@ I1, is a declarative language, it
cannot be used to write actual applications! It provides no control constructs or variables, so it
cannot be compiled or interpreted into an e'ecutable program! It is suitable only for declaring
interfaces for objects and defining the data types used to communicate with objects!
+anguage mappings specify how I1, is translated into different programming languages!
-or each I1, construct, a language mapping defines which facilities of the programming
language are used to mae the construct available to applications!
78
-or e'ample, in #==, I1, interfaces are mapped to classes, and operations are mapped to
member functions of those classes! <imilarly, in Java, I1, interfaces are mapped to public Java
interfaces!
OB1ECT ADAPTORS
In #.R/), object adapters serve as the glue between servants and the .R/! )s
described by the )dapter design pattern, which is independent of #.R/), an o'.ect adapter is
an object that adapts the interface of one object to a different interface e'pected by a caller! In
other words, an object adapter is an interposed object that uses delegation to allow a caller to
invoe re$uests on an object without nowing the object(s true interface!
#.R/) object adapters fulfill three ey re$uirements namely
%hey create object references, which allow clients to address objects!
%hey ensure that each target object is incarnated by a servant!
%hey tae re$uests dispatched by a server2side .R/ and further direct them to the
servants incarnating each of the target objects!
&ithout object adapters, the .R/ would have to directly provide these features in addition to
all its other responsibilities! )s a result, it would have a very comple' interface that would be
difficult for the .M@ to manage, and the number of possible servant implementation styles
would be limited!
0ntil version 8!6, #.R/) contained specifications only for the /asic .bject )dapter
(/.))! %he /.) was the original #.R/) object adapter, and its designers felt that it would
suffice for the majority of applications, with other object adapters filling only niche roles!
3owever, #.R/) did not evolve as e'pected because of the following problems with the /.)
specification!
%he /.) specification did not account for the fact that, because of their need to support
servants, object adapters tend to be language2specific! %hat is!, an object adapter that provides
solid support for servants in one programming language is not liely to also provide ade$uate
support for servants written in a different language because of differences in implementation
style and usage of those servants!
) number of critical features were missing from the /.) specification! #ertain
interfaces were not defined and there were no servant registration operations! ;ven those
operations that were specified contained many ambiguities!
#.R/) version 8!8 introduced the "ortable .bject )dapter to replace the /.)! /ecause
the ".) addresses the full gamut of interactions between #.R/) objects and programming
language servants while maintaining application portability, the $uality of the ".) specification
is vastly superior to that of the /.)! )s a result, the /.) specification has been removed from
#.R/)!
%he re$uest flow through ".) is given as
79
%his diagram depicts a high2level view of the client and server .R/ subsystems involved
in dispatching a re$uest! -irst, the server application somehow e'ports an object reference for a
#.R/) object! %he client obtains the e'ported object reference for the object, perhaps via the
>aming <ervice or the %rading <ervice or by receiving it from another re$uest invocation!
2 . NETWORK ORB INTEROPERABILITY
Interoperability is the ability of distinct hardware or software components to interoperate
by e'ecuting services available with one component by another through arguments passed
between them by using a common communication format! @eneral Inter2.R/ "rotocol (@I."),
which specifies, on a high level, a standard for communication between various #.R/) .R/s
and components! @I.", as its name suggests, is only a general protocolB the #.R/) standard
also specifies additional protocols that speciali9e @I." to use a particular transport protocol! -or
instance, @I."2based protocols e'ist for %#"+I" and 1#;! %he (eneral Inter-ORB *rotocol
,(IO*- is a high2level standard protocol for communication between .R/s! /ecause @I." is a
generali9ed protocol, it is not used directlyB instead, it is speciali9ed by a particular protocol that
would then be used directly!
%hus Internet Inter2.R/ protocol comes into the picture as the connecting bridge
between various networ protocols available at present!
80
II." provides general communication format specification and deals with all the
transactions done between the remote clients and the servers! ;'ploring #.R/) in networ of
heterogeneous systems need this type of standards in order to mae the object passing and
referencing an Independent activity!
II." specifies common format for*
object references, nown as the Interoperable .bject Reference (I.R)
Messages e'changed between a client and the object
and describes how agents open %#"+ I" connections and use them to transfer @I." messages
standard communication protocol between .R/s
%he commonly e'plored communication protocol for #.R/) is the #.R/) .bject
model which uses .bject 1istribution and .bject References by /asic or "ortable .bject
)daptors!
Interoperable Object Reference (IOR)
%he #.R/) maret provides many strategies, standards, and products for locating
#.R/) objects, but only one mechanism wors for all II."2compliant #.R/)
implementations* Interoperable .bject References (I.Rs)! &hen woring in a multiple2.R/
environment, an I.R usually provides the only means to obtain an initial reference to an object,
be it a naming service, transaction service, or customi9ed #.R/) servant! .R/s supporting
II." identify and publish object references using I.Rs! )n I.R contains the information
re$uired for a client .R/ to connect to a #.R/) object or servant! <pecifically, an I.R
contains the following*
IIOP version: 1escribes the II." version implemented by the .R/!
Host: Identifies the %#"+I" address of the .R/(s host machine!
81
Port: <pecifies the %#"+I" port number where the .R/ is listening for client
re$uests!
Key: :alue uni$uely identifies the servant to the .R/ e'porting the servant!
Components: ) se$uence that contains additional information applicable to object
method invocations, such as supported .R/ services and proprietary protocol
support!
%he I.R is represented through a <tring instance by a process nown as stringification/
<tringification is the process of converting a servant reference to and from a string representation
of an I.R! .nce an object reference has been stringified, it can be used by other applications to
obtain a remote servant reference! I.Rs are convenient because they are easy to use and are
.R/2implementation2independent!
COS Naming Service
%he #.< >aming <ervice is an .M@2specified e'tension to the core #.R/) standard,
where #.< stands for #ommon .bject <ervice! %his naming service allows an object to be
published using a symbolic name, and it allows client applications to obtain references to the
object using a standard )"I! %he #.< >aming <ervice can reside on any host accessible within
the networ and enables applications to publish, looup and list #.R/) object references from
any networ host! %he naming service maps human2readable names to object references and
stores those names in a namespace! %his name2to2object reference is called a name binding! %o
resolve a name means to find the object associated with the name! %o bind a name is to create a
name2to2object association! %here is an option to associate one or more names with an object
reference! ;very object has a uni$ue reference! %he naming service organi9es the namespace in a
treelie structure of naming conte'ts! ) naming conte't contains a list of one or more names that
have been bound to an object or to another naming conte't object! >ame conte't hierarchies
enable clients to navigate through the different naming conte't trees to find the objects they
want! >aming conte'ts from different domains can be used together to create federated name
services for object!
)ll #.R/) interfaces are defined using the language2neutral .M@ Interface 1efinition
,anguage (I1,)! %he .M@ then provides language2specific mappings from the .M@ I1, to
Java , enabling implementation of the #.R/) interfaces in Java! %he #os>aming module
(mapped to the org!omg!#os>aming pacage in Java) provides all the interfaces re$uired by the
#.R/) >aming <ervice with the resulting ey Java interfaces as follows*
!amingConte"t#
%his, the central interface in #os>aming, provides operations to bind names to object
references and creates subconte'ts to resolve names to object references!
!ameCom$onent#
%his represents the names, defined as se$uences of >ame#omponent objects! )ll that
is really re$uired is to set the id for the >ame#omponent!
82
Bin%ing Iterator:
%he >aming#onte't list method returns a /indingIterator object that enables you to
iterate on a set of names and thus traverse the naming hierarchy!
>aming#onte't and /indingIterator are the two ey interfaces that implement the
naming service! >aming#onte't objects contain a set of name2to2object bindings! %he
newIconte't method returns a naming conte't! %he bindInewIconte't method creates a new
conte't and binds it to the name we supply! &e can invoe the bind method on the
>aming#onte't object to associate an object(s name with a naming conte't! &e can use rebind to
bind a name that already e'istsB this will create a naming hierarchy! &e can unbind to remove a
name from a binding conte't! -inally, the destroy method deletes a naming conte't! &e can find
a named object by using the resolve method! %his will retrieve an object bound to a name in a
given conte't! &e can then use the list method, which returns a /indingIterator object to iterate
through a returned set of names! J15 6!8 and its higher versions have with the following*
&ava ID Object Request Bro'er#
%his is compliant with the #.R/)+II." 8!7 <pecification and supports transient
#.R/) objects 2 objects with lifetimes limited by their server process( lifetime!
&ava Ma$$ing of the CORBA ($ecifications containe% in the follo)ing $ac'ages:
org!omg!#.R/) 2 contains the core #.R/) interfaces and classes!
org!omg!#.R/)!#ontained"acage 2 contains a class describing a #.R/) object in a
#.R/) container!
org!omg!#.R/)!Interface1ef"acage 2 contains a class that is the description of a
#.R/) interface definition
org!omg!#.R/)!.R/"acage 2 contains a class for the #.R/) Invalid>ame
e'ception!
org!omg!#.R/)!%ype#ode"acage 2 contains classes for #.R/) e'ception that can be
thrown by %ype#ode operations!
org!omg!#os>aming 2 contains classes and interfaces for communicating with the
#.R/) >aming <ervice!
org!omg!#os>aming!>aming#onte't"acage 2 contains helper and holder classes for
#.R/) e'ceptions that can be thrown by the #.R/) >aming <ervice!
*ransient CORBA !aming (ervice+ tnameserv+ store% in the bin %irectory:
%his service does not store any namespace information and all namespace data is lost
once the naming service is closed! %his provides a base implementation so that developers
can test their applications, but a full persistent implementation will re$uire the purchase of a
commercial naming service!
CREATING THE IDL INTERFACE:
83
Java
%M
I1, is a technology for distributed objects22that is, objects interacting on
different platforms across a networ! Java I1, enables objects to interact regardless of whether
they(re written in the Java programming language or another language such as #, #==, #./.,,
or others!
%his is possible because Java I1, is based on the #ommon .bject Re$uest /roerage
)rchitecture (#.R/)), an industry2standard distributed object model! ) ey feature of #.R/)
is I1,, a language2neutral Interface 1efinition ,anguage! ;ach language that supports #.R/)
has its own I1, mapping22and as its name implies, Java I1, supports the mapping for Java!
%o support interaction between objects in separate programs, Java I1, provides an
.bject Re$uest /roer, or .R/! %he .R/ is a class library that enables low2level
communication between Java I1, applications and other #.R/)2compliant applications!
Define the remote interface
Eou define the interface for the remote object using the .M@(s Interface
1efinition ,angauge (I1,)! Eou use I1, instead of the Java language because the idlj
compiler automatically maps from I1,, generating all Java language stub and seleton
source files, along with the infrastructure code for connecting to the .R/! )lso, by using
I1,, you mae it possible for developers to implement clients and servers in any other
#.R/)2compliant language!
>ote that if you(re implementing a client for an e'isting #.R/) service, or a
server for an e'isting client, you would get the I1, interfaces from the implementer22
such as a service provider or vendor! Eou would then run the idlj compiler over those
interfaces and follow these steps!
Compile the remote interface
&hen you run the idlj compiler over your interface definition file, it generates the
Java version of the interface, as well as the class code files for the stubs and seletons
that enable your applications to hoo into the .R/!
Implement the server
.nce you run the idlj compiler, you can use the seletons it generates to put
together your server application! In addition to implementing the methods of the remote
interface, your server code includes a mechanism to start the .R/ and wait for
invocation from a remote client!
Implement the client
<imilarly, you use the stubs generated by the idlj compiler as the basis of your
client application! %he client code builds on the stubs to start its .R/, loo up the server
84
using the name service provided with Java I1,, obtain a reference for the remote object,
and call its method!
Declaring the CORBA IDL Module
) #.R/) module is a namespace that acts as a container for related interfaces and
declarations! It corresponds closely to a Java pacage! ;ach module statement in an I1, file is
mapped to a Java pacage statement! %he module statement loos lie this*
module modname
K
++ <ubse$uent lines of code here!
MB
&hen you compile the I1,, the module statement will generate a pacage statement in
the Java code!
Declaring the Interface
,ie Java interfaces, #.R/) interfaces declare the )"I contract an object has with other
objects! ;ach interface statement in the I1, maps to a Java interface statement when mapped! In
your intfname!idl file, the interface statement loos lie this*
module modname
K
interface intfname ++ %hese lines
K ++ declare the
++ interface
MB ++ statement!
MB
&hen you compile the I1,, this statement will generate an interface statement in the
Java code!
Declaring the Operations
#.R/) operations are the behavior that servers promise to perform on behalf of clients
that invoe them! ;ach operation statement in the I1, generates a corresponding method
statement in the generated Java interface! In your modname!idl file, the operation statement loos
lie this*
module modname
K
interface intfname
K
string method6()B ++ %his line is an operation statement!
85
void method8()B ++ %his line is another
MB
MB
%he tool idlj reads .M@ I1, files and creates the re$uired Java files!;nter the compiler
command*
idlj 2fall 3ello!idl
%he idlj compiler generates a number of files! %he actual number of files generated depends
on the options selected when the I1, file is compiled! %he generated files provide standard
functionality, so you can ignore them until it is time to deploy and run your program! 0nder
J8<; v!6!G, the files generated by the idlj compiler for intfname!idl, with the 2fall command line
option, are*
intfnamePOA.java
%his abstract class is the stream2based server seleton, providing basic #.R/)
functionality for the server! It e'tends org!omg!"ortable<erver!<ervant, and implements
the Invoe3andler interface and the intfname.perations interface! %he server class,
intfname<ervant, e'tends intfname".)!
IintfnameStub.java
%his class is the client stub, providing #.R/) functionality for the client! It e'tends
org!omg!#.R/)!portable!.bjectImpl and implements the intfname!java interface!
intfname.java
%his interface contains the Java version of our I1, interface! %he intfname!java interface
e'tends org!omg!#.R/)!.bject, providing standard #.R/) object functionality! It
also e'tends the intfname.perations interface and org!omg!#.R/)!portable!I1,;ntity!
intfnameHelper.java
%his class provides au'iliary functionality, notably the narrow() method re$uired to cast
#.R/) object references to their proper types! %he 3elper class is responsible for
reading and writing the data type to #.R/) streams, and inserting and e'tracting the
data type from )nys! %he 3older class delegates to the methods in the 3elper class for
reading and writing!
intfnameHolder.java
%his final class holds a public instance member of type intfname! &henever the I1, type
is an out or an inout parameter, the 3older class is used! It provides operations for
org!omg!#.R/)!portable!.utput<tream and org!omg!#.R/)!portable!Input<tream
arguments, which #.R/) allows, but which do not map easily to Java(s semantics! %he
86
3older class delegates to the methods in the 3elper class for reading and writing! It
implements org!omg!#.R/)!portable!<treamable!
HelloOperations.java
%his interface contains the methods method6() and method8()! %he I1,2to2Java mapping
puts all of the operations defined on the I1, interface into this file, which is shared by
both the stubs and seletons!
Declaring the Servant Class
-irst, we import the pacages re$uired for the server class*
++ %he pacage containing our stubs
import 3ello)pp!OB
++ 3ello<erver will use the naming service
import org!omg!#os>aming!OB
++ %he pacage containing special e'ceptions thrown by the name service
import org!omg!#os>aming!>aming#onte't"acage!OB
++ )ll #.R/) applications need these classes
import org!omg!#.R/)!OB
++ #lasses needed for the "ortable <erver Inheritance Model
import org!omg!"ortable<erver!OB
import org!omg!"ortable<erver!".)B
++ "roperties to initiate the .R/
import java!util!"ropertiesB
In this e'ample, we are defining the class for the servant object outside the <ervant!java
class!
class Impl e'tends intfname".)
K
++ %he method6() and method8() methods go here!
M
%he servant is a subclass of intfname".) so that it inherits the general #.R/)
functionality generated for it by the compiler!
87
-irst, we create a private variable, orb that is used in the set.R/(.R/) method! %he
set.R/ method is a private method defined by the application developer so that they can set the
.R/ value with the servant! %his .R/ value is used to invoe method() on that specific .R/ in
response to the method() method invocation from the client!
private .R/ orbB
public void set.R/(.R/ orbIval) K
orb J orbIvalB
M
>e't, we declare and implement the re$uired method() method*
public <tring method() K
return 4Pn3ai worldLLPn4B
M
CLIENT:
.nce the #.R/) I1, module is compiled, the client2side application can be developed
that will re$uest the services of the object! %he client2side application is class that re$uires three
pacages! .ne generated by the idlj compiler and two #.R/) pacages! %he #.R/) pacages
are org!omg!#os>aming, org!omg!#os>aming!>aming#onte't"acage and org!omg!#.R/)!
#os>aming!O pacage contains the naming services used by the class to call #.R/) objects
and org!omg!#.R/)!O pacage contains all the #.R/) classes! %he following steps have to be
followed*
#reate and Initiali9e the .R/!
.R/ orb J .R/!init(args, null)B
@et the root naming conte't!
org!omg!#.R/)!.bject objRef J
orb!resolveIinitialIreferences(4>ame<ervice4)B
0se >aming#onte't;'t instead of >aming#onte't! %his is a part of the Interoperable
naming <ervice! >arrowing down the object reference!
>aming#onte't;'t ncRef J >aming#onte't;'t3elper!narrow(objRef)B
Resolve the .bject Reference in >aming!
<tring name6 J 4Impl4B
stubJ3ello3elper!narrow(ncRef!resolveIstr(name6))B
Invoe the operation!
Return %ype variableJstub!function(argument6,argument8)B
SERVER:
88
%he server2side program begins by importing the pacages and creates an .R/ object as
above! %hree additional pacages imported are org!omg!"ortable<erver!O,
org!omg!"ortable<erver!".) and java!util!"roperties! %he first two contains classes for "ortable
<erver Inheritance Model and the last pacage contains properties used to initiate the .R/! In
the server side, the following steps have to be followed*
#reate and Initiali9e the .R/!
.R/ orb J .R/!init(args, null)B
@et a reference to the root ".) and activate the ".)Manager!
".) rootpoa J ".)3elper!narrow(orb!resolveIinitialIreferences(4Root".)4))B
rootpoa!theI".)Manager()!activate()B
Manage the servant object by instantiating the server object! 3ere the servant is registered
with the .R/, then an object reference from the servant is got followed by narrowing it
to the proper types!
Impl imp J new Impl()B
matIimpl!set.R/(orb)B
org!omg!#.R/)!.bject ref J rootpoa!servantItoIreference(imp)B
3ello href J 3ello3elper!narrow(ref)B
.btain the initial naming conte't!
org!omg!#.R/)!.bject objRefJorb!resolveIinitialIreferences(4>ame<ervice4)B
>arrow down the object reference!
>aming#onte't;'t ncRef J >aming#onte't;'t3elper!narrow(objRef)B
Register the server with name server by binding the object reference in naming!
<tring name J 43ello)pp4B
>ame#omponent pathQR J ncRef!toIname( name )B
ncRef!rebind(path, href)B
<ystem!out!println(4<erver ready and waiting !!!4)B
&ait for the invocation!
orb!run()B
PROCEDURE TO RUN THE CORBA APPLICATION:
Using transient naming service:
.pen a command prompt and compile the idl file after setting up the path!
Sidlj fall moduleIname!idl
89
Run the naming service by using the following command,
Stnameserv .R/Initial"ort portInumber
)nd see if %ransient>ame<erver* setting port for initial object references to
portInumber is Ready! %he transient naming service runs in the nameIserverIhost! %his is
used in case the application is run on different hosts!
.pen another command prompt and compile the server!
Sjavac server!java
%he implementation file gets compiled while the server is getting compiled!
Run the server in the same window as
Sjava server 2.R/Initial"ort portInumber 2.R/Initial3ost nameIserverIhost
.pen another command prompt and compile the client!
Sjavac client!java
Run the client in the same window as
Sjava client 2.R/Initial"ort portInumber 2.R/Initial3ost nameIserverIhost
Using daemon process (orbd):
.pen a command prompt and start the orbd!
Sstart orbd .R/Initial"ort portInumber 2.R/Initial3ost hostIname
.pen another command prompt and start the server after its compilation!
Sstart java server 2.R/Initial"ort portInumber 2.R/Initial3ost hostIname
.pen another command prompt and start the client after its compilation!
>start java client 2.R/Initial"ort portInumber 2.R/Initial3ost hostIname

VIVA QUESTIONS
1. What is the need for IDL?
%he first step in developing a #.R/) application is to define the interfaces to the objects
re$uired in your distributed system! %o define these interfaces, you use #.R/) I1,!
Java I1, enables distributed &eb2enabled Java applications to transparently invoe
operations on remote networ services using the industry standard .M@ I1, (.bject
Management @roup Interface 1efinition ,anguage) and II." (Internet Inter2.R/ "rotocol)!
%he I1, specification is responsible for ensuring that data is properly e'changed between
dissimilar languages! %he I1, language is part of the standard #.R/) specification and is
independent of any programming language!
90
2. How do you attach services with business logic in CORBA?
%he following services help in including business logic in #.R/)*
;vent <ervice
>aming <ervice
%rading <ervice

%he ;vent <ervice provides a mechanism through which #.R/) objects can send and
receive events! %he >aming <ervice enables #.R/) objects to register and be located by name!
%his service uses the notion of a naming context, which contains a set of uni$ue names! %he
>aming <ervice also supports a federated architecture, meaning that name servers can be
distributed across the networ and wor in conjunction with each other! %he %rader <ervice, lie
the >aming <ervice, enables other objects to locate #.R/) objects! Rather than use a name to
locate an object, a client object loos for services based on operation names, parameters, and
result types!
%he #.R/) Interoperable >aming <ervice defines a 0R,2formatted object reference
called cor'aloc that applications can use to reach remote services! ) second 0R, format called
cor'aname allows applications to directly invoe the remote service! %he %rading .bject <ervice
supports an advanced looup, registration and discovery of services based on service type!
3. Compare garbage collection in CORBA, .NET, E1B?
CORBA:
@arbage collection issues arise not only for implementation repositories, but also apply to
#.R/) in general! -or e'ample, #.R/) relies e'tensively on the factor" pattern/ ) factory is
an object that creates other objects! %o create a new object, a client invoes an operation on the
factory! %he factory operation creates a new object and returns its I.R to the client! %o delete the
object, the client invoes an operation on the object that instructs it to destroy itself! @I." has no
session concept and does not permit servers to distinguish between orderly and disorderly client
shut2down! If a client crashes or loses connectivity before it gets around to destroying an object,
the server has no means to detect this, and the object simply hangs around forever (or, if it is a
transient object, continues to e'ist until its server shuts down)! If too many persistent objects are
left behind over time, the object garbage can accumulate to the point where performance is
severely compromised! #.R/) currently does not offer garbage collection as a platform feature
and forces applications to deal with the problem! @arbage collection can be $uite easy to
implement for a specific application scenarioB the most common approach is to destroy objects if
they have not been accessed for some time!
%he flip2side of losing an I.R is losing an object! %his happens if a client decides to
delete an object while other clients still hold references to that object! .nce the object is gone,
the references held by other clients dangle! %he problem is similar to that of broen lins on &eb
pages! 1angling references fall under the broader topic of referential integrit"! ) system of
91
#.R/) objects and their I.Rs has referential integrity if there are no dangling references
(references without objects) and there are no orphaned objects (objects that cannot be contacted
via a reference)! )s an analogy, the &eb would e'hibit referential integrity if there were no
broen lins, and every page could be reached from some starting point by traversing some
se$uence of lins! #learly, it is very difficult to maintain referential integrity in a heterogeneous
distributed system that spans enterprise and administrative boundariesB random failures that
compromise referential integrity are unavoidable! @arbage collection is one way to address
referential integrity! It can be used both to prevent deletion of objects that are still of interest and
to guarantee deletion of objects that are no longer wanted! )nother way to guarantee integrity is
to use transactions, #.R/) already includes a transaction specification, and the .M@ is in the
process of addressing garbage collection!
E1B:
<tateful <ession /ean*
)t the end of the life cycle, the client invoes the remove method and the ;J/ container
calls the bean(s ejbRemove method! %he bean(s instance is ready for garbage collection!
;ntity /ean*
In the pooled state, the values of the instance variables are not needed! Eou can mae
these instance variables eligible for garbage collection by setting them to null in the
ejb"asssivate method!
Message2 1riven /ean*
)t the end of the life cycle, the container calls the ejbRemove method! %he bean(s
instance is then ready for garbage collection!
DOT NET:
1ot net uses the garbage collector for garbage collection! %he garbage collector (@#)
of !>;% completely absolves the developer from tracing memory usage and nowing when to
free memory! %he Microsoft!>;% #,R (#ommon ,anguage Runtime) re$uires that all resources
be allocated from the managed heap! we will never free objects from the managed heap2objects
are automatically freed when they are no longer needed by the application!
Memory is not infinite! %he garbage collector must perform a collection in order to free
some memory! %he garbage collector(s optimi9ing engine determines the best time to perform a
collection, (the e'act criteria is guarded by Microsoft) based upon the allocations being made!
&hen the garbage collector performs a collection, it checs for objects in the managed heap that
are no longer being used by the application and performs the necessary operations to reclaim
their memory! 3owever for automatic memory management, the garbage collector has to now
the location of the roots i!e! it should now when an object is no longer in use by the application!
%his nowledge is made available to the @# in !>;% by the inclusion of a concept now as
metadata! ;very data type used in !>;% software includes metadata that describes it! &ith the
92
help of metadata, the #,R nows the layout of each of the objects in memory, which helps the
@arbage #ollector in the compaction phase of @arbage collection! &ithout this nowledge the
@arbage #ollector wouldn(t now where one object instance ends and the ne't begins!
4. What is the principle used for connecting client and server for connecting the same
ORB product, same network protocol suite and different network protocol?
%he principle that is used for connecting client and server for communicating among the
same .R/ products, same networ protocol suite and different networ protocol is II."! It
unites objects and applications on the &eb! II." is an inter2.R/ protocol and part of the
#.R/) specifications put forth by the .M@ (.bject Management @roup)! It is a concrete
protocol provided by @I."! #.R/) 8!7 outlined a @eneral Inter2.R/ "rotocol (@I.") that
specifies how .R/ products from different vendors could communicate with each other! @I."
defines a standard data transfer synta' and messaging format over a transport protocol! It doesn(t
specify a particular communication protocol! It(s a simple, protocol2neutral specification that can
be mapped to several different networ protocols! <ince an .R/ is concerned with maintaining
object and data persistence between re$uests, @I." assumes that the transport protocol is
connection2oriented!