We investigate, in a process algebraic setting, a new notion of correctness for service compositions, which we call strong service compliance: composed services are strong compliant if their composition is both deadlock and livelock free (this is the traditional notion of compliance), and whenever a message can be sent to invoke a service, it is guranteed to be ready to serve the invocation. We also define a new notion of refinement, called strong subcontract pre-order, suitable for strong compliance: given a composition of strong compliant services, we can replace any service with any other service in subcontract relation while preserving the overall strong compliance. Finally, we present a characterisation of the strong subcontract pre-order by resorting to the theory of a (should) testing pre-order.M. Bravetti and G. Zavattaro 602 than orchestrations. Indeed, orchestrations require the implementation of central points of coordination, while choreography languages support a high-level description of peerto-peer interactions among services that directly communicate without the mediation of any orchestrator. More precisely, the aim of choreography languages is to support the high-level description of systems that should be actually implemented as a combination of autonomous, loosely coupled and heterogenous services. One of the most challenging problems concerned with high-level specification languages for service composition is related to the discovery of available services that, once combined, are guaranteed to implement the specified system correctly. In order to solve this problem, two aspects must be addressed: on the one hand, appropriate interface languages that describe the externally observable behaviour of services must be defined; while, on the other hand, retrieval mechanisms must be developed such that, given a composition of services exposing certain interfaces, the overall behaviour of the system is guaranteed to be in accordance with the given high-level specification.As far as interface languages are concerned, the attention of the research community is concentrated on contracts, which are intended as the description of 'the externally visible message-passing behaviour of the service' (Fournet et al. 2004). Several papers have already investigated contracts (Carpineti et al. 2006;Bravetti and Zavattaro 2007a;Laneve and Padovani 2007;Castagna et al. 2008), exploiting them for checking service compliance. Services are compliant when they can be correctly combined in such a way that all the service invocations of one service in the system are guaranteed to be eventually served by another service in the system.For instance, the following three services S1, S2, and S3 are compliant:S 1 : invoke(a@S 2 ); receive(b) S 2 : receive(a); invoke(c@S 3 ) S 3 : receive(c); invoke(b@S 1 ).We use invoke(a@S) to denote the invocation of operation a on service S, and receive(a) for the reception of an invocation on operation a. According to this notion of compliance, the following is also an example of compliant s...