UNIT IV

CORBA

1 01/21/2025
 Unit IV Contents
CORBA: CORBA – Distributed Systems –
Purpose – Exploring CORBA alternatives –
Architecture overview – CORBA and
networking model – CORBA object model –
IDL – ORB – Building an application with
CORBA.

2 01/21/2025
3 01/21/2025
 PURPOSE
CORBA provides a standard mechanism for
defining the interfaces between
components
OMG provides directory and naming
services, persistent object services, and
transaction services
Two features are platform independence
and language independence

4 01/21/2025
 CORBA alternatives
Socket Programming
Remote Procedure Call
 Function oriented interface
OSF Distributed Computing Environment
 OSF standard to RPC
MS-DCOM
 Restricted to only Microsoft technologies
Java Remote Method Invocation
 Passing of objects by value
 Java only solution

5 01/21/2025
 CORBA alternatives

 Microsoft DCOM
 The Distributed Component Object Model (DCOM), Microsoft's offers
capabilities similar to CORBA
 DCOM is a relatively robust object model that enjoys particularly good
support on Microsoft operating systems because it is integrated with
Windows 95 and Windows NT.
 CORBA has existed since 1990. Commercial implementations have
been available since 1992.
 DCOM was made available in beta form in 1996. CORBA has had more
time to mature. There are also a large number of different companies
developing CORBA ORBs. This level of competition increases the
robustness of CORBA solutions on the whole.
 DCOM is well suited to front-end application development. If entire
distributed application runs under Microsoft platforms, DCOM might be
a good choice.
 DCOM can also be used with CORBA. Microsoft now promises to provide
DCOM on other platform
6  DCOM is available for the Sun Solaris operating system, with01/21/2025
support
promised for Digital UNIX, IBM MVS.
 CORBA alternatives

Java RMI
 It is a very CORBA-like architecture with a few
twists.
 One advantage of RMI is that it supports the
passing of objects by value, a feature not
(currently) supported by CORBA.
 A disadvantage, however, is that RMI is a Java-only
solution; that is, RMI clients and servers must be
written in Java.
 For all-Java applications--particularly those that
benefit from the capability to pass objects by
value--RMI might be a good choice
 CORBA is a better choice when interoperability with
7 01/21/2025
other language application is required.
 CORBA vs. Java RMI
CORBA differs from the architecture of Java
RMI in one significant aspect:
 RMI is a proprietary facility developed
by Sun MicroSystems, Inc., and supports
objects written in the Java programming
language only.
 CORBA is an architecture that was
developed by the Object Management Group
(OMG), an industrial consortium.

8 01/21/2025
 Architecture overview
An Object Oriented
architecture
Object Request Broker
Interface Definition
Language
Communications Model
Clients and Servers, Stub
9 and skeleton 01/21/2025
 CORBA
The Common Object Request Broker
Architecture (CORBA) is a standard
architecture for a distributed objects
system.
CORBA is designed to allow distributed
objects to interoperate in a heterogenous
environment, where objects can be
implemented in different programming
language and/or deployed on different
platforms

10 01/21/2025
 CORBA
CORBA is not in itself a distributed objects
facility; instead, it is a set of protocols.
A distributed object facility which adhere to
these protocols is said to be CORBA-
compliant, and the distributed objects that
the facility support can interoperate with
objects supported by other CORBA-compliant
facilities.
CORBA is a very rich set of protocols. We will
instead focus on the key concepts of CORBA
related to the distributed objects paradigm.

11 01/21/2025
 The Basic Architecture
n am in g
look u p
o bje ct
n a m in g s e rv ice o bje ct clie n t
im ple m e n ta tio n

s tu b s k e le to n

ORB ORB

n e two rk n e two rk

o pe ra tin g o pe ra tin g
s y s te m s y s te m

lo g ica l da ta flo w
ph y s ica l da ta flo w

12 01/21/2025
 Cross-language CORBA application

o bje ct im ple m e n ta tio n writte n

o bje ct clie n t writte n in J a v a
in C + +

