Presentation is loading. Please wait.

Presentation is loading. Please wait.

Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka Tech-X Corporation Boulder, CO Funded by DOE OASCR SBIR.

Similar presentations


Presentation on theme: "Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka Tech-X Corporation Boulder, CO Funded by DOE OASCR SBIR."— Presentation transcript:

1 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 Grant #DE-FG02-04ER84099 CCA Meeting, April 19, 2007

2 Distributed Components Nanbor Wang and Roopa Pundaleeka2 Overview Brief review of the project New development since the last CCA meeting Future work

3 Distributed Components Nanbor Wang and Roopa Pundaleeka3 Babel RMI Support Babel 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 framework –This protocol is essentially a bridge between Babel and TAO BABEL RMI CLIENT BABEL RMI SERVER TaoIIOP Protocol TAO BABEL RMI CLIENT BABEL RMI SERVER Simple Protocol

4 Distributed Components Nanbor Wang and Roopa Pundaleeka4 Adding CORBA protocol for Babel RMI Goal –Develop CORBA protocol for Babel RMI for communication between Babel clients and servants –Also allowing interoperability between existing CORBA and Babel objects Direct mapping approach –Requires support of certain Babel types; complex numbers, multidimensional arrays and exceptions –All special type mappings defined under namespace taoiiop_rmi –Still exchange messages in CORBA format –Allow development of new SIDL-compatible CORBA objects

5 Distributed Components Nanbor Wang and Roopa Pundaleeka5 Client-side Operation Invocations CORBA 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 TAO’s Operation_Details to expose internal CDR data members to extract the results –Create TAO Argument list in pack methods for ‘in’ and ‘inout’ parameters –TAO argument list no longer requires the return type as the first argument

6 Distributed Components Nanbor Wang and Roopa Pundaleeka6 Client-side Operation Invocations in TAO TAO client makes the method invocation on the TAO stubs TAO Stubs: 1.Create argument list based on the signature 2.Create an instance of the TAO Invocation Adapter 3.Call invoke on the TAO Invocation Adapter Makes the remote method invocation Used for transferring messages Encapsulates invocation requests and replies in CDR streams

7 Distributed Components Nanbor Wang and Roopa Pundaleeka7 Client-side Operation Invocations in TaoIIOP Interface 1.Invocation Adapter creates an instance of TaoIIOP_Operation_Details, which in turn creates the Input CDR and marshals all the input arguments 2.Makes the remote method invocation Babel stubs call pack on TaoIIOP Invocation object for every ‘in’ and ‘inout’ arguments, and then triggers the remote invocation TaoIIOP Invocation: 1.Creates TAO argument list when pack is called 2.Creates TaoIIOPInvocation adapter, which inherits from TAO Invocation Adapter

8 Distributed Components Nanbor Wang and Roopa Pundaleeka8 Server-side Request Handling A default TAO servant handles all Babel invocations Need to extend TAO’s PortableServer class to expose the Input (for reading input parameters) and Output (to set the results) CDRs –SIDL 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

9 Distributed Components Nanbor Wang and Roopa Pundaleeka9 Server-side Request Handling in TAO TAO PortableServer gets the request from the client ORB 1.dispatch method has a reference to the TAO_ServerRequest object, which has the method signature, InputCDR and OutputCDR 2.The skeleton finds the implementation object and executes the call 3.Updates the TAO Arg List with the return values TAO PortableServer dispatches the call to the appropriate skels

10 Distributed Components Nanbor Wang and Roopa Pundaleeka10 Server-side Request Handling in TaoIIOP Interface 1.Default TAO object (TaoIIOPObject) extends TAO PortableServer::ServantBase, and implements the ‘dispatch’ method, which gets the Input and Output CDRs in ServerReq obj. 2.The dispatch method creates the sidl::rmi::Response, which stores the CDR 3.Gets a reference to the target SIDL object from the InstanceRegistry 4.Executes the target method 1.Pack methods are called on the response object for return, inout and out parameters 2.The results are directly packed into the CDR

11 Distributed Components Nanbor Wang and Roopa Pundaleeka11 New Development since last CCA Meeting Exception handling One-way method invocation Non-blocking/ Asynchronous Method Invocation (AMI)

12 Distributed Components Nanbor Wang and Roopa Pundaleeka12 Implementation of Exception Handling TaoObject IDL interface defines a CORBA user exception called ServerException exception 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); }

13 Distributed Components Nanbor Wang and Roopa Pundaleeka13 Implementation of One-way Calls It was a simple modification to the existing Two-way invocations We had already extended TAO’s invocation adapter to invoke synchronous two-way method calls: –By default, the Invocation_Adapter makes a two-way call –Just 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);

14 Distributed Components Nanbor Wang and Roopa Pundaleeka14 Support for Non-blocking Calls in Babel Babel generates interfaces for Polling model. Simple protocol implements Polling model Each 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 server –Has special get/recv methods to obtain the results from the response object

15 Distributed Components Nanbor Wang and Roopa Pundaleeka15 Implementation of Non-blocking Calls in TAO TAO implements the CORBA AMI Call-back Model Client passes an object reference of a reply_dispatcher which has a callback method as a parameter, along with ‘in’ and ‘inout’ parameters The stubs create an instance of TAO::Asynch_Invocation_Adapter, which stores the reply_dispatcher locally on the client ORB, and makes the remote call When the server replies, the client ORB receives the response, and dispatches it to the appropriate callback operation on the reply_dispatcher provided by the client TAO does not support polling model. No return values sent to the clients

16 Distributed Components Nanbor Wang and Roopa Pundaleeka16 Mapping Babel Non-blocking (Polling) to TAO AMI (Callback) TaoIIOP extends TAO’s Asynch Invocation class to create a default Asynch_Reply_Dispatcher, which will be used for every AMI call The TaoIIOP::rmi::Asynch_Invocation_Adapter stores the dispatcher in the client ORB to receive callback When the reply arrives, the callback is invoked on the default reply dispatcher –The callback method stores the CDR object in the Response object to be used by the clients Polling is not supported

17 Distributed Components Nanbor Wang and Roopa Pundaleeka17 Summary of CORBA protocol for Babel RMI Tasks implemented: –Both client and server side interfaces –Interoperability with regular CORBA server –All basic types, complex numbers, strings, and arrays –Exception support –One-way and Non-blocking calls Tasks to do: –Opaque and serializable support –Benchmark performance for comparing multiple protocols –Regression tests: some tests are in place, but need some work to be able to use them with both TaoIIOP and Simple protocols –Will package TaoIIOP and make it available on the web soon. Please email nanbor@txcorp.com or roopa@txcorp.com for more information

18 Distributed Components Nanbor Wang and Roopa Pundaleeka18 References https://collaborate.txcorp.com/collaborate/distr ibuted-technologies/distributed- components/distributed-components-home A. Arulanthu, C. O’Ryan, D. Schmidt, M. Kircher and J. Parsons, “The Design and Performance of a Scalable ORB Architecture for CORBA Asynchronous Messaging” A. Arulanthu, C. O’Ryan, D. Schmidt, M. Kircher and A. Gokhale, “Applying C++, Patterns and Components to Develop an IDL Compiler for CORBA AMI Callbacks”


Download ppt "Update on CORBA Support for Babel RMI Nanbor Wang and Roopa Pundaleeka Tech-X Corporation Boulder, CO Funded by DOE OASCR SBIR."

Similar presentations


Ads by Google