Dynamic Object Requests

Dynamic Object Requests 1

Dynamic Object Requests

Outline Motivating Examples Dynamic Invocation Reflection Designing Generic Applications


Outline Motivating Examples Dynamic Invocation

The CORBA Dynamic Invocation Interface

Reflection The CORBA Interface Repository

Designing Generic Applications Using CORBA


Motivation


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 browser Generic bridges Scripting language interpreter


Motivating Example: Object Browser


Motivating Example: Generic Bridge

Client

ORB CoreORB Core

Obj. Imp.

DSI DII

Generic and request-level bridge


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


Dynamic Invocation


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


DynamicInvocation

ClientStubs

ORBInterface

Implementation Skeletons

Client Object Implementation

ORB Core

ObjectAdapter

Dynamic Requests in CORBA


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()


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 len, // length of argument value in Flags arg_flags // argument flags ); Status invoke ( in Flags invoke_flags // invocation flags ); Status delete (); Status send ( in Flags invoke_flags // invocation flags ); Status get_response ( in Flags response_flags // response flags ) raises (WrongTransaction);};


Transparency of Dynamic Invocation Client programs have to be written differently Use of dynamic

invocation interfaces is not transparent to client programmers Server objects are unaware of dynamic invocation Use of DII

is transparent


Reflection


Reflection Principles How do clients discover attributes & operations that servers

have? Need to

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


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)


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 Invalid {};

AttributeDef

members

attribute ATMList ATMs;

OperationDef

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


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<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();

};


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.


Designing Generic Applications


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


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


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


II. Dynamic Object Requests

Review: static object request vs dynamic object request Static object request

Clients compile with stub generated by IDL compilation Clients depend on server interfaces Server interface changes cause client to be recompiled Type safe

Dynamic object request Client makes the request at run-time Clients do not assume the existence of stub Clients use dynamic invocation interfaces provided by middleware


IDL and Interface Repository

IDL FileIDL

CompilerInterface

Repository

Virtual Machine

ORB Class Lib

Skeletoncode

ObjectImplementation

Virtual Machine

ORB Class Lib

Server Client

Dll Request

populate

generate

query


II. Dynamic Object Requests

Elements in a request Server object Operation name Actual parameters Return values

Dynamic request interface Supported by middleware Type safety Object type repository

Client enquires at run-time for object type information


ObjectAdapter

ImplementationSkeletons

ORB Core

Client Object Implementation

ClientStubs

ORBInterface

DynamicInvocation

standard interface

One interface per object operation

One interface per object adaptor

Proprietary ORB interface

Normal call interfaceUp call interface

Dynamic Invocation in CORBA



Client first creates a Request object Request object export operations that enable the client object to

issue the request Result is determined from the request object Client decides invocation scheme (dynamic or static) Invocation scheme is transparent to server object



Every CORBA object can create request objects

interface Object {

InterfaceDef get_interface();

Status create_request (

in Context ctx, // context object for operation

in Indentifier operation, // intended operation

in NVList arg_list, // args to operation

inout NamedValue result, // operation result

out Request request, // newly created request

in Flags req_flags // request floags

);

…

};

interface Object {

InterfaceDef get_interface();

Status create_request (

in Context ctx, // context object for operation

in Indentifier operation, // intended operation

in NVList arg_list, // args to operation

inout NamedValue result, // operation result

out Request request, // newly created request

in Flags req_flags // request floags

);

…

};


InterfaceDef

interface InterfaceDef: Continer, Contained, IDLType {

attribute InterfaceDefSeq base_interfaces;



Identifier name;

RepositoryId id;


VersionSpec version;

opDescriptionSeq operations;

AttrDescriptionSeq attributes;

RepositoryIdSeq base_interfaces;

typeCode type;

};

FullInterface Description describe_interface();

…

};

interface InterfaceDef: Continer, Contained, IDLType {

attribute InterfaceDefSeq base_interfaces;



Identifier name;

RepositoryId id;


VersionSpec version;

opDescriptionSeq operations;

AttrDescriptionSeq attributes;

RepositoryIdSeq base_interfaces;

typeCode type;

};

FullInterface Description describe_interface();

…

};


Interface Request

Request objects provide add_arg, invoke/send operations

native OpaqueValue;

