CORBA M Cossentino 1 Contents Corba history The

CORBA M. Cossentino 1

Contents • Corba history • The Corba server side • Applications of Corba • The Interface Definition Language • What is Corba • The Corba Object model • The Corba client side • IDL - C++ comparison • C++ Mapping • The query service 2

Corba history 3

CORBA History • The OMG grew out of the object technology boom of the 1980 s. • Its founders were Data General, Hewlett. Packard, and Sun. • Today some 700 (and growing) companies comprise the OMG. • Together these companies have created and continue to create standards for objectoriented computing 4

CORBA History • Microsoft has its own plan for the future of distributed object technology using their OLE/DCOM technology. • Many feel that CORBA is the superior technology and it is only Microsoft's dominance of the desktop world that keeps the rivalry alive. • Another OMGs contribution to distributed computing has been a standard to describe how different vendor's implementations of CORBA will talk to each other. It is the Internet Inter-ORB Protocol which involved producers like Sun, IBM, and HP 5

CORBA History • References: – D. Kassay (Harvard Univ. ): http: //www. das. harvard. edu/cs/academics/courses/cs 265/1996/proj/cor ba/index. htm – Orfali, Harkey, Edwards' book: “The Essential Distributed Objects Survival Guide” http: //www. omg. org/dh/do-flyer. htm – Dinesh Katiyarl's report (a comparison of OLE and CORBA): ftp: //theory. stanford. edu/pub/katiyar/misc/ole_vs_corba. html 6

Applications of Corba 7

Medical Imaging • Domain Challenges – Large volume of 'Blob' data (e. g. : 10 to 40 Mbps) – 'Lossy compression' isn't viable – Prioritization of request • References – – – http: //www. cs. wustl. edu/~schmidt/COOTS 96. ps. gz http: //www. cs. wustl. edu/~schmidt/av. ps. gz http: //www. cs. wustl. edu/~schmidt/NMVC. h tml 8

Real-time Avionics • Domain Challenges – Real-time periodic processing – Complex dipendencies – Very low latency • References – – http: //www. cs. wustl. edu/~schmidt/JSAC 98. ps. gz http: //www. cs. wustl. edu/~schmidt/TAOboeing. html 9

Global PCS • Domain Challenges – Long latency satellite links – High reliability – Prioritization • References – http: //www. cs. wustl. edu/~schmidt/TAPOS -95. ps. gz 10

What is CORBA 11

What is CORBA • CORBA = Common Object Request Broker Architecture • It is a standard that vendors can implement. • It allows objects across a heterogeneous computing environment to talk to one another without the programmer being concerned exactly where an object resides on the network or how it is implemented. • Programmers need only know about the object's public interface. 12

The Object Management Architecture 13

Technical Overview • Corba allows an object residing on system A to invoke a method of an object residing on system B where A and B can be completely different systems and the objects may be implemented in different languages. • Objects can even communicate across ORBs implemented by different vendors via the IIOP. Legacy systems can be wrapped in the OMG Interface Definition Language (IDL) so they can operate in a new CORBA environment. • This way businesses do not need to abandon the applications they have been using for years. 14

Corba architecture elements 15

An article on object interconnections • Doug Schmidt and Steve Vinoski: http: //www. sigs. com/publications/cppr – It is a comparisons of different frameworks for implementing a distributed application, using UNIX sockets, using a C++ communications class library, and using CORBA – In this article Prof. Schmidt and Mr. Vinoski walk through a financial services client/server application and demonstrate the programming necessary for each of the frameworks. 16

A problem For high-bandwidth applications the ORB is a bottleneck! Various solutions for the CORBA bottleneck problem have been proposed such as using CORBA combined with UNIX sockets • References: – Design and Performance of an Object-Oriented Framework for High -Speed Electronic Medical Imaging by Pyarali, Harrison, and Schmidt: http: //www. cs. wustl. edu/~schmidt/COOTS-96. ps. gz 17

Implementation of a CORBA ORB • The standard leaves this up to the vendor. For example: § it can be a library that applications link with, § it can be a service of the underlying operating system § it can be implemented as a runtime application that clients and servers communicate with using an IPC mechanism. • All that is required of an ORB to be CORBA compliant is that it provide that appropriate interfaces to the ORB for the object clients and servers. • These common interfaces are provided via the IDL language mappings, also standardized by the OMG. 18

The CORBA Object Model 19

