objektorienteret middleware (tioomi) dynamic requests

Objektorienteret Middleware (TIOOMI)

Dynamic Requests

Outline

1. Dynamic InvocationThe CORBA Dynamic Invocation Interface

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

DynamicInvocation

ClientStubs

ORBInterface

Implementation Skeletons

Client Object Implementation

ORB Core

ObjectAdapter

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 Requestsinterface 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 Requestsinterface 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 synchronouscall semantics

deferred withsend_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<Player> PlayerList;

ExceptionDef

InvalidNumber

exception InvalidNumber{};

AttributeDef

members

attribute PlayerList members;

OperationDefadd void add(in short number,

in Player p); raises(InvalidNumber)

Abstract Syntax Trees (ASTs)

ContainerContainer

AST Node Types

IRObjectIRObject

ContainedContained

OperationDefOperationDef

ExceptionDefExceptionDef

TypedefDefTypedefDef AttributeDefAttributeDef

ConstantDefConstantDef

ModuleDefModuleDefInterfaceDefInterfaceDef RepositoryRepository

Container (node with children)interface Container : 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

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 Definitioninterface InterfaceDef : 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;

...

};

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:Playeri:InterfaceDef

r1: Request

i=get_interface()

name()

r1=create_request(…,“Name”,…)

describe_interface()

invoke()

r2=create_request(…,“Number”,…)

r2: Requestinvoke()

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 deAndre frameworks typisk

Ikke de samme mulighederSom CORBA

CORBA DII og IR er væsentlige

Elementer i CORBA’s arkitektur,

Og udover DCOM, har deAndre frameworks typisk

Ikke de samme mulighederSom CORBA

MANGLER: hvordan I praktisk omsætter denne viden. Og får det heller ikke ;-)

DII og DSI er ikkespecielt access transperant,men øger heterogeniteten

DII og DSI er ikkespecielt access transperant,men øger heterogeniteten

Dynamic Invocation kanvæ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 kanvære en vigtig parameter for visse projekter, og kan

sikre højere effektivitet.I har fået teorien til at forholde jer til dette.