IT-SC book: Advanced CORBA® Programming with C++

Chapter 19. The OMG Trading Service

19.1 Chapter Overview

This chapter covers the OMG Trading Service, which provides a dynamic object discovery facility. Sections 19.2 to 19.4 present an overview of the major functional areas of the trader. Sections 19.5 to 19.9 explain the detailed functionality of the type repository and discuss how to export, withdraw, and modify service offers. Section 19.10 covers the trader constraint language, and Section 19.11 shows how to retrieve service offers from a trader. Advanced aspects of trading, such as configuration, dynamic properties, and federation, are presented in Sections 19.12 to 19.16. The chapter concludes with a discussion of the architectural trade-offs of trading, deployment options, and dealing with duplicate service offers in Sections 19.17 to 19.20. We show how to use trading in the context of the climate control system in Section 19.21. The trading specification is large, and much of its functionality either relates to administration and configuration or deals with advanced features. As a result, much of this chapter is reference material that you may want to refer to as needed.

19.2 Introduction

The OMG Naming Service (see Chapter 18) permits a client to locate object references by supplying a symbolic name. This mechanism is sufficient for the client to locate an object provided that the client knows exactly what object it wants to use. The analogy with a white pages phone book is that in order to use it, you must know the name of the person you want to call.

Frequently, clients require a more dynamic mechanism to locate objects. For example, a client may have some idea of what kind of object it needs but may not have all the information required to make a precise choice. The OMG Trading Service [21] provides functionality that allows clients to locate objects with the help of a trader. As with the Naming Service, a trader stores object references. However, instead of storing a name for each reference, a trader stores a description of the service provided by each reference. Clients perform dynamic lookup of services based on queries over the service descriptions. This mechanism, known as dynamic binding, enables a more dynamic mapping of selection criteria to object references.

Traders are often likened to a Yellow Pages phone book. Instead of listing services by name, a Yellow Pages phone book categorizes entries by subject and describes each entry with further details, such as name, address, range of products and prices, and so on.

19.3 Trading Concepts and Terminology

Before we look at trading in detail, we present a number of concepts and terms that make the material easier to understand.

713

IT-SC book: Advanced CORBA® Programming with C++

19.3.1 Basic Trading Concepts

Here are some of the fundamental concepts and terms used in trading.

A trader stores advertisements for services. A stored advertisement is known as a service offer. A service offer contains a description of the service as well as an object reference to an object that provides the service. Service offers also have a specific service type, which we discuss in the next section.

The act of placing an advertisement is known as an export operation. The program or person who places the advertisement is called the exporter.

The object reference inside a service offer denotes an object that provides the advertised service. That object is known as the service provider. After a service offer is exported, the service provider is immutable. You cannot change the object reference inside a service offer without deleting the offer and re-exporting it.

The description of the service inside a service offer (the "text" of the ad) is provided by a number of name—value pairs called properties. In contrast to the service provider, property values can be updated in place. There is no need to delete and re-export an offer in order to update a service description.

The same service provider can be advertised multiple times, typically with different property values. Drawing on the Yellow Pages analogy, this corresponds to advertising the same shop or service under different categories.

A number of advertisements can have the same property values but different service providers. This corresponds to a single advertisement that lists multiple shops at different locations, as is often the case with franchises.

Advertisements can be withdrawn, that is, deleted from a trader.

Advertisements can be exported or withdrawn by a party other than the service provider.

The act of searching the trader for a service provider that meets certain criteria is known as an import.

These few explanations give you a basic picture of a trader. At the most basic level, a trader is a database that stores object references that are described by properties. We can export (add) new object references and their descriptions and withdraw (delete) them. In addition, we can update the properties (description) without deleting an offer, but we cannot update the service provider (the object reference) without deleting and re-creating an offer.

19.3.2 Service Types and IDL Interface Types

714

IT-SC book: Advanced CORBA® Programming with C++

