Problems with the specification lead to new specifications, forcing vendors to

Transcription

1 CORBA Distributed object-based system Common Object Request Broker Architecture (CORBA) CORBA is a specification of a distributed system. There are no suggestions made about the implementation of the middleware itself These specifications have been drawn up by the Object Management Group (OMG), a non-profit organisation with more than 800 members Goals: make better use of distributed systems use object-oriented programming define a distributed system that could overcome many of the interoperability problems with integrating networked applications Core component: the object request broker (ORB), a 'software bus' for enabling and managing communication Components of the CORBA Framework CORBA specifies... A (raw) abstract object model An interface definition language (IDL) Mapping from IDL to different programming languages: Ada, C, C++, COBOL, Java, Lisp, Python, SmallTalk, A repository for managing IDL specifications The ORB as communication infrastructure A communication protocol (GIOP/IIOP), together with a transfer syntax and message formats A client interface to the ORB (proxy) A server interface to the ORB (skeleton) Interoperability with other standards, e.g. DCOM Services supporting management and use of distributed applications: Naming, Transactions, CORBA implementation guidelines were made, but many organisations thought that CORBA would be a good product: Large set of options to define every aspect of a distributed system Competition: fast implementations to be first-on-the-market Poor performance due to fast implementation and large set of specified options In the first versions: incompatibilities between implementations of different vendors Problems with the specification lead to new specifications, forcing vendors to re-build their implementations Re-building implementations lead to re-design of the developers software Today, lot of different implementations exist, e.g. Commercial: Orbix, VisiBroker, Freeware: MICO, OmniORB,... Integrated: e.g. Java-ORB 27 CORBA Architecture Application Objects Horizontal CORBAfacilities Vertical Object Request Broker Naming Trading Event Security tification... LifeCycle CORBAservices Reference model consists of four components The Object Request Broker (ORB) as communication infrastructure CORBAservices as useful services for all distributed applications CORBAfacilities as additional services used by some applications Application Objects as the distributed applications implemented by a programmer for its special purposes 29

2 CORBA Components Object Request Broker Core of any CORBA system Responsible for enabling basic (synchronous!) communication between objects and their clients while hiding issues related to distribution and heterogeneity CORBAservices Set of basic services (used by many applications) supporting a programmer in constructing a distributed application and supporting the application at runtime Examples: Naming, LifeCycle, Event, Security CORBAfacilities General purpose high level services with useful functions needed by several applications, but which are not necessary for basic functioning Horizontal facilities (CORBAfacilities): services that are independent of an application domain such as user interfaces or system management Vertical facilities (CORBAdomains): services that are targeted to a specific application domain such as electronic commerce, banking, medicine, telecommunications,... Application Objects t standardised, these are all objects programmed by a user for a special purpose 30 Comparison to DCOM DCOM generates binary interfaces CORBA generates language-dependent stubs One specification of an interface Re-use of the specification DCOM A new specification for each mapping to a programming language CORBA Separate translation of the interface for each language 32 Object Model CORBA uses the remote object model with RMI as communication principle: used is multi-language RMI Objects and services are specified in the CORBA Interface Definition Language (CORBA IDL) IDL provides precise syntax for expressing methods and their parameters, but not the semantics. By using IDL, the whole interface of an object is specified The CORBA implementation provides compilers to translate the IDL specification into an object with proxies resp. stubs (client) and skeletons (server) for handling the communication. The programmer only has to specify the application-specific code, not the communication mechanism It is necessary to provide exact rules concerning the mapping of IDL specifications to exisiting programming languages (C, C++, Java, Smalltalk, Ada and Cobol) Each object is 'named' by an unique object reference The term CORBA object is used to refer to remote objects. A CORBA object implements an IDL interface, has a remote object reference and its methods can be invoked remotely 31 CORBA IDL Abstract interface definition IDL has the same lexical rules as C++ but has additional keywords to support distribution The grammar of IDL is a subset of ANSI C++ with additional constructs to support method signatures IDL provides facilities for defining modules, interfaces, types, attributes and method signatures It allows standard C++ pre-processing facilities, e.g. #include for including other interface definition files in the new file (inheritance) Through an interface, only CORBA data types can be passed for an invocation. CORBA provides a lot of data types, but own data types which have to be passed are to be defined together with the interface specification tice: pointers are not supported! 33