In the Corba model: The client – requests a service from a server via a message. – uses an object reference to invoke the message. – does not have to be aware of the location of the object it is requesting service from. The server – object could be part of the same process as the client or it could reside across a network. The ORB – takes care of locating the object and getting the object reference. 20

IDL • The interfaces to objects are specified using the OMG Interface Definition Language (IDL). • The IDL defines: § the operations that an object must support § the input parameter names and types § the return types of the operation. • A request may include input and output parameters denoted by the keywords in, out and inout. 21

Objects • Objects may be created and destroyed and have a type associated with them. • The types allowed by CORBA IDL is a superset of C++ types. • OMG IDL is a strongly typed language • It includes the basic types of C++ and Boolean • It also allows the following constructed types: record, union, sequence, array and interface 22

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] 23

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] It means that only input parameters are allowed and no exceptions may be declared. 24

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] op_type_spec is the type of the return result. Operations not declared oneway can return values in out or inout parameters. 25

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] {identifier} is the name of the operation. 26

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] Parameters are flagged with the direction of the data flow with respect to the object requesting the service by in, out, and inout. 27

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] raises(except 1, . . . , except. I) are the user-defined exceptions that may be raised if the operation fails in some way. 28

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] context which is equivalent to the environment in UNIX and DOS programs. It is a list of name-values pairs called properties. 29

Operations • Clients request Operations of their servers. • Operations are identified by signatures that take the following general form: [oneway] {op_type_spec} {identifier} (param 1, . . , param. N) [raises(except 1, . . . , except. I)] [context(name 1, . . . , name. J)] CORBA objects also take advantage of the object-oriented properties of encapsulation, inheritance, and polymorphism. 30

The CORBA Client Side 31

The CORBA Client Side It consists of: – Invocation Interfaces (dynamic or static) – Interface repository 32

The CORBA Client Side • CORBA clients – make requests from CORBA servers. • The ORB – provides the communication infrastructure needed to deliver requests and their associated parameters to the servers. – is responsible making the connection to the server, marshaling the parameters for transfer cross a network and to return the operation result to the client. • The programmer – must supply the IDL source code for each CORBA object. to be continued 33

The CORBA Client Side - 2 • The client application – uses a naming service such as the default CORBA naming service or an implementation of a more complete Common Object Service (COS) Naming Service. Using the naming service the client can locate and bind to a server and then invoke methods on the server object. – accesses the object with an object reference returned when a client object binds to a server. 34

The IDL interface compilation • The IDL is compiled by a vendor's IDL compiler and generates the source code in the language the developer has chosen for both the client and server sides. • This generated code provides the stub and skeleton interfaces for the object and its implementation. • The compiled IDL automatically marshals and demarshals the method parameters relieving the programmer of this error-prone task. 35

Dynamic Invocation Interface • The DII allows applications to dynamically issue requests on objects not statically linked in via client stubs. • This allows clients to use objects discovered at runtime • To the object implementation the request looks the same whether it was dynamically or statically invoked. 36

The dynamic invocation of a method • To dynamically invoke an object method the client follows four simple steps: 1) identifies the object to invoke, 2) retrieves the objects interface (via an ORB get_interface request), 3) constructs the request (via an ORB create_request call), 4) invokes the request and receives the results. 37

Interface Repository • It is a database of all the object's interfaces registered with the ORB. • Interfaces are added to the IR either at IDL compile time or dynamically through methods on the IR object. • An ORB uses the IR database for many purposes including the following: 1) it provides type-checking of method's signatures, 2) it helps connect ORBs together, 3) it provides metadata information to clients and tools, 4) it provides self-describing objects. • An ORB accesses an IR by using that IR's unique Repository ID. 38

ORB Initialization • Both sides of the client/server communication must initialize with the ORB. • On the client side, the client needs object references for its ORB, a Naming service, and the Interface Repository. • Clients use Pseudo-IDL to define an ORB_Init function. This function call returns a pointer to an ORB object. 39

ORB Initialization-2 • The ORB also provides a function to stringify and destringify object references. – Thus, if the application wishes to insert the object into a database or file it can be stringified so that when it is retrieved later it can be converted to an object reference that is still valid – Object references only remain valid while the application using it is running and connected to an ORB. – The stringified object, however, remains valid across sessions. 40

The Corba Server Side 41

The Corba Server Side In a CORBA environment it consists of: § object implementations, § skeletons, § an object adapter, § an interface to the ORB. 42

