CORBA Overview Developing Basic CORBA Applications DS 520

CORBA Overview; Developing Basic CORBA Applications DS 520 - Distributed Systems Frameworks

Review i Anatomy and Requirements of Distributed Computing i Advantages and Features of DOC Systems i General Architecture of DOC Systems i Overview of Object Management Architecture and CORBA Distributed Systems Frameworks 2

Distributed Computing i Can think of DC as: 4 breaking down an application into individual computing agents 4 distributed over a network 4 work together on a cooperative task i Motivation for DC: 4 parallel processing: can solve larger problems without larger computers 4 applications and data may be difficult to relocate 4 redundant processing agents for fault tolerant systems i Flavors of Distributed Programming 4 Messaging h Asynchronous, Open-loop: programmer must maintain context h Examples; socket programming, cgi (based on http), etc. 4 Remote Invocation h Synchronous (usually), Closed-loop, Location transparency (looks like a local call) h Examples: Remote Procedure Call (RPC), Distributed Objects Distributed Systems Frameworks 3

General Pattern for Remote Invocation Client Code Server Code Stub Skeleton Infrastructure i Call: 4 marshal arguments 4 convert to network format 4 locate server 4 transmit data Distributed Systems Frameworks i Serve: 4 receive data 4 convert & unmarshal 4 invoke method 4 marshall return value 4 transmit data 4

Anatomy of a Distributed Application i 3 layers of a distributed application: 4 network level (TCP/IP, network protocols) 4 higher-level services (directory services, security protocols, etc. ) 4 application level i At the application level: 4 processes 4 threads 4 objects: processes can be made up of one or more objects which can be accessed by one or more threads within the process 4 agents: an “independent” functional element (e. g. , in a banking application we may have a customer agent, a transaction agent, an information brokerage agent) i Example (the customer agent): 4 object 1: running on client machine (2 threads: listening for data; updating display) 4 object 2: running on the bank server (issuing queries; sending data back to client) Distributed Systems Frameworks 5

Requirements for a Distributed Application i Partitioning and Distributing Data and Functions 4 data-driven distribution 4 functional distribution 4 object-based distribution i Flexible, Extendible Communication Protocols 4 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) 4 may also be dictated by legacy systems that need to be incorporated i Multi-threading Requirements 4 server object may need to service multiple remote agents at once 4 effective way to optimize resources i Security Requirements 4 authentication of agent identities 4 define resource access levels 4 data encryption Distributed Systems Frameworks 6

Features of DOC Systems i Object Interface Specification 4 to allow clients to access objects regardless of implementation details i Object Manager 4 The core of a distributed object system (e. g. , ORB, or Registry in RMI) 4 Manages object skeletons and object references on the server 4 When a client requests a new object, the object manager h locates the skeleton for the class of the requested object h creates new instance based on skeleton; stores new object in the object storage h sends a reference to the new object back to the client i Registration / Naming Service 4 Acts as an intermediary between the object client and the object manager 4 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 i Object Communication Protocol to handle remote object requests 4 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 Service Object Interface Specification IDL Compilers Server Implementation Object Skeleton Object Storage Object Manager Naming Service Client Stub Interface Client Application Distributed Systems Frameworks 8

Remote Object Transactions at Runtime Server Object Implementation Object Skeleton 2. Resolve Object 4. Object Interactions Object Manager Naming Service 1. Request Object Client Application Distributed Systems Frameworks 3. Object Handle Object Stubs 9

OMG’s Mission i Develop a single architecture, using object technology, for distributed application integration, guaranteeing: 4 reusability of components; 4 interoperability & portability; 4 basis in commercially available software h Consensus-based approach i Focus on swiftly-developed, easily usable (“off the shelf”) component standards: 4 Single terminology for object-orientation. 4 Common abstract framework. 4 Common reference model. 4 Common interfaces & protocols Distributed Systems Frameworks 10

Long Term Vision WEB Server WEB Browser Java Enabled Hot Java Beans Active. X Java Interpreter IIOP -- HTML -- GIF, JPEG -- AV, WAV -- Java OMG IDL Programs IIOP (CORBA) Sea of Objects (CORBA) P R O G R A M S Active X APP COM/CORBA Legacy DCE APP DCE Distributed Systems Frameworks DCE 11

Object Management Architecture Non-standardized application-specific interfaces Application Interfaces Vertical domain-specific interfaces Domain Interfaces Horizontal facility interfaces CORBAfacilities Object Request Broker CORBAservices General service interfaces Distributed Systems Frameworks 12