3 IDL Basic Types Support of basic keywords and data types: any default inout out switch attribute double interface raises TRUE boolean enum long readonly typedef case exception module sequence unsigned char FALSE Object short union const float octet string void context in oneway struct IDL Attributes Components of interfaces Equivalent to two operations: read and write an attribute value Definition: attribute <TypeIdentifier> <AttributeName>; Example: attribute short x; Special attributes for read-only: readonly attribute short x; Meaning: a client can't modify the attribute value, but the object itself possibly can The IDL compiler generates a write operation and a read operation for such a definition IDL Definitions IDL definition: definition of Modules to group interface definitions into name spaces module <ModulName> {... Interfaces as access points to objects. Interfaces can inherit from several other interfaces interface <InterfaceName> {... Constants const <Typ> <ConstantName> = <Wert> Types to group basic data types typedef <TypeName>... enum <EnumName> {... struct <StructName> {... Exceptions for receiving ORB-specific or other (self-defined) distribution-specific error messages exception <ExceptionName> IDL Methods Similar to function declarations in C++ Consist of an identifier for the resulting type, one for the function name, and a list of identifiers for arguments short operation(in short arg1, in short arg2); Optional: oneway (the client gets no response) oneway void operation(in char arg); Optional: Exceptions (for catching error messsages) void operation(out short arg2) raises (Except); Arguments: differentiation between three types: in for parameters only used to pass information to the object out for parameters only used to give back a result to the client inout for parameters used in both directions General method signature: [oneway] <return_type> <method_name> (parameter1,...,parameterl) [raises (except1,..., exceptn)] [context (name1,..., namem)] 37