Object Implementations • These are the objects that do the work of the client request • It is the implementation of the interfaces defined in IDL. • This code is written by the application programmer and the interface to objects is provided by the IDL skeletons. • Object implementers must provide ways to save the state of their objects if the object is to be CORBA compliant. 43

Server Skeletons • The server skeletons are generated from source by a vendor's IDL compiler and provide a bridge between the ORB and the object implementation. • Client invocations pass through the skeleton and return the same way they entered. 44

Object Adapters - scope • Object adapters fit between the ORB and the object implementations. They assist in activating objects and delivering requests to object implementations and are thus key to object implementation portability. • Object adapters are specialized to support one type of object implementation style. – For example, one system may have different OAs to support C++ objects, object-oriented databases, and for optimizing access to objects located in the same process. 45

Object Adapters - advantages • By having objects interact with OAs instead of directly with the ORB, it keeps the size of the ORB to a minimum. • This allows ORBs to support diverse object implementations without becoming bloated with functionality that not all applications need. Implementers only use the OAs they need. – Of course, if the ORB is designed for a large memory system then more functionality can be placed in the ORB to improve performance. 46

Object Adapters - functionality • OAs provide the following functionality to the ORB: · register server classes with the implementation repository · instantiate new objects at run time · generate and manage object references · broadcast presence of object servers · handle incoming client calls · route the up-call to the appropriate method via the static skeleton. 47

The BOA (Basic Object Adapter) • The OMG only has a specification for one OA, the Basic Object Adapter • According to the specification the BOA is to provide reasonable support for a range of object implementations. 48

The BOA interface • The BOA interface supports the following four activation policies for activating servers and objects: – shared server, the server consists of several object implementations – persistent server, like the shared server only the server is activated by a process other than the BOA and is registered with the BOA by an installation procedure – unshared server, only one object of a given implementation can be active in the server – server-per-method, the BOA starts a new server for each method invocation and terminates the server when the request completes. 49

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA. the ORB receives the request and checks its repository to see if the server or object is active SERVER SIDE 50

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA. the ORB activates the server and gives the server information it needs to communicate with the BOA SERVER SIDE 51

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA. the server calls impl_is_ready on the BOA telling the BOA it is ready to activate objects SERVER SIDE 52

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA calls the server's activate_object routine with an object reference parameter to activate the object. SERVER SIDE 53

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA passes the request to the object through the skeleton and receives the response, which it sends back to the client SERVER SIDE 54

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA. If necessary, the server can shutdown the object with a call to the BOA, deactivate_object, saving the object's state to persistent storage if required. SERVER SIDE 55

The path of a client’s request • This figure shows the path of a client's request being handled by the BOA. If necessary, the server will be shutdown with the call on the BOA, deactivate_impl. If more requests come in for the server, the BOA must start over again at step 1 SERVER SIDE 56

The Dynamic Skeleton Interface (DSI) • This is the server-side equivalent of the DII. • The DSI allows server requests to be invoked on object implementations that do not have a static skeleton. • Dynamic skeletons are very useful for providing bridges between ORBs for inter-orb requests. 57

• Omg site: Corba references www. omg. org • Corba site: www. corba. org • Schmidt's (Washington Univ. ) papers, overview and tutorials on corba: http: //www. cs. wustl. edu/~schmidt/corba. html • Vinoski's pages on C++, CORBA and distributed objects: http: //www. iona. com/hyplan/vinoski/ • Kassay, Liu, Gbadegesin (Harvard Univ. ) tutorial: http: //www. das. harvard. edu/cs/academics/courses/cs 26 5/1996/proj/corba/index. htm 58

The Interface Definition Language (IDL) 59

What is IDL? • It defines an object's interface in Corba. • It is used to specify the operations the object is prepared to perform, the input and output parameters they require, and any exceptions that may be raised along the way. • It is an interface by which the client and the object can talk to each other. • On the other hand, the object implementor is responsible for implementing all of the operations stated in the interface. 60

Why do we need IDL for CORBA? -1 • The beauty of CORBA is that each ORB will interoperate with the others. • The interoperability allows all of the objects from different operating systems, written in different languages to communicate. • It also allows different databases, relational database, object-oriented database or other kinds of database to talk to each other. • The interoperability is based on ORB-to-ORB (object request broker) communication. to be continued 61

