View
218
Download
0
Category
Preview:
Citation preview
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.
Recommended