stu b i n Java ge n e rate d by com pi l i n g s k e le to n in C ++ g e n e r a t e d b y

th e C O R B A o b j e c t i n t e r f a c e co m pi l i n g th e C O R B A o bje ct
i n te rfa ce

O R B writte n in J a v a O R B writte n in C + +

13 01/21/2025
 CORBA ARCHITECTURE

14 01/21/2025
 CORBA Object Interface
 A distributed object is defined using a software file similar
to the remote interface file in Java RMI.
 Since CORBA is language independent, the interface is
defined using a universal language with a distinct syntax,
known as the CORBA Interface Definition Language
(IDL).
 The syntax of CORBA IDL is similar to Java and C++.
However, object defined in a CORBA IDL file can be
implemented in a large number of diverse programming
languages, including C, C++, Java, COBOL, Smalltalk, Ada,
Lisp, Python, and IDLScript.
 For each of these languages, OMG (Object management
Group) has a standardized mapping from CORBA IDL to the
programming language, so that a compiler can be used to
process a CORBA interface to generate the proxy files
needed to interface with an object implementation or an
object client written in any of the CORBA-compatible
languages.
15 01/21/2025
 Object Request Broker (ORB)
Facilitates communication
between objects
The Object Request Broker (ORB)
determines the location of the
target object, sends a request to
that object, and returns any
response back to the caller.
Marshals and un-marshals
parameters
16 01/21/2025
 ORB
 The OMG ORB model can be divided
into two main parts:
• Application oriented
components
 Application Interfaces
 Domain Interfaces
 Common Facilities
• System oriented components
 Object Request Broker
 Object Services
17 01/21/2025
18 01/21/2025
 Marshalling
Marshaling refers to the process of
translating input parameters to a format
that can be transmitted across a network.
Unmarshaling is the reverse of marshaling;
this process converts data from the
network to output parameters.

19 01/21/2025
20 01/21/2025
 Client –Server Interaction-
CORBA

21 01/21/2025
 Client –Server Interaction-
CORBA

22 01/21/2025
 Interface Definition Language
It is used for specifying the Interfaces
between CORBA objects
Example: Client written in C++ can
communicate with server written in Java,
which in turn communicate with another
server written in python , and so on
It is not an implementation language
The sole purpose of IDL is to define
interfaces, providing implementation is
performed using some other language.

23 01/21/2025
 Stubs and Skeleton
A client stub is a small piece of code that
allows a client component to access a
server component
This piece of code is compiled along with
the client portion of the application
Server skeleton are pieces of code that you
“fill in” when you implement a server
No need to write the client stubs and
skeleton, these are generated during
compilation of IDL interface definitions

24 01/21/2025
 CORBA communication and N/W Model
It uses the notion of object
references(Interoperable Object Reference) to
facilitate the communication between objects
Using the IOR , the client object can invoke
methods on the server object
A client is simply any application that uses
services of a CORBA object
A server is an application that creates CORBA
objects and makes the services provided by
those available to other application
CORBA ORBs usually communicate using the
Internet Inter ORB Protocol(IIOP)
25 01/21/2025
CORBA communication and N/W Model
Inter-ORB protocols
 General Inter-ORB Protocol (GIOP)
 Internet Inter –ORB Protocol (IIOP)
CORBA Applications are built on top of GIOP-
derived protocol such as IIOP
These protocols rest on TCP/IP, DCE or any
other transport protocols
CORBA creates another layer, the inter ORB
protocol layer which used the underlying
transport layer.
This is a key to interoperability between CORBA
applications, as CORBA does not dictate the
26
use of particular network transport protocol.
01/21/2025
 Inter-ORB Protocols
The IIOP specification includes the following
elements:
1. Transport management requirements:
specifies the connection and disconnection
requirements, and the roles for the object client and
object server in making and unmaking connections.
2. Definition of common data representation: a
coding scheme for marshalling and unmarshalling data
of each IDL data type.
3. Message formats: different types of message format
are defined. The messages allow clients to send requests
to object servers and receive replies. A client uses a
Request message to invoke a method declared in a
CORBA interface for an object and receives a reply
message from the server.
27 01/21/2025
 CORBA Object Model
