ress the composition strategies. We have chosen event-condition-action declarative policy rules [4,7]. There are two main reasons for this choice. First, it is natural to use signaling in order to set up a service session involving a set of com- ponents. As signaling is an event-oriented activity, an event-driven model is a natu- ral candidate for notifying distributed components of changes that occur. Second, specifying the declarative policies separately from the behavioral specifications of the various service parts results in more freedom for the dynamic composition with respect to which separately specified behaviors to compose. In our approach, events specified as policy triggers are monitored, and these events are used to trigger the evaluation of one or more policy rules. We allow for policy rules with the same trigger to have overlapping conditions, SO that more than one of them may be true at a given point in time. If this is the case, then the choice between which one of the possible actions to be performed is made nondeterminis- tically. This means, that if the conditions of a policy are matched, then the action specified by the policy rule may be executed. For deploying the approach in the runtime system, an architectural model for the policy-enabled dynamic composition system, and a process for runtime dynamic composition using the policy-based approach are required. For the architecture, we have been inspired by the Poema [8] approach, although in Montanari et al. [8], the policy-managed adaptation is used for dynamic re-configuration of Mobilcode applications specifically, and not to enable the dynamic composition of services in general. The Chisel adaptive process described in Keeney [9] provides a guide for defining a process for runtime dynamic service com- position. However, the actual way that the adaptation is performed in Chisel involves manipulation of the existing behavior in the system, using metatypes to adapt exist- ing objects. In our approach, we do not change the existing building b