Why do we need IDL for CORBA? -2 • The following figure shows a request passing from a client to an object implementation in the CORBA architecture. Both client and object implementation are isolated from the object request broker (ORB) by an IDL interface. • The client's request is passed to an ORB. If the target object is local, the ORB routes the message to its destination by another IDL interface (called IDL Skeleton). If not, the ORB routes the invocation to a remote ORB. The remote ORB then routes the message to the target object. 62

Why do we need IDL for CORBA? -2 • The following figure shows a request passing from a client to an object implementation in the CORBA architecture. Reference: http: //www. cs. wustl. edu/~schmidt/corba. html 63

Why do we need IDL for CORBA? -2 • The following figure shows a request passing from a client to an object implementation in the CORBA architecture. Both client and object implementation are isolated from the object request broker (ORB) by an IDL interface. Reference: http: //www. cs. wustl. edu/~schmidt/corba. html 64

Why do we need IDL for CORBA? -2 • The following figure shows a request passing from a client to an object implementation in the CORBA architecture. The client's request is passed to an ORB. If the target object is local, the ORB routes the message to its destination by another IDL interface. Reference: http: //www. cs. wustl. edu/~schmidt/corba. html 65

Why do we need IDL for CORBA? -2 • The following figure shows a request passing from a client to an object implementation in the CORBA architecture. The client's request is passed to an ORB. If the target object is not local, the ORB routes the invocation to a remote ORB. The remote ORB then routes the message to the target object. Reference: http: //www. cs. wustl. edu/~schmidt/corba. html 66

What does IDL look like? • Although IDL interfaces are programming language -independent, the IDL language looks like ANSI C++ in many ways. • This is a strategical consideration since C++ is probably by far the most popular language among professional programmers. The C++-like syntax makes it much easier for programmers to use the interface. 67

An example of IDL - description The following example concerns a store with point-of -sale (POS) terminals. The POS terminal object uses the interface to communicate with its bardcode-reader object, keypad object, and receipt-printer object. 68

