Comparison and Source of Inspiration

During the 80's, the ODP community has defined a type management system for the ODP trading function [10]. This research result has been partly integrated in the ODP / OMG CosTrading specification. However, to our knowledge, no similar works to our TORBA proposal have been performed to reduce the CosTrading complexity and to increase reliability of trading based applications. The trading aspects of ODL (Object Definition Language) defined by the TINA consortium [22] were only related to defining trading properties of objects. This could only be seen as basic trading contracts : attributes are inevitably strings and ODL do not permit to define typed queries. Thus, the complexity of the trader's use is not reduced actually. In the meantime, our original work relies on the use of well-known mechanisms of distributed object computing middleware: the proxy principle, the ORB structure, and the component approach.

The proxy principle has been defined in [23] as a structural concept to build distributed applications, acting on the behalf of a remote object. This principle extends the RPC (Remote Procedure Call) mechanism as defined in [3] in order to use it in an object-oriented context (i.e. Remote Method Invocation). At the communication level, a proxy (a.k.a. stub) serializes invocations to remote objects like in CORBA [19], DCOM [8], and Java RMI [24] environments. Such a proxy implementation fully hides the technicity related to the serialization process: marshalling of parameters into a network message, care taking of heterogeneity, network layer and error management, and finally unmarshalling the network reply to application data. These proxies are generated based on communication contracts written using an interface definition language (IDL). These IDL descriptions simplify and bring automation to produce the implementation of communication means, increasing the reliability of applications. In the context of TORBA, the communication contract concept, the IDL language, and communication proxies are transposed to trading contracts, the TDL language, and trading proxies. Thus, TDL descriptions simplify and bring automation to produce code related to trading, increasing application reliability.

Compared to smart proxies used in the Quality of Objects (QuO) middleware [30], or as implementation of meta-programming mechanism [29], TORBA proxies cannot be labeled as smart. In these two examples, smart proxies are proxies that potentially perform more processing--like logging, caching, QoS control, or meta-programming--in a transparent way from the client point of view. Extra processing is added to the standard one, without modifying the proxy interface. In the context of TORBA, proxies have an explicit interface which is different from the classical interface of the CosTrading. Moreover, smart proxies tend to offer dynamic mechanism for reconfiguration while TORBA proxies are quite static, and could not be changed dynamically at runtime.

TORBA is close to CORBA. The OMG IDL language permits designers to describe interface contracts for CORBA objects, while the TDL language permits them to define trading contracts. The OMG IDL language is compiled to produce communication stubs, or to feed the Interface Repository. Similarly, the TDL language is compiled to generate trading proxies, or to feed the trading contract repository. CORBA stubs rely on an ORB runtime, encapsulating the GIOP/IIOP protocol, while TORBA proxies rely on the TORBA runtime hiding the CosTrading service, as well as the ORB.

The component-oriented approach is the last source of inspiration of the TORBA proposal. As an example, the CORBA Component Model [18] defines a component as being a software entity providing multiple interfaces (or facets). Each facet is a point of view on the component, which logically defines a set of operations. In that, TORBA provides access to the generic ODP/OMG trading service through facets dedicated to application requirements. Each lookup proxy generated is a dedicated facet being a point of view on the trading service as depicted in Figure 13.

Figure 13: TORBA, towards a `componentized' trading service.