Overview of CORBA Objects i CORBA objects differ from typical programming language objects: 4 CORBA objects can be located anywhere on a network. 4 CORBA objects (like Java objects) can run on any platform. 4 CORBA objects can be written in any of several languages. i 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. 4 CORBA objects approach universal accessibility. i A client of an object has access to an object reference for the object, and invokes operations on the object. 4 A client knows only the logical structure of the object according to its interface and experiences the behavior of the object through invocations. 4 Client code has no knowledge of the implementation of the object or which ORB is used to access the implementation. i 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 i A request consists of: 4 Target object (target object identified by a unique object reference) 4 Operation 4 Parameters (the input, output and in-out parameters defined for the operation; may be specified individually or as a list) 4 Optional request context 4 Results (the result values returned by the operation) Client Object Implementation Client Proxy (stub code) Skeleton code Request ORB Distributed Systems Frameworks 14

CORBA Framework Elements i Object Request Broker (ORB) 4 This is the object manager in CORBA i Mechanisms for specifying interfaces 4 Interface Definition Language (IDL) - for static interface definitions 4 Dynamic Invocation Interface (DII) - lets clients access interfaces as first-class objects at run-time from an Interface Repository. i Internet Inter-Orb Protocol (IIOP) 4 A binary protocol for communication between ORBs. 4 Was added in CORBA 2. 0 Distributed Systems Frameworks 15

Today i CORBA Framework and Components i CORBA IDL i Steps in Developing CORBA Applications i Examples Distributed Systems Frameworks 16

Object Request Broker (ORB) i The Object Manager in CORBA i On client side the ORB is responsible for 4 accepting requests for a remote object 4 finding implementation of the object 4 accepting client-side reference to the remote object(converted to a language specific form, e. g. , a Java stub object) 4 routing client method calls through the object reference to the object implementation i On server side the ORB 4 lets object servers register new objects 4 receives requests from the client ORB 4 uses object’s skeleton interface to invoke object’s activation method 4 creates reference for new object and sends it back to client Distributed Systems Frameworks 17

OMG IDL i OMG Interface Definition Language (IDL): 4 mappings for many languages/compilers; 4 independent of any particular language/compiler; 4 multiple-inheritance, public interface-structured specification language; 4 not for implementation. 4 primary support for interoperability between static and dynamic requests mechanisms. i IDL Structure 4 Module auction { exception Not. Allowed {}; h a namespace struct Sale { int price; string item; } 4 Interface h abstract type h multiple inheritance interface Auction { void bid (in long price) raises Not. Allowed; } 4 Struct h structured data } Distributed Systems Frameworks 18

Internet Inter-Orb Protocol (IIOP) i CORBA specification is neutral with respect to network protocols 4 the CORBA standard specifies what is known as the General Inter-ORB Protocol (GIOP) 4 GIOP is a high-level standard protocol for communication between ORBs 4 not used directly; instead, it is specialized by a particular protocol that would then be used directly i Internet Inter-ORB Protocol (IIOP) 4 IIOP is the GIOP-based protocol for TCP/IP networks 4 As of the 2. 0 version of the CORBA specification, vendors are required to implement the IIOP protocol i CORBA Networking Model 4 CORBA applications are built on top of GIOP-derived protocols such as IIOP 4 these protocols, in turn, rest on top of TCP/IP, DCE, or other underlying transport protocol the network uses 4 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 i In a distributed application, there are two possible methods for an application component to obtain access to an object in another process: 4 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. 4 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. 4 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 i An Object Reference is the information needed to specify an object within an ORB. 4 The representation of an object reference handed to a client is only valid for the lifetime of that client. 4 The language mapping also provides additional ways to access object references in a typed way for the convenience of the programmer. 4 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. i To invoke a CORBA object, you need a reference for the object. There are two ways to get a reference for a CORBA object: 4 from another object, such as a factory or a name service 4 from a string that was specially created from an object reference i Interoperable Object References 4 CORBA uses IOR as a “pointer” to a specific instance of a class in a distributed environment 4 encodes host, port, object identity 4 may be externalized (using object_to_string) Distributed Systems Frameworks 21

CORBA Components i Client stub 4 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). 4 The stubs make calls on the rest of the ORB using interfaces that are private to Java. IDL. 4 Alternatively, a client may dynamically construct and invoke request objects which can represent any object operation. i Implementation Skeleton 4 Each skeleton provides the interface through which a method receives a request (dynamic and static skeletons) i Object Adapter 4 Purpose is to interface an object's implementation with its ORB 4 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. i ORB Interface 4 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 Object Implementation Client Dynamic Invocation Client Stubs ORB Interface Implementation Skeletons Object Adapter ORB Core standard interface Proprietary ORB interface One interface per object adaptor Normal call interface Up call interface One interface per object operation Distributed Systems Frameworks 23