Every object oriented architecture features an object
model, which describes how objects are represented in
the system
CORBA object can be anywhere in the network
CORBA object can be available on any platform
CORBA object references are persistent
CORBA object implementation in any of the several
languages
CORBA has “semi-transparent” support for object
distribution
A remote method call looks like a local method call(client
stub)
Objects are transparent
Object distribution brings more potential for failure

28 01/21/2025
 CORBA Object Model
It makes use of object references
Makes use of call by reference
It uses object adaptors

29 01/21/2025
30 01/21/2025
 Object Servers and Object Clients

As in Java RMI, a CORBA distributed object is

exported by an object server, similar to the
object server in RMI.
An object client retrieves a reference to a
distributed object from a naming or directory
service, to be described, and invokes the
methods of the distributed object.

31 01/21/2025
 Aob HOst,
CorbA
Naming Service Implm
Name ,IP
Addr, Port
Num, nick
Server(A) name
Remote interface
Clientfrom Naming
Implementation( B
Service get
reference of Aob usiness Logic)
calls the methods Object will be
of Server created(Skelton)
Application (Register)Stored
in Naming Service.
(Aob)

32 01/21/2025
 CORBA Object References
As in Java RMI, a CORBA distributed object
is located using an object reference.
Since CORBA is language-independent, a
CORBA object reference is an abstract
entity mapped to a language-specific object
reference by an ORB, in a representation
chosen by the developer of the ORB.
For interoperability, OMG specifies a
protocol for the abstract CORBA object
reference object, known as the
Interoperable Object Reference (IOR)
protocol.

33 01/21/2025
 Interoperable Object
Reference (IOR)
For interoperability, OMG specifies a protocol
for the abstract CORBA object reference
object, known as the Interoperable Object
Reference (IOR) protocol.
An ORB compatible with the IOR protocol will
allow an object reference to be registered
with and retrieved from any IOR-compliant
directory service. CORBA object references
represented in this protocol are called
Interoperable Object References (IORs).

34 01/21/2025
 Interoperable Object
Reference (IOR)
An IOR is a string that contains encoding
for the following information:
The type of the object.
The host where the object can be found.
The port number of the server for that object.
An object key, a string of bytes identifying
the object.
The object key is used by an object server to
locate the object.

35 01/21/2025
 Interoperable Object
Reference (IOR)
The following is an example of the string
representation of an IOR [5]:
IOR:000000000000000d49444c3a677269643a312e3000000
00000000001000000000000004c0001000000000015756c74
72612e6475626c696e2e696f6e612e6965000009630000002
83a5c756c7472612e6475626c696e2e696f6e612e69653a67
7269643a303a3a49523a67726964003a
The representation consists of the character
prefix “IOR:” followed by a series of
hexadecimal numeric characters, each
character representing 4 bits of binary data in
the IOR.

36 01/21/2025
 CORBA Naming Service
CORBA specifies a generic directory service.
The Naming Service serves as a directory
for CORBA objects, and, as such, is platform
independent and programming language
independent.
The Naming Service permits ORB-based
clients to obtain references to objects they
wish to use. It allows names to be associated
with object references. Clients may query a
naming service using a predetermined name
to obtain the associated object reference.

37 01/21/2025
 CORBA Naming Service
To export a distributed object, a CORBA object
server contacts a Naming Service to bind a
symbolic name to the object. The Naming
Service maintains a database of names and
the objects associated with them.
To obtain a reference to the object, an object
client requests the Naming Service to look up
the object associated with the name. (This is
known as resolving the object name.)
The API for the Naming Service is specified in
interfaces defined in IDL, and includes
methods that allow servers to bind names to
objects and clients to resolve those names.
38 01/21/2025
 CORBA Naming Service
To be as general as possible, the CORBA object
naming scheme is necessarily complex. Since
the name space is universal, a standard
naming hierarchy is defined in a manner
similar to the naming hierarchy in a file
directory n a m in g con te xt 1