interface Request { // PIDL

void add_arg ( in Identifier name, // argument name

in TypeCode arg_type, // argument datatype

in OpaqueValue value, // argument value to be added

in long len, // length/count of argument value

in Flags arg_flags // argument flags );

void invoke ( in Flags invoke_flags // invocation flags ); // synchronous

void delete ();

void send ( in Flags invoke_flags // invocation flags ); // deferred syn.

void get_response( in Flags response_flags ) raises (WrongTransaction);

// blocking or non-blocking if the flat is set

boolean poll_response();

};

native OpaqueValue;

interface Request { // PIDL

void add_arg ( in Identifier name, // argument name

in TypeCode arg_type, // argument datatype

in OpaqueValue value, // argument value to be added

in long len, // length/count of argument value

in Flags arg_flags // argument flags );

void invoke ( in Flags invoke_flags // invocation flags ); // synchronous

void delete ();

void send ( in Flags invoke_flags // invocation flags ); // deferred syn.

void get_response( in Flags response_flags ) raises (WrongTransaction);

// blocking or non-blocking if the flat is set

boolean poll_response();

};


Request Object

org.omg.CORBA.Request

string operation

Operation name

Operation parameters

NVList

NamedValue Flag Name Value


…

Operation Result



TypeCode Interface

TypeCodes represent type information about any IDL type Nested TypeCodes CORBA module defines a pseudo-IDL definition of an element,

TCKind No holder and helper classes are defined as it will never be used in making

remote invocations

IDL type

enum TCKind{tk_null, tk_void, tk_short, tk_long, …}; // PIDL

Java class

public final class TCKind {

public static final int _tk_null = 0;

public static final TCKind tk_null =

new TCKind(_tk_null);

…

public static TCKind from_int(int value);

…

}

IDL type

enum TCKind{tk_null, tk_void, tk_short, tk_long, …}; // PIDL

Java class

public final class TCKind {

public static final int _tk_null = 0;

public static final TCKind tk_null =

new TCKind(_tk_null);

…

public static TCKind from_int(int value);

…

}


TypeCode Interface

Two equality operators with different semantics

interface TypeCode { // PIDL

boolean equal (in TypeCode tc); // stronger semantics

boolean equivalent (in TypeCode tc);

TypeCode get_compact_typecode(); // optional names, member names are stripped off

TCKind kind();

RepositoryId id() raise (BadKind);

};

interface TypeCode { // PIDL

boolean equal (in TypeCode tc); // stronger semantics

boolean equivalent (in TypeCode tc);

TypeCode get_compact_typecode(); // optional names, member names are stripped off

TCKind kind();

RepositoryId id() raise (BadKind);

};


Named Value Lists NamedValue is type

struct NamedValue{

Identifier name;

any argument;

long len; // length/count of argument value

Flags arg_modes; // in, out, or inout

};

Typedef sequence<NamedValue>NVList;

struct NamedValue{

Identifier name;

any argument;

long len; // length/count of argument value

Flags arg_modes; // in, out, or inout

};

Typedef sequence<NamedValue>NVList;


Contexts Context contains a list of properties, which are pairs of names

and values. Intend role of context objects is similar to that of environment

variables in various OS. Rarely used

interface Context {

void set_one_value (in Identifier propname, in any propvalue);

void set_values (in NVList values);

…

};

interface Context {

void set_one_value (in Identifier propname, in any propvalue);

void set_values (in NVList values);

…

};


Interface Repository Fundamental service to provide run-time type information

about the interface types of objects supported in a particular ORB installation

A set of objects that encapsulate the IDL definitions of all CORBA types available in a particular domain

interface {

…

};

interface {

…

};


Reflection

Reflection provide details about the type of an object Identify the type of an object Provide the attribute info of the object Provide the operation info of the object Provide type info about the parameters, return results and exceptions of an

operation

Reflection information cannot provided by a specific programming language, such as C++, Java

IDL compiler gathers reflection information and stores it persistently for run-time use.


CORBA Interface Repository

CORBA provides reflection through its Interface Repository (IR) Types defined for the interface repository

IRObject

InterfaceDef

ContainerContained

OperationDef

ConstantDefExceptionDef

AttributeDefTypedefDef

ModuleDef Repository


Locate Type Information

Three ways to locate an interface definition Object reference Query repository by name Navigate and discover all types registered in the repository


Dynamic Skeleton Interface

DSI allows the ORB to invoke an object implementation without compile-time knowledge about the interface, i.e., without a skeleton class.

For an object implementation, calls via skeleton or DSI are not distinguishable.

DynamicImplementation contains a general operation, called by the ORB, to convey the original request to the server.

Interface repository identifier: “IDL:”{module_name”/”}*interface_name”:”major”.”minor

The major/minor pair are currently always 1 and 0.

Date post:	13-Jan-2016
Category:	Documents
Upload:	maitland
View:	31 times
Download:	0 times

Dynamic Object Requests

Documents