haracteristics of the SIP protocol: synchronous interactions and a protocol that is not just question- response like HTTP, which implies that most of the cache infrastructure will not Service Delivery Platforms be reusable. Under this consideration it may not be able to deploy real SIP services integrated into an operator infrastructure into a public or hybrid (mixing public and private infrastructure) clouds. This does not mean that there is no a place for the cloud computing paradigm and technology into the IMS architecture. The Service Brokering Layer may be the right interface where to interconnect a cloud service with the in-company SIP communication infrastructure. Under this approach, it is possible to offer SDP capability to other operators using the Cloud computing paradigm and business model. For example, for a vir- tual operator, it can be offered a "pay as you grow" model or even not paying for the "Infrastructure as a Service," but for "SDP as a Service" where virtual operators or those which have still not deployed the SDP may pay for the capability of imple- menting the services provided in the SDP. In this line of work, it is quite important to enable the creation of mash-ups by third parties with the virtual services offered. This is why now the WIMS 2.0 pro- posal is even more interesting. IT will provide a standard way of joining both worlds with the right set of APIs coming from the Telco world, also allowing implement- ing the Web 2.0 needs. 3.4 WIMS 2.0 SDP in the Cloud Previous sections have shown how a traditional SDP can be migrated to a cloud computing architecture. This section provides the strategy to follow in the way of moving the real WIMS 2.0 SDP to the cloud. As it has been exposed in Section 3.2.6, the different entities that compound the WIMS 2.0 SDP have been placed in existing or new entities under the tradi- tional SDP architecture. Analyzing the proposal for migrating, a traditional SDP to a cloud computing architecture done in Section 3.3, it is understandable that the migr