More than presenting the main operations provided by the ODP/OMG CosTrading service to type and search offers, this section outline the drawbacks of these functions. First, the CosTrading service does not provide a definition language to define offer types. Such a language is mentioned in the CosTrading specification, however only for an illustrative purpose. The service only relies on the use of a type repository used at runtime. Then, the technicity and complexity of this service have been discussed. In order to benefit from the CosTrading service, it is necessary to master the use of operations like query and data structures provided by the service. Finally, using strings to manipulate properties implies runtime type checking and forbids type checking at compilation time. This reduces the easiness to produce reliable applications in an efficient way. To summarize, as any CORBA service, the CosTrading service only offers a set of complete OMG IDL interfaces. This brings the following four questions.
Looking at today's software industry, three answers arise. First, a GUI could be provided to use the trading service easily. This solution is already available for many trading service products. Nevertheless, this choice does not address the use of the trading service from an application. Then, a library may hide the trading service complexity. However, providing such a library is a huge task: It would be easy to suffer the same drawbacks as the CosTrading interfaces. Moreover, it would only define a programming framework, but no design method, nor language to specify offer types. Finally, a trading function, to be specialized to each application needs, could be defined using the concept of trading contract as discussed in the following section.