Service offers have a type, known as the service type. The service type loosely corresponds to the categories of a Yellow Pages phone book. For example, if we look up tire shops in a Yellow Pages phone book, we expect a certain amount of information that is common to all tire shops, such as name, phone number, address, range of brands offered, and credit cards accepted. The service type of a service offer determines the information an importer can expect to be available—in other words, the properties available to search for tire shops.

The service type can also be compared to a database table definition. If we assume that all service offers of a particular type are stored in a single table, then the service type determines the name, number, and type of the columns in the table. For example, for tire shops we might have a table that specifies columns called Name, Address, Phone, Brands, and CreditCards. The name of the table itself could be TireShops and would correspond to the name of the service type.

The object reference to the service provider that is stored in each service offer also has a type: the IDL interface type. Whereas the service type determines which properties are used to describe particular service offers, the IDL interface type determines the type of object that provides the actual service. For example, the IDL interface for objects that provide a tire shop service could be Shops::Tires. (In older literature, you may see the IDL interface type referred to as the service offer type, which is not the same as the service type.)

You can group service types into hierarchies using inheritance. If an importer requests service offers of a specific type, the trader will return not only matching service offers of the specified type but also service offers that have a type derived from the specified type. In other words, service offers obey the usual type compatibility rules of object-oriented type systems—namely, that a derived type can be substituted where a base type is expected. To protect the importer from surprises, the IDL interface type of a derived service type must be compatible with (must be the same as or be derived from) the IDL interface type of the base service type.

Service types correspond loosely to database table definitions, with one difference: whereas database tables have a fixed number of columns, the trader allows the exporter to export properties for which no corresponding definition exists. This loosely corresponds to exports being able to append additional columns to tables at run time. We discuss this feature in detail in Section 19.7.3.

19.3.3 Service Requests

To search a trader for a particular service, the importer submits a service request to the trader. A service request contains

The service type, such as TireShops

A constraint expression, which controls which particular shops should be returned

715

IT-SC book: Advanced CORBA® Programming with C++

Preferences, which control the order in which service offers are to be returned (see

Section 19.3.8)

Policies, which control non-functional aspects of a search, such as how many offers to return and whether to return the full description of a service or only the object reference to the service provider (see Section 19.3.9)

19.3.4 Constraint Expressions

The most important part of a service request is the constraint expression, which determines the particular tire shops that meet the importer's criteria. Constraint expressions (also called queries) are Boolean expressions over the property values of service offers. In the simplest case, a constraint expression can be TRUE, in which case any service offer (of the specified type) will match the constraint. An example of a more complex constraint is as follows:

Find a set of steel radial tires on offer in the San Francisco Bay area with a speed rating of at least 120 m.p.h., size P205/65R15, made by either Bridge-stone or Goodyear. Make sure that either Visa or MasterCard is accepted for payment.

Of course, the actual constraint is expressed not in English but rather in a formal constraint language (see Section 19.10).

19.3.5 Federation

Federation (or interworking) of traders permits access to very large collections of service offers without the need to store all offers in a single physical database. (The idea is analogous to federated naming graphs.) Federation is transparent to clients (unless they choose to explicitly take it into account); a federated trader appears to the client as a single logical trader, just as a federated naming graph appears as a single logical graph to clients of the Naming Service.

Traders are federated by one trader acting as the client to another trader. For example, suppose a client submits a service request to trader A. Trader A not only searches its own database but also forwards the request to its federated trader B. Eventually, trader B returns its results to trader A, which merges them with its own results and then returns the merged results to the client.

The topology of a trader federation can be arbitrarily complex and is even allowed to contain loops. The OMG specification allows federated traders to implement loop detection so that queries from clients are not forwarded from trader to trader indefinitely.

19.3.6 Dynamic Properties

Normally, the properties in a service offer have a value that is simply stored by the trader. This means that the value of a property does not change unless someone explicitly

716

IT-SC book: Advanced CORBA® Programming with C++

updates it. Such static property values are fine for things such as tire shops because the service being advertised does not change characteristics very often.

