nstruction and processing. Most Internet players providing functional- ities via API are adopting this best practice, offering client libraries in a limited number of programming languages and also the bare REST interface with different data formats available for those programmers utilizing other programming lan- guages besides those considered by the client libraries. For instance, the Telecom Exposure Layer should offer client libraries in JavaScript and ActionScript languages for client-server scenarios, and Java, PHP, Python and Ruby for server-server scenarios. For developers utilizing other lan- guages, they still can access the functionality by handling the REST APIs directly. 3.2.6 WIMS 2.0 SDP Deployment Previous sections have shown the reference model of the WIMS 2.0 SDP. In order to deploy onto the service delivery domain of an operator, it is required to analyze how the different entities of the WIMS 2.0 reference model can be either imple- mented by existing entities in the telecom Service Architecture or how new ones- specific for WIMS 2.0-fits into the service delivery domain. Figure 3.5 shows the functional entities of the WIMS 2.0 reference model that are new in the service delivery domain of an operator (IMS thin client, UGC 2.0 platform, IMS PSE 2.0 Moving the SDP to the Cloud flickr You Tube Web 2.0 Services/users ost-fm facebook Third party PSE PSE PSE application server UGC 2.0 Subscription platform IMS thin Management IMS PSE 2.0 client Event/ platform Service application UGC gen Content layer Distribution Integrator towards Service integration parties layer Integrator towards SOA components SDP OSS/BSS Intelligent API gateway IMS exposure layer Service exposure Network layer (SCP, SDP, Common Non-IMS enablers enablers IMS enablers (user profile, user Service enabling (browsing, equipment profile) (presence, push-to- layer messaging, talk, converged content User profile messaging, etc.) download, etc.) ID& Prefs Service brokering SCIM / Service broker layer Common Core IMS Service control s