Objektorienteret Middleware (TIOOMI) Dynamic Requests

Outline 1. Dynamic Invocation The CORBA Dynamic Invocation Interface 2. Reflection The CORBA Interface Repository This is a huge topic – but not necessarily very relevant for most CORBA developers. The Pure CORBA book has the following relevant chapters discussing Dynamic Invocation: Chapter 8 (in part – the Any type), 17 (DynAny),18 (primarely DII), 19 (DSI),20 (IR), but reading chapter 18 and skimming the others will be sufficient for this curriculum

What is a Dynamic Request? Sometimes clients need to be built before their server interfaces are defined They need to defer request definition until they are executed These are dynamic requests Examples: Object browsers Automatic test programs Bridges to other middleware technologies or legacy technology

Commonalities Discovery of type information at run-time Use of type information to build client objects that can cope with any type of server objects Definition of object requests at run-time Requires two primitives from middleware: Dynamic invocation interfaces Reflection mechanisms

1. Dynamic Requests: Principles Any object request has to identify server object operation name actual parameters data structure for operation result exceptions In Dynamic Requests: server object identified by object reference operation name identified by string actual parameters as list of name/value pairs operation result determined by an address exceptions

Dynamic Invocation Client Stubs ORB Interface Implementation Skeletons Client Object Implementation ORB Core Object Adapter Dynamic Requests in CORBA In CORBA: Server objects are unaware of dynamic invocation - Use of DII is transparent

Dynamic Requests in CORBA Dynamic invocation interface (DII) supports dynamic creation of requests Requests are objects themselves Request objects have attributes for operation name, parameters and results Request objects have operations to change operation parameters issue the request and obtain the request results

Dynamic Request in CORBA :Client rr:Request :Server Op() r=create_request(…,”Op”,…) add_arg()invoke() delete() Requst object is usually NOT remote – it is local to client

Using DII with Java … //obtain the obj stub – e.g. from IOR org.omg.CORBA.Object obj = orb.string_to_object(ref) ; // Create a DII request and set the arguments and result org.omg.CORBA.Request r = obj._request("sayHello"); r.set_return_type(orb.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); // call the Hello server object and print results r.invoke(); java.lang.Exception ex = r.env().exception(); //handling of exception … (removed) // extract the result String result; result = r.return_value().extract_string(); System.out.println("Result from DII: " + result + "Now without stubs!"); Create dynamic request call invoke (synchronous) on request – and call the object Cheating a bit – how do we know it’s a string?

