ion messages. With our approach, however, the specification of which role plays the initiating role and which role plays the participating role is not integrated in the specification of the subordinate collabora- tions. The initiating party in our approach is the party that receives the trigger and has nothing to do with who makes the first move within the collaboration use. In our approach, the management layer takes care of coordination using role requests. This allows us to loosen the demands on the ordering of initiating and terminating roles in the specification of the subordinate collaborations, as the management layer takes care of the synchronization of roles. We have chosen this approach because our focus is on enabling choice in dynamic service execution, including allowing for one collaboration to be replaced by another collaboration, regardless of which role internal to the collaboration sends the first signal. By decoupling the internal ordering of behavior from the choreography, we are able to enable such substitutions/choices between which collaboration should be executed next. How to Model Dynamic Service Composition Using UML 2.x A UML 2.x activity is commonly used to model a WEB services choreography, capturing interactions from a global perspective [25,26]. The PESM is similar; however, it allows us to define the overall choreography in a dynamic way. Policies and rules are used in Chun [27] for discovering and finding compatibility to gener- ate service flows in dynamic composition of Web services. In automatic WEB ser- vices composition, software agents perform composition based on predefined algorithms [28]. In rule-based service composition approaches, constructs are pro- vided for specifying processes by means of sets of rules. Rules are used in the Web services composition approach to drive the process of service composition and govern service composition [29]. As in our approach, the rules are based on the so- called event-condition-action paradigm [13]. While there are similarities to o