In some situations, however, static properties are inadequate. A typical example is trading for shares in a share market. In this case, the different shares on offer are the service offers, and the current share price corresponds to one of the properties of each offer. The problem is that the share price can fluctuate very quickly. If static properties were used to indicate share prices, they would have to be updated frequently (possibly hundreds of times a day) to continually reflect the current price.

To accommodate such situations, traders offer dynamic properties. A dynamic property does not store an actual value for the property. Instead, it stores an object reference to an object that can deliver the current value of the property when the trader evaluates a constraint. The trader calls an operation on the object to get the current property value. Dynamic properties are ideally suited for environments in which property values must reflect rapidly changing information.

Importers are unaware of whether a property is static or dynamic. If an importer asks the trader for the value of a particular property, the importer simply sees the value, whether that value is stored statically or is obtained by the trader invoking an operation on a dynamic property.

Dynamic properties have performance implications because they expose a trader to the implementation quality of objects outside the trader's control. For example, if a trader invokes an operation on a dynamic property reference to get the current value but that operation is slow to complete, the entire matching process slows down. High-quality implementations of the Trading Service take active steps to prevent complete lockup of the service if dynamic properties are slow to return the current value or are unavailable. However, there is only so much a trader can do to protect itself against failure. In addition, by their very nature, dynamic properties are slower to look up than static properties.

19.3.7 Proxy Offers

A proxy offer is like a normal service offer in that it has a service type and contains properties that have values. However, in addition, a proxy offer stores

An object reference to a standardized Lookup interface

A constraint recipe

When an importer submits a constraint, the trader considers proxy offers as equivalent to ordinary offers during evaluation of the constraint. If a proxy offer matches the constraint, the trader constructs a new constraint according to the constraint recipe. The trader then invokes an operation on the Lookup interface stored with the proxy offer, passing the new constraint it has just constructed. Eventually, the operation completes and returns a number of service offers to the trader, which adds them to the results returned to the importer.

717

IT-SC book: Advanced CORBA® Programming with C++

Proxy offers are effectively "canned queries." Their main use is to integrate legacy systems, such as existing databases, into an OMG trader. You can integrate the legacy system by building a front-end Lookup object and by storing a constraint recipe that constructs the query in the back end's native database language.

Another (although unusual) use for proxy offers is to build smart factories. With this technique, a client can create a new object by submitting a query to a trader. It is understood that this query cannot match an existing object but will match an existing proxy offer. When the trader calls the Lookup interface in the matching proxy offer, the implementation of the Lookup object creates an object that matches the client's criteria instead of looking it up in a database. The newly created object is returned to the client from the import operation. From the importer's perspective, nothing unusual has happened; the importer simply went looking for a service and found it. However, behind the scenes, the proxy offer was used to create a new object that matches the client's requirements.

Proxy support is optional, and few trader implementations support proxy offers. For this reason, we do not provide further detail about proxies and constraint recipes in this book. You can consult the CORBAservices specification [21] for further details.

19.3.8 Preferences

A service request made by an importer can optionally include preferences, which control the order in which service offers are returned to the importer. For example, the importer can request that service offers be returned in order of increasing value of a property or that service offers be randomized. Here again is the service request from page 831, modified here with a preference.

Find the cheapest set of steel radial tires on offer in the San Francisco Bay area with a speed rating of at least 120 m.p.h., size P205/65R15, made by either Bridgestone or Goodyear. Make sure that either Visa or MasterCard is accepted for payment.

This service request not only looks for a set of tires that match our requirements but also makes sure that we get the cheapest such set on offer.

19.3.9 Policies

Policies control non-functional aspects of a trader. For example, an importer can use policies to impose a limit on the number of matching service offers that will be returned from an import operation. The specification describes quite a large number of policies; they can be categorized as follows.

Trader policies

Trader policies apply to a trader as a whole. For example, a trader can limit the number of offers it will search during an import operation.

Import policies

718