n a m in g con te xt 1 ... n a m in g con te xt2

...
n a m in g con te xt 1 ... n a m in g con te xt 1

...
o bje ct o bje ct
nam e 1 nam e n

39 01/21/2025
 Interoperable Naming Service
The Interoperable Naming Service
(INS) is a URL-based naming system
based on the CORBA Naming Service, it
allows applications to share a common
initial naming context and provides a
URL to access a CORBA object.

40 01/21/2025
 CORBA services
OMG has published standards for 15 object Services
 Life cycle service
Defines operations for creating, copying, moving and
deleting components on the bus
 Persistence service
A single interface for storing components persistently
on a variety of storage servers
 Naming service
Allows component on the bus to locate other
components by name
 Collection service
To generically create and manipulate the most common
collections

41 01/21/2025
 CORBA services
 Event services
Allows component on a bus to dynamically register
and unregister their interest in specific events
 Concurrency control service
Provides a lock manager that can obtain locks on
behalf of either transactions or threads
 Transaction service
Provides two phase commit coordination among
recoverable components using flat or nested
transaction
 Externalization service
Provides a standard way for getting data into and out
of a component using a stream like mechanism

42 01/21/2025
 CORBA services
Relationship service
Provides a way to create dynamic association
Provides mechanism for traversing the links that
group these components
Query service
Provides query operations for objects
Licensing service
Provides operation for metering the use of
components to ensure fare compensation for
their use
It supports charging per session, per node, per
instance creation and per site
43 01/21/2025
 CORBA services
 Property service
It provides operations to associate named values with
any components .ex: title, date etc.,
 Time service
Provides interfaces for synchronizing time in a
distributed environment
It also provides operations for defining and managing
time triggered events
 Security service
Supports authentication, access control lists,
confidentiality etc.,
 Trader service(yellow pages)
Allows objects to publicize their services and bid for jobs

44 01/21/2025
 CORBA Object Adaptors
 A CORBA server has to provide an implementation object, called a
servant, for each of the proxy objects manipulated by the client.
 For ex.The Bank server example needs to implement the initial bank
servant, and then create new servants for each of the account objects
created in response to openAccount , openCheckingAccount and
retrieveAccount requests.
 Each of these servants needs to be registered in the CORBA
environment and assigned an object reference, so that the ORB can
direct incoming requests to the appropriate servant.
 In CORBA, the primary means for an object implementation to access
ORB services such as object reference generation is via an object
adapter . The object adapter is responsible for the following functions:
 Generation and interpretation of object references

 Registration of servants

 Mapping object references to the corresponding servants

 IDL method invocations, mediated by skeleton methods

45  Servant activation and deactivation 01/21/2025

 Object Adapters

dis tribu te d o bje ct

im ple m e n ta tio n

o bje ct a da pte r

ORB

46 01/21/2025
 Object Adapters
It Provides Three object ADAPTER types
 Basic Object Adapters
 provides set of methods for accessing ORB
functions
 Portable Object Adapters
 Based on application
 OO Database Adapters
 useful for accessing objects in persistent
storage
 Library Object Adaptors
47 01/21/2025
 Object Adapter
Object Adapter
 Like an interface an object's implementation with its
ORB.
An object adapter simplifies the responsibilities of
an ORB by assisting an ORB in delivering a client
request to an object implementation.
When an ORB receives a client’s request, it locates
the object adapter associated with the object and
forwards the request to the adapter.
The adapter interacts with the object
implementation’s skeleton, which performs data
marshalling and invoke the appropriate method in
48 01/21/2025
the object.
 BOA(Basic Object Adaptors)
 One of the main tasks of the BOA is to support on-demand
object activation. When a client issues a request, the BOA
determines if the object is currently running and if so, it
delivers the request to the object. If the object is not running,
the BOA activates the object and then delivers the request.
 The BOA defines four different models for object activation:
 Shared server
 Multiple active objects share the same server. The server services requests
from multiple clients. The server remains active until it is deactivated or
exits.
 Unshared server
 Only one object is active in the server. The server exits when the client that
