Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka {nanbor,roopa}@txcorp.com Tech-X Corporation Boulder, CO Funded by DOE OASCR SBIR

Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka {nanbor,roopa}@txcorp.com Tech-X Corporation Boulder, COFunded by DOE OASCR SBIR Grant #DE-FG02-04ER84099CCA Meeting, April 19, 2007

Nanbor Wang and Roopa Pundaleeka

Distributed Components

OverviewBrief review of the project

New development since the last CCA meeting

Future work



Babel RMI SupportBabel generates mapping for remote invocations, and uses Simple Protocol

Babel has the capability to allow users to take advantage of various remoting technologies through third party RMI libraries

We are developing a CORBA protocol library for Babel RMI using TAO (version 1.5.1 or later)TAO is the C++ based CORBA middleware frameworkThis protocol is essentially a bridge between Babel and TAO



Adding CORBA protocol for Babel RMIGoalDevelop CORBA protocol for Babel RMI for communication between Babel clients and servantsAlso allowing interoperability between existing CORBA and Babel objects

Direct mapping approach Requires support of certain Babel types; complex numbers, multidimensional arrays and exceptionsAll special type mappings defined under namespace taoiiop_rmiStill exchange messages in CORBA formatAllow development of new SIDL-compatible CORBA objects



Client-side Operation InvocationsCORBA uses Common Data Representation (CDR) a binary serialization format, for transferring messages

An Operation_Details object encapsulates all information related to invocations in TAO outgoing CDR and incoming CDR streams

Need to extend TAOs Operation_Details to expose internal CDR data members to extract the resultsCreate TAO Argument list in pack methods for in and inout parametersTAO argument list no longer requires the return type as the first argument



Client-side Operation Invocations in TAOTAO client makes the method invocation on the TAO stubsTAO Stubs:Create argument list based on the signatureCreate an instance of the TAO Invocation Adapter Call invoke on the TAO Invocation AdapterMakes the remote method invocationUsed for transferring messagesEncapsulates invocation requests and replies in CDR streams



Client-side Operation Invocations in TaoIIOP InterfaceInvocation Adapter creates an instance of TaoIIOP_Operation_Details, which in turn creates the Input CDR and marshals all the input argumentsMakes the remote method invocationBabel stubs call pack on TaoIIOP Invocation object for every in and inout arguments, and then triggers the remote invocationTaoIIOP Invocation:Creates TAO argument list when pack is calledCreates TaoIIOPInvocation adapter, which inherits from TAO Invocation Adapter



Server-side Request HandlingA default TAO servant handles all Babel invocations

Need to extend TAOs PortableServer class to expose the Input (for reading input parameters) and Output (to set the results) CDRsSIDL Call and Response objects get a reference to the Input and Output CDRs respectively

Requests are demultiplexed to target Babel objects based on the instance/object ID



Server-side Request Handling in TAOTAO PortableServer gets the request from the client ORBdispatch method has a reference to the TAO_ServerRequest object, which has the method signature, InputCDR and OutputCDRThe skeleton finds the implementation object and executes the callUpdates the TAO Arg List with the return valuesTAO PortableServer dispatches the call to the appropriate skels



Server-side Request Handling in TaoIIOP InterfaceDefault TAO object (TaoIIOPObject) extends TAO PortableServer::ServantBase, and implements the dispatch method, which gets the Input and Output CDRs in ServerReq obj.The dispatch method creates the sidl::rmi::Response, which stores the CDRGets a reference to the target SIDL object from the InstanceRegistryExecutes the target methodPack methods are called on the response object for return, inout and out parametersThe results are directly packed into the CDR



New Development since last CCA MeetingException handlingOne-way method invocationNon-blocking/ Asynchronous Method Invocation (AMI)



Implementation of Exception HandlingTaoObject IDL interface defines a CORBA user exception called ServerExceptionexception ServerException {string info;};The server side implementation throws CORBA exceptions, which are caught by the client side TaoIIOP interface and converted to taoiiop::rmi::GenNetworkException, which can be caught by the Babel clients.Example:catch (CORBA::Exception &ex) {taoiiop::rmi::GenNetworkException e =taoiiop::rmi::GenNetworkException::_create ();e.setNote (ex._info ().c_str ());e.add (__FILE__, __LINE__, method_name);throw (e);}



Implementation of One-way CallsIt was a simple modification to the existing Two-way invocationsWe had already extended TAOs invocation adapter to invoke synchronous two-way method calls:By default, the Invocation_Adapter makes a two-way callJust changed the default to be one-way:// one-way call taoiiop::rmi::Invocation_Adapter _tao_call (taoiiop, _the_tao_operation_signature, arg_length, nameNid.c_str (), nameNid.length (), NULL, ::TAO::TAO_ONEWAY_INVOCATION);



Support for Non-blocking Calls in BabelBabel generates interfaces for Polling model. Simple protocol implements Polling modelEach AMI operation returns a Poller object (sidl::rmi::Ticket)When the client is ready to get the return values, it can use the poller to check the status of the request by polling or just decide to block until the reply is obtained from the serverHas special get/recv methods to obtain the results from the response object



Implementation of Non-blocking Calls in TAOTAO implements the CORBA AMI Call-back ModelClient passes an object reference of a reply_dispatcher which has a callback method as a parameter, along with in and inout parametersThe stubs create an instance of TAO::Asynch_Invocation_Adapter, which stores the reply_dispatcher locally on the client ORB, and makes the remote callWhen the server replies, the client ORB receives the response, and dispatches it to the appropriate callback operation on the reply_dispatcher provided by the clientTAO does not support polling model. No return values sent to the clients



Mapping Babel Non-blocking (Polling) to TAO AMI (Callback)TaoIIOP extends TAOs Asynch Invocation class to create a default Asynch_Reply_Dispatcher, which will be used for every AMI callThe TaoIIOP::rmi::Asynch_Invocation_Adapter stores the dispatcher in the client ORB to receive callbackWhen the reply arrives, the callback is invoked on the default reply dispatcherThe callback method stores the CDR object in the Response object to be used by the clientsPolling is not supported



Summary of CORBA protocol for Babel RMITasks implemented:Both client and server side interfacesInteroperability with regular CORBA serverAll basic types, complex numbers, strings, and arrays Exception supportOne-way and Non-blocking callsTasks to do:Opaque and serializable supportBenchmark performance for comparing multiple protocolsRegression tests: some tests are in place, but need some work to be able to use them with both TaoIIOP and Simple protocolsWill package TaoIIOP and make it available on the web soon. Please email [email protected] or [email protected] for more information



Referenceshttps://collaborate.txcorp.com/collaborate/distributed-technologies/distributed-components/distributed-components-home

A. Arulanthu, C. ORyan, D. Schmidt, M. Kircher and J. Parsons, The Design and Performance of a Scalable ORB Architecture for CORBA Asynchronous Messaging

A. Arulanthu, C. ORyan, D. Schmidt, M. Kircher and A. Gokhale, Applying C++, Patterns and Components to Develop an IDL Compiler for CORBA AMI Callbacks


Documents

Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka {nanbor,roopa}@txcorp.com Tech-X Corporation Boulder, CO Funded by DOE OASCR SBIR