The TORBA Definition Language (TDL) is the formalism to define TORBA trading contracts. Using simple typed constructions, it describes offer types, their inheritance relation, their properties (name and type), as well as query operations (name, parameters, and constraints). Property and parameter types rely upon the OMG IDL type model. Constraints are defined using the OMG Constraint Language (OCL) extended to take into account query operation parameters as well as to offer composition of query operations. TDL is defined as two languages: an XML DTD and a BNF grammar. This paper only describes the second one, being more concise and quite familiar to CORBA users. Figure 5 presents an example of offer type definitions.
A trading offer type is defined using the offer keyword followed by the type name, and possibly the list of inherited super-types. Basically, a type is concrete: provider could export offers using this type. Then, it has to include an interface entry defining the base interface to be supported by exported objects. The abstract keyword defines a type as being abstract, no offer may be exported for this type. It will be inherited to define concrete types. The TDL contract of Figure 5 defines two offer types related to the printer example of this paper: The Printer concrete type inherits from the Device abstract type, and specifies offers for objects implementing the PrintService interface (or one of its sub-interfaces). Properties are defined using the property keyword followed by an optional access mode, an OMG IDL type, and a formal name. If undefined the access mode is normal (see section 2.2).
The Printer offer includes the four following properties: the name string inherited from Device, the color boolean, the cost_per_page float, and the ppm unsigned short. Search operations are defined using the query keyword followed by a name, potentially a list of arguments (defined as for OMG IDL operations), and a constraint. The constraint is based upon the properties of the offer type (e.g. the colors() query), the properties and the parameters (e.g. the faster() query), or a composition of query operations (e.g. the faster_colors() query). The all() query is defined with TRUE as constraint in order to retrieve all the available offers for the Printer type. Query operation inheritance has the following semantic: The constraint is kept, however it does not apply on the super-type, but on the inherited type. The operation implementation is implicitly overloaded in generated proxies. When applied to the Device type, the all() operation returns all the available device offers. When applied to the Printer type, it only returns the available printer offers.
Defining specific queries for given values of properties should not be misused. The point is not to define a query for any potential property value, but to define the most commonly used queries. For queries that may appear from time to time only, the generic query operation available with all types has to be used (see section 3.3.1). Nevertheless, using the generic query() generated by TORBA already brings type checking and reduces the technicity of the lookup mechanism.
Two constraints are implied by the use of TDL contracts. First, like OMG IDL contracts, TDL contracts have to be globally known to clients. Moreover, the type hierarchy of TDL may be extended but has to stay consistent, i.e. no TDL contract should be removed nor modified. Second, each TDL contract has to be defined using an identifier being unique in the whole system. Here too, like OMG IDL definition it is important for designers to define their TDL contracts using modules in order to avoid name collisions.
This section has presented the second TDL formalism (BNF grammar), being simple to learn. This basis will be extended according to the need arising from our experiments. As an example, dynamic properties specification, whose values are computed at runtime and not statically set at exportation time, seems an interesting extension. However, it is important for this language not to become too complex and underused due to this complexity.
