1 CORBA M. Cossentino. 2Contents Corba history Applications of Corba What is Corba The Corba Object...

92
1 CORBA CORBA M. Cossentino

Transcript of 1 CORBA M. Cossentino. 2Contents Corba history Applications of Corba What is Corba The Corba Object...

1

CORBACORBA

M. Cossentino

2

ContentsContents

• Corba history

• Applications of Corba

• What is Corba

• The Corba Object model

• The Corba client side

• The Corba server side

• The Interface Definition Language

• IDL - C++ comparison

• C++ Mapping

• The query service

3

Corba historyCorba history

4

CORBA HistoryCORBA History

• The OMG grew out of the object technology boom of the 1980s.

• 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 object-oriented computing

5

CORBA HistoryCORBA 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

6

CORBA HistoryCORBA History

• References:– D. Kassay (Harvard Univ.):

http://www.das.harvard.edu/cs/academics/courses/cs265/1996/proj/corba/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

7

Applications of CorbaApplications of Corba

8

Medical ImagingMedical 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.html

9

Real-time AvionicsReal-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/TAO-

boeing.html

10

Global PCSGlobal PCS• Domain Challenges

– Long latency satellite links

– High reliability– Prioritization

• References– http://www.cs.wustl.edu/~schmidt/TAPOS-

95.ps.gz

11

What is CORBAWhat is CORBA

12

What is CORBAWhat 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.

13

The Object Management The Object Management ArchitectureArchitecture

14

Technical OverviewTechnical 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.

15

Corba architecture elementsCorba architecture elements

16

An article on object An article on object interconnectionsinterconnections

• 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.

17

A problemA 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

18

Implementation of a CORBA ORB 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.

19

The CORBA Object ModelThe CORBA Object Model

20

In the Corba model: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.

21

IDLIDL• 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.

22

ObjectsObjects

• 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

23

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

24

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

It means that only input parameters are allowed and no exceptions may be declared. It means that only input parameters are allowed and no exceptions may be declared.

25

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

op_type_spec is the type of the return result. Operations not declared oneway can return values in out or inout parameters.

op_type_spec is the type of the return result. Operations not declared oneway can return values in out or inout parameters.

26

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

{identifier} is the name of the operation. {identifier} is the name of the operation.

27

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

Parameters are flagged with the direction of the data flow with respect to the object requesting the service by in, out, and inout.

Parameters are flagged with the direction of the data flow with respect to the object requesting the service by in, out, and inout.

28

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

raises(except1, ..., exceptI) are the user-defined exceptions that may be raised if the operation fails in some way.

raises(except1, ..., exceptI) are the user-defined exceptions that may be raised if the operation fails in some way.

29

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

context which is equivalent to the environment in UNIX and DOS programs. It is a list of name-values pairs called properties.

context which is equivalent to the environment in UNIX and DOS programs. It is a list of name-values pairs called properties.

30

OperationsOperations

• Clients request Operations of their servers.

• Operations are identified by signatures that take the following general form:

[oneway] {op_type_spec} {identifier} (param1, ...., paramN) [raises(except1, ..., exceptI)] [context(name1, ..., nameJ)]

CORBA objects also take advantage of the object-oriented properties of encapsulation, inheritance, and polymorphism.

31

The CORBA Client SideThe CORBA Client Side

32

The CORBA Client SideThe CORBA Client Side

It consists of:– Invocation Interfaces

(dynamic or static)– Interface repository

33

The CORBA Client SideThe 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

34

The CORBA Client Side - 2The 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.

35

The IDL interface compilationThe 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.

36

Dynamic Invocation InterfaceDynamic 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.

37

The dynamic invocation of a The dynamic invocation of a methodmethod

• 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.

38

Interface RepositoryInterface 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.

39

ORB InitializationORB 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.

40

ORB Initialization-2ORB 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.

41

The Corba Server SideThe Corba Server Side

42

The Corba Server SideThe Corba Server Side

In a CORBA environment it consists of: object implementations,

skeletons,

an interface to the ORB.

an object adapter,

43

Object ImplementationsObject 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.

44

Server SkeletonsServer 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.

45

Object Adapters - scopeObject 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.

46

Object Adapters - advantagesObject 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.

47

Object Adapters - Object Adapters - functionalityfunctionality

• 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.

48

The BOA (Basic Object Adapter)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.

49

The BOA interfaceThe 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.

50

SERVER SIDE

The path of a client’s requestThe 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

51

SERVER SIDE

The path of a client’s requestThe 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

52

SERVER SIDE

The path of a client’s requestThe 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

53

SERVER SIDE

The path of a client’s requestThe path of a client’s request• This figure shows the path of a client's request

being handled by the BOA.

the BOA calls the server's activate_object routine with an object reference parameter to activate the object.

54

SERVER SIDE

The path of a client’s requestThe path of a client’s request• This figure shows the path of a client's request

being handled by the BOA.

the BOA passes the request to the object through the skeleton and receives the response, which it sends back to the client

55

SERVER SIDE

The path of a client’s requestThe 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.

56

SERVER SIDE

The path of a client’s requestThe 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

57

