Transcript The Object Management Architecture At the heart of the OMA

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 1980s.
• Its founders were Data General, HewlettPackard, 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/cs265/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}
(param1, ...., paramN) [raises(except1,
..., exceptI)] [context(name1, ...,
nameJ)]
23
Operations
• 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.
24
Operations
• 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.
25
Operations
• 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.
26
Operations
• 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.
27
Operations
• 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.
28
Operations
• 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.
29
Operations
• 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.
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.
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.
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/cs26
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 pointof-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 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();
};
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 SendMessage(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 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.
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_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.
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 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);
79
C++ mapping
• The mechanism to access the IDL interface is called
programming language mappings. Example:
// IDL
interface example1 {
The C++ mapping
// defineprovides
a classa _var type for
//this operation take a long int asalmost
its every type that
// input, it returns a long integer
automates memory
long op1(in long arg1);
management.
}
For a class example1 ,
its T_var Type is
//C++
constructed by adding
// Declare object reference:
example1_var myex1;
// it is _var
a T_var
type
to its
name.
CORBA::long mylongin, mylongout;
// code to retrieve a reference to an example1
// object and bind it to myex1 …
mylongout = myex1->op1 (mylongin);
80
C++ mapping
• The mechanism to access the IDL interface is called
programming language mappings. Example:
// IDL
interface example1 {
// define a class
//this operation take a long int asYou
itsmay notice that the
// input, it returns a long integer long type in IDL is mapped
as CORBA::long in C++.
}
The defined IDL types
map to C++ types
//C++
generally as CORBA::type.
// Declare object reference:
Such a mapping assures
example1_var myex1;
// it is a T_var type
that, CORBA::type is
CORBA::long mylongin, mylongout;
independent of its
// code to retrieve a reference system.
to an example1
// object and bind it to myex1 …
long op1(in long arg1);
mylongout = myex1->op1 (mylongin);
81
C++ mapping
• The mechanism to access the IDL interface is called
programming language mappings. Example:
// IDL
interface 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:
Result of the function
op1 invoked through the
IDL interface
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);
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
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(...);
}
88
An 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
89
An 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
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