Who Makes What: RESTful Service Delivery Platforms
If apps are the new POTS, SDPs are the new digital switches. So who's making them?
March 8, 2010
Service Delivery Platforms (SDPs) for mass-market Web Services are now being routinely spotted around the globe as the first waves of big telecom service providers embrace the technology as a mainstream approach to build and expand their infrastructures. Recent examples from 2009 include Globe Telecommunications in the Philippines, TDC A/S (Copenhagen: TDC) in Denmark, and Telefónica SA (NYSE: TEF)'s entire Latin American operations.
And, inevitably, has come the global industry initiative to make it all official and boost the case for applications. In this case it’s the Wholesale Applications Community (WAC) , which “aims to unite a fragmented marketplace and create an open industry platform that benefits everybody – from applications developers and network operators to mobile phone users themselves.”
Launched during the hoopla of Mobile World Congress in February, the WAC so far embraces 24 service providers and three mobile device vendors, all big names in the mobile business. (See MWC 2010: Operators Form WAC Pack for Apps Push.) So it is serious stuff.
It’s them again
As is often the case with telecom services, much of the initial impetus for this movement has come from outside the telecom industry. Service providers generally have watched agog as Apple Inc. (Nasdaq: AAPL)’s iTunes AppStore has hit stratospheric levels of downloads and applications choice, as millions of users have demonstrated that, at last, here is something that they are prepared to buy in quantity – and something that telecom service providers could offer, too.
Certainly, the expansion and impact of Apple’s AppStore has been phenomenal. From its launch in mid-2008 it had grown to over 140,000 third-party applications by 2010, generating around 2 billion downloads (and numbers of dollars of the same order). According to AdMob Inc. , which serves banner and text-link ads on mobile Web pages for more than 15,000 mobile sites and applications globally, in December 2009 36 percent (about 1.5 billion) of global ad requests on its network were made by iPhones or iPod Touch devices, with the majority of requests due to apps.
“Major carriers have gone with SDP initiatives in the 2008/9 timeframe, whereas in 2007 they were still kind of scratching their heads and asking whether there was really a business case, and would people really use these applications,” says Joe C. Dyoub, worldwide solution manager for the HP Inc. (NYSE: HPQ) SDP Service Governance Framework (SGF). “What Apple did was to make a lot of those naysayers in marketing departments into believers. Now they view data services and apps as a proven, lucrative market moving at warp speed – now we have to do something.”
For Dyoub and many others in the telecom industry, that something is now obvious: Carriers and service providers need to exploit their network and IT assets and capture more of the service or application value chain. Indeed, Service Provider Information Technology (SPIT) is it. (See The SPIT Manifesto.)
Apple’s AppStore, for example, shares the application value between Apple and the developer (an agency business model), while the carrier receives only its normal data-service revenue – and data service plans being bid down by the carriers as they scramble for market share of these new, innovative devices on their respective networks.
“Many of our customers realize that, long term, that is not the best strategy for the communication provider. They would like to get to a more controlled environment where they can add their own value, their own differentiation to the subscriber experience,” says Dyoub. “And an SDP, because of its services-oriented architecture, RESTful Web 2.0 service exposure, and ability to bring in [telecom things] like location services, billing services, charging – whether prepay or postpay – and subscriber persona will help to differentiate the carrier from just being a pure bit pipe and hosting over-the-top services.”
In short, SDPs are a central component in the transformation of telecom network providers into more complex value-added service and application providers.
The exposure problem
But, if telecom service providers are going to steal Apple’s thunder by using SDPs to create their own agency business models with app developers and achieve differentiation by allowing telecom/subscriber attributes and capabilities to be included in apps, they have some problems to overcome. Primarily, developers need to master telecom APIs that give access to network capabilities, and these are notoriously recondite to non-telecom software developers. Further, there is a host of security, performance, and other issues to address before the engineering department will allow hordes of third-party developers loose on the communication provider’s network.
The access aspect is further complicated because just about every operator that already exposes its network capabilities to third-party developers has, for historical and business reasons, taken a different approach. Some are already based on SOAP/XML interfaces, while others have used Parlay X, or native interfaces, XML interfaces like the LIF MLP standard for location, and others use their own SDKs. But REST (Representational State Transfer) – hence RESTful as an adjective – has now emerged as an API approach that is very easy for third-party developers to use, as it is based entirely on a restricted set of widely used and understood standards – basically, HTTP.
“RESTful SDPs are fast becoming the preferred method for accessing subscribers and resources for a given service provider,” says Jaime Palmer, senior director of technology for BroadSoft Inc. “Primarily because it is lightweight, does not require advanced software development skills and permits for rapid application development. This is in contrast to other protocols such as SOAP that are still widely used, but better suited to perform transactional messaging such as provisioning or back-end systems integration.”
So SDP vendors now have a strong motive for making their products RESTful, and this Who Makes What thus takes a look at what this means for SDP products and their vendors’ approaches. However, caution is needed, because SDP is a very elastic term and can embrace a wide range of functions and, therefore, hardware and software products to implement them.
“More and more what we are seeing is that operators are creating a service delivery platform which is not a single box; it’s a complete environment based around an integration technology,” says Graham Cobb, director of service delivery marketing at Telcordia Technologies Inc. “Telcordia and companies like us supply the real-time systems that enable interactive services, whilst IBM or Oracle are building those environments and putting in some basic components such as a gateway function. Then services and service enablers are exposed, noting that one man’s service is another man’s enabler.”
So readers should resist the idea that an SDP is necessarily a single, well defined product like a server/software combination that can be ordered from a catalogue. And even if some can be, there are all the associated requirements for BSS/OSS, data management, charging/billing, e-commerce, ads, customer management, personalization, and so on that are needed to make third-party applications fly in a commercial environment.
The lack of a product archetype is somewhat unfortunate for a Who Makes What, and so the approach taken here is to take a fairly relaxed view as to what is, or is not, a true SDP, and to consider a fairly broad span of types of SDP and SDP-related products. Preemptively, the answer to your PR firm's "Why isn't my client's box/solution/magic dust included?" will have to be, for now, 'I dunno.' "
Here’s a hyperlinked contents list:
Page 2: What I – SDPs
Page 3: What II – RESTful Technology
Page 5: Vendors & Products
Page 6: Vendor Angles & Activities I
Page 7: Vendor Angles & Activities II
Page 8: Vendor Angles & Activities III
— Tim Hills is a freelance telecommunications writer and journalist. He's a regular author of Light Reading reports.
Next Page: What I – SDPs
SDPs have evolved a long way from their early first incarnations as custom-build IT projects undertaken by systems integrators for operators keen to sell ringtones, games, and other simple static content to customers as part of a walled-garden approach to new-service development. SDPs then moved towards a more product-based approach, with vendors offering specific solutions, and this approach in turn came under the spell of the Telco 2.0 movement – the idea that telecom service providers should mimic the Web 2.0 model and open some of their network capabilities to third-party application developers, even to those wholly outside the telecom industry.
Heavy Reading chief analyst Graham Finnie weighs in on IT's fundamental role in the "new" telco in this interview:
{videoembed|188658}At this point the story becomes a little Biblical, because the standards bodies had been on the general case for some time, and, notably, the industry’s Parlay Group (founded in 1998) had already produced a set of developer APIs for some basic telephone-network capabilities, such as call control and SMS. But these were deemed too complex for general developer use, and so Parlay begat Parlay X, a set of simpler APIs based on a SOAP-style of Web Services, which is a very well known and widely used technology in the enterprise world for enabling distributed applications in a Web environment. But there are still complexities around SOAP, and Web developers do not necessarily need all the features of a SOAP-based interface.
So more recently there has been the eruption into the telecom SDP world of the even simpler REST-based interfaces, which, in SOAP terms, are pretty lightweight and to which large numbers of third-party developers have become accustomed because of the central role that REST plays in the Web 2.0 economy – the Web being essentially a REST-based system. Many Web-based service providers and businesses, such as Amazon.com Inc. (Nasdaq: AMZN), Facebook , Flickr, Google (Nasdaq: GOOG), RememberTheMilk, and Twitter Inc. , provide REST-based interfaces. Examples are OAuth and OpenID for authentication and identification. And the combination of REST with technologies like Ajax allows browsers to support very sophisticated applications that scale well over large numbers of users. The latter is very appealing to telecom operators with large consumer markets, as these tend to be heavily browser based.
What SDPs do
To create an API, RESTful or not, it is necessary to know what the system to which it gives access does. This is where the elasticity of the term SDP becomes obvious, as vendors differ somewhat on this point.
A common buzzterm in the SDP world is communications service providers (CSPs). These are the people buying (or ought to be buying, as the industry sees it) SDPs – telcos, network operators, service providers of various sorts, and so on – and a point of the term is to emphasize that this part of the telecom environment is very diverse, and not only in terms of players. Networks may be IMS or non-IMS, fixed or mobile; CPE may be very smart or pretty dumb; and a core aim is somehow to bring all this together and leverage the capabilities into the new area of applications, in-house or third party. So the range of functions and capabilities of an SDP can be very broad.
At base, there has to be some kind of application server, real-time and carrier-grade for the heavyweight CSPs, that supports service creation and execution across a range of network technologies. So it has to expose various network functions and capabilities to the developer, which may be internal or external to the CSP. But the resulting application or service has to be managed in a great many ways – advertised, sold and provisioned to customers, charged, billed, revenue collected and redistributed between CSP and developer, and so on. And developers and CSPs need to be supported with software development kits (SDKs) and libraries, community forums, and so forth.
All this takes the SDP well into BSS/OSS territory and beyond, with the further complication that the SDP has to be accommodated within existing and next-generation network architectures, and to the migration paths between them. So it is not surprising that an SDP is not as straightforward a product class as, say, a router or Ethernet switch is, and that vendors may emphasize some aspects more than others. For example, some SDPs are currently focused on particular types of CSP (such as mobile operators) or market type (such as enterprise VoIP and Unified Communications) and are used for internal, professional telecom use, rather than for exposing network assets to miscellaneous third parties. Such SDPs can be offered as managed services to CSPs looking for a way of responding quickly to market changes but without having to provide large capital investment and operations support.
Thus, in her Light Reading Services Software Insider, "Telco App Servers: NGIN Revs Up for a Serious Run at SIP" (August 2009), Caroline Chappell observes that:
The SDP is still shrouded in an element of market confusion. Some vendors maintain that a telco app server and an SDP are the same platform... Certain vendors continue tightly integrating SDP function with their telco app servers. Some NGIN [Next-Generation Intelligent Network] platform vendors implement one or two SDP functions, such as charging, subscriber policy, and preference management, as IN applications running on their telco app servers. Other vendors with hybrid Java EE/SIP Servlet app servers argue that this function should be regarded as part of the OSS/BSS and orchestrated as part of operational business processes, such as order to cash.
However, she reports that a mainstream view is beginning to emerge (reflecting that of IT vendors and systems integrators) in which an SDP is distinct from a telco app server and provides management functions across the service lifecycle. This means that the SDP orchestrates common management functions (including OSS/BSS functions) to support the lifecycles and operational needs of different types of services, whether communications services running on telecom app server(s) or content services and software-as-a-service (SaaS) applications hosted on behalf of third-party service providers or developers. Table 1 shows what this means in practice.
Table 1: SDP Common Functions
Area | Functions to |
Services | Provision, assure, rate, charge, and bill for new services; analyze and report on service metrics, such as service usage; and change and retire communications services/service features |
Service onboarding | Manage the onboarding of new services developed by third parties, including applications that use an operator's exposed assets. The onboarding process involves interactions with multiple operational systems, from finance and accounting, settlement, and provisioning systems, to identity management and third-party relationship management systems |
Subscribers | Manage subscriber access to communications services, using rich subscriber policies and preference data to personalize service experience |
Devices | Manage the delivery of services to different devices |
Third parties | Support portals for different service-layer communities of interest, including developers, service partners, and service consumers (for example enterprise/consumer purchasers of services through app stores/service marketplaces) |
Source: Light Reading Services Software Insider, "Telco App Servers: NGIN Revs Up for a Serious Run at SIP," 2009 |
Next Page: What II – RESTful Technology
REST – Representation State Transfer – is a particular style or methodology for constructing distributed software systems, which in the telecom context may be very loosely defined as ones in which geographically distinct software processes are able to interact to produce a larger process. The Web itself is a (probably the) prime example both of such a telecom system and of a REST-style distributed software system; and one practical way of looking at REST is as a set of best practices for using the basic elements of the Web: HTTP, URIs, and so on.
The close relationship between the Web and REST is hardly surprising, as REST was proposed by one of the main authors of HTTP itself, Roy Fielding. In one sense, REST abstracts the best bits that the Web particularizes. So REST requires standard ways of uniquely naming (distributed) things, of linking things, of interacting linked things, and of transferring state information between linked things, to name some of the important ones. Its name clearly derives from the last.
On the Web, these are provided by URLs, hypermedia links, HTTP methods (such as PUT, GET, POST, and DELETE), and its general stateless way of operating, as servers respond to clients and then forget them. To a keep a sequence of interactions going intelligibly, each one has to include all the information on the current state of the sequence so that the server will know how to respond. This is in complete contrast to the traditional telecom finite-state-machine approach, where both sides know at all times where they are in the interaction and don’t need to be reminded as to what is going on.
It should be emphasized that REST doesn’t have to use HTTP; other Application Layer protocols that do a similar job and follow REST principles may be used. And, conversely, HTTP can be implemented in ways that are not compatible with REST principles. But, in general, the Web is very REST-like, and the adoption of REST into telecom SDPs is likely to encourage the spread of REST practices.
Table 2 summarizes some of the appealing characteristics of the RESTful approach to Web Services and examples of their applications scope. Hewlett-Packard, for example, recommends that any RESTful SDP gateway should support at a minimum the following HTTP content types: JSON, Atom, RSS, and XML.
Table 2: Some REST Characteristics
Aspect | Characteristics and examples |
Web Services and RESTful APIs | Simple to understand, use, support, maintain... |
Speed of integration, no libraries to merge... | |
Simplify integration among components as each API typically performs one discrete operation and is usable by multiple components and users | |
Most operations, especially public APIs, are covered by GET and POST | |
Usable for both machine-to-machine or Web-based interactive applications | |
Leverage existing and well known security methods such as HTTPS (SSL/HTTP) | |
Scalable because essentially stateless, so the server side can be scaled easily | |
Natural choice/direction for IMS migration and convergence of voice/data networks as it is based on the same technologies and infrastructures | |
Current use within SDP environments | Ad servers |
Media transcoders | |
Messaging gateways | |
Payments and billing | |
Subscriber identification/authentication | |
Simple billing transactions | |
Raise charge | |
Prepay more complex as it typically involves state, that is reserve amount, show advice of charge, charge/release amount (although this could be merged into a single operation) | |
Subscription management | |
Subscribe, unsubscribe, subscribed | |
Content management | |
Add/update/content content items and catalogues | |
Register/unregister remote services, such as RSS feeds | |
Bulk send content to subscription groups | |
Operator's SDP handles actual subscriptions � content provider sends content to subscription group once authorized by SDP | |
Ensure Do Not Disturb and Unsubscribe requests are respected � a problem in some geographies | |
Get reports | |
Usage and settlement reports | |
Source: Volantis Systems, 2010 |
Standards
This being telecom, it is impossible to go very far without stumbling into standards requirements and initiatives. As BroadSoft’s Palmer points out, the need for REST is effectively embedded in the architecture of next-generation networks, as RESTful SDPs play a part in IMS migration and Web 2.0 convergence. The MMTel global standard that references the IMS architecture specifies the Ut-interface for the management of subscriber services and settings, and these are ultimately RESTful interfaces with XCAP payloads.
“The exposure of RESTful SDPs permits the convergence of Enterprise and Web 2.0 systems and enables an entirely new breed of applications called mashups,” Palmer says. “The de facto standards of Web services and the changing mind-shift towards openness is simplifying the integration of disparate systems. Further, service providers view Unified Communications and Rich Communications Suite as key market drivers, and UC and RCS typically require RESTful SDPs to deliver either core or value-added features to these overall solutions.”
The current core RESTful SDP standards initiative lies within the GSM Association (GSMA) OneAPI program, launched in early 2009 to specify a commonly supported API to allow mobile (and other network) operators to expose useful network information and capabilities to Web application developers. As part of this work, the Open Mobile Alliance (OMA) is specifying APIs that will handle REST and SOAP, and the initial APIs will thus be available in both RESTful and lightweight Web Service flavors. The OMA ParlayREST standards are expected to be finalized in late February or early March 2010 and will include key operator services such as messaging, location, and charging.
“It is believed that GSMA OneAPI will adopt this new OMA RESTful Parlay X standard and obsolete their existing standard. We also understand that some major global telecom carriers are going to adopt this new standard,” says HP’s Dyoub.
The point of creating such a harmonized set of APIs is application portability across providers – that is, if a developer writes an application for one operator, it is not necessary to rewrite it for use by another operator, even if the second operator is in a different country, which is currently a major issue.
Aepona Ltd. is the technology provider for the OneAPI reference implementation, and, according to Michael Crossey, VP of marketing at Aepona, both SOAP and REST versions of the exposed APIs were included to maximize choice.
“SOAP is more feature rich – it has more methods, there is more traceability with SOAP, and for certain applications that is desirable,” he says. “But for many Web applications that just need to query location or send a message, REST-based interfaces are desirable because they are very easy to use.”
A OneAPI beta has been running for about a year, and its first commercial launch, in Canada, was announced at the Mobile World Congress in February 2010, with the three major Canadian operators – Bell Mobility Inc. , Rogers Communications Inc. (Toronto: RCI) and Telus Corp. (NYSE: TU; Toronto: T) – participating in a commercial pilot commencing in February 2010. The pilot will use the GSMA's PathFinder number-translation service to determine which operator to send the OneAPI call to, while allowing for number portability. The GSMA says that PathFinder’s global nature will enable the rapid rollout of OneAPI to different markets around the world.
According to HP’s Dyoub, the new OMA RESTful Parlay X standards are likely to prove attractive to telcos and service providers because they do not rely primarily on an underlying SOAP/REST conversion, a common current approach to supporting REST.
“These new OMA REST APIs are very specific to REST structures and really take advantage of some of its inherent features,” says Dyoub. “From our view, they appear powerful and probably more attuned to what the telco customers are going to be looking for from their application developer community.”
Next Page: Another Angle – Hosted/Managed-Service Providers
Although the main interest of a Light Reading Who Makes What lies in telecom technology products and their vendors in the basic sense of hardware or software kit that can be purchased per se for telecom purposes, SDPs cannot be so neatly pigeonholed. The reason is that there is a market segment where hosted/managed-service providers create their own SDP-type systems to support the offering of primarily IP-based converged enterprise services through their own networks.
One such company is IntelePeer Inc. , which operates a worldwide carrier-grade voice peering network and offers a communications-as-a-service (CaaS) platform. The idea is to provide open access to carrier-grade telecom functionality with hardware, software, and network capacity delivered from the Internet cloud as an on-demand, fully hosted and managed service. Capabilities include dynamic protocol translation, transcoding, call routing, device discovery, intelligent call routing, SIP session management, and next-generation application development.
Underpinning this is the company’s AppworX RESTful SDP, introduced in mid-2008.