Understanding the ORB: Client Side

1. Understanding the ORB: Client Side • Structure of ORB (fig 4.1) • Client requests may be passed to ORB via either SII or DII • SII decide object type and operation at compile time (static typing), DII at runtime (dynamic typing) • Both allow dynamic binding -- can select target object instance at runtime • DII cannot check argument type correctness at compile time • One IDL stub for each SI, while one DII shared by all dynamic invocations • SII invocations generally synchronous (blocking), DII may be invoked synchronous, asynchronous or deferred synchronous CEN6502, Spring 1998

2. Building CORBA Object • Define object interface using OMG IDL (fig 2.2, 2.3) • Making choices of • Implementation language • runtime platform and OS • the ORB it will connect to • whether it will run local to its client or remotely • the network hardware or protocol it will use, etc • Write code for the object • Compile IDL interface, which generates Stub and Skeleton code • Linking implementation code with Skeleton code connects the object to the ORB • Integrating purchased object/component (fig. 2.5) CEN6502, Spring 1998

3. IDL Stubs • The role of client is simply to request services. Object activation, deactivation, suspension, etc. are either performed automatically by the ORB or by customized services located outside the client • Client specifies target object instance via its object reference and through object IDL interfaces • Standardized object reference specification, but not implementation • Client-to-stub interface is defined by standard OMG language mapping, stub-to-ORB interface proprietary CEN6502, Spring 1998

4. DII • Trade off compile time type checking for runtime flexibility • Gives a client the capability, at any time, of invoking any operation on any object it may access over the network • Useful for accessing objects for which the client has no stub or discovered via naming or trading services. • Server cannot distinguish between SI an d DI • 4 steps to a DI • Identify the object to be invoked (e.g. via Trader Service) • Retrieve its interface • Construct the invocation • Invoke the request and receive the request CEN6502, Spring 1998

5. DII • Retrieving the target interface • Using the object reference, the client invokes the ORB operation get_interface, which returns an object reference to the interface • Additional calls return the interface’s operations: name, parameters and their type • Need additional info: what does each operation do, the function of each parameter, allowed parameter ranges, allowable operation sequences, etc. must come from else where. Not standardized. CEN6502, Spring 1998

6. DII • Constructing the Invocation • DII provides standard interfaces for constructing a request, referred to as pseudo-object, and its interface is described in pseudo-IDL • Operation create_request Typedef unsigned long ORBStatus ORBStatus create_request ( // PIDL in Context ctx, in Identifier operation, in NVList arg_list, inout NamedValue result, out Request request in Flags req_flags } CEN6502, Spring 1998

7. DII • Invoke DII via pseudo-object request, I.e. Specifying request as target • Synchronous DII invocation • Use operations invoke, send and get_response (defined in the request interface) • ORBStatus invoke ( in Flags invoke_flags // invocation flags ); //specified with the request as the target CEN6502, Spring 1998

8. DII • Asynchronous DII invocation • Has two forms • Individual request form, send and get_response, are part of the request interface • Multiple request form issues multiple request in parallel, does not have an object as target and is implemented as ORB calls defined only by a language mappings • Control returns to client immediately after send CEN6502, Spring 1998

9. Interface Repository • Each ORB required to implement the IR interface • Allows IDL definitions for objects be stored, modified, and retrieved • Can be used by ORB to: • Provide interoperability between different ORB implementations • Provide type-checking of request signatures, whether a request was issued through the DII or a stub • To check the correctness of inheritance graphs CEN6502, Spring 1998

10. IR • For client objects and users • To manage installation and distribution of interface definitions around your network • To browse or modify interface definitions or other info stored in IDL • Compilers could compile stubs and skeletons directly from IR instead of from the IDL files • Access IR • Use utilities provided by ORB vendor • Write code that invokes the standard IR IDL interface mandated by OMG CEN6502, Spring 1998

11. IR Implementation • A large component of ORB, implementation proprietary • Options: built on top of DB, distributed, replicated, cached • Performance and scalability are important concerns CEN6502, Spring 1998

12. Structure of IR • IR components - modules, interfaces, operations, attributes, parameters, constants, typedefs, exceptions, and contexts - as objects that may contain other objects • Does not have to store IDL, although many do CEN6502, Spring 1998

13. Understanding the ORB: Implementation Side • Simple client, complex server • Object builders must write code to handshake with ORB • A scenario of object invocation on server side (fig. 5.1) • A server process runs distinct from the ORB • ORB receives a request targeting an object in the server. ORB checks its repository and determines that neither the server nor the object is currently active • ORB activates server, and server is passed the info it needs to communicate with the BOA • Server calls impl_is_ready on the BOA, indicating that the server is ready to activate objects CEN6502, Spring 1998

14. Scenario • BOA calls the server’s object activation routine for the target object, passing it the object reference. Server activates the object • BOA passes the invocation to the object through the skeleton and receives the response, which it routes back to the client • BOA may receive and pass additional request to the object • Server may shut down an object using deactivate_obj • Server may shut down entirely CEN6502, Spring 1998

15. Server-Side Components • Server-side ORB structure (fig. 5.2) • Object adapter provides interfaces between ORB and object, implementation depends on specific object implementation model • ORB uses DSI to create a proxy skeleton for objects, typically remote, whose static skeletons are not bound to it • ORB interfaces provides operations on object references, access to interface and implementation repository CEN6502, Spring 1998

16. Object Implementation Structure • Most objects are not running and active all the time • ORB, CORBAServices work together to activate the objects when necessary • Context switch hidden from user • Responsibility of handling object state changes shifted to object implementor • When writing an OMA-compliant object, you have to provide a way to save the object state at shut down and to checkpoint the object state • No standard enforcement on this implementor responsibility CEN6502, Spring 1998

17. Object Adaptors • Responsible for • registering implementations • generating and interpreting object references • mapping object references to their corresponding implementations • activating and deactivating object implementations • invoking methods, via skeleton or DSI • coordinating interaction security, in cooperation with the Security Object service CEN6502, Spring 1998