Get documents about "CORBA Overview; Developing Basic CORBA Applications
Document Sample
CORBA Overview;
Developing Basic CORBA
Applications
DS 520 - Distributed Systems Frameworks
Review
Anatomy and Requirements of Distributed Computing
Advantages and Features of DOC Systems
General Architecture of DOC Systems
Overview of Object Management Architecture and CORBA
Distributed Systems Frameworks 2
Distributed Computing
Can think of DC as:
breaking down an application into individual computing agents
distributed over a network
work together on a cooperative task
Motivation for DC:
parallel processing: can solve larger problems without larger computers
applications and data may be difficult to relocate
redundant processing agents for fault tolerant systems
Flavors of Distributed Programming
Messaging
Asynchronous, Open-loop: programmer must maintain context
Examples; socket programming, cgi (based on http), etc.
Remote Invocation
Synchronous (usually), Closed-loop, Location transparency (looks like a local call)
Examples: Remote Procedure Call (RPC), Distributed Objects
Distributed Systems Frameworks 3
General Pattern for Remote Invocation
Client Code Server Code
Stub Skeleton
Infrastructure
Call: Serve:
marshal arguments receive data
convert to network format convert & unmarshal
locate server invoke method
transmit data marshall return value
transmit data
Distributed Systems Frameworks 4
Anatomy of a Distributed Application
3 layers of a distributed application:
network level (TCP/IP, network protocols)
higher-level services (directory services, security protocols, etc.)
application level
At the application level:
processes
threads
objects: processes can be made up of one or more objects which can be accessed
by one or more threads within the process
agents: an “independent” functional element (e.g., in a banking application we
may have a customer agent, a transaction agent, an information brokerage agent)
Example (the customer agent):
object1: running on client machine (2 threads: listening for data; updating display)
object2: running on the bank server (issuing queries; sending data back to client)
Distributed Systems Frameworks 5
Requirements for a Distributed Application
Partitioning and Distributing Data and Functions
data-driven distribution
functional distribution
object-based distribution
Flexible, Extendible Communication Protocols
allocation of tasks to agents has a direct influence on the complexity of the
communication protocol (type of data, amount of data, persistence of connections)
may also be dictated by legacy systems that need to be incorporated
Multi-threading Requirements
server object may need to service multiple remote agents at once
effective way to optimize resources
Security Requirements
authentication of agent identities
define resource access levels
data encryption
Distributed Systems Frameworks 6
Features of DOC Systems
Object Interface Specification
to allow clients to access objects regardless of implementation details
Object Manager
The core of a distributed object system (e.g., ORB, or Registry in RMI)
Manages object skeletons and object references on the server
When a client requests a new object, the object manager
locates the skeleton for the class of the requested object
creates new instance based on skeleton; stores new object in the object storage
sends a reference to the new object back to the client
Registration / Naming Service
Acts as an intermediary between the object client and the object manager
Once the interface to an object is defined, an implementation of the interface
must be registered with the service so that it can be addressed by clients
Object Communication Protocol to handle remote object requests
Must support a means of transmitting and receiving object and method
references, and data in the form of objects or basic data types
Distributed Systems Frameworks 7
General Architecture for a DOC System
Registration Object Object
Service Skeleton Storage
Server
Implementation
Object Manager
IDL Compilers
Object
Interface Naming Service
Specification
Client Stub
Interface
Client Application
Distributed Systems Frameworks 8
Remote Object Transactions at Runtime
Server Object
Implementation Object
Skeleton
4. Object
2. Resolve Interactions
Object
Object Manager Naming Service
1. Request
Object
3. Object Object
Client Handle Stubs
Application
Distributed Systems Frameworks 9
OMG’s Mission
Develop a single architecture, using object technology, for
distributed application integration, guaranteeing:
reusability of components;
interoperability & portability;
basis in commercially available software
Consensus-based approach
Focus on swiftly-developed, easily usable (“off the shelf”)
component standards:
Single terminology for object-orientation.
Common abstract framework.
Common reference model.
Common interfaces & protocols
Distributed Systems Frameworks 10
Long Term Vision
WEB Browser WEB Server
Java Enabled P
R
IIOP OMG IDL O
Hot Java Programs G
Java Beans -- HTML R
IIOP (CORBA) A
ActiveX -- GIF, JPEG M
S
-- AV, WAV
Java Interpreter -- Java
IIOP
Sea of Active
Objects X
(CORBA) APP
COM/CORBA
Legacy
DCE APP
DCE
DCE
Object Management Architecture
Non-standardized Vertical Horizontal
application-specific domain-specific facility interfaces
interfaces interfaces
Application Interfaces Domain Interfaces CORBAfacilities
Object Request Broker
CORBAservices
General service interfaces
Distributed Systems Frameworks 12
Overview of CORBA Objects
CORBA objects differ from typical programming language objects:
CORBA objects can be located anywhere on a network.
CORBA objects (like Java objects) can run on any platform.
CORBA objects can be written in any of several languages.
CORBA object developers need know nothing of where their clients
will be, what hardware or OS they will run on, or what language they
will be written in.
CORBA objects approach universal accessibility.
A client of an object has access to an object reference for the object,
and invokes operations on the object.
A client knows only the logical structure of the object according to its interface and
experiences the behavior of the object through invocations.
Client code has no knowledge of the implementation of the object or which ORB is used
to access the implementation.
An object implementation provides the semantics of the object, usually
by defining data for the object instance and code for the object's
methods.
Distributed Systems Frameworks 13
A Request
A request consists of:
Target object (target object identified by a unique object reference)
Operation
Parameters (the input, output and in-out parameters defined for the operation;
may be specified individually or as a list)
Optional request context
Results (the result values returned by the operation)
Client Object Implementation
Client Proxy Skeleton
(stub code) code
Request
ORB
Distributed Systems Frameworks 14
CORBA Framework Elements
Object Request Broker (ORB)
This is the object manager in CORBA
Mechanisms for specifying interfaces
Interface Definition Language (IDL) - for static interface definitions
Dynamic Invocation Interface (DII) - lets clients access interfaces as first-class
objects at run-time from an Interface Repository.
Internet Inter-Orb Protocol (IIOP)
A binary protocol for communication between ORBs.
Was added in CORBA 2.0
Distributed Systems Frameworks 15
Today
CORBA Framework and Components
CORBA IDL
Steps in Developing CORBA Applications
Examples
Distributed Systems Frameworks 16
Object Request Broker (ORB)
The Object Manager in CORBA
On client side the ORB is responsible for
accepting requests for a remote object
finding implementation of the object
accepting client-side reference to the remote object(converted to a language
specific form, e.g., a Java stub object)
routing client method calls through the object reference to the object
implementation
On server side the ORB
lets object servers register new objects
receives requests from the client ORB
uses object’s skeleton interface to invoke object’s activation method
creates reference for new object and sends it back to client
Distributed Systems Frameworks 17
OMG IDL
OMG Interface Definition Language (IDL):
mappings for many languages/compilers;
independent of any particular language/compiler;
multiple-inheritance, public interface-structured specification language;
not for implementation.
primary support for interoperability between static and dynamic requests
mechanisms.
IDL Structure Module auction {
exception NotAllowed {};
Module
a namespace struct Sale {
int price;
Interface string item;
abstract type }
multiple inheritance interface Auction {
void bid (in long price)
Struct raises NotAllowed;
structured data }
}
Distributed Systems Frameworks 18
Internet Inter-Orb Protocol (IIOP)
CORBA specification is neutral with respect to network protocols
the CORBA standard specifies what is known as the General Inter-ORB Protocol (GIOP)
GIOP is a high-level standard protocol for communication between ORBs
not used directly; instead, it is specialized by a particular protocol that would then be
used directly
Internet Inter-ORB Protocol (IIOP)
IIOP is the GIOP-based protocol for TCP/IP networks
As of the 2.0 version of the CORBA specification, vendors are required to implement the
IIOP protocol
CORBA Networking Model
CORBA applications are built on top of GIOP-derived protocols such as IIOP
these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying transport
protocol the network uses
an application architecture can be designed to use a bridge that would interconnect, for
instance, DCE-based application components with IIOP-based ones.
Distributed Systems Frameworks 19
Passing Objects by Reference
In a distributed application, there are two possible methods for
an application component to obtain access to an object in
another process:
When an object is passed by reference, the object itself remains "in place"
while an object reference for that object is passed. Operations on the object
through the object reference are actually processed by the object itself.
When an object is passed by value, the object's state is copied and passed to its
destination (via object serialization), where a new copy of the object is
instantiated. Operations on that object's copy are processed by the copy, not by
the original object.
Note: in CORBA, objects are generally passed by reference (however, CORBA
3.0 specification has now added pass-by-value semantics).
Distributed Systems Frameworks 20
Object References
An Object Reference is the information needed to specify an object
within an ORB.
The representation of an object reference handed to a client is only valid for the lifetime
of that client.
The language mapping also provides additional ways to access object references in a
typed way for the convenience of the programmer.
There is a distinguished object reference, the null reference, guaranteed to be different
from all object references, that denotes no object. In Java, this is a Java null.
To invoke a CORBA object, you need a reference for the object. There
are two ways to get a reference for a CORBA object:
from another object, such as a factory or a name service
from a string that was specially created from an object reference
Interoperable Object References
CORBA uses IOR as a “pointer” to a specific instance of a class in a distributed
environment
encodes host, port, object identity
may be externalized (using object_to_string)
Distributed Systems Frameworks 21
CORBA Components
Client stub
Each stub represents (it is a proxy) an object operation (a possible request) which a client
invokes in a language-dependent manner (e.g., by calling a subroutine which represents
the operation).
The stubs make calls on the rest of the ORB using interfaces that are private to JavaIDL.
Alternatively, a client may dynamically construct and invoke request objects which can
represent any object operation.
Implementation Skeleton
Each skeleton provides the interface through which a method receives a request
(dynamic and static skeletons)
Object Adapter
Purpose is to interface an object's implementation with its ORB
Each object adapter provides access to those services of an ORB (such as activation,
deactivation, object creation, object reference management) used by a particular type of
object implementation.
ORB Interface
The interface to the small set of ORB operations common to all objects, e.g., the
operation which returns an object's interface type.
Distributed Systems Frameworks 22
CORBA Components
Client Object Implementation
Dynamic Client Implementation Object
ORB
Invocation Stubs Skeletons Adapter
Interface
ORB Core
standard interface Proprietary ORB interface
One interface per object adaptor Normal call interface
One interface per object operation Up call interface
Distributed Systems Frameworks 23
Client Side
Clients perform requests using object references.
Clients may issue requests through
object interface stubs (static) or
Client dynamic invocation interface.
Clients may access general ORB
services:
Dynamic Client ORB
• Interface Repository.
Invocation Stubs Interface • Context Management.
• List Management.
• Request Management.
Distributed Systems Frameworks 24
Implementation Side
Implementations receive requests through skeletons (without
knowledge of invocation approach).
Object Implementation
ORB Implementation Object
Interface Skeletons Adapter
The Object Adapter provides for:
• management of references;
• method invocation;
• authentication;
• implementation registration;
• activation/deactivation.
Distributed Systems Frameworks 25
Static v. Dynamic Invocation
Static Invocation
Static interfaces are generated in form of client stubs by the IDL (pre-)
compiler.
This means that the structure of the object has to be known before hand (at
compile time).
Allows for better type checking; less runtime overhead; self-documentation.
Dynamic Invocation
Dynamic Invocation Interface (DII) allows clients to invoke 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).
Clients must discover interface-related information at runtime (e.g., using the
interface repository)
Servers can offer new services anytime without the need for recompilation on
the client side.
Distributed Systems Frameworks 26
Dynamic Requests
The Dynamic Invocation Interface (DII) allows clients to
dynamically:
discover objects;
discover objects’ interfaces;
create requests;
invoke requests;
receive responses.
Major features of Dynamic Invocation Interface:
requests appear as objects themselves;
requests are reusable;
invocation may be synchronous or asynchronous;
requests may be generated dynamically, statically or in combination approach.
Distributed Systems Frameworks 27
CORBA Interface Repository
The Interface Repository is a service that provides persistent
objects that represent the IDL information in a form available
at runtime.
Note: The JavaIDL runtime does not include an implementation of an Interface
Repository and one is not generally required by clients at runtime.
Using the IR, it is possible for a program to encounter an object whose
interface was not known at compile time, yet be able to determine what
operations are valid on the object and make invocation on it.
Interface Repository provides:
Dynamic client access to interface definitions to construct a request.
Dynamic type-checking of request signatures.
Traversal of inheritance graphs.
ORB-to-ORB interoperability.
Distributed Systems Frameworks 28
CORBA Implementation Repository
The Implementation Repository contains information that allows the
ORB to locate and activate implementations of objects.
Ordinarily, installation of implementations and control of policies
related to the activation and execution of object implementations is
done through operations on the Implementation Repository.
In addition to its role in the functioning of the ORB, the
Implementation Repository is a common place to store additional
information associated with implementations of ORB objects. (e.g.,
debugging information, administrative control, resource allocation,
security, etc)
The Implementation Repository supports the implementation of object
servers. It is not needed by clients in order to access servers.
Distributed Systems Frameworks 29
Summary of CORBA Interfaces
IDL Interface Implementation
Definitions Installation
Interface Implementation
Repository Client Implementation Repository
Stubs Skeletons
Accesses Includes Includes Describes
Client Object Implementation
All objects are defined in IDL by specifying their interfaces.
Object definitions (interfaces) are manifested as objects in the Interface
Repository, as client stubs, and as implementation skeletons.
Descriptions of object implementations are maintained as objects in the
Implementation Repository.
Distributed Systems Frameworks 30
Summary: CORBA Remote Method Invocation
Clients use “object interfaces” through language mapping
Java clients should work on any ORB that supports the Java language bindings.
Clients can call any object instance remotely, so long as the object instance
implements the interface.
Clients can call remote objects statically or dynamically
The server cannot tell whether the client is using static or dynamic invocation.
Objects are identified using a unique id: Interoperable Object
Reference (IOR)
CORBA passes objects by reference
IOR was Introduced in CORBA 2.0
Object references can be converted to strings and back to “live” objects via
ORB interface functions.
Distributed Systems Frameworks 31
Steps in Developing CORBA
Applications
Write specification for each object using IDL
Use IDL Compiler (e.g., idl2java) to generate:
Client Stub code
Server Skeleton code
Write the client (in Java, can be applications or applets)
Write the server object implementation code (the “servant”)
Compile the client and server code
Start the server
Run the client application
Distributed Systems Frameworks 32
The Structure of CORBA IDL
(See Section 2.3.4 of Brose, Vogel, Duddy)
Modules
provide namespaces for a set of related class descriptions
map to Java packages with the same name
Interfaces
specification of the operations a client can invoke on a remote object
in addition to operations, interfaces include constructs such as:
constant declarations
attributes (can be read/write or readonly; implementation automatically creates get
and set operations for these attributes)
exceptions (raised if the operations do not perform successfully)
Operations
CORBA equivalent of methods in Java
IDL defines the operations’ signature: parameters and return values/types
parameters can be in, out, or inout
IDL also defines what exceptions can be raised by the operation
Distributed Systems Frameworks 33
Data Types in CORBA IDL
Basic Types
short, long, unsigned long, unsigned short, float, double, long double, char,
wchar, boolean, string, octet, etc.
Constructed Types
struct and union (similar to C++; can be used in conjunction with a typedef)
sequence (variable sized arrays of objects)
any (generic type which represents any possible IDL types; similar to the Java
Object type)
enum (enumerated type with named integer values)
arrays
valuetypes (similar to interfaces; preceded with keyword valuetype to provide
pass-by-value semantics)
Each CORBA IDL data type gets mapped to a native data type
via the appropriate language binding (e.g, IDL-to-Java mapping).
Distributed Systems Frameworks 34
IDL Syntax
module <identifier> {
<type declarations>;
<constant declarations>;
<exception declarations>;
interface <identifier> [:<inheritance>] {
<type declarations>;
<constant declarations>;
<attribute declarations>;
<exception declarations>;
[<op-type>]<identifier>(<parameters>)
[raises <exceptions>]
[<op-type>]<identifier>(<parameters>)
[raises <exceptions>]
. . .
};
interface <identifier> [:<inheritance>] {. . .};
. . .
};
Distributed Systems Frameworks 35
An IDL Example
module MyAnimals {
interface Dog: Pet, Animal {
attribute short age;
exception NotInterested{string explanation};
void Bark(in short how_long)
raises (NotInterested);
void Sit(in string where)
raises (NotInterested);
. . .
};
interface Cat: Animal {
void Eat();
. . .
};
};
Distributed Systems Frameworks 36
Another IDL Example
module RoomBooking {
interface Meeting {
readonly attribute string purpose;
readonly attribute string participants;
oneway void destroy();
};
interface MeetingFactory {
Meeting CreateMeeting(in string purpose,in string participants);
};
interface Room {
// A Room provides methods to view, make,cancel bookings.
enum Slot { am9, am10, am11, pm12, pm1, pm2, pm3, pm4 };
const short MaxSlots = 8;
typedef Meeting Meetings[ MaxSlots ];
exception NoMeetingInThisSlot {};
exception SlotAlreadyTaken {};
readonly attribute string name;
Meetings View();
void Book( in Slot a_slot, in Meeting a_meeting )
raises(SlotAlreadyTaken);
void Cancel( in Slot a_slot )
raises(NoMeetingInThisSlot);
};
};
Distributed Systems Frameworks 37
The CORBA Count Example
The Count Program
the client will invoke a method increment() on the remote object Count;
increment() adds 1 to the value of the attribute sum and returns the value
to the client program;
the initial value of sum is set by the client (sum is a read/write attribute, so the
client can use CORBA’s built-in accessor functions to manipulate it.
// Count.idl
module Counter
First we must start {
with an IDL interface Count
definition for the {
Count object: attribute long sum;
long increment();
};
};
Distributed Systems Frameworks 38
The IDL Compiler
Before using the IDL compiler or running the program make sure that
the PATH and CLASSPATH environment variables are properly set
up:
Your PATH must point to the Java runtime environment directory as well as
the ORB runtime directory ( \inprise\vbroker\bin);
Your CLASSPATH variable must include the current directory (“.”), the usual
Java classes and libraries (including the directory where your program classes
will be stored) as well as the following jar files required by Visibroker:
In Visibroker 3.x In Visibroker 4.x
\inprise\vbroker\lib\vbjcosnm.jar \inprise\vbroker\lib\vbdev.jar
\inprise\vbroker\lib\vbjorb.jar \inprise\vbroker\lib\vbjdev.jar
\inprise\vbroker\lib\vbjapp.jar \inprise\vbroker\lib\vbjorb.jar
\inprise\vbroker\lib\vbjtools.jar \inprise\vbroker\lib\vbjmigration.jar
\inprise\vbroker\lib\vbjgk.jar \jdk1.2.2\lib\servlet.jar
Distributed Systems Frameworks 39
The IDL Compiler
Now you can compile the IDL definition:
> idl2java -no_tie Count.idl
Important Notes:
if you are using Visibroker 3.3, you need JDK 1.1.8; as VBJ 3.3 is not
compatible with Java 2 platform
in VBJ 4.x, idl2java compiler generated code is based on the POA (portable
object adapter) semantics; in order to use BOA semantics, must use:
> idl2java -boa Count.idl
also some additional casting needs to be done in BOA initialization (more on
this later, but see Chapters 30 and 31 of the VBJ 4.x Programmer’s Guide)
in VBJ 3.x, the idl2java compiler generated code is based on BOA semantics
(also the API for the stub and skeleton code is different than those in VBJ 4.x)
Distributed Systems Frameworks 40
What Does the IDL Compiler Generate?
Count.idl
VBJ 3.x
Client Stub Implementation Skeleton
idl2java
Client-Side Server-Side
_st_Count.java _CountImplBase.java
CountHelper.java CountHolder.java Count.java _example_Count.java
Note: these source files will be a part of the Java package Counter and will be placed in
a directory with the same name.
Distributed Systems Frameworks 41
What Does the IDL Compiler Generate?
Count.idl
VBJ 4.x using POA
Client Stub Implementation Skeleton
idl2java
Client-Side Server-Side
_CountStub.java CountPOA.java
CountHelper.java CountHolder.java Count.java
Note: if -boa option is used with idl2java compiler, _CountImplBase.java is also
generated to be used in the object implementation.
Distributed Systems Frameworks 42
Generated Classes & Interfaces
Counter._st_Count: implements the client-side stub for the Count object; it
provides the marshaling functions for the client. [_CountStub in VBJ 4.x].
Counter._CountImplBase: implements the server-side skeleton for Count; it
unmarshals the arguments passes by the client. [CountPOA in VBJ 4.x using POA].
Counter.CountHelper: provides some additional utility functions for the client,
including the narrow operation for downcasting CORBA object references, and (in
this case) the Visibroker specific bind operation for finding the remote object.
Counter.CountHolder: it is used as a wrapper for passing out and inout
parameters of type Count (Java only natively supports in parameters).
Counter.Count: contains the Java interface corresponding to the IDL interface for
Count; the object implementation for Count must implement this interface.
Counter._example_Count: a sample class for the Count object implementation
which could be filled-in by the programmer. [not generated in VBJ 4.x].
package Counter;
public interface Count extends org.omg.CORBA.Object {
public void sum(int sum);
public int sum();
public int increment();
}
Distributed Systems Frameworks 43
Class Hierarchy for BOA Count Interface
class class
org.omg.CORBA.portable.ObjectImpl org.omg.CORBA.portable.Skeleton
(provided by the ORB) (provided by the ORB)
interface
Counter.Count Extends
Extends (generated by id2java)
Implements abstract class
Counter._CountImplBase
abstract class (generated by id2java)
Counter._st_Count
(generated by id2java)
Extends
Note: in case of POA, the object skeleton “CountPOA” class CountImpl
extends org.omg.CORBA.PortableServer.Servant (written by programmer
and used by the server)
Distributed Systems Frameworks 44
Steps in Developing the Count Application
Write a client program in Java:
this can be an applet or an application;
in this case we write a Java application CountClient.java.
Write the server-side code for the Count application:
write a server application which creates and serves instance(s) of the Count object
(instances of the class CountImpl);
write the object implementation (CountImpl).
Object Implementation:
CORBA inheritance model: the implementation class is always derived from the
corresponding _XXXImplBase class generated by IDL compiler (in this case from
_CountImplBase; [Note: with POA this is XXXPOA, e.g., CountPOA]
this inheritance allows the servant class to obtain the properties of both CORBA and Java
object models;
the alternative to inheritance model is to use delegation (in CORBA terminology the Tie
method); if -no_tie option is not used with idl2java relevant classes will be
generated;
in this case we create our CountImpl by modifying the file _example_Count.java.
Distributed Systems Frameworks 45
_example_Count.java
package Counter;
public class _example_Count extends Counter._CountImplBase {
public _example_Count(java.lang.String name) {
super(name);
}
public _example_Count() {
super();
}
public int increment() {
// implement operation...
return 0;
}
public void sum(int sum) {
// implement attribute writer...
}
public int sum() {
// implement attribute reader...
return 0;
} }
Distributed Systems Frameworks 46
The BOA Count Object Implementation
// CountImpl.java: The Count Implementation
class CountImpl extends Counter._CountImplBase
{
private int sum;
// Constructors
CountImpl(String name)
{
super(name);
System.out.println("Count Object Created");
sum = 0;
}
// get sum
public int sum() { return sum; }
// set sum
public void sum(int val) { sum = val; }
// increment method
public int increment() {
sum++;
return sum;
}
}
Distributed Systems Frameworks 47
Tasks Performed by the Main Server Class
Initialize the Object Request Broker
done by creating an instance of the ORB pseudo-object;
the static Java method init() on the class org.omg.CORBA.ORB returns
an instance of an ORB.
Initialize the Basic Object Adaptor
a reference to an instance of the BOA is obtained via the method BOA_init().
Create the object (an instance of the class implementation)
in this case we create an instance of CountImpl class
Activate the newly created object
in BOA this is done by calling the obj_is_ready() method of the ORB
instance on the object;
this action exports the object to the ORB.
Wait for incoming requests
in BOA this is done by calling the impl_is_ready() method of the ORB
instance on the object;
Distributed Systems Frameworks 48
// CountServer.java: The Count Server main program
class CountServer {
static public void main(String[] args) {
try {
// Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// Initialize the BOA
org.omg.CORBA.BOA boa = orb.BOA_init();
The // Note: if using VBJ 4.x with -boa option the BOA
BOA // initialization must be done with following cast:
// com.inprise.vbroker.CORBA.BOA boa =
Count // ((com.inprise.vbroker.CORBA.ORB)orb).BOA_init();
// Create the Count object
CountImpl count = new CountImpl("My Count");
Server // Export to the ORB the newly created object
boa.obj_is_ready(count);
// Ready to service requests
boa.impl_is_ready();
}
catch(org.omg.CORBA.SystemException e) {
System.err.println(e);
}
}
}
Distributed Systems Frameworks 49
Tasks Performed by the Client
Initialize the ORB
done the same way as for the server.
Locate the Remote Object
in this case client binds to the object via the Visibroker bind() method.
Perform Operations via Remote Methods
set the remote sum attribute to zero;
calculate the start time;
invoke the increment method 1000 times;
calculate the elapsed time;
print the results.
Distributed Systems Frameworks 50
The BOA Count Client
// CountClient.java Static Client, VisiBroker for Java
class CountClient{
public static void main(String args[]) {
try {
// Initialize the ORB
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
// Bind to the “persistent” Count Object reference
Counter.Count counter = Counter.CountHelper.bind(orb, "My Count");
// Set sum to initial value of 0
counter.sum((int)0);
// Calculate Start time
long startTime = System.currentTimeMillis();
// Increment 1000 times
for (int i = 0 ; i < 1000 ; i++ ) { counter.increment();}
// Calculate stop time; print out statistics
long stopTime = System.currentTimeMillis();
System.out.println("Avg Ping = " + ((stopTime-startTime)/1000f)+" msecs");
System.out.println("Sum = " + counter.sum());
}
catch(org.omg.CORBA.SystemException e) {
System.err.println("System Exception");
System.err.println(e); }
} }
Distributed Systems Frameworks 51
Building and Running the Count Example
Compile the client, server, and the implementation classes
vbjc -d \CorbaJavaBook.2e\classes CountClient.java
vbjc -d \CorbaJavaBook.2e\classes CountServer.java
vbjc -d \CorbaJavaBook.2e\classes CountImpl.java
Note: \CorbaJavaBook.2e\classes is where the Java
bytecode classes will be stored (without -d option classes are
generated in the current directory).
Start the Visibroker Smart Agent (OSAgent)
osagent -c OR start osagent -c
OSAgent may be installed as an NT Service or started using the icon in the
program menu
Start the Count Server: vbj CountServer
Execute the Client Application: vbj CountClient
Distributed Systems Frameworks 52
The Count
Program in
Action
Distributed Systems Frameworks 53
Next time
More Examples of CORBA Applications
CORBA Object References
The POA version of Count Application
More on IDL elements
read/readonly attributes
oneway methods
parameter passing mechanisms
exceptions and exception handling
Discussion of Project Phase I
Distributed Systems Frameworks 54