caused its activation exits.
 Server-per-method
 Each request results in the creation of a server. The server exits when the
method completes.
 Persistent server
49  The server is started by an entity other than the BOA (you, 01/21/2025
operating
services, etc.). Multiple active objects share the server.
 The Portable Object Adapter

 The Portable Object Adapter, or POA, is a particular type

of object adapter that is defined by the CORBA specification.
An object adapter that is a POA allows an object
implementation to function with different ORBs, hence the
word portable.
 The main aim is to provide an object adapter that can be
used with multiple ORB implementations with a minimum of
rewriting needed to deal with different vendors’
implementations.
 The POA is also intended to allow persistent objects
 That is, as far as the client is concerned, these objects are
always alive, and maintain data values stored in them.
 The POA allows the object implementor a lot more control
Now, additionally, the implementor has more control over
50 01/21/2025
the object’s identity, state, storage, and lifecycle.
 The Portable Object
Adapter

 The POA has support for many other features,

including the following:
 Transparent object activation
 Multiple simultaneous object identities
 Transient objects
 Object ID namespaces
 Policiesincluding multithreading, security, and
object management
 Multiple distinct POAs in a single server with
51 different policies and namespaces 01/21/2025
 The Java IDL (Java 1.4 version)

52 01/21/2025
 IDL
Provides interface b/w various CORBA
objects
Is a generic language
Has its own language constraints
IDL is not a procedural language; it can
define only interfaces, not
implementations as its name suggests,
is the language used to define
interfaces between application
components

53 01/21/2025
 IDL Ground Rules
Case Sensitivity
IDL Definition Syntax
 The Module
In addition to ,
Comments
Use of C preprocessor
Coupling & cohension

54 01/21/2025
 PRIMITIVE TYPES
Void Integer types
Boolean Long & long long

Char & wchar Unsigned ..,.,.,.

Float Short
Double & long Unsigned short
types octet
String
Const modifier

55 01/21/2025
 Constructed types
The Enumerated type
The Structure type
The Union type
Term : A discriminator, as used in an IDL
union, is a parameter that determines the
value used by the union.
THE INTERFACE TYPE and so on

56 01/21/2025
 Java IDL – Java’s CORBA
Facility
IDL is part of the Java 2 Platform, Standard
Edition (J2SE).
The Java IDL facility includes a CORBA
Object Request Broker (ORB), an IDL-to-
Java compiler, and a subset of CORBA
standard services.
In addition to the Java IDL, Java provides a
number of CORBA-compliant facilities,
including RMI over IIOP, which allows a
CORBA application to be written using the
RMI syntax and semantics.

57 01/21/2025
 Key Java IDL Packages
package org.omg.CORBA – contains
interfaces and classes which provides the
mapping of the OMG CORBA APIs to the
Java programming language
package org.omg.CosNaming - contains
interfaces and classes which provides the
naming service for Java IDL
org.omg.CORBA.ORB - contains interfaces
and classes which provides APIs for the
Object Request Broker.
58 01/21/2025
 Java IDL Tools
Java IDL provides a set of tools needed for
developing a CORBA application:
idlj - the IDL-to-Java compiler (called idl2java
in Java 1.2 and before)
 orbd - a server process which provides
Naming Service and other services
servertool – provides a command-line
interface for application programmers to
register/unregister an object, and
startup/shutdown a server.
tnameserv – an olderTransient Java IDL
Naming Service whose use is now
discouraged.
59 01/21/2025
 A Java IDL application example

60 01/21/2025
 The CORBA Interface file
Hello.idl
01. module HelloApp
02. {
03. interface Hello
04. {
05. string sayHello();
06. oneway void shutdown();
07. };
08. };

61 01/21/2025
 Compiling the IDL file (using Java
1.4)
The IDL file should be placed in a directory dedicated to
the application. The file is compiled using the
compiler idlj using a command as follows:
idlj -fall Hello.idl
The –fall command option is necessary for the
compiler to generate all the files needed.
In general, the files can be found in a subdirectory
named <some name>App when an interface file
named <some name>.idl is compiled.
If the compilation is successful, the following files can be
found in a HelloApp subdirectory:
HelloOperations.java Hello.java
HelloHelper.java HelloHolder.java
_HelloStub.java HelloPOA.java
These files require no modifications.
62 01/21/2025
 The *Operations.java file
