1. CEN6502, Spring 19981 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

2. CEN6502, Spring 19982 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)

3. CEN6502, Spring 19983 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

4. CEN6502, Spring 19984 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

5. CEN6502, Spring 19985 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.

6. CEN6502, Spring 19986 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 }

7. CEN6502, Spring 19987 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

8. CEN6502, Spring 19988 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

9. CEN6502, Spring 19989 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

10. CEN6502, Spring 199810 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

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

12. CEN6502, Spring 199812 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

13. CEN6502, Spring 199813 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

14. CEN6502, Spring 199814 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

15. CEN6502, Spring 199815 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

16. CEN6502, Spring 199816 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

17. CEN6502, Spring 199817 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