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

Both the search cardinality and the hop count policy were introduced with these concerns in mind. The aim was to provide importers with at least some means, however inadequate, of limiting the propagation of a query.

19.17 Trader Tools

The OMG Trading Service specification does not place any requirements on implementations with respect to tools. Nevertheless, most vendors provide at least a minimal set of tools that allow you to administer a trader and to manipulate its offer space. Typically, traders provide command-line interfaces that allow you to change configuration values, maintain the service type repository, and add and remove service offers. Some vendors also provide graphical user interfaces that allow you to conveniently view and update the contents of a trader.

Because tools are outside the scope of the specification and differ from vendor to vendor, we do not cover them here. However, you should become familiar with the tools provided for your trader.

19.18 Architectural Considerations

Now that you have seen what a trader can do, an interesting question is, how should you use it? As with the Naming Service, there are a number trade-offs.

As soon as you make the decision to use a trader as part of your application, you gain a number of advantages.

The trader provides a standard way to dynamically select objects based on complex criteria. Because it is standardized, the trader is widely understood as an architectural component of CORBA. If your application requires some form of integration with applications from other vendors, using a trader instead of a proprietary mechanism makes such integration easier.

A trader is very efficient at evaluating constraints, and you can use it to run queries on large numbers of objects without generating significant messaging overhead.

A trader is a flexible tool and is suitable for use by many diverse applications. The cost of using a trader is typically far lower than the cost of developing a separate applicationspecific mechanism for object selection for each application. If selection criteria or policies change over time, applications are easily modified because a different constraint often is sufficient to implement the change.

Dynamic properties provide a way to easily build systems that are highly flexible and that dynamically adjust their behavior. For example, you can create dynamic properties that report the system load on different machines to select a service on the machine that has the lowest load.

784

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

Traders permit you to advertise objects by criteria that are unknown to the objects themselves. Even though at least some properties are likely to reflect object state, we can add other criteria that are not part of an object's state. For example, we might choose to add properties to controller advertisements that describe the size and color of the physical cabinet. This approach adds an extra degree of flexibility because we can change the way objects are advertised without changing the objects themselves.

We believe that traders will continue to grow in importance as an architectural component of distributed systems. A trader's role in a distributed system is similar to that of a search engine for the Web. Traders are general-purpose information brokers and are suitable for a variety of commercial purposes. In particular, trading for easily described commodity items, such as shares and CDs, is likely to become more and more important. In addition, with appropriate service type definitions, traders can form the basis for applications such as on-line browsing of catalogs and other electronic commerce applications.

On the other hand, using a trader forces you to deal with many of the same issues you must deal with when using the Naming Service. Often, the most significant issue is reliability. Adding a trader to your application design adds a dependency on another system component that might fail. This exposes your application to the reliability of a component outside your control, and you must anticipate and deal with failure of an independent component. For many applications, it is sufficient to give up or to simply refuse service if their trader is non-functional. However, in more demanding environments, you may have to create sophisticated error-handling and recovery strategies to deal with failures in an acceptable way.

Performance and scalability also may be important to you. Even though you may have a trader that meets your reliability requirements, this does not mean that it can handle the query throughput your application requires. Similarly, a trader may work fine with a few dozen service types and a few thousand service offers, but its performance may degrade unacceptably if you have hundreds of service types and hundreds of thousands of service offers.

You may be tempted to use a proprietary mechanism for object discovery for performance reasons. Often, a custom-built search mechanism that is part of the application is faster than a general-purpose trader. For example, we can view the find operation in the climate control system as a special-purpose trader. The advantages of building our own object discovery operations, such as find, are that we remove the dependency on the trader and that we can make the find operation arbitrarily fast by using appropriate data structures. Implementing find with the help of a trader will likely be slower because the trader uses general-purpose data structures instead of something that is highly optimized for specific queries.

On the other hand, operations such as find are very inflexible. Whenever we want to change the criteria by which we locate objects, we must update the code and possibly even change the application's data structures to support the new search criteria efficiently.

785

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

As soon as we require any degree of flexibility in the way clients search for objects, a trader is likely to be a better choice than tailor-made search operations because of the effort that is required to build a general-purpose search engine that supports a flexible query language.