The Dynamic Skeleton Interface The Dynamic Skeleton Interface (DSI)(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.

58

Corba referencesCorba references• Omg site:

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/

cs265/1996/proj/corba/index.htm

59

The Interface Definition The Interface Definition Language (IDL)Language (IDL)

60

What is IDL?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.

61

Why do we need IDL for Why do we need IDL for CORBA?-1CORBA?-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

62

Why do we need IDL for Why do we need IDL for CORBA?-2CORBA?-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.

63

Why do we need IDL for Why do we need IDL for CORBA?-2CORBA?-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

64

Why do we need IDL for Why do we need IDL for CORBA?-2CORBA?-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

65

Why do we need IDL for Why do we need IDL for CORBA?-2CORBA?-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

66

Why do we need IDL for Why do we need IDL for CORBA?-2CORBA?-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

67

What does IDL look like?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.

68

An example of IDL - An example of IDL - descriptiondescription

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.

69

An example of IDL - codeAn example of IDL - code module POS { typedef string Barcode; interface InputMedia { typedef string OperatorCmd; void barcode_input(in Barcode item); void keypad_input(in OperatorCmd cmd);

}; interface OutputMedia { boolean output(in string StringToPrint); };

interface POSTerminal { void end_of_sale(); void print_POS_sales_summary(); };

};

70

IDL - C++ comparisonIDL - C++ comparison

71

IDL - C++ similaritiesIDL - C++ similarities

• The similarities of IDL to C++ include:

C++-like preprocessing; IDL lexical rules; IDL grammar, but lacks algorithmic structures and

variables.

72

IDL - C++ differenciesIDL - 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.

73

IDL - C++ differenciesIDL - 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 best-effort 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 SendMessage(in string message);

74

IDL - C++ differenciesIDL - C++ differencies

• Attribute variables e.g. interface circle { attribute float radius; }; equivalent: 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.

75

IDL - C++ differenciesIDL - C++ differencies• Inheritance

IDL supports both single and multiple inheritances. interface example1 { // define a class long operation1(in long arg1); };

interface example2:example1 { // inheritance void operation2(in long arg2, out long arg3); };An example for a multiple inheritance: interface example4:example3, example1 { ... }Interface example4 inherits not only all of example3, but also

example1.

76

IDL - C++ differenciesIDL - 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_out_of_range {long dummy}; void operation1(in long arg1) raises (input_out_of_range);

The first sentence declares an exception class. The second says that the operation1 will raise an exception input_out_of_range. The keyword ‘raises’ is different from the keyword ‘throw’ in C++, or the keyword ‘throws’ in Java.

77

IDL - C++ differenciesIDL - 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.

78

C++ mappingC++ mapping

79

C++ mappingC++ mapping• The mechanism to access the IDL interface is called

programming language mappings. Example:// IDLinterface example1 { // define a class //this operation take a long int as its // input, it returns a long integer long op1(in long arg1); }

//C++// Declare object reference:example1_var myex1; // it is a T_var type CORBA::long mylongin, mylongout;

// code to retrieve a reference to an example1 // object and bind it to myex1 …

mylongout = myex1->op1 (mylongin);

80

C++ mappingC++ mapping• The mechanism to access the IDL interface is called

programming language mappings. Example:// IDLinterface example1 { // define a class //this operation take a long int as its // input, it returns a long integer long op1(in long arg1); }

//C++// Declare object reference:example1_var myex1; // it is a T_var type CORBA::long mylongin, mylongout;

// code to retrieve a reference to an example1 // object and bind it to myex1 …

mylongout = myex1->op1 (mylongin);

The C++ mapping provides a _var type for almost every type that automates memory management. For a class example1 , its T_var Type is constructed by adding _var to its name.

81

C++ mappingC++ mapping• The mechanism to access the IDL interface is called

programming language mappings. Example:// IDLinterface example1 { // define a class //this operation take a long int as its // input, it returns a long integer long op1(in long arg1); }

//C++// Declare object reference:example1_var myex1; // it is a T_var type CORBA::long mylongin, mylongout;

// code to retrieve a reference to an example1 // object and bind it to myex1 …

mylongout = myex1->op1 (mylongin);

You may notice that the long type in IDL is mapped as CORBA::long in C++. The defined IDL types map to C++ types generally as CORBA::type. Such a mapping assures that, CORBA::type is independent of its system.

82

C++ mappingC++ mapping• The mechanism to access the IDL interface is called

programming language mappings. Example:// IDLinterface example1 { // define a class //this operation take a long int as its // input, it returns a long integer long op1(in long arg1); }

//C++// Declare object reference:example1_var myex1; // it is a T_var type CORBA::long mylongin, mylongout;

// code to retrieve a reference to an example1 // object and bind it to myex1 …

mylongout = myex1->op1 (mylongin);

Result of the function op1 invoked through the IDL interface

83

The Query ServiceThe Query Service

84

The Query ServiceThe 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.

85

Elements of a query serviceElements 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

86

Standardized Query Standardized Query LanguageLanguage

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 object-oriented 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.

87

Standardized InterfaceStandardized 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.

88

An example of interfaceAn example of interface

interface QueryEvaluator { readonly attribute sequence ql_types; readonly attribute QLType default_ql_type;

any evaluate ( in string query, in QLType ql_type, in parameterlist params) raises(...);

}

89

An example of interfaceAn example of interface

interface QueryEvaluator { 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

90

An example of interfaceAn example of interface

interface QueryEvaluator { 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

91

Submitting a querySubmitting 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.

92

Query Query Evaluators/ManagersEvaluators/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.