4 Data Types Basic types Any char float Object short void unsigned short boolean double long octet string unsigned long - boolean: defined values TRUE, FALSE - char: 1 Byte. - octet: similar to char, but with a constant value - any: can contain each combination of other IDL data types - Object: Interface type; all interfaces inherit from this type to offer special functions for binding or name resolving Structs - Combines several data type to a new one -Example: struct structure { char element1; short element2; 38 Data Types Type Examples Use record struct GraphicalObject { string type; Rectangle enclosing; boolean isfilled; Defines a type for a record containing a group of related entities. Structs are passed by value in arguments and results. enumerated enum Rand (Exp, Number, Name); The enumerated type in IDL maps a type name onto a small set of integer values. union union Exp switch (Rand) { case Exp: string vote; case Number: long n; case Name: string s; The IDL discriminated union allows one of a given set of types to be passed as an argument. The header is parameterised by an enum which specifies which member is in use. 40 Data Types Type Examples Use sequence typedef sequence <Shape, 100> All; typedef sequence <Shape> All bounded and unbounded sequences of Shapes string String name; typedef string<8> SmallString; unbounded and bounded sequences of characters Defines a type for a variable-length sequence of elements of a specified IDL type. An upper bound on the length may be specified. Defines a sequences of characters, terminated by the null character. An upper bound on the length may be specified. array typedef octet uniqueid[12]; typedef GraphicalObject GO[10][8] Defines a type for a multi-dimensional fixed-length sequence of elements of a specified IDL type. 39 IDL Interfaces and Modules Interfaces group all methods and parameters: interface Grid { readonly attribute short height; readonly attribute short width; void set(in short n, in short m, in long value); long get(in short n, in short m); and modules form a name space: module Whiteboard { struct Rectangle{...} ; struct GraphicalObject {... interface Shape {... typedef sequence <Shape, 100> All; interface ShapeList {... 41

5 CORBA IDL Interfaces Shape and ShapeList struct Rectangle { } ; long width; long height; long x; long y; struct GraphicalObject { string type; Rectangle enclosing; boolean isfilled; interface Shape { long getversion() ; GraphicalObject getallstate() ; // returns state of the GraphicalObject typedef sequence <Shape, 100> All; interface ShapeList { exception FullException{ Shape newshape(in GraphicalObject g) raises (FullException); All allshapes(); // returns sequence of remote object references long getversion() ; 42 IDL Compiler The IDL compiler generates programming language constructs from the interface definitions: IDL Client- Code IDL-Compiler Server- Code Client Stub Header Server Stub Compiler & Linker Compiler & Linker Client Application (Object Code) Server Application (Object Code) Client Server 44 Parameters in CORBA IDL Passing CORBA objects: Any parameter or return value whose type is specified by the name of a IDL interface, e.g. Shape, is a reference to a CORBA object (see newshape) and the value of a remote object reference is passed Passing CORBA primitive and constructed types: Arguments of primitive and constructed types are copied and passed by value. On arrival, a new value is created in the recipient s process. E.g., the struct GraphicalObject (argument of newshape and result of getallstate) te: the method allshapes returns an array of remote object references as follows: typedef sequence <Shape, 100> All; All allshapes(); Type Object - is a supertype of all IDL interfaces (its values are object references) IDL Language Mapping Mapping of IDL definitions to data structures. Here: C++ (generated code depends on CORBA implementation here: only one example, Orbix) Generated: Stubs of client and server. Additionally: Management of dynamically allocated memory for IDL data types Determination of how to execute an operation call for an object reference Simple mapping rules: module M {... namespace M {... interface I {... class I {... struct S {... struct S {... Very simple: interfaces can be mapped to classes; by this, objects to an interface can be instantiated easily. Mapping of basic types: e.g. short CORBA::Short unsigned short CORBA::UShort 43 45

6 IDL Language Mapping Arguments The mapping of arguments depends on their usage: IDL: type0 op(in type1 arg1, inout type2 arg2, out type3 arg3); C++: type0 op(type1 arg1, type2& arg2, type3& arg3); interface example { readonly attribute long ro_value; attribute long value; void op(in long in_par, out long out_par); te: the virtual class is generated by the IDL compiler and has to be implemented as a class by the programmer class example : public virtual CORBA::Object { public: virtual CORBA::Long ro_value(); virtual CORBA::Long value(); virtual void value(corba::long val); virtual void op(corba::long in_par, CORBA::Long& out_par); 46 Writing Client and Sever using the IDL-generated Stubs (Orbix) Defining the interface Specify the IDL definition in file.idl Use IDL compiler to map it to C++. Generally, some stub files like files.cc for server stub and filec.cc for client stub are generated. Writing the object implementation Include files.cc (server stub) Implement the operations which were defined in IDL Register the server with the ORB Writing the client Include filec.cc (client stub) Implement client functionality, including operation requests Bind to the server 48 IDL Language Mapping Strings Are defined as char* ORB manages memory for character strings Two possible definitions of string variables: char* string1; CORBA::String_var string2; ORB offers some functions for working with strings (recommended to use them): char* CORBA::string_alloc(CORBA::Ulong len); char* CORBA::string_dup(const char*); char* CORBA::string_free(char*); Other types, e.g. sequence _var is defined as above (regarding memory management) Mapped to a list, accessible by giving the index: IDL: typedef sequence<content> Example C++: Example_var ex_variable; ex_variable[2] =... Simple Example grid / C++ Specifying the interface IDL // In file grid.idl interface Grid { readonly attribute short height; readonly attribute short width; void set(in short n, in short m, in long value); long get(in short n, in short m); Compiling the interface definition produces grid.hh (general type information for types defined in file.idl) gridc.cc (client stub) grids.cc (server stub) 47 49

7 Simple Example grid / C++ The grid.hh file produced by the IDL compiler contains the following: // Automatically produced (in grid.hh). class Grid : public virtual CORBA::Object { tice: each class inherits from the general CORBA object public: virtual CORBA::Short height(corba::environment& IT_env = CORBA::default_environment); virtual CORBA::Short width(corba::environment& IT_env = CORBA::default environment); virtual void set(corba::short n, CORBA::Short m, CORBA::Long value, CORBA::Environment& IT_env = CORBA::default_environment); virtual CORBA::Long get(corba::short n, CORBA::Short m, CORBA::Environment& IT_env = CORBA::default_environment); 50 Simple Example grid / C++ Your server implementation - grid_i.c #include "grid_i.h" Grid_i::Grid_i(CORBA::Short h, CORBA::Short w) : m_height(h), m_width(w) { m_a = new CORBA::Long*[h]; CORBA::Short i; for (i = 0; i < h; i++) m_a[i] = new CORBA::Long[w]; } Grid_i::~Grid_i() { CORBA::Short i; for (i = 0; i < m_height; i++) delete[] m_a[i]; delete[] m_a; } CORBA::Short Grid_i::height(CORBA::Environment&) { return m_height; }... // the same for Grid_i::weight void Grid_i::set(CORBA::Short n, CORBA::Short m, CORBA::Long value, CORBA::Environment&) { m_a[n][m] = value; } CORBA::Long Grid_i::get(CORBA::Short n, CORBA::Short m, CORBA::Environment&) { } return m_a[n][m]; 52 Simple Example grid / C++ (partly) generated header file for your implementation - grid_i.h #include "grid.hh" class Grid_i : public virtual GridBOAImpl { CORBA::Short m_height; CORBA::Short m_width; CORBA::Long** m_a; public: Grid_i(CORBA::Short h, CORBA::Short w); // Constructor virtual ~Grid_i(); // Destructor virtual CORBA::Short width(corba::environment&); virtual CORBA::Short height(corba::environment&); virtual void set(corba::short n, CORBA::Short m, CORBA::Long value, CORBA::Environment&); virtual CORBA::Long get(corba::short n, CORBA::Short m, CORBA::Environment&); 51 Simple Example grid / C++ Providing the server - Srv_Main.C #include "grid_i.h" #include <iostream.h> main() { // We could create any number of objects // here but we just create one. Grid_i mygrid(100,100); // Orbix objects can be explicitly named, // but this is not required in this simple // example. CORBA::Orbix.impl_is_ready("GridSrv"); cout << "Server terminating" << endl; } te: additionally it is necessary now to make an entry for GridSrv in the so-called Interface Repository which enables a mapping of the server name to an executable 53

8 Simple Example grid / C++ Writing a client - Client.C #include "grid.hh" #include <iostream.h> main() { Grid_var gvar; Simple example Orbix provides a comfortable bind function. In other implementations, you would have to work with object references try on your own in exercise 5. gvar = Grid::_bind(":GridSrv"); cout << "height is " << gvar->height() << endl; cout << "width is " << gvar->width() << endl; } gvar->set(2,4,123); cout << "Grid[2,4] is " << gvar->get(2,4) << endl; w: what makes all that work? CORBA Architecture ORB services (from the perspective of a process): The ORB is offering a few functions by itself: 1. Manipulating object references (marshal and unmarshal object references to exchange them between processes, comparing object references) 2. Finding the services that are available to a process (an initial reference to an object implementing a specific CORBA service, in general a naming service) Object Adapter Bridges the gap between CORBA objects with IDL interfaces and the programming language interfaces of the corresponding server Creates object references for CORBA objects Each active CORBA object is registered with its object adapter, which keeps a remote object table to map names of CORBA objects to servers Responsible for dispatching incoming requests via a skeleton to the addressed object Possibly has to activate an object when a request comes in CORBA Architecture Implementation Repository Interface Repository The ORB is not a single component, rather it is a service executed on each computer (maybe as a daemon) The skeleton is the generated stub for the server side, the generated proxy is the stub for the client side (implements the same interface as the object the client is using). Both stubs are specific for the current application and are the only parts the client resp. the server see; the ORB is invisible for them Portable Object Adapter Object adapter Implements an activation policy for a group of objects (single thread, multithreading,...) Responsible for providing a consistent image of what an object Adapts a program such that clients can see the program as an object Portable Object Adapter (POA) Server-side code can be written independently of specific ORB - it is portable in means of ORBs from different vendors Assumes: object implementations are partly provided by servants - the part of an object that implements the methods that clients can invoke. Servants are programming-language dependent Each POA offers the following operation: Objectld activate_object(in Servant p_servant); This operation takes a pointer to a servant as input parameter and returns a CORBA object identifier as a result universal definition of type servant; it is mapped to a language dependent data type The returned ObjectId is an index into the POA's Active Object Map 55 57

9 Dynamic Invocations Dynamic Invocation Interface (DII)/ Dynamic Skeleton Interface (DSI) There are occasions in which statically defined interfaces are simply not available to a client, instead it has to find out what it needs during runtime DSI and DII are providing generic interfaces for sending/receiving each request, independent of specific proxies and skeletons E.g. used for implementing gateways to achieve interoperarbility between different platforms, e.g. CORBA and DCOM Required knowledge: what does the interface to a specific object looks like? Subsequently compose an invocation request for that object 58 Interface Repository How to find information about interfaces to construct a dynamic request? For this, the Interface Repository is needed. Stores all interface definitions Often implemented by means of a separate process offering a standard interface to store and retrieve interface definitions Can be viewed as the part of CORBA that assists in runtime type checking facilities Whenever an interface definition is compiled, the IDL compiler assigns a repository identifier to that interface The repository ID can be used to retrieve an interface definition from the repository By default it is derived from the name of the interface and its methods (no guarantees are given with respect to its uniqueness) Because interface information are stored in IDL, it is possible to structure each interface repository in the same way. The interface repositories in CORBA all offer the same operations for navigating through interface definitions 60 Dynamic Interfaces What does DII do? CORBA offers DII to clients, which allows them to construct an invocation request at runtime It provides a generic invoke operation, which takes (1) an object reference, (2) a method identifier, and (3) a list of input values as parameters. These information are marshalled into a request and send to an object Later it returns the result in a list of output variables provided by the caller What does DSI do? In the same way, a server object has a DSI which is able to receive any request and decompose it into object reference, method identifier and parameters. Implementation Repository How to assign object references with real files? CORBA systems offer an Implementation repository Contains all that is needed to implement, register and activate objects, as well as locating running servers Stores a mapping of the names of object adapters to the file containing the object implementation Such functionality is related to the ORB (and its implementation) itself as well as to the underlying operating system. For this, it is difficult to provide a standard implementation for each CORBA system. Mainly used by an object adapter, which is responsible for dispatching a request to the right object. If this object isn't running in the address space of a server, the object adapter could contact the implementation repository to find out what needs to be done: map the object reference to a binary file, start this file as a CORBA server in a specific way, 59 61

10 Communication in CORBA Simple communication model: only synchronous communication (But: with the time, some invocation facilities were added to this model) Object invocation model: When a client invokes an object, it sends a request to the corresponding object server and blocks until it receives a response. These semantics correspond exactly to a normal method invocation when the caller and callee reside in the same address space. In the presence of failures, a client will receive an exception indicating that the invocation did not fully complete. One-way request: Problem with synchronous communication: if the client does not get back a result, it is blocked unnecessarily Solution: a form of invocation, in which no result is expected. The client isn't blocked, but it has no guarantees that the request is delivered Deferred synchronous communication: One-way requests are used by a client to make a request and by a server to pass back the result Message Types GIOP (and thus IIOP or any other realisation of GIOP) knows eight different message types: Message type Request Reply LocateRequest LocateReply CancelRequest CloseConnection MessageError Fragment Originator Client Server Client Server Client Both Both Both Description Contains an invocation request Contains the response to an invocation Contains a request on the exact location of an object Contains location information on an object Indicates client no longer expects a reply Indication that connection will be closed Contains information on an error Part (fragment) of a larger message Interoperability CORBA only specifies functionalities, not implementation issues. Each vendor of a CORBA implementation had his own way of enabling communication between clients and object servers as well as referencing objects lack of interoperability This problem was solved by the General Inter-ORB Protocol (GIOP) Standard protocol for communication in CORBA Builds upon a reliable, connection oriented transport protocol Specifies message types, a 'Common Data Representation' (CDR) as transfer syntax, interoperable object references (IORs), and more Internet Inter-ORB Protocol (IIOP) The realisation of GIOP running on top of TCP t the only communication protocol implemented, but the widest used one 63 Object References A client needs an object reference to invoke a method at an object A client resp. a server uses a language specific implementation of an object reference - in most cases this is a pointer to a local representation of the object That reference cannot be passed from a process A to process B Process A will first have to marshal the pointer into a process independent representation (done by the ORB) The ORB uses an own, language-independent representation Process B unmarshals it When a process refers to an object its underlying ORB is implicitly passed enough information to know which object is actually being referenced Common representation of an object reference: Interoperable Object Reference (IOR) The IOR is used to pass references to other ORBs. Internally, ORBs can have their own representation. 65

11 Object References Organization of an IOR with specific information for IIOP: Tagged Profile: complete information to invoke an object. If the object server supports several protocols, multiple tagged profiles are included Object key: server-specific information for demultiplexing incoming requests to the object Components: optionally contains additional information needed for invoking the referenced object (e.g. security information) 66 Indirect Binding First step: binding to the implementation repository The repository checks if the server is already running. If yes, it checks, where it is located. If no, the repository starts it When the client invokes the referenced object for the first time, the invocation request is sent to the implementation repository which responds by giving the details where the object's server can actually be reached So the invocation requests are forwarded to the proper server 68 Binding How does a client bind to an object to invoke a method? Use a name service to resolve a given name to an object reference (IOR) Because this IOR references directly to an object, the following is called direct binding The client's ORB uses the repository ID to place a proxy at the client and pass a pointer to this proxy on to the client The ORB uses a tagged profile, e.g. for IIOP and sets up a TCP connection with the object's server A client's invocation is marshaled into an IIOP request message and sent over the TCP connection to the POA associated with the object key The POA forwards the request to the proper servant where it is unmarshaled and transformed into an actual method call Alternative: indirect binding An implementation repository is involved The implementation repository is identified in the IOR It acts as a registry to locate and activate an object before transmitting invocations primarily used for persistent objects 67 Interceptors Client implementations are simple: define IDL, generate proxy, done. But if an object expects a client to enhance its functionality (e.g. caching), the client is not enabled to do so. Thus: some addition is needed enhancing the current software Interceptors Mechanism by which an invocation can be intercepted on its way from client to server and adapted as necessary before letting it continue Piece of code modifying or analysing a request General method to achieve extensibility There may be various interceptors added to an ORB Also possible for server-side Are seen only by the ORB, the ORB has to invoke them 69

12 Types of Interceptors 1. Request level interceptor: is logically placed between a client's proxy and the ORB Comes in before an invocation request is passed to the ORB The interceptor may modify the request On server side, it is placed between the ORB and the object adapter 2. Message level interceptor: placed between an ORB and the underlying network Knows nothing about the message content that is to be sent Only sees GIOP messages that it could modify add additional information, e.g. for instructing a server process or enhance a client by caching modify request, e.g. for fragmenting large GIOP messages or to transparently redirect a request by exchanging the IOR Both types: add monitors to analyse the performance of communications 70 Event Service Asynchronous communication can by realised with one-way calls, but One-way calls are best effort Overhead when simply a signalling information should be transmitted Communication by events CORBA's Event Service Provide a service that could simply signal the occurance of an event. In this model each event is associated with a single data item, generally represented by means of an object reference or otherwise an applicationspecific value. An event is produced by a supplier and received by a consumer The event service offers an event channel which is logically placed betwenn suppliers and consumers and suits for delivering events 72 CORBAservices CORBAservices are general purpose and application independent services. CORBAservices strongly resemble the types of services commonly provided by an operating system. Service Description Collection Facilities for grouping objects into lists, queue, sets, etc. Query Facilities for querying collections of objects in a declarative manner Concurrency Facilities to allow concurrent access to shared objects (locking) Transaction Flat and nested transactions on method calls over multiple objects Event Facilities for asynchronous communication through events tification Advanced facilities for event-based asynchronous communication Externalization Facilities for marshaling and unmarshaling of objects LifeCycle Facilities for creation, deletion, copying, and moving of objects Licensing Facilities for attaching a license to an object Naming Facilities for system-wide name of objects Property Facilities for associating (attribute, value) pairs with objects Trading Facilities to publish and find the services on object has to offer Persistence Facilities for persistently storing objects Relationship Facilities for expressing relationships between objects Security Mechanisms for secure channels, authorisation, and auditing Chapter Time 8: Middleware Provides the current time within specified error margins 71 Push and Pull Model Push model: Whenever en event occurs, the supplier produces the event and pushes it through the event channel Event channel passes the event on to its consumers In this model consumers passively wait for event propagation and expect to be interrupted when an event happens Pull model: Consumers poll the the event channel to check whether an event has happened The event channel in turn polls the various suppliers te: the models can be combined How does it work? For both, consumers and suppliers, proxies (for push and pull operations) are implemented in the event channel. Consumer and producer use synchronous communication with these proxies for the time delivering or getting events 73

13 Event Channel PushSupplier 1 Event Channel.. PushConsumer 1 PushSupplier n PushConsumer r ProxyPushConsumer ProxyPushSupplier ProxyPullConsumer ProxyPullSupplier PullSupplier 1 PullConsumer 1.. PullSupplier m PullConsumer s tice: kind of multicast: all events are passed from a Supplier Proxy to all Consumer Proxies Messaging Communication in CORBA is transient Many applications require persistent communication as offered by message queuing CORBA supports this model as an additional messaging service Messaging in CORBA is different because it is inherent object based approach in communication. Two models for messaging: Callback model A client implements a callback method. The communication system calls this method to deliver a result from an asynchronous request. It is the client's responsibility to transform the original synchronous invocation into an asynchronous one The server is presented a normal (synchronous) invocation request Polling model The client is offered a collection of operations to poll its ORB for incoming results. It is the client's responsibility to transform the original synchronous invocation into an asynchronous one tification Service Event services drawbacks: CORBA's event service does not support persistence of events. If a consumer connects to the event channel too late, events get lost Consumers have no chance to filter events. Each event is passed to every consumer. If different event types need to be distinguished it is necessary to set on a separate event channel for each event type. Event propagation is unreliable. guarantees need to be given concerning the delivery of events tification service Event typing Filtering capabilities have been added Offers facilities to prevent event propagation when no consumers are interested in a specific event Callback Model Constructing an asynchronous invocation is done in two steps: 1. The original interface as implemented by the object is replaced by two new interfaces that are to be implemented by the client-side software: Specification of methods that the client can call; none of these methods returns a value or has any output parameter Callback interface 2. This step consists of simply compiling the generated interfaces Original method: int add(in int I, in int j, out int k); New methods: void sendcb_add(in int I, in int j); void replycb_add(in int ret_val, in int k); 75 77

14 Polling Model Again, the original method is replaced by two new methods The ORB has to provide the second method Original method: int add(in int I, in int j, out int k); New methods: void sendpoll_add(in int I, in int j); void replypoll_add(out int ret_val, out int k); 78 CORBA Naming Service Used to look up object references using a character based name Names in CORBA are sequences of name components each taking the form of a (id,kind)-pair, where id and kind are both strings: id is used to name an object, kind is a simple indication of the name object (e.g. 'dir' for a directory object) The representation of a sequence is a language dependent There are no restrictions with respect to the structure of a naming graph. Each node in a naming graph is treated as an object Naming context: an object that stores a table mapping name components to object references (like directory node) Naming graph does not have a root context, however each ORB is required to provide an initial naming context which effectively operates as the root in a naming graph Names are always resolved with respect to a given naming context A client resolves a name by invoking the resolve method on a specific naming context If name resolution succeeds, it always returns either a reference to a naming context or a reference to a named object Name resolution proceeds exactly as presented in part 3 of the lecture 80 Naming CORBA supports different types of names Most basic types, object references and character-based names, are supported by the CORBA naming service There are a number of advance naming facilities whereby objects can found based on associated properties Independently from logical object names, CORBA objects can be addressed by URLs: iioploc://appserver.klick-and-bau.com:4711/object-24 references the CORBA object which can be connected to on host 'appserver.klick-and-bau.com' using port 4711 and object identifier 'object-24' iiopname://appserver.klick-andbau.com/buchhaltung/stammdaten/artikelhome references the CORBA object which the naming service on host 'appserver.klick-and-bau.com' knows by the name 'Buchhaltung/Stammdaten/ArtikelHome' In both cases, IIOP is used as communication protocol 79 Part of the CORBA Naming Service Interface in IDL struct NameComponent { string id; string kind; typedef sequence <NameComponent> Name; interface NamingContext { void bind (in Name n, in Object obj); binds the given name and remote object reference in my context void unbind (in Name n); removes an existing binding with the given name void bind_new_context(in Name n); creates a new naming context and binds it to a given name in my context Object resolve (in Name n); looks up the name in my context and returns its remote object reference void list (in unsigned long how_many, out BindingList bl, out BindingIterator bi); returns the names in the bindings in my context 81

15 How to Find the First Naming Context? The CORBA name service allows you to search a name context and to navigate through several name contexts. This works as in other name services. But how to find the root context, i.e. the naming service itself? The naming service is identified by an object reference To solve the problem, the ORB itself is responsible to provide facilities to get initial object references. A reference to the root context can be got by calling the function resolve_initial_reference("name Service") provided by the ORB: interface ORB {... Object resolve_initial_references (in String name);... } CORBA defines some more names the ORB has to resolve, e.g. "RootPOA" and "InterfaceRepository". Further names can be configured by the administrator. 82 The Trading Process matches both descriptions sorts all services with matching type and properties by a client s constraint gives back the reference to the best matching service 3. Selected service Trader Service Directory A service is described by Service Type Service Properties n Type T4 T5 T2 Reference Service Export Properties Service Import T2 T2 1 4 static vs. dynamic properties Importer Exporter Exporter Exporter 4. Service usage The client specifies its demands to a service A server specifies its functionality and its capabilities 84 Trading Service Naming Service = White pages But sometimes, no concrete name but only a description of the needed service is known Trading Service (= Yellow pages) An object is not denoted by a logical name, but by a description of its capabilities: Service Type (description of object functionality, determines interface) Service Properties (non-functional description of a service) Roles: Trader: stores and searches service descriptions Importer: a client searching for an object s service Exporter: an object offering a service Example: searching a print service Exporter: specifies its offer, i.e. type and properties, e.g. format={a3, A4, A5} cost_per_page=10 pages_per_sec=5 Importer: specifies type and constraints, e.g. format=a4 AND cost_per_page<15 minimize cost_per_page Only service offers fulfilling those restrictions are further considered Thematchingservicesare sorted by this criterion te: properties can be static or dynamic (value is changing over time). Considering dynamic properties is seldom realised

16 Synchronisation and Transactions Two important services that facilitate synchronisation in CORBA are the Concurrency control service and the Transaction service The two services collaborate to implement distributed and nested transactions using two phase locking A transaction is initiated by a client and consists of a series of invocations on objects. When an object is invoked for the first time it automatically becomes part of the transaction. This information is passed to the server when invoking the object Two types of objects can be part of a transaction: Recoverable object: is executed by an object server capable of participating in two phase commit protocol Transactional objects: executed by server that do not participate in a transaction's two phase commit protocol (typically read-only objects) CORBA transactions are similar to distributed transactions and their protocols as presented in the 6th part of the lecture The service is implemented using a central lock manager; it does not use distributed locking techniques The service distinguishes read from write locks and is also capable of supporting locks at different granularities (e.g. whole tables vs. single records) Fault Tolerance Supported strategies: passive replication, active replication, quorum-based replication When a client passes an IOGR to the ORB, the ORB attempts to bind to one of the replicas. The Components filed could refer to the primary or a copy of the object's replicas If binding fails, the ORB can try another copy Replication and Fault Tolerance CORBA offers no support for generic caching and replication Application developers have to resort to an ad-hoc approach when replication is needed (such approaches are often based on using interceptors) Only the replication of objects for fault tolerance is included in the current CORBA version 3 Fault Tolerance Dealing with failures: replicate objects into object groups, consisting of identical copies of an object referenced as if it would be a single object. A group offers the same interface as the objects it contains Uses a special kind of an IOR, the Interoperable Object Group Reference (IOGR) Fault Tolerance Replication manager: creating and managing object groups, replacing replicas in case of a failure Interceptors are used to pass invocations to a separate replication component maintaining consistency and realising recoverability 87 89

17 Trading service Comparison of CORBA, DCOM and Globe Issue Design goals Object model Services Interfaces Synchronous communication Asynchronous communication Callbacks Events Messaging Object server Directory service CORBA Interoperability Remote objects Many of its own Languagedependent Flexible (POA) DCOM Functionality Remote objects From environment Binary Hard-coded Globe Scalability Distributed objects Few Binary Object dependent 90 Comparison of CORBA, DCOM and Globe Issue Naming service Location service Object reference Synchronisation Replication support Transactions Fault tolerance Recovery support Security CORBA Object's location Transactions Separate server By replication Various mechanisms DCOM Interface pointer Transactions ne By transactions By transactions Various mechanisms Globe True identifier Only intra-object Separate subobject By replication More work needed 91