Name: Ritika Maheshwari

Progress Report

Suitability of CORBA for NASA EOSDIS System
by Ritika Maheshwari
Instructor: Rod Fatoohi
College of Engineering, San Jose State University
December 1998

Background: Designs and implementations of EOSDIS Core System (ECS) must be adaptable to changes in new user’s requirements, new technologies, and new paradigms for data acquisition and distribution. This is exceptionally accented in an environment of federated providers where the list of new providers is projected to grow significantly. It is also indicative of the era of interoperable applications evolving into a global means for the international science community to share critical science data and information.

To meet these requirements, ECS applications could be comprised of collections of distributed objects that can be reused and rapidly reassembled. Standards for distributed objects and applications, such as Object Management Group’s (OMG) Common Object Request Broker Architecture (CORBA) or Microsoft’s Distributed Component Object Model (DCOM) have emerged to promise more flexible, adaptable, and scalable applications. Distributed object applications can be implemented over any number of client and server systems with prospects for improved adaptable computing performance.

ECS requirements dictate multi-vendor integrated solutions. Vendor produced technologies implementing CORBA standards are maturing in a commercial market. Separating the reality from the promise of these emerged technologies is critical for system developers and project managers coping with technology change. The purpose of my project is to prove that CORBA is a suitable technology for the currently DCE based EOSDIS system.

Accomplishments: My major accomplishments during the course of this semester are as follows:

Understanding of the NASA’s EOSDIS system and its various sub-systems.

Understanding of the interactions between these sub systems.

Understanding of the middleware design in the ECS system and its short- comings.

Understanding of OODCE, one of the middleware layers in the ECS architecture.

Implementing a sample OODCE application in CORBA and comparing the differences between the two. This experiment gave me a better understanding of OODCE and how it maps to CORBA. In the sample OODCE application the client invokes simple arithmetic operations (like add, subtract, multiply, divide) on a server side math object and then displayed the results on the screen.

Comparisons between sample application code in CORBA and OODCE
IDL File

In OODCE each defined remote procedure call must use explicit binding management. Therefore, in the OODCE IDL file all procedure declarations have a binding handle of type handle_t, as their first argument. A binding handle is the data structure that manages binding in applications. The handle is a reference (pointer) to information for one possible binding.

DCE IDL also supports the implicit and automatic binding modes; however, they must not be used in the IDL files passed to the idl++ compiler. The functionality provided by implicit and automatic binding is supported at a higher level in OODCE.

In CORBA no binding information is passed to the IDL compiler. The bind method of the helper class helps in binding to a particular object.

In OODCE an interface version number must be specified so that idl++ can generate class names that allow multiple versions of an interface to be used within an application without name clashes.

In CORBA interfaces do not have version numbers.

Client Side Code

In OODCE the application code that requires access to a remote DCE object simply constructs an instance of the concrete class (supplying optional location information, like the object UUID, the protocol etc) and makes member function calls to that object. All member function calls are passed by the proxy object to the remote object to which it is bound for processing.

In CORBA there are no concrete classes, the client IDL Stub, acts like a local proxy for the remote server object. You can use naming services to bind to the object of a particular type. The compiler produces helper classes with a narrow function that lets clients cast CORBA object references to the individual object type. In addition to the required CORBA helper functions, the VisiBroker implementation provides a very useful, but non standard, function called bind; it is used by clients to locate objects of a given type.

Server Side Code

In OODCE, in addition to the class definitions, the idl++ compiler generates a server entrypoint vector (EPV) for the interface. The EPV generated by the idl++ compiler provides the mapping between the C calls made by the server stub and the c++ method calls provided by the class library and the developer. An incoming client request must be mapped into a member function call on a specific c++ object instance. The EPV locates the correct c++ object and makes the requested member function call.

The EPV is emitted in a file whose name is also derived from that of the input file. In this case, the suffix of the target is "E.C".

In CORBA there are no EPV’s. The Server IDL Stubs, provide static interfaces to each service exported by the server.

In OODCE, there is a class called DCEServer that manages objects and interfaces with DCE. The DCEServer class is responsible for object registration, protocol selection, the CDS and security preferences, cleanup, and listening for the client requests. Only one instance of a DCEServer object can exist per process. This is because DCE only allows one rpc_server_listen call per process. For convenience, the OODCE library contains a Global Server Object (GSO) called theServer that can be used by server programs.

In CORBA, there is no such server class available, the objects are registered with the ORB.

In OODCE, one of the biggest problems facing a server developer is performing cleanup tasks after receiving signals. If appropriate cleanup is not executed when such a signal is sent to a process, stale information can be left in DCE that can cause performance problems and sometimes failure in other system elements (such as stale bindings being passed to clients). The DCEServer class implementation provided by OODCE provides a default signal handler that performs appropriate cleanup.

The following code fragment shows how to activate the default signal handler

DCEPThread * cleaner = new DCEPThread(theServer->ServerCleanup, NULL);

This code creates a thread that executes the ServerCleanup member function on the global server object. ServerCleanup sets up a signal handling function that waits for signals and executes a server shutdown if a signal is sent to the process.

In CORBA, there is no such server clean up mechanism.

In OODCE, by default the GSO (Global Server Object) listens for client requests on all protocols supported by DCE on the platform (i.e. TCP/IP and UDP/IP on UNIX)

In CORBA, the only protocol supported is IIOP.

My Goal

My goal is to finish my implementation by June end.

CORBA IMPLEMENTATION