There is a file HelloOperations.java found in
HelloApp/ after you compiled using idlj
It is known as a Java operations
interface in general
It is a Java interface file that is equivalent
to the CORBA IDL interface file (Hello.idl)
You should look at this file to make sure
that the method signatures correspond to
what you expect.

63 01/21/2025
 HelloApp/
HelloOperations.java
The file contains the methods specified in the
original IDL file: in this case the methods
sayHello( ) and shutdown().
package HelloApp;
01. package HelloApp;
04. /**
05. * HelloApp/HelloOperations.java
06. * Generated by the IDL-to-Java compiler (portable),
07. * version "3.1" from Hello.idl
08. */
09.
10. public interface HelloOperations
11. {
12. String sayHello ();
13. void shutdown ();
14. } // interface HelloOperations
64 01/21/2025
 HelloApp/Hello.java
The signature interface file combines the
characteristics of the Java operations interface
(HelloOperations.java) with the characteristics
of the CORBA classes that it extends.
01. package HelloApp;
03. /**
04. * HelloApp/Hello.java
05. * Generated by the IDL-to-Java compiler (portable),
06. * version "3.1" from Hello.idl
07. */
09. public interface Hello extends HelloOperations,
10. org.omg.CORBA.Object,
11. org.omg.CORBA.portable.IDLEntity
12. { …
13. } // interface Hello

65 01/21/2025
 HelloHelper.java, the Helper class
The Java class HelloHelper (Figure 7d)
provides auxiliary functionality needed to
support a CORBA object in the context of
the Java language.
In particular, a method, narrow,allows a
CORBA object reference to be cast to its
corresponding type in Java, so that a
CORBA object may be operated on using
syntax for Java object.

66 01/21/2025
 HelloHolder.java, the Holder
class
The Java class called HelloHolder holds
(contains) a reference to an object that
implements the Hello interface.
The class is used to handle an out or an
inout parameter in IDL in Java syntax
( In IDL, a parameter may be declared to be
out if it is an output argument, and inout if
the parameter contains an input value as
well as carries an output value.)

67 01/21/2025
 _HelloStub.java
The Java class HelloStub (Figure 7e) is the
stub file, the client-side proxy, which
interfaces with the client object.
It extends
org.omg.CORBA.portable.ObjectImpl and
implements the Hello.java interface.

68 01/21/2025
 HelloPOA.java, the server skeleton
The Java class HelloImplPOA is the
skeleton, the server-side proxy, combined
with the portable object adapter.
It extends org.omg.PortableServer.Servant,
and implements the InvokeHandler
interface and the HelloOperations interface.

69 01/21/2025
 The application
Server-side Classes
 On the server side, two classes need to be
provided: the servant and the server.
The servant, HelloImpl, is the
implementation of the Hello IDL interface;
each Hello object is an instantiation of this
class.

70 01/21/2025
 The Servant - HelloApp/HelloImpl.java
// The servant -- object implementation -- for the Hello
// example. Note that this is a subclass of HelloPOA,
// whose source file is generated from the
// compilation of Hello.idl using j2idl.
06. import HelloApp.*;
07. import org.omg.CosNaming.*;
08. import java.util.Properties; …
15. class HelloImpl extends HelloPOA {
16. private ORB orb;
18. public void setORB(ORB orb_val) {
19. orb = orb_val;
20. }
22. // implement sayHello() method
23. public String sayHello() {
24. return "\nHello world !!\n";
25. }
27. // implement shutdown() method
28. public void shutdown() {
29. orb.shutdown(false);
30. }
71 31. } //end class 01/21/2025
 The server - HelloApp/HelloServer.java

