Hewlett-Packard
HP views RESTful SDPs as a very mature technology: The company delivered its first RESTful Web 2.0 gateway to an SDP customer in late 2008, for example, with a further delivery in North America in 2009 and is participating in lab testing in Europe and Japan. In general, HP sees increasing operator and service provider interest in SDPs, although that interest is still tempered with some caution and differing perspectives.

“Some are moving aggressively in this space, some are taking a wait-and-see approach, some want a hosted service offering, some in-network solutions” says HP’s Dyoub. “The biggest issue is getting telco customers that are still in a wait-and-see mode to change their strategy from a closed-garden approach to an open application developer environment, where key service enablers are provided by the carrier to maintain the value of the operator in the new Web Services marketplace.”

He lists the key features and function of a RESTful SDP as including:

• Compliance with the upcoming OMA RESTful Parlay X standards
• Provision of governance to control and manage access to the APIs
• Full AAA support
• Diagnostics to enforce SLAs and report on breaches, and to provide a real-time dashboard of winning applications
• Integration with the network carrier's IT and telco assets – charging and billing, messaging, location, presence, subscriber database and persona, voice services, data services, parental control, and so forth
• State-of-the-art SOA diagnostics to help manage the various SDP systems and quickly locate any issues with Java Virtual Machine applications, thereby reducing operational costs

Further, the SDP should provide not only policy and enforcement southbound to manage the access to the carrier's assets, but also northbound to manage the large ecosystem of developers that will want to consume these services as Web 2.0 RESTful APIs. In addition, a world-class UDDI Registry should be provided that allows application developers quickly to discover and download information about new services or changes in services offered by the SDP. That is, if a new version of SMS combined with charging is offered, then that metadata and WSDL or WADL need to be readily available for the application developers to locate and adopt for their applications.

Another important aspect is controlling the life-cycle of services, so that new application developers cannot register with mature or soon-to-be-retired services, and instead are pointed to the newest version of the service to be offered by the carrier. The SDP should also have a rapid on-boarding process for application developers to quickly discover and access the services, but with different classes of services and SLAs, as network operators don't want a rookie developer to have the same level of access (in terms of transactions per second, availability, and so on) as do proven professional developers. HP’s own solution to this is the SDP Service Governance Framework (SGF)(Figure 3).

And the SDP developer portal needs to be able to showcase winning applications, provide best practices, provide blogs for application developer discussions, and enable access to the latest tools, such as mashups and widget creation, for the apps developers.

HP argues that revenue management, monetization, and settlement are key elements of the its SDP solution, as the company has extensive BSS system integration expertise and can integrate the SDP into the communication provider’s prepay and postpay systems though its Internet Usage Manager (IUM) product. The SDP system has to be open and easy to integrate, as the communication provider will not want to purchase yet another BSS system just to do settlement.

Finally, there must be a Web Services service-creation environment to allow rapid creation of compound services – such as billing, premium SMS, parental control, and white list/black list – available for the network-operator marketing department to rapidly launch new services to the developer community.

From these considerations, and the company’s IT background, it is not surprising that HP sees SDPs as being more of a solution to integrate according to each customer’s network and business requirements than as a single specific product to be sold. Figure 4 indicates some of the software elements and integration expertise that are involved in the company’s SDP offering.

It follows that providing RESTful APIs, while important, is only a small part of the vendor’s task of implementing an SDP capability. In particular, Dyoub argues that transformation capabilities are essential. Existing Web 1.0 APIs – such as charging, location, and billing, but there are many others – must be converted to RESTful interfaces as part of the offering. This has to be done efficiently and supported, managed, and run in a high-availability telco-grade environment, and delivered either in-network to a customer or as a hosted service offering. The latter has recently become available through the company’s Enterprise Services business, formed through the acquisition of EDS.

The most recent iteration of HP’s portfolio of SDP elements is Service Delivery Platform 3.0. released in September 2009. This included a number of new components, including the SDP Service Governance RESTful Gateway, which automatically translates Web Services into REST.

A second is Web 2.0 Storefront Portal. This, Dyoub says, offers developers access to similar features and tools that they are used to on sites such as Facebook and Amazon – blogs, best practices, sample code, showcases, and so in. Additionally, and crucially, it provides a tie-in direct to the SGF to control the access, governance, and life-cycle of the application developers, and give tools to the carrier so that it can manage the ecosystem.