Creating Dynamic CORBA Requests interface Object { ORBstatus create_request( in Context ctx, // operation context in Identifier operation,// operation to exec in NVList arg_list, // args of operation inout NamedValue result,// operation result out Request request // new request object in Flags req_flags // request flags );... };

Manipulating Dynamic CORBA Requests interface Request { Status add_arg ( in Identifier name, // argument name in TypeCode arg_type,// argument datatype in void* value, // argument to be added in long length, // length of argument value in Flags arg_flags // argument flags ); Status invoke( in Flags invoke_flags // invocation flags ); Status send( in Flags invoke_flags // invocation flags ); Status get_response( in Flags response_flags // response flags ) raises (WrongTransaction); Status delete(); }; oneway semantics blocking synchronous call semantics deferred with send_deferred

2. Reflection Principles In order to achieve true Dynamic Invocation How do clients discover attributes & operations that servers have? May be achieved by capturing type information during interface compilation storing type information persistently provide an interface for clients to obtain type information during run-time Reflection interfaces provided by CORBA Interface Repository

Introduction to the CORBA Interface Repository Service Makes type information of interfaces available at runtime Achieves type-safe dynamic invocations Used by CORBA implementations themselves (need a IR server process running) Persistent storage of IDL interfaces in abstract syntax trees (ASTs) – parse trees Very vendor specific implementations Not supported by Orbacus Java & SUNs ORB it is there – but no interface is available

Interface repository persistently stores ASTs of IDL modules, interfaces, types, operations etc. module SoccerMgmt { }; ModuleDef SoccerMgmt InterfaceDef Player interface Player; InterfaceDef Team interface Team { }; TypedefDef PlayerList typedef sequence PlayerList; ExceptionDef InvalidNumber exception InvalidNumber{} ; AttributeDef members attribute PlayerList members; OperationDef add void add(in short number, in Player p); raises(InvalidNumber) Abstract Syntax Trees (ASTs)

Container AST Node Types IRObject Contained OperationDef ExceptionDef TypedefDef AttributeDef ConstantDef ModuleDef InterfaceDef Repository

Container (node with children) interface Container : IRObject { Contained lookup(in ScopedName search_name); sequence contents( in DefinitionKind limit_type, in boolean exclude_inherited); sequence lookup_name( in Identifier search_name, in long levels_to_search, in DefinitionKind limit_type, in boolean exclude_inherited);... }; search_name: scoped name of node we are searching for (e.g. an interface or operation) levels_to_search: how many levels will be searched, only this object or all

Contained (child) interface Contained : IRObject { attribute Identifier name; attribute RepositoryId id; attribute VersionSpec version; readonly attribute Container defined_in ; struct Description { DefinitionKind kind; any value; }; Description describe ();... };

Interface Definition interface InterfaceDef : Container,Contained { attribute sequence base_interfaces; boolean is_a (in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; RepositoryIdSequence base_interfaces; sequence operations; sequence attributes;... }; FullInterfaceDescription describe_interface (); }; Interface Definitions ARE CORBA Objects defined.

Locating CORBA Interface Definitions Alternatives: Any interface inherits the operation InterfaceDef get_interface() from Object Associative search using lookup_name () Navigation through the interface repository using contents and defined_in attributes

Example: Object Browser Use run-time type information to find out about object types and attribute names Use dynamic invocation interfaces to obtain attribute values

:Browser p:Player i:InterfaceDefr1: Request i=get_interface() name() r1=create_request(…,“Name”,…) describe_interface() invoke() r2=create_request(…,“Number”,…) r2: Request invoke() Name() delete()Number() delete() Object Browser in CORBA Reflection part Invocation part

CORBA Java Reflection I // Java import org.omg.CORBA.*;... org.omg.CORBA.ORB =... // initialize the ORB org.omg.CORBA.Object obj =... // get object reference somehow org.omg.CORBA.Object defObj = obj._get_interface_def(); if(defObj == null) { System.err.println("No Interface Repository available"); System.exit(1); } InterfaceDef def = InterfaceDefHelper.narrow(defObj); org.omg.CORBA.InterfaceDefPackage.FullInterfaceDescription desc = def.describe_interface(); Get the interface description of the Interface Definition of the CORBA object Get the interface def

CORBA Java Reflection II int i; System.out.println("name = " + desc.name); System.out.println("id = " + desc.id); System.out.println("defined_in = " + desc.defined_in); System.out.println("version = " + desc.version); System.out.println("operations:"); for (i = 0 ; i < desc.operations.length ; i++) { System.out.println(i + ": " + desc.operations[i].name); } System.out.println("attributes:"); for(i = 0 ; i < desc.attributes.length ; i++) { System.out.println(i + ": " + desc.attributes[i].name); } System.out.println("base_interfaces:"); for(i = 0 ; i < desc.base_interfaces.length ; i++) { System.out.println(i + ": " + desc.base_interfaces[i]); } Extract data from the interface description Iterate through the operations Iterate through the attributes Iterate through the base interfaces

Static Invocation Advantages: Requests are simple to define Availability of operations checked by programming language compiler Requests can be implemented fairly efficiently Disadvantages: Generic applications cannot be build Recompilation required after operation interface modification

Dynamic Invocation Advantages: Components can be built without having access to the interfaces they must use at runtime Higher degree of concurrency through deferred synchronous and asynchronous execution Components can react to changes of interfaces Disadvantages: Less efficient More complicated to use and Not type safe! And not supported by all

Group Work Discuss (5 minutes): Could we use the DII in our project? And for what? Plenum (5 minutes): Discussion of group results

Note on DSI Server Side Dynamics: Dynamic Skeleton Interface Let the server be unware of objects types Usage: Adpaters (dynamic protocol environment) Bridges (DCOM, RPC, RMI) Legacy Application (COBOL, Fortran) Use the Servant Manager POA pattern Use Interface Repository for type info See chapter 19 for details

Læringsmål Alignment Når kurset er færdigt forventes den studerende at kunne: Definere, beskrive og sammenligne forskellige typer af objektorienterede middleware frameworks til apparater og computere, med primær fokus på CORBA og sekundært.NET Remoting teknologierne, herunder fordele og ulemper forbundet med de forskellige teknologier Definere og beskrive principper omkring transparens og heterogenitet i relation til middlewareteknologier Definere og beskrive gængse teorier, metoder og retningslinier indenfor det objektorienterede middleware paradigme og anvende disse til at designe effektive distribuerede systemer Designe og konstruere et distribueret system der gør brug af CORBA og.NET Remoting teknologierne med tilhørende værktøjssupport CORBA DII og IR er væsentlige Elementer i CORBA’s arkitektur, Og udover DCOM, har de Andre frameworks typisk Ikke de samme muligheder Som CORBA CORBA DII og IR er væsentlige Elementer i CORBA’s arkitektur, Og udover DCOM, har de Andre frameworks typisk Ikke de samme muligheder Som CORBA MANGLER: hvordan I praktisk omsætter denne viden. Og får det heller ikke ;-) DII og DSI er ikke specielt access transperant, men øger heterogeniteten DII og DSI er ikke specielt access transperant, men øger heterogeniteten Dynamic Invocation kan være en vigtig parameter for visse projekter, og kan sikre højere effektivitet. I har fået teorien til at forholde jer til dette. Dynamic Invocation kan være en vigtig parameter for visse projekter, og kan sikre højere effektivitet. I har fået teorien til at forholde jer til dette.