public class HelloServer {

public static void main(String args[]) {
try{
// create and initialize the ORB
ORB orb = ORB.init(args, null);
// get reference to rootpoa & activate the POAManager
POA rootpoa = (POA)orb.resolve_initial_references("RootPOA");
rootpoa.the_POAManager().activate();
// create servant and register it with the ORB
HelloImpl helloImpl = new HelloImpl();
helloImpl.setORB(orb);
// get object reference from the servant
org.omg.CORBA.Object ref =
rootpoa.servant_to_reference(helloImpl);
// and cast the reference to a CORBA reference
Hello href = HelloHelper.narrow(ref);
72 01/21/2025
 HelloApp/HelloServer.java - continued

// get the root naming context

// NameService invokes the transient name service
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
// Use NamingContextExt, which is part of the
// Interoperable Naming Service (INS) specification.
NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef);
// bind the Object Reference in Naming
String name = "Hello";
NameComponent path[] = ncRef.to_name( name );
ncRef.rebind(path, href);
System.out.println
("HelloServer ready and waiting ...");
// wait for invocations from clients
orb.run();
73 01/21/2025
 The object client application
A client program can be a Java application, an
applet, or a servlet.
The client code is responsible for creating and
initializing the ORB, looking up the object using the
Interoperable Naming Service, invoking the narrow
method of the Helper object to cast the object
reference to a reference to a Hello object
implementation, and invoking remote methods
using the reference. The object’s sayHello
method is invoked to receive a string, and the
object’s shutdown method is invoked to deactivate
the service.
74 01/21/2025
 Client Application

// A sample object client application.

import HelloApp.*;
import org.omg.CosNaming.*; …
public class HelloClient{
static Hello helloImpl;
public static void main(String args[]){
try{
ORB orb = ORB.init(args, null);
org.omg.CORBA.Object objRef =
orb.resolve_initial_references("NameService");
NamingContextExt ncRef =
NamingContextExtHelper.narrow(objRef);
helloImpl =
HelloHelper.narrow(ncRef.resolve_str(“Hello”));
System.out.println(helloImpl.sayHello());
helloImpl.shutdown();
75 01/21/2025
 Compiling and Running a Java IDL
application
1. Create and compile the Hello.idl file on the
server machine:
idlj -fall Hello.idl
2. Copy the directory containing Hello.idl
(including the subdirectory generated by
idlj) to the client machine.
3. In the HelloApp directory on the client
machine: create HelloClient.java. Compile the
*.java files, including the stubs and
skeletons (which are in the directory
HelloApp):
javac *.java HelloApp/*.java
76 01/21/2025
 Compiling and Running a Java IDL
application
4. In the HelloApp directory on the server
machine:
 Create HelloServer.java. Compile the .java files:
javac *.java HelloApp/*.java
 On the server machine: Start the Java Object
Request Broker Daemon, orbd, which includes a
Naming Service.

To do this on Unix:
orbd -ORBInitialPort 1050 -ORBInitialHost
servermachinename&

To do this on Windows:
start orbd -ORBInitialPort 1050 -ORBInitialHost
servermachinename
77 01/21/2025
 Compiling and Running a Java IDL
application
5. On the server machine, start the Hello
server, as follows:
java HelloServer –ORBInitialHost <nameserver
host name> -ORBInitialPort 1050
6. On the client machine, run the Hello
application client. From a DOS prompt or
shell, type:
java HelloClient -ORBInitialHost nameserverhost
-ORBInitialPort 1050
all on one line.
Note that nameserverhost is the host on
which the IDL name server is running. In this
case, it is the server machine.
78 01/21/2025
 Compiling and Running a Java IDL
application
7. Kill or stop orbd when finished. The name
server will continue to wait for invocations
until it is explicitly stopped.
8. Stop the object server.

79 01/21/2025
80 01/21/2025
 Building a CORBA Application
The outline of the process is this:
1. Define the server's interfaces using IDL.
2. Choose an implementation approach for the
server's interfaces
3. Use the IDL compiler to generate client stubs
and server skeletons for the server interfaces
4. Implement the server interfaces.
5. Compile the server application.
6. Run the server application.

81 01/21/2025