CORBA Overview Developing Basic CORBA Applications

1
CORBA OverviewDeveloping Basic CORBA
Applications

• DS 520 - Distributed Systems Frameworks

2
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

3
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

4
General Pattern for Remote Invocation
Client Code
Server Code
Stub
Skeleton
Infrastructure

• Serve
• receive data
• convert unmarshal
• invoke method
• marshall return value
• transmit data

• Call
• marshal arguments
• convert to network format
• locate server
• transmit data

5
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)

6
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

7
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

8
General Architecture for a DOC System
Registration Service
Object Skeleton
Object Storage
Server Implementation
Object Manager
Object Interface Specification
IDL Compilers
Naming Service
Client Stub Interface
Client Application
9
Remote Object Transactions at Runtime
Server Object Implementation
Object Skeleton
4. Object Interactions
2. Resolve Object
Object Manager Naming Service
1. Request Object
3. Object Handle
Object Stubs
Client Application
10
OMGs 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

11
Long Term Vision
WEB Server
WEB Browser Java Enabled Hot Java Java
Beans ActiveX Java Interpreter
PR O G R A M S
OMG IDL Programs IIOP (CORBA)
IIOP -- HTML -- GIF, JPEG -- AV, WAV -- Java
IIOP
Sea of Objects (CORBA)
ActiveX APP
COM/CORBA
Legacy DCE APP
DCE
DCE
12
Object Management Architecture
Verticaldomain-specific interfaces
Non-standardizedapplication-specific interfaces
Horizontalfacility interfaces
Domain Interfaces
Application Interfaces
CORBAfacilities
Object Request Broker
CORBAservices
General service interfaces
13
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.

14
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 (stub code)
Skeleton code
Request
ORB
15
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

16
Today

• CORBA Framework and Components
• CORBA IDL
• Steps in Developing CORBA Applications
• Examples

17
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 objects skeleton interface to invoke
  objects activation method
• creates reference for new object and sends it
  back to client

18
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
• a namespace
• Interface
• abstract type
• multiple inheritance
• Struct
• structured data

Module auction exception NotAllowed
struct Sale int price string item
interface Auction void bid (in long
price) raises NotAllowed
19
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.

20
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).

21
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)

22
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.

23
CORBA Components
Object Implementation
Client
Object Adapter
Implementation Skeletons
Dynamic Invocation
Client Stubs
ORB Interface
ORB Core
standard interface
Proprietary ORB interface
One interface per object adaptor
Normal call interface Up call interface
One interface per object operation
24
Client Side
Clients perform requests using object references.
Clients may issue requests through object
interface stubs (static) or dynamic invocation
interface.
Client

• Clients may access general ORB services
• Interface Repository.
• Context Management.
• List Management.
• Request Management.

Dynamic Invocation
Client Stubs
ORB Interface
25
Implementation Side
Implementations receive requests through
skeletons (without knowledge of invocation
approach).
Object Implementation
Object Adapter
Implementation Skeletons
ORB Interface

• The Object Adapter provides for
• management of references
• method invocation
• authentication
• implementation registration
• activation/deactivation.

26
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.

27
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.

28
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.

29
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.

30
Summary of CORBA Interfaces
Implementation Installation
IDL Interface Definitions
Interface Repository
Implementation Repository
Client Stubs
Implementation Skeletons
Describes
Includes
Accesses
Includes
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.

31
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.

32
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

33
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

34
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).

35
IDL Syntax

• module ltidentifiergt
• lttype declarationsgt
• ltconstant declarationsgt
• ltexception declarationsgt
• interface ltidentifiergt ltinheritancegt
• lttype declarationsgt
• ltconstant declarationsgt
• ltattribute declarationsgt
• ltexception declarationsgt
• ltop-typegtltidentifiergt(ltparametersgt)
• raises ltexceptionsgt
• ltop-typegtltidentifiergt(ltparametersgt)
• raises ltexceptionsgt
• . . .
• interface ltidentifiergt ltinheritancegt . .
  .
• . . .

36
An IDL Example
module MyAnimals interface Dog Pet,
Animal attribute short age exception
NotInterestedstring explanation void
Bark(in short how_long) raises
(NotInterested) void Sit(in string where)
raises (NotInterested) . . .
interface Cat Animal void Eat() . .
.
37
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(NoMeetingInThisS
lot)
38
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 CORBAs built-in accessor functions to
  manipulate it.

• // Count.idl
• module Counter
• interface Count
• attribute long sum
• long increment()

First we must start with an IDL definition for
the Count object
39
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\vbjorb.jar \inprise\vbroker\lib\vbjapp.jar \i
nprise\vbroker\lib\vbjtools.jar \inprise\vbroker\l
ib\vbjgk.jar
\inprise\vbroker\lib\vbdev.jar \inprise\vbroker\li
b\vbjdev.jar \inprise\vbroker\lib\vbjorb.jar \inpr
ise\vbroker\lib\vbjmigration.jar \jdk1.2.2\lib\ser
vlet.jar
40
The IDL Compiler

• Now you can compile the IDL definition
• gt 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
• gt 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 Programmers
  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)

41
What Does the IDL Compiler Generate?
Count.idl
VBJ 3.x
Implementation Skeleton
Client Stub
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.
42
What Does the IDL Compiler Generate?
Count.idl
VBJ 4.x using POA
Implementation Skeleton
Client Stub
idl2java
Client-Side
Server-Side
_CountStub.java
CountPOA.java
Count.java
CountHelper.java
CountHolder.java
Note if -boa option is used with idl2java
compiler, _CountImplBase.java is also generated
to be used in the object implementation.
43
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()
44
Class Hierarchy for BOA Count Interface
class org.omg.CORBA.portable.Skeleton (provided
by the ORB)
class org.omg.CORBA.portable.ObjectImpl (provided
by the ORB)
interface Counter.Count (generated by id2java)
Extends
Extends
abstract class Counter._CountImplBase (generated
by id2java)
Implements
abstract class Counter._st_Count (generated by
id2java)
Extends
class CountImpl (written by programmer and used
by the server)
Note in case of POA, the object skeleton
CountPOA extends org.omg.CORBA.PortableServer.Se
rvant
45
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.

46
_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

47
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
48
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

49
TheBOA Count Server
// 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() // Note if using VBJ 4.x
with -boa option the BOA // initialization
must be done with following cast //
com.inprise.vbroker.CORBA.BOA boa //
((com.inprise.vbroker.CORBA.ORB)orb).BOA_init()
// Create the Count object CountImpl
count new CountImpl("My Count") //
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)
50
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.

51
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.bi
nd(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 lt 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)
52
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

53
The Count Program in Action
54
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