CS551 Object Oriented Middleware (IV) Dynamic Requests (Chap. 6 of EDO)

CS551 Object Oriented Middleware (IV)Dynamic Requests (Chap. 6 of EDO) Yugi Lee STB #555 (816) 235-5932 yugi@cstp.umkc.edu www.cstp.umkc.edu/~yugi CS551 - Lecture 15

Outline • Dynamic Invocation • The CORBA Dynamic Invocation Interface • COM IDispatch Interfaces • Reflection • The CORBA Interface Repository • The COM Type Library • Designing Generic Applications • Using CORBA • Using COM CS551 - Lecture 15

Why Dynamic Request? • Sometimes clients need to be built before their server interfaces are defined • They need to defer request definition until they are executed • Examples: • Object browser • Generic bridges • Scripting language interpreter CS551 - Lecture 15

Motivating Example: Object Browser • Use run-time type information to find out about • object types • attribute names • Use dynamic invocation interfaces to obtain attribute values CS551 - Lecture 15

Client Obj. Imp. DII DSI ORB Core ORB Core Motivating Example: Generic Bridge • Generic and request-level bridge CS551 - Lecture 15

Motivating Example: Scripting CS551 - Lecture 15

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 CS551 - Lecture 15

Dynamic Requests: Principles • Any object request has to identify • server object • operation name • actual parameters • data structure for operation result • 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 CS551 - Lecture 15

Object Implementation Client Implementation Skeletons Object Adapter Dynamic Invocation ORB Interface Client Stubs ORB Core Dynamic Requests in CORBA CS551 - Lecture 15

Dynamic Requests in CORBA • Dynamic invocation interface (DII) supports dynamic creation of requests (objects). • 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. CS551 - Lecture 15

:Client :Server r =create_request(…,”Op”,…) r:Request r add _arg() invoke() Op() delete() Dynamic Request in CORBA CS551 - Lecture 15

Dynamic Requests in COM • COM often used with interpreted scripting languages (e.g. VBScript) • Interpreters of these languages need to make dynamic requests. • Dynamic Requests in COM are defined in the IDispatch interface • Any COM server that implements IDispatch can be requested dynamically CS551 - Lecture 15

:Client :Server :ITypeInfo QueryInterface(IID_IDispatch) GetIDsOfNames(“Op”) GetIDsOfNames(“Op”) Invoke() Invoke() Op() Dynamic Request in COM CS551 - Lecture 15

Dual Interfaces • Are accessible both via stubs and via dynamic invocation • Example: Interface Player: [object,dual,uuid(75DA6450-DD0E-00d1-8B59-0089C73915CB] interface DIPlayer: IDispatch { [id(1),propget] HRESULT Name([out] BSTR val); [id(2),propget] HRESULT Number([out] short val); [id(3)] HRESULT book([in] Date val) }; • Interfaces have to be defined as dual! CS551 - Lecture 15

Transparency of Dynamic Invocation • In both COM and CORBA: • Client programs have to be written differently Þ Use of dynamic invocation interfaces is not transparent to client programmers • In COM: • Interfaces of server objects have to be designed as dual Þ Use of dynamic invocation not transparent in server design • In CORBA: • Server objects are unaware of dynamic invocation Þ Use of DII is transparent CS551 - Lecture 15

Reflection Principles • How do clients discover attributes & operations that servers have? • capture type information during interface compilation • store type information persistently • provide an interface for clients to obtain type information during run-time • Reflection interfaces provided by • CORBA Interface Repository • COM Type Library CS551 - Lecture 15

CORBA Interface Repository • Makes type information of interfaces available at run-time. • Achieves type-safe dynamic invocations. • Supports construction of interface browser • Used by CORBA implementations themselves • Persistent storage of IDL interfaces in abstract syntax trees (ASTs) CS551 - Lecture 15

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

IRObject Contained Container ModuleDef InterfaceDef OperationDef ExceptionDef ConstantDef TypedefDef AttributeDef AST Node Types Repository CS551 - Lecture 15

COM Type Library • COM’s provision of run-time type information • Raw information generated by MIDL compiler • Stored in tokenized form (.TLB files) • Main interfaces: 1 0 ..* ITypeLib ITypeInfo CS551 - Lecture 15

ITypeLib • Provides operations to browse through all interfaces contained in the type library • GetTypeInfoCount (returns number of TypeInfo objects in the library) • GetTypeInfo (can be used to obtain type info at a particular index number) • Locate ITypeInfo objects using the GUIDs CS551 - Lecture 15

ITypeInfo interface ITypeInfo : IUnknown { HRESULT GetFuncDesc( UINT index, FUNCDESC **ppFuncDesc); HRESULT GetIDsOfNames( OLECHAR **rgszNames, UINT cNames, DISPID *pMemId); HRESULT GetNames(DISPID memid, BSTR *rgBstrNames, UINT cMaxNames, UINT *pcNames); HRESULT GetTypeAttr(TYPEATTR **ppTypeAttr); HRESULT GetVarDesc(UINT index, VARDESC **ppVarDesc); HRESULT Invoke(VOID *pvInstance, DISPID memid, USHORT wFlags, DISPPARAMS *pDispParams, VARIANT *pVarResult, EXCEPINFO *pExcepInfo, UINT *puArgErr); ... }; CS551 - Lecture 15

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. CS551 - Lecture 15

Dynamic Invocation • Advantages: • Components can be built without having the interfaces they use, • Higher degree of concurrency through deferred synchronous execution. • Components can react to changes of interfaces. • Disadvantages: • Less efficient, • More complicated to use and • Not type safe! CS551 - Lecture 15

Key Points • Dynamic requests are used when static requests are not viable • Dynamic requests supported by both CORBA and COM • Dynamic requests are unsafe • Reflection mechanisms provided by COM and CORBA make dynamic requests safe • IDL compilers store type information persistently so that reflection implementations can provide them CS551 - Lecture 15

CS551 Object Oriented Middleware (IV) Dynamic Requests (Chap. 6 of EDO)