A sequence of actions to be performed preceding the establishment of a component interaction is called the binding process. This can be achieved by linking to the peer component directly, if its reference is known to the initiator in advance, or establish- ing the binding indirectly, via a third party. In open systems due to their required exibility, the latter case prevails. A trading of service denitions is performed by the Trader in our model.
In traditional systems, the binding process is typically implemented as an inte- gral action inhibiting component customization, and disabling the participation of a third party (e.g., Unix system calls [3], rpc [7], corba [56], etc.) However, in open distributed systems, the binding process requires clearly delimited phases [66] in order to achieve exibility and provide user-customization.
In our model, the binding process comprises the following phases: 1. Exporting service denitions
2. Negotiating service denitions
3. Establishing a communication channel
When a communication channel is established (the third phase is successfully per- formed), the required end-to-end binding takes place. Although this is the nal goal, it is not a part of the actual binding process. In this section we describe these phases in greater detail.
3.3.1 Exporting Service Denitions
A service denition created for a service interface has to be passed to a compo- nent containing a complementary interface via the Trader which nds the requested match. A service export is a process of oering a service (defned by its service deni- tion) to the Trader. A complementary operation, service withdrawal, is a process of removing a service denition from the Trader. Although it is not necessary for the binding process, service withdraw is an essential operation of the Trader. Figure 3.3 illustrates service export, service withdraw and negotiation of service denitions.
Policies
In order to achieve an agreement between components exporting their service deni- tions, policies dening operation semantics must be formulated. An export policy is a set of rules controlling the service export to the Trader including, for example, an obligation for a specic format, permission rules, timeout, etc. The complementary set of rules dening service withdrawal is called a withdrawal policy. In the case of distributed trading systems, these policies must dene the propagation of service export between remote parts of the system.
It is up to system designers to decide whether all three types of policy are enabled. In addition, each particular application should be able to dene and tailor available policies for its components.
Federation
In scalable distributed systems Traders must be networked in order to cooperate on providing remote information. One approach is to form a global trading system that any Trader may dynamically join or leave. Although there are systems requiring global shared information (e.g., distributed database engines, Internet search en- gines), this approach encounters problems similar to designing a global nameserver [37].
As components often interact on a local scale (such as resource managers within a particular domain), an alternative solution to the global trading system is a local trading system. In this case inter-Trader communication must be supported to enable service export for components beyond the local domain. Trader domains with domain-specic security and propagation policy information, internetworking with other Trader domains are called federations. Passing service denitions across the federation boundary, consequently, must be handled by appropriate communication channels reecting the `beyond-federation' distribution and security issues [66].
In Figure 3.2 a trading system consisting of two federations is illustrated.
3.3.2 Negotiating Service Denitions
A service denition (a type and characteristics of the requested binding together with enough naming information to locate the interface, the interface reference) is exported via the Trader. These characteristics form the set of requirements, from both components involved in the communication, which must be met before the binding can be established. A communication channel can only be established if the requested properties of both involved parties are satised.
Rules
When all service denitions are exported into the trading system according to sys- tem policies, the actual matching process takes place. In the general case, it com- prises two phases search and select, dened by the client and the Trader.
Matching rules dene the search operation; they include [67]:
pre-conditions of the binding ensuring that the interaction can be technically
established, e.g., interfaces must be of the same type, and complementary roles (client, server).
a minimal set of requirements of both components (dened by the service
Client Trader Server Client Server Trader Client Server Trading System Federation 1 Federation 2 Inter-federation Interaction
Server Client Trader
Matching process Service Withdraw Export policy
Matching Rules --- SEARCH Preference Rules --- SELECT
Withrdaw Policy Service Export
Figure 3.3: Trading
Matching rules can be formulated exactly, or component requirements can be pa- rameterized (user-customized matching process) enabling a set of dierent service denitions to match the requirement.
Preference rules dene the operation select that extracts one service from a set of service denitions fullling the matching rules.
Service characteristics expressed in terms of parameters typically cannot be lin- early ordered (e.g., Is speed better than resolution?) without preferences expressed by components themselves. Therefore, components using a trading system support- ing this level of negotiation are obliged to express their preferences in terms of preference rules when exporting service denitions into the trading system, per- formed as a user-customized matching process. Otherwise, the select operation must be performed non-deterministically (e.g., rst-t strategy).
In the case of a federation, additional rules and protection checks dening the propagation of exported service denitions may be dened, such as reecting the domain scope, and dening constraints under which a search or select operation may take place beyond federation boundaries.
Figure 3.3 illustrates the negotiation phase of the binding process.
3.3.3 Establishing a Communication Channel
A special component attached to every functional component responsible for cre- ating a communication channel is called a binder. When the required component pair has been found by the Trader (service denitions have matched), client and server binders are invoked to create the requested communication channel. If this task is successfully performed, the required binding is established and components may start communicating.
Communication channels implementing an actual binding may use primitives of varying complexity, from simple message-passing primitives, procedure calls, through dispatchers marshaling functions and parameters, to network protocols. They can be primitive (represented by one functional unit), or composed (featur- ing a sequence of functional units cooperating on the task for example, network
protocols). Bindings might operate locally, remotely within a domain, or between federations.
If the interaction comprises service characteristics, such as QoS constraints, it is the channel's responsibility to maintain the agreed level of service characteristics by constant monitoring of relevant features [46].