When you are using a trader as part of an application architecture, a common mistake is to treat it as a database. Even though a trader has many database characteristics, it is not a general-purpose database. For one thing, traders are typically optimized to deal efficiently with the most common import scenario, in which the importer selects a single matching service offer. If you routinely use a trader for queries that return large sets of service offers, you may find that performance or memory consumption of the trader becomes a problem.

Second, a trader is unreliable in the sense that it can give incomplete answers. For example, the max_search_card and max_return_card policies can cause arbitrary truncation of query results. In addition, in a federation, one or more traders may be down or the max_hop_count policy can prevent searching of the complete offer space. A database guarantees either to return all matching results or to return an error indication. A trader, on the other hand, can silently return partial results. Do not create designs that rely on a trader for complete answers. If you require complete knowledge of matching data, you must use a database.

19.19 What to Advertise

Your application requirements determine which objects you should advertise. As with the Naming Service, the prime candidates are bootstrap objects and objects that are public integration points for your application. Typically, you will create the service types required by your application only once: during installation of the software. If you have singleton objects such as a controller, you might also create the service offers for these objects during installation (possibly using a command-line tool, which saves you having to write a separate client to do the exports).

For objects that support explicit life cycle operations, such as thermometers and thermostats, it is probably best to tie export and withdrawal to the create and remove operations to avoid leaving stale service offers in the trader. This also means that you must have a strategy of dealing with the situation in which the trader is not available at the time an object is created or destroyed.

If your objects have short lifetimes, it is probably best not to advertise them in the trader at all. In addition, service offers in the trader should have properties that change only rarely because that means you have less overhead in keeping the property values up-to- date. If you use properties that reflect writable object state, a good strategy is to have each object implementation update not only the object state but also the service offer. In that way, you minimize the likelihood that object state and property values will get out of sync. Another option is to use dynamic properties, but this requires more development effort and reduces query performance.

786

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

19.20 Avoiding Duplicate Service Offers

One tempting strategy for ensuring that service offers are always present and up-to-date is to have the server automatically export the service offers for its objects on start-up. There is nothing wrong with this strategy, but you must be aware of a somewhat surprising behavior of the trader: if you call export twice with exactly the same parameters, the trader makes no attempt either to reject the second call or to update the service offer created by the first call. Instead, calling export twice with identical parameters results in two distinct service offers with identical contents.

You may think this behavior strange—after all, the trader could reject an export operation if it already holds a service offer with the same information, so why do this? The answer is that this behavior may be exactly what is desired. Consider commercial television. It is not uncommon to see the same advertisement multiple times during a movie or even twice in the same commercial break. Obviously, the advertiser believes (rightly or wrongly) that this practice has a positive effect on sales.

Now translate this into a trading environment where traders are used as brokers for commercial purposes, such as advertising bookstores. It is likely that each bookstore pays the trader operator a fee to place its advertisements. An aggressive bookstore may place multiple identical advertisements to increase its chances of being selected during an import operation. Alternatively, the bookstore might have an agreement with the trader operator that ensures that its advertisements will be returned for at least 70% of matching service offers.[5] Such agreements are not uncommon in the commercial world. In a trading context, they are equivalent to showing the same TV advertisement multiple times or paying for a full-page advertisement in a newspaper instead of a quarter-page advertisement.

[5] Note that setting the preference for a query to random does not necessarily change this. The specification requires the matching service offers to be randomized with this preference but does not state that the randomization function must be without bias.

The point is that the trader specification cannot impose a notion of fairness on service offers—and therefore cannot reject duplicate offers—because what is fair depends on the environment.

For many applications, duplicate service offers are undesirable. For example, if we blindly export a service offer for the controller every time the server starts up, we end up cluttering the trader with lots of duplicate service offers for no good reason. Worse, if we updated the controller's offer, we could forget to update some of the offers and leave different offers having different property values for the same controller.

There is a simple technique for avoiding duplicate service offers. Instead of blindly exporting the service offer every time the server starts up, we can remember the offer ID that was returned by the previous export. On start-up, we call describe to see whether the offer still exists. If the offer has disappeared for some reason or has not been exported previously, we export the offer and remember the offer ID returned by that export.

787