The third new element is the Service Orchestration Manager, which essentially handles the interactions for combinational services across different environments and technologies – for example, using a billing service with a Parlay X or SOAP/XML API in conjunction with SMS to create a new offering to developers via RESTful APIs. In a novel twist to the issue of adding SDP value, HP is looking at the possibility of helping the development of the application ecosystem through its consumer products division, and has already made some recent announcements in this area for application developers for touch screen devices.

“HP has a large product group that sells to consumers and that is now looking at smartbooks and netbooks,” says Dyoub. “They would have widgets that would consume services from the carrier for the netbook widget application – broadband widgets, wireless widgets, communications widgets. That, I think, is where HP can provide a lot of value to our telco customers because we extend the SDP value all the way into that realm, can extend into the subscriber’s home, and we can deliver value via the consumer device to that end.”

Telcordia
Telcordia’s main interest in REST is to provide the underlying real-time network services and service enablers that are accessed by such APIs, and not, for example, the gateways that are designed for integrating with third parties to support the APIs and other functions. According to Telcordia’s Cobb, this focus means that typically there are requirements for multiple APIs even within an operator’s network, and these are then exposed as different capabilities to the third parties. So Telcordia might provide a Web services-based API into an integration environment, and a further gateway function would convert that into one more RESTful or Parlay X API for third parties.

Figure 5 shows how the company’s Converged Application Server (CAS) provides this underlying enabler role.

“The underlying Web Services API that Telcordia provides is typically not standardized, but is very custom to the particular operator,” says Cobb. “We do have standardized APIs, but every operator wants their own extensions to them, because they want to be able to offer a variety of APIs targeted at different communities. Some will be standards based, some may be proprietary extensions with additional features. They tend to build an interface module which uses the underlying API that we expose, which is generally more functional than in the standards, so that they can create different niche APIs for different communities.”

Despite the imminence of standards such as OneAPI, Cobb sees the current mix of standards-based and proprietary APIs continuing for some time as the industry experiments with the possibilities: A major mobile operator might be interested in working with some big advertisers to enable some form of advertisement tagging that would work only with its network, for example.

“We think that some operators will move quite quickly to create both simple standardized interfaces and more sophisticated but nonstandard interfaces. Both could happen tomorrow, in principle, and will happen over the next 12 months. But, for the more complex ones – the sort we are working on in the TM Forum to try to drive some of that standardization – that process takes time, and that’s why the TM Forum kicked off the Content Encounter program a couple of years ago.”

In both cases, the result will be a wide range of APIs, with different requirements on them in terms of performance, scalability, reliability, and price. For example, an operator might offer a simple advertising service available at one price, and a much more sophisticated targeted advertising service at a higher one. And, although a charging service clearly has to be hugely reliable, setting up a simple voice call within a salesforce application may not need to be – especially if it is very expensive to ensure extreme reliability.

“Given that, within this SDP environment, operators are going to have to make some hard decisions about which things are real time, which things are not real time, which are highly available – what highly available means,” Cobb says. “In the IT world it probably means 99 percent or 99.9 percent; in the telecom world it typically means 99.999 percent; and in the Internet world it might mean just Best Effort. Which of those apply to the different interfaces? And it is going to be different for each one. There is no right answer to those decisions. You have to look at the business as well as the technical requirements.”

CAS is very much positioned at the high-reliability/high-scalability end of the spectrum, and recent development has been to introduce new, or to extend existing, capabilities for this underlying platform. Examples are in IP-based protocols, in particular DIAMETER, SIP, and HTTP, and in charging, which has been extended to include what the company calls "user policies." These allow users to define certain features, such as spending limits on particular capabilities, or permitted-caller lists.

An area that Telcordia is currently working on in customer pilots, although it is not yet shipping the product, is mobile advertising and marketing. The basic and much hyped idea within the industry is to enable third parties to deliver advertising as part of a content delivery service. In Telcordia’s view, mobile advertising has to be closely linked into policy, because to be acceptable the advertising has to be under the user’s control, so the user decides how many – and what kind of – adverts they are willing to tolerate. Crucially, to protect the user’s privacy, the personal information needed by the system is not released by the operator to the third party, as the APIs provide access only to anonymized and categorized information.

Next Page: Vendor Angles & Activities III