As this paper focuses on the search process, the drawbacks of the export process are not discussed here. However, these drawbacks are similar to those presented in this section.
Once offers have been exported by servers, their references and properties could be retrieved using the CosTrading search operation. Figure 3 presents its Lookup interface used to perform searches. The query operation allows clients to find back services from the set of exported offers. The argument number of this operation is quite high. This is due to the genericity required by the operation in order to be usable in a wide number of applications.
The type parameter defines the offer type required by the client application. The constr parameter contains a constraint to be matched by the properties of selected offers. This constraint is a string containing a boolean expression written using the OMG Constraint Language (OCL). The pref parameter specifies the returned offer order in OCL. The policies parameter specifies the strategies to be used during the search. The desired_props argument contains the properties to be returned for each offer to the client: none, all, or only specific ones. As there may be a huge number of matching offers, the how_many argument fixes the maximum number of offers to be returned. Following offers could be retrieved later on using the offer_itr iterator provided by the operation. Finally, the two last out parameters contain, after processing, the result (offers) and the limits effectively applied to the search policy (limits_applied).
Furthermore, when providing wrong parameter values, the query operation raises one of the ten listed exceptions. Such exceptions mean a misuse of the CosTrading service related to search strategies or to its type model, like an illegal or unknown type name, a badly expressed preference or constraint, or an unknown property name. Thus, the CosTrading service only checks requests at runtime, while type checking could be performed at application compilation time, improving both software quality and service performance--avoiding runtime type checking. At the moment, TORBA, as discussed in the following, mainly addresses type checking at application compilation time.
Figure 4 presents how an application, written in OMG IDLscript1 [21], may retrieve offers about color printers faster than two pages per minute. The offers, iter et limits variables are initialized to receive the query() operation results. The offer type, property constraints, and the result order are provided as strings. Thus, it is up to the CosTrading server to check and to evaluate these strings in order to perform the search, implying type errors to be only discovered at runtime.
The simplicity of this excerpt relies on the use of the OMG IDLscript language. However, a real application has to set the search strategy, catch and process the potential exceptions, and process the returned results. The latter includes the offers sequence processing, and potentially the use of the iter iterator to process the following offers. Thus, about fifty lines of Java or C++ are required only to obtain the list of color printers faster than two pages per minute. In that, we claim that the query operation is complex and very technical to use. Moreover, the huge use of this operation forces applications to build, invoke, and process many trading requests, introducing code complexity and potential runtime errors. Section 3.3 discusses how TORBA automates this trading related technical code production to simplify application code.