Client Side Clients perform requests using object references. Clients may issue requests through object interface stubs (static) or dynamic invocation interface. Client Dynamic Invocation Client Stubs Distributed Systems Frameworks ORB Interface Clients may access general ORB services: • Interface Repository. • Context Management. • List Management. • Request Management. 24

Implementation Side Implementations receive requests through skeletons (without knowledge of invocation approach). Object Implementation ORB Interface Implementation Skeletons Object Adapter The Object Adapter provides for: • management of references; • method invocation; • authentication; • implementation registration; • activation/deactivation. Distributed Systems Frameworks 25

Static v. Dynamic Invocation i Static Invocation 4 Static interfaces are generated in form of client stubs by the IDL (pre-) compiler. 4 This means that the structure of the object has to be known before hand (at compile time). 4 Allows for better type checking; less runtime overhead; self-documentation. i Dynamic Invocation 4 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). 4 Clients must discover interface-related information at runtime (e. g. , using the interface repository) 4 Servers can offer new services anytime without the need for recompilation on the client side. Distributed Systems Frameworks 26

Dynamic Requests i The Dynamic Invocation Interface (DII) allows clients to dynamically: 4 4 4 discover objects; discover objects’ interfaces; create requests; invoke requests; receive responses. i Major features of Dynamic Invocation Interface: 4 requests appear as objects themselves; 4 requests are reusable; 4 invocation may be synchronous or asynchronous; 4 requests may be generated dynamically, statically or in combination approach. Distributed Systems Frameworks 27

CORBA Interface Repository i The Interface Repository is a service that provides persistent objects that represent the IDL information in a form available at runtime. 4 Note: The Java. IDL runtime does not include an implementation of an Interface Repository and one is not generally required by clients at runtime. 4 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. i Interface Repository provides: 4 Dynamic client access to interface definitions to construct a request. 4 Dynamic type-checking of request signatures. 4 Traversal of inheritance graphs. 4 ORB-to-ORB interoperability. Distributed Systems Frameworks 28

CORBA Implementation Repository i The Implementation Repository contains information that allows the ORB to locate and activate implementations of objects. i 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. i 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) i 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 Implementation Installation IDL Interface Definitions Interface Repository Accesses Client Stubs Includes Client Implementation Skeletons Implementation Repository Includes Describes Object Implementation 4 All objects are defined in IDL by specifying their interfaces. 4 Object definitions (interfaces) are manifested as objects in the Interface Repository, as client stubs, and as implementation skeletons. 4 Descriptions of object implementations are maintained as objects in the Implementation Repository. Distributed Systems Frameworks 30

Summary: CORBA Remote Method Invocation i Clients use “object interfaces” through language mapping 4 Java clients should work on any ORB that supports the Java language bindings. 4 Clients can call any object instance remotely, so long as the object instance implements the interface. i Clients can call remote objects statically or dynamically 4 The server cannot tell whether the client is using static or dynamic invocation. i Objects are identified using a unique id: Interoperable Object Reference (IOR) 4 CORBA passes objects by reference 4 IOR was Introduced in CORBA 2. 0 4 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 i Write specification for each object using IDL i Use IDL Compiler (e. g. , idl 2 java) to generate: 4 Client Stub code 4 Server Skeleton code i Write the client (in Java, can be applications or applets) i Write the server object implementation code (the “servant”) i Compile the client and server code i Start the server i Run the client application Distributed Systems Frameworks 32

The Structure of CORBA IDL (See Section 2. 3. 4 of Brose, Vogel, Duddy) i Modules 4 provide namespaces for a set of related class descriptions 4 map to Java packages with the same name i Interfaces 4 specification of the operations a client can invoke on a remote object 4 in addition to operations, interfaces include constructs such as: h constant declarations h attributes (can be read/write or readonly; implementation automatically creates get and set operations for these attributes) h exceptions (raised if the operations do not perform successfully) i Operations 4 CORBA equivalent of methods in Java 4 IDL defines the operations’ signature: parameters and return values/types 4 parameters can be in, out, or inout 4 IDL also defines what exceptions can be raised by the operation Distributed Systems Frameworks 33