An example of IDL - code module POS { typedef string Barcode; interface Input. Media { typedef string Operator. Cmd; void barcode_input(in Barcode item); void keypad_input(in Operator. Cmd cmd); }; interface Output. Media { boolean output(in string String. To. Print); }; interface POSTerminal { void end_of_sale(); void print_POS_sales_summary(); }; 69

IDL - C++ comparison 70

IDL - C++ similarities • The similarities of IDL to C++ include: § C++-like preprocessing; § IDL lexical rules; § IDL grammar, but lacks algorithmic structures and variables. 71

IDL - C++ differencies • The keyword interface defines a class. This is exactly the same as Java's interface. • parameter must have a direction: in, out, inout. e. g. void barcode_input(in Barcode item); It indicates that the item is an input parameter of the operation barcode_input. 72

IDL - C++ differencies • A new type: any A variable of the any type may be used anywhere another IDL type would be allowed. It is a generic type of variable. The any type is similar to a generic pointer (pointer to void) in C. There are very few cases where the any type is actually required. • oneway declaration – If an operation is declared as oneway, it will not return anything. The invocation of this operation is a besteffort by the ORB, which does not guarantee that the invocation will be delivered to the target object. It is called "shot and forget". e. g. oneway void Send. Message(in string message); 73

IDL - C++ differencies • Attribute variables e. g. equivalent: interface circle { attribute float radius; }; interface circle { float _get_radius(); void _set_radius(in float r); }; Attributes are just a more convenient way of declaring a variable with a set/get operation pair. 74

IDL - C++ differencies • Inheritance IDL supports both single and multiple inheritances. interface example 1 { // define a class long operation 1(in long arg 1); }; interface example 2: example 1 { // inheritance void operation 2(in long arg 2, out long arg 3); }; An example for a multiple inheritance: interface example 4: example 3, example 1 {. . . } Interface example 4 inherits not only all of example 3, but also example 1. 75

IDL - C++ differencies • Exceptions Not all current C++ compilers support the exception handling in the ANSI C++. IDL exception declaration is slightly different from ANSI C++. exception input_of_range {long dummy}; void operation 1(in long arg 1) raises (input_of_range); The first sentence declares an exception class. The second says that the operation 1 will raise an exception input_of_range. The keyword ‘raises’ is different from the keyword ‘throw’ in C++, or the keyword ‘throws’ in Java. 76

IDL - C++ differencies • Not case-sensitive – Some programming languages, such as C/C++ are case sensitive, while others, such as FORTRAN and LISP, are not. – The IDL are not case sensitive. 77

C++ mapping 78

C++ mapping • The mechanism to access the IDL interface is called programming language mappings. Example: // IDL interface example 1 { // define a class //this operation take a long int as its // input, it returns a long integer } long op 1(in long arg 1); //C++ // Declare object reference: example 1_var myex 1; // it is a T_var type CORBA: : long mylongin, mylongout; // code to retrieve a reference to an example 1 // object and bind it to myex 1 … mylongout = myex 1 ->op 1 (mylongin); 79

C++ mapping • The mechanism to access the IDL interface is called programming language mappings. Example: // IDL interface example 1 { The C++ mapping provides // definea a_var class type for almost //this operation take a long int asevery its type that // input, it returns a long integer automates memory long op 1(in long arg 1); management. } For a class example 1 , its T_var Type is //C++ constructed by adding // Declare object reference: example 1_var myex 1; // it is _var a T_var type to its name. CORBA: : long mylongin, mylongout; // code to retrieve a reference to an example 1 // object and bind it to myex 1 … mylongout = myex 1 ->op 1 (mylongin); 80

C++ mapping • The mechanism to access the IDL interface is called programming language mappings. Example: // IDL interface example 1 { // define a class //this operation take a long int as. You itsmay notice that the // input, it returns a long integerlong type in IDL is mapped as CORBA: : long in C++. } The defined IDL types map to C++ types generally //C++ as CORBA: : type. Such a // Declare object reference: mapping assures that, example 1_var myex 1; // it is a T_var type CORBA: : type is CORBA: : long mylongin, mylongout; independent of its system. // code to retrieve a reference to an example 1 // object and bind it to myex 1 … long op 1(in long arg 1); mylongout = myex 1 ->op 1 (mylongin); 81

C++ mapping • The mechanism to access the IDL interface is called programming language mappings. Example: // IDL interface example 1 { // define a class //this operation take a long int as its // input, it returns a long integer } long op 1(in long arg 1); //C++ // Declare object reference: Result of the function op 1 invoked through the IDL interface example 1_var myex 1; // it is a T_var type CORBA: : long mylongin, mylongout; // code to retrieve a reference to an example 1 // object and bind it to myex 1 … mylongout = myex 1 ->op 1 (mylongin); 82

The Query Service 83

The Query Service Object query service can combine: – CORBA objects – object-oriented databases, – relational databases, – files on your system, into a single database which you can search with a query invocation. 84

Elements of a query service To integrate a database in a query service it is necessary: – a standard query language. – a standard interface • so that an object that has a query can pass it to an independently build object for invocation. – collections of CORBA objects to query – a query evaluator to perform the query. This evaluator is composed of: • a query evaluator interface on the top • an interface into the database on the bottom 85

Standardized Query Language Two query languages have been selected by the OMG, and they are: § SQL-92 Query, the subset of SQL-92 § OQL-93 : an adaptation of SQL-92 Query, fully objectoriented query language. The OMG had to pick two because there is no single query language that provides full query capability for all the databases and is object-oriented and thus capable of queries that scope to CORBA and OODB objects. 86

Standardized Interface A common interface is needed to pass a query from one query evaluator to another, especially if the query evaluators are implemented by different vendors. The standard interface is expressed in OMG IDL. 87

An example of interface Query. Evaluator { readonly attribute sequence ql_types; readonly attribute QLType default_ql_type; any evaluate ( in string query, in QLType ql_type, in parameterlist params) raises(. . . ); } 88

An example of interface Query. Evaluator { readonly attribute sequence ql_types; readonly attribute QLType default_ql_type; any evaluate ( in string query, in QLType ql_type, in parameterlist params) raises(. . . ); } The user can read the attribute default_ql_type to find the default query language for the query evaluator 89

An example of interface Query. Evaluator { readonly attribute sequence ql_types; readonly attribute QLType default_ql_type; any evaluate ( in string query, in QLType ql_type, in parameterlist params) raises(. . . ); } The user can read the attribute ql_types for a list of other supported query languages 90

Submitting a query The query is submitted as a string in the chosen query language and it is passed to the query evaluator, specifying the language and a list of parameters. When the query either completes or meets an error, you get back either an any or an exception. The return type any is a generic type; and the most common return type will probably be a collection of objects. 91

Query Evaluators/Managers The Query Evaluator actually execute the query. It takes in a standardized query, through a standardized interface, and executes it on a particular domain with a particular query system. 92