Here are the various files, which were created, while implementing the math application in CORBA.

************************************************************************

// IDL file for the math object

module math

{ interface mathObject

{

double add(in double a, in double b);

double subtract(in double a, in double b);

double multiply(in double a, in double b);

double divide(in double a, in double b);

};

interface mathObjectDispenser

{

mathObject reservemathObject() ;

void releasemathObject(in mathObject matha);

};

};

************************************************************************

//mathClient.java

The client binds to a dispenser object and gets reference

to the math object through the dispenser object. Then uses that

reference to invoke functions on the object //

import java.io.*;

import java.util.*;

import java.lang.*;

import org.omg.CosNaming.*;

public class mathClient {

public static void main(String args[]){

math.mathObject myMathObject1 = null;

math.mathObject myMathObject2 = null;

math.mathObject myMathObject3 = null;

math.mathObject myMathObject4 = null;

double x = 10.0, y = 5.0, result = 0.0 ;

math.mathObjectDispenser myMathObjectDispenser = null;

try

{

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

myMathObjectDispenser = math.mathObjectDispenserHelper.bind(orb, "My Dispenser");

myMathObject1 = myMathObjectDispenser.reservemathObject();

myMathObject2 = myMathObjectDispenser.reservemathObject();

myMathObject3 = myMathObjectDispenser.reservemathObject();

myMathObject4 = myMathObjectDispenser.reservemathObject();

} catch(Exception e)

{ e.printStackTrace(); }

result = myMathObject1.add(x,y);

System.out.println("The result of addition is:");

System.out.println(result);

myMathObjectDispenser.releasemathObject(myMathObject1);

result = myMathObject2.subtract(x,y);

System.out.println("The result of subtraction is:");

System.out.println(result);

myMathObjectDispenser.releasemathObject(myMathObject2);

result = myMathObject3.multiply(x,y);

System.out.println("The result of multiplication is:");

System.out.println(result);

myMathObjectDispenser.releasemathObject(myMathObject3);

result = myMathObject4.divide(x,y);

System.out.println("The result of division is:");

System.out.println(result);

myMathObjectDispenser.releasemathObject(myMathObject4);

}

}

************************************************************************

// mathObjectDispenserImpl.java

The object dispenser is an object which prestarts the specified number of math objects and register them with the ORB. It provides methods for the client to bind to these objects and release these objects. Therefore the dispenser object cater to the client needs, by reusing the objects, in this pool of prestarted objects//

public class mathObjectDispenserImpl extends math._mathObectDispenserImplBase

{

private int maxObjects = 10;

private int numObjects = 0;

private mathObjectStatus[] mathobject =

new mathObjectStatus[maxObjects];

public mathObjectDispenserImpl(java.lang.String[] args,

java.lang.String name, int num) {

super(name);

try

{

// initialize the ORB

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);

// prestart n mathObjects

numObjects = num;

for (int i=0; i < numObjects; i++)

{

mathobject[i] = new mathObjectStatus();

mathobject[i].ref = new mathObjectImpl("mathObject" + (i+1));

orb.connect(mathobject[i].ref);

}

} catch(Exception e)

{ System.err.println(e);

}

}

public mathObjectDispenserImpl() {

super();

}

public math.mathObject reservemathObject() {

// implement operation...

for (int i=0; i < numObjects; i++)

{

if (!mathobject[i].inUse)

{ mathobject[i].inUse = true;

System.out.println("mathObject" + (i+1) + " reserved.");

return mathobject[i].ref;

}

}

return null;

}

public void releasemathObject(

math.mathObject matha

) {

for (int i=0; i < numObjects; i++)

{

if (mathobject[i].ref.equals(matha));

{ mathobject[i].inUse = false;

System.out.println("mathObject" + (i+1) + " released.");

return;

}

}

System.out.println("Reserved Object not found");

return;

}

class mathObjectStatus

{

mathObjectImpl ref;

boolean inUse;

mathObjectStatus()

{ ref = null;

inUse = false;

}

}

************************************************************************

// mathObjectImpl.java

This class actually implements all the functions of the math object as specified in the IDL //

import java.util.*;

public class mathObjectImpl extends math._mathObjectImplBase {

public mathObjectImpl(java.lang.String name) {

super(name);

}

public mathObjectImpl() {

super();

}

public double add(

double a,

double b

) {

// implement operation...

return (a+b);

}

public double subtract(

double a,

double b

) {

// implement operation...

return (a-b);

}

public double multiply(

double a,

double b

) {

// implement operation...

return (a*b);

}

public double divide(

double a,

double b

) {

// implement operation...

return (a/b);

}

}

************************************************************************

//mathServer.java

This class intializess the ORB, creates new dispenser object, register it with ORB. Then it just waits for the calls from the client.//

import org.omg.CosNaming.*;

class mathServer

{

static public void main(String[] args)

{

int numberInstances;

try

{ if(args.length == 0)

numberInstances = 4;

else

numberInstances = Integer.parseInt(args[0]);

// Initialize ORB

org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,null);

// Initialize the BOA.

org.omg.CORBA.BOA boa = orb.BOA_init();

// Create the mathObjectDispenser

mathObjectDispenserImpl dispenser = new mathObjectDispenserImpl(args,

"My Dispenser", numberInstances);

// Export the newly create object.

boa.obj_is_ready(dispenser);

System.out.println(dispenser + " is ready.");

// Wait for incoming requests

boa.impl_is_ready();

}catch (Exception e)

{ System.err.println(e);

}

}

************************************************************************