Data Types in CORBA IDL i Basic Types 4 short, long, unsigned short, float, double, long double, char, wchar, boolean, string, octet, etc. i Constructed Types 4 struct and union (similar to C++; can be used in conjunction with a typedef) 4 sequence (variable sized arrays of objects) 4 any (generic type which represents any possible IDL types; similar to the Java Object type) 4 enum (enumerated type with named integer values) 4 arrays 4 valuetypes (similar to interfaces; preceded with keyword valuetype to provide pass-by-value semantics) i 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>]. . . }; interface <identifier> [: <inheritance>] {. . . }; Distributed Systems Frameworks 35

An IDL Example module My. Animals { interface Dog: Pet, Animal { attribute short age; exception Not. Interested{string explanation}; void Bark(in short how_long) raises (Not. Interested); void Sit(in string where) raises (Not. Interested); . . . }; interface Cat: Animal { void Eat(); . . . }; }; Distributed Systems Frameworks 36

Another IDL Example module Room. Booking { interface Meeting { readonly attribute string purpose; readonly attribute string participants; oneway void destroy(); }; interface Meeting. Factory { Meeting Create. Meeting(in string purpose, in string participants); }; interface Room { // A Room provides methods to view, make, cancel bookings. enum Slot { am 9, am 10, am 11, pm 12, pm 1, pm 2, pm 3, pm 4 }; const short Max. Slots = 8; typedef Meetings[ Max. Slots ]; exception No. Meeting. In. This. Slot {}; exception Slot. Already. Taken {}; readonly attribute string name; Meetings View(); void Book( in Slot a_slot, in Meeting raises(Slot. Already. Taken); void Cancel( in Slot a_slot ) raises(No. Meeting. In. This. Slot); a_meeting ) }; }; Distributed Systems Frameworks 37

The CORBA Count Example The Count Program 4 the client will invoke a method increment() on the remote object Count; 4 increment() adds 1 to the value of the attribute sum and returns the value to the client program; 4 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 First we must start with an IDL definition for the Count object: Distributed Systems Frameworks module Counter { interface Count { attribute long sum; long increment(); }; }; 38

The IDL Compiler i Before using the IDL compiler or running the program make sure that the PATH and CLASSPATH environment variables are properly set up: 4 Your PATH must point to the Java runtime environment directory as well as the ORB runtime directory ( inprisevbrokerbin); 4 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 inprisevbrokerlibvbjcosnm. jar inprisevbrokerlibvbjorb. jar inprisevbrokerlibvbjapp. jar inprisevbrokerlibvbjtools. jar inprisevbrokerlibvbjgk. jar Distributed Systems Frameworks In Visibroker 4. x inprisevbrokerlibvbdev. jar inprisevbrokerlibvbjorb. jar inprisevbrokerlibvbjmigration. jar jdk 1. 2. 2libservlet. jar 39

The IDL Compiler i Now you can compile the IDL definition: > idl 2 java -no_tie Count. idl i Important Notes: 4 if you are using Visibroker 3. 3, you need JDK 1. 1. 8; as VBJ 3. 3 is not compatible with Java 2 platform 4 in VBJ 4. x, idl 2 java compiler generated code is based on the POA (portable object adapter) semantics; in order to use BOA semantics, must use: > idl 2 java -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) 4 in VBJ 3. x, the idl 2 java 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 Implementation Skeleton Client Stub idl 2 java Client-Side Server-Side _st_Count. java Count. Helper. java Count. Holder. java _Count. Impl. Base. 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? VBJ 4. x using POA Count. idl Implementation Skeleton Client Stub idl 2 java Client-Side Server-Side _Count. Stub. java Count. Helper. java Count. Holder. java Count. POA. java Count. java Note: if -boa option is used with idl 2 java compiler, _Count. Impl. Base. java is also generated to be used in the object implementation. Distributed Systems Frameworks 42

Generated Classes & Interfaces i. Counter. _st_Count: implements the client-side stub for the Count object; it provides the marshaling functions for the client. [_Count. Stub in VBJ 4. x]. i. Counter. _Count. Impl. Base: implements the server-side skeleton for Count; it unmarshals the arguments passes by the client. [Count. POA in VBJ 4. x using POA]. i. Counter. Count. Helper: 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. i. Counter. Count. Holder: it is used as a wrapper for passing out and inout parameters of type Count (Java only natively supports in parameters). i. Counter. Count: contains the Java interface corresponding to the IDL interface for Count; the object implementation for Count must implement this interface. i. 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 org. omg. CORBA. portable. Skeleton (provided by the ORB) class org. omg. CORBA. portable. Object. Impl (provided by the ORB) Extends interface Counter. Count (generated by id 2 java) Implements abstract class Counter. _st_Count (generated by id 2 java) Extends abstract class Counter. _Count. Impl. Base (generated by id 2 java) Extends Note: in case of POA, the object skeleton “Count. POA” extends org. omg. CORBA. Portable. Server. Servant Distributed Systems Frameworks class Count. Impl (written by programmer and used by the server) 44

Steps in Developing the Count Application i Write a client program in Java: 4 this can be an applet or an application; 4 in this case we write a Java application Count. Client. java. i Write the server-side code for the Count application: 4 write a server application which creates and serves instance(s) of the Count object (instances of the class Count. Impl); 4 write the object implementation (Count. Impl). i Object Implementation: 4 CORBA inheritance model: the implementation class is always derived from the corresponding _XXXImpl. Base class generated by IDL compiler (in this case from _Count. Impl. Base; [Note: with POA this is XXXPOA, e. g. , Count. POA] 4 this inheritance allows the servant class to obtain the properties of both CORBA and Java object models; 4 the alternative to inheritance model is to use delegation (in CORBA terminology the Tie method); if -no_tie option is not used with idl 2 java relevant classes will be generated; 4 in this case we create our Count. Impl by modifying the file _example_Count. java. Distributed Systems Frameworks 45

_example_Count. java package Counter; public class _example_Count extends Counter. _Count. Impl. Base { 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 // Count. Impl. java: The Count Implementation class Count. Impl extends Counter. _Count. Impl. Base { private int sum; // Constructors Count. Impl(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 i Initialize the Object Request Broker 4 done by creating an instance of the ORB pseudo-object; 4 the static Java method init() on the class org. omg. CORBA. ORB returns an instance of an ORB. i Initialize the Basic Object Adaptor 4 a reference to an instance of the BOA is obtained via the method BOA_init(). i Create the object (an instance of the class implementation) 4 in this case we create an instance of Count. Impl class i Activate the newly created object 4 in BOA this is done by calling the obj_is_ready() method of the ORB instance on the object; 4 this action exports the object to the ORB. i Wait for incoming requests 4 in BOA this is done by calling the impl_is_ready() method of the ORB instance on the object; Distributed Systems Frameworks 48

// Count. Server. java: The Count Server main program class Count. Server { 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 BOA Count Server // 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 Count. Impl count = new Count. Impl("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. System. Exception e) { System. err. println(e); } } } Distributed Systems Frameworks 49

Tasks Performed by the Client i Initialize the ORB 4 done the same way as for the server. i Locate the Remote Object 4 in this case client binds to the object via the Visibroker bind() method. i Perform Operations via Remote Methods 4 set the remote sum attribute to zero; 4 calculate the start time; 4 invoke the increment method 1000 times; 4 calculate the elapsed time; 4 print the results. Distributed Systems Frameworks 50

The BOA Count Client // Count. Client. java Static Client, Visi. Broker for Java class Count. Client{ 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. Count. Helper. bind(orb, "My Count"); // Set sum to initial value of 0 counter. sum((int)0); // Calculate Start time long start. Time = System. current. Time. Millis(); // Increment 1000 times for (int i = 0 ; i < 1000 ; i++ ) { counter. increment(); } // Calculate stop time; print out statistics long stop. Time = System. current. Time. Millis(); System. out. println("Avg Ping = " + ((stop. Time-start. Time)/1000 f)+" msecs"); System. out. println("Sum = " + counter. sum()); } catch(org. omg. CORBA. System. Exception e) { System. err. println("System Exception"); System. err. println(e); } Distributed Systems Frameworks } } 51

Building and Running the Count Example i Compile the client, server, and the implementation classes vbjc -d Corba. Java. Book. 2 eclasses Count. Client. java vbjc -d Corba. Java. Book. 2 eclasses Count. Server. java vbjc -d Corba. Java. Book. 2 eclasses Count. Impl. java Note: Corba. Java. Book. 2 eclasses is where the Java bytecode classes will be stored (without -d option classes are generated in the current directory). i Start the Visibroker Smart Agent (OSAgent) 4 osagent -c OR start osagent -c 4 OSAgent may be installed as an NT Service or started using the icon in the program menu i Start the Count Server: vbj Count. Server i Execute the Client Application: vbj Count. Client Distributed Systems Frameworks 52

The Count Program in Action Distributed Systems Frameworks 53

Next time i More Examples of CORBA Applications i CORBA Object References i The POA version of Count Application i More on IDL elements 4 read/readonly attributes 4 oneway methods 4 parameter passing mechanisms 4 exceptions and exception handling i Discussion of Project Phase I Distributed Systems Frameworks 54