Objektorienteret Middleware (TIOOMI)

1. Objektorienteret Middleware (TIOOMI) Dynamic Requests

2. 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

3. 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

4. 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

5. 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

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

7. 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

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

9. Using DII with Java Create dynamic request call invoke (synchronous) on request – and call the object Cheating a bit – how do we know it’s a string?

10. 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 ); ... };

11. 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();}; blocking synchronous call semantics oneway semantics deferred with send_deferred

12. 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

13. 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

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

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

16. Container (node with children) interfaceContainer : IRObject { Contained lookup(in ScopedName search_name); sequence<Contained> contents( in DefinitionKind limit_type, in boolean exclude_inherited); sequence<Contained> 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

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

18. Interface Definition interfaceInterfaceDef : Container,Contained { attribute sequence<InterfaceDef> base_interfaces; boolean is_a(in RepositoryId interface_id); struct FullInterfaceDescription { Identifier name; RepositoryId id; RepositoryId defined_in; RepositoryIdSequence base_interfaces; sequence<OperationDescription> operations; sequence<AttributeDescription> attributes; ... }; FullInterfaceDescriptiondescribe_interface(); }; Interface Definitions ARE CORBA Objects defined.

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

20. 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

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

22. CORBA Java Reflection I Get the interface def Get the interface description of the Interface Definition of the CORBA object

23. CORBA Java Reflection II Extract data from the interface description Iterate through the operations Iterate through the attributes Iterate through the base interfaces

24. 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

25. 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

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

27. 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

28. 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 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 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. MANGLER: hvordan I praktisk omsætter denne viden. Og får det heller ikke ;-)