New features for CORBA 3.0 by Steve Vinoski Presented by Ajay Tandon

CORBA 3.0 This paper presents three new features for CORBA3.0 Asynchronous Method Invocation (AMI) Objects By Value (OBV) Portable Object Adapter (POA) Why they were required ? How they helped ?

What is CORBA ?? CORBA keywords:- Object – Oriented. Distributed. Platform/language independent. Allows heterogeneous systems to do distributed computing over a network.

What is CORBA ?? Five components of CORBA :- Object Request Broker (ORB). Interface Definition Language (IDL). Dynamic Invocation Interface (DII). Interface Repository (IR). Object Adapters (OA).

What is CORBA ?? How CORBA works A client with an object reference may invoke an operation on it. The IDL tells the client what operations/data are defined. The request is carried over the network to the object. The response is carried back to the client. CORBA is different from RPC.

Asynchronous Messaging All systems that need to communicate are not connected all the time. Eg : Laptops, palmtops, handhelds. Original CORBA was heavily dependent on synchronous invocation techniques.

Asynchronous Messaging The first versions of CORBA provided three different models for process invocation :- Synchronous: The client invokes an operation, then blocks waiting for the response. Deferred Synchronous: The client invokes an operation, then continues processing. Later goes back and either polls or blocks waiting for the response. Oneway: The client invokes an operation, and the ORB provides only a best-effort guarantee that the request will actually be delivered. There is no response.

Asynchronous Messaging The new specification adds two more methods:- Callback: The client supplies an additional object reference parameter with each request invocation, and when the response arrives the ORB uses that object reference to deliver the response back to the application. Polling: The client invokes an operation, which immediately returns a valuetype (explained in OBV) that can be used to separately poll or wait for the response.

Objects By Value An Analogy In normal programming instead of small functions it is suggested that MACROS be used. In OO computing, sending the object over the network might sometimes be wiser than sending many messages over the network. This is called sending objects by value and original specification did not support it. New specification supports it by a new IDL specification called “valuetype”.

Objects By Value State is manageable. How do you pass behaviour over the network. Eg:client in Java, server in C++. Solution For Java applications send over enough information so receiving application can download ‘bytecode’. For C++ applications either it must have compile time knowledge of valuetype or it must acquire it probably in the form of a dynamically – loadable library.

Objects By Value Objects By Value is not complete. Cannot pass true CORBA objects. OBV is just a new IDL type. Passing true CORBA objects is a difficult problem. OBV is best used to define lightweight encapsulated datatypes such as linked lists, graphs and dates. CORBA still lacks a real Objects By Value solution.

Portable Object Adapter (POA) Original CORBA had a Basic Object adapter (BOA) which had many missing features and was ambiguous. The new object adapter is called the Portable Object adapter (POA).

Portable Object Adapter (POA) Persistent and transient objects One application might send a reference to another with the intention of having the second eventually call it back. What if the first application exits?? It may no longer want the object broker to reactivate it or the callback object. Solution POA supports persistent objects originally defined. It defines a new transient object type that dies with the POA that created it.

Portable Object Adapter (POA) Explicit Activation An application with just a few objects may want to create servants for those objects and register them with POA. On-demand Activation At the other end, applications with many CORBA objects may only want to activate those objects that actually receive requests. This would cause a huge savings in resources.

Portable Object Adapter (POA) Separation of Servant and CORBA object lifecycles A single servant could incarnate one or more CORBA objects in its lifetime. This is necessary for scalability. Also, a single CORBA object could be incarnated by one or more servants during its lifetime. This is necessary to support persistent objects.

Portable Object Adapter (POA) Support for Multithreading Application can create a POA with one of two different threading models :- Single threaded model: All requests are sent to a single thread. ORB controlled model: ORB implementation chooses an appropriate multi - threading model.

Portable Object Adapter (POA) Multiple POAs per application All properties discussed so far are enabled by applying them to a POA when created. A single application may want to utilize different sets of POA policies. It can create multiple POAs and use them as required.

Portable Object Adapter (POA) No persistent state If a POA were required to keep track of its objects it would have to store state. Databases would be required to store state. Databases provided may not scale for all kinds of applications. Eg: embedded industrial control sensor. Ultimate responsibility for keeping track of object identity and existence lies with the client application.

Portable Object Adapter (POA) Static and Dynamic skeleton interface Usually knowledge about calling interface is known at compile time, stored in a skeleton and the information used by Object adapter in dispatching each request to the proper servant. Some applications must be able to determine object interfaces at runtime. The dynamic skeleton interface (DSI) allows servants to determine the details of interface and operation of target object at runtime. It often makes use of the interface repository (IR).

Questions QUESTIONS ??