Service
Delivery
Broker
Whitepaper
v1.1
January 2012
Executive Summary
Communications Service Providers business is facing challenging times due the arrival of new
over-the-top players, telecommunications market struggle and regulatory pressures.
This document explores the momentum of Communications Service Providers, putting the
Telco industry vision about how to generate new revenues into practice using SAPO Service
Delivery Broker (SDB) that is a complete end-to-end solution for software-enabled services
delivery, management and products commercialization. Moreover, the SDB is an important
infrastructure in a Service Oriented Architecture (SOA) environment providing all the features
that an Enterprise Service Bus (ESB) must implement and further SOA Governance. Therefore,
the SDB is useful for Telcos as well for all companies that to expose services internally or to
third parties.
Being based on standards recognized by the TM Forum, W3C, etc., the SDB is a platform that
fits in every real world scenarios where delivering services and products is a goal, giving extra,
but worthy, business and technical enhancements to the SDB provider as well to their
consumers.
The SDB is characterized by three distinct dimensions, namely: service management, services
delivery and products delivery. Each dimension is extensively described offering an in-depth
view of the key features that the SDB offers, both to SDB provider and to third parties.
The current document also explores SDB participation as a Catalyst Project for at the World
Management World Americas 2010 (Orlando FL), where it showed real world scenarios in
action.
V1.1 14 April 14, 2012
2
Index
Executive Summary ................................................................................................................... 2
Figures Index ............................................................................................................................. 5
Introduction .............................................................................................................................. 6
Shifting toward new revenues .................................................................................................. 6
Business Models ........................................................................................................................ 7
Business strategy into practice ................................................................................................. 9
What is SAPO Delivery Broker ................................................................................................. 10
SDB history: SDB makes the difference................................................................................... 11
SDB alignment with SES Management Solution ..................................................................... 12
SDB Runtime........................................................................................................................ 13
Inventory Endpoint.............................................................................................................. 14
Intermediary Routing .......................................................................................................... 15
Brokered Authentication ..................................................................................................... 15
Protocol Bridging ................................................................................................................. 15
Data Model Transformation ................................................................................................ 16
Data Format Transformation .............................................................................................. 16
Exception Shielding ............................................................................................................. 17
Message Exchange Pattern ................................................................................................. 17
SDB Pipeline ........................................................................................................................ 17
SDB Quality of Service (QoS) ............................................................................................... 19
SDB Tackling of overload ..................................................................................................... 20
SDB SDBSS ............................................................................................................................... 22
SDB Support Application .................................................................................................... 22
Infrastructure Support Services .......................................................................................... 23
Management Support Services ........................................................................................... 23
SDB Marketplaces ................................................................................................................... 23
SBD on Windows Azure ........................................................................................................... 24
Integration with BSS/OSS and network resources .................................................................. 25
PT Inovação Service Enablers .................................................................................................. 25
Business Models as a Service .................................................................................................. 27
V1.1 14 April 14, 2012
3
Management World Americas 2010 Orlando Catalyst ........................................................... 28
Demo 1 - Create a SES (reusable and managed service)..................................................... 28
Demo 2 - Service composition ............................................................................................ 30
Demo 3 - Policy-based Management .................................................................................. 31
Demo 4 - Monitor and Manage Services............................................................................. 32
Demo 5 - Marketplace registration ..................................................................................... 33
Demo 6 - Online (Real-time) Application Provider Charging .............................................. 34
Demo 7 - Online (Real-time) Revenue Sharing by the CSP ................................................. 35
Demo 8 - Online (Real-time) Revenue Sharing with the application using directly the
OneAPI Payment SDF Service .............................................................................................. 36
Demo 9 - Pre-paid SMS Pack and OneAPI SMS SES Service usage ...................................... 37
Demo 10 - Subscribe the access to a web application (SAPO GIS Studio) and use SES-MI to
manage the application....................................................................................................... 38
Conclusions ............................................................................................................................. 39
Business Benefits................................................................................................................. 39
Technical key facts .............................................................................................................. 39
Contacts................................................................................................................................... 40
V1.1 14 April 14, 2012
4
Figures Index
Fig. 1 - SDB logical architecture ................................................................................................... 10
Fig. 2 - SAPO Mobile web portal ................................................................................................. 11
Fig. 3 - SDB Runtime architectural patterns ................................................................................ 14
Fig. 4 - SDB Runtime components ............................................................................................... 18
Fig. 5 - SDSS logical blocks ........................................................................................................... 22
Fig. 6 - SDBSA............................................................................................................................... 22
Fig. 7 - SDB logical architecture on Windows Azure ................................................................... 24
Fig. 8 - Service Creation Workflow .............................................................................................. 29
Fig. 9 - Service Composition Cycle ............................................................................................... 30
Fig. 10 - Commercial policy workflow ......................................................................................... 31
Fig. 11 - SDBSA Monitorization Interface ................................................................................... 32
Fig. 12 - Third Party SDB Marketplace registration workflow ..................................................... 33
Fig. 13 - Operation stage of OneAPI SMS with real-time charging in the third party mobile
phone account............................................................................................................................. 34
Fig. 14 - Operation stage of OneAPI SMS with real-time charging in the application end user
mobile phone account and revenue share with third party executed by the CSP ..................... 35
Fig. 15 - Operation stage of OneAPI SMS with real-time charging in the application end user
mobile phone account and revenue share executed by the third party using OneAPI Payment
SES ............................................................................................................................................... 36
Fig. 16 - Operation stage of OneAPI SMS SES with a pre-paid SMS pack commercial policy ..... 37
Fig. 17 - Provisioning workflow of a web application sold out on the SDB Marketplace ........... 38
V1.1 14 April 14, 2012
5
Introduction
Communication Service Providers (CSPs) are facing challenging times, where the digital
economy is getting wider due to the Internet explosion, the rise of broadband capacity, the
widespread of wireless connections, massification of always-connected smart devices and
Telco related product commoditization trends. All that brought new players with new valuedadded services (VAS) over CSPs core business (network services) such as Apple, Google,
Facebook and Netflix. CSPs trend is to be seen only as a pipe, thus, losing relevance on the
digital economy and for its customers.
Even CSPs specific Telco services like voice and text messages are now been provided by overthe-top services providers, that have lightweight structures agnostic to the network
infrastructure layer, giving them a very agile market response. In fact they don't need to worry
about the infrastructures needed to deliver their VAS to their customers because they assume
that connectivity is not a constraint but a commodity that a CSP provides on network
neutrality model.
Beyond market players struggle, costumers are getting better informed, more rational and
demanding new VAS, more quality of service (QoS) and all of that bundled with competitive
prices.
Hence, CSPs need to shift their business strategy, from a product-centric offer to a customercentric offer and takeover the over-the-top services, explore niche markets, lightweight their
structure towards faster time-to-market and cost-effective concept-to-cash.
Repacking products into services and collaboration, exploring CSPs knowhow and credibility is
the way to escape from product commoditization. The shift time is now!
Shifting toward new revenues
The core business for CSPs is on top of one-sided market (retail, enterprise and infrastructure)
that favors product-centric vertically-integrated solutions as the best way of leveraging
revenue growth. Products have very strict and limited market boundaries, they cannot operate
in a multi-context/domain environment and therefore their revenue is locked-in on that
product market reach. This happened because CSPs had a dominant position in the market,
controlling end-to-end the value chain. For decades, CSPs were the only ones that could
deliver IT-based services in a broad scale, balancing market acceptance against product
investment risk. So, why should their business strategy pass by sharing their dominant position
on the value chain or splitting revenue with SMEs or even to operate in niche markets?
Due the shrinking margins coming out from the aggressive market war, regulatory and overthe-top players pressures brought into the CSPs ecosystem the need to adopt a broader
business strategy, exploring a two-sided market that takes into consideration working
collaboratively with third parties, extracting assets from their know-how, from customer
V1.1 14 April 14, 2012
6
intimacy and exploring their expertise's towards the mitigation of enterprises burn over IT
(Cloud Computing).
Thus, CSPs must move fast and be part of the digital economy not only as a pipe but delivering
over-the-top VAS, being IaaS/PaaS service providers to vertical business and enabling B2B.
This is a substantive change for CSPs, which brings several challenges/opportunities: enhanced
Telco retail (e.g. click-to-call); vertical industry services (e.g. healthcare services delivery, banks
— PaaS); maintain their own brand over-the-top (e.g. social networking applications); enabling
B2B services (e.g location and payment services); infrastructure services (e.g. IaaS); etc.
Business Models
The new business strategy must be translated into business models. Those are one of the most
important business strategy dimensions to take into account, because they enable costumer
business and intimacy leveraging the traction of the CSP.
Actually, all the business models that can support the business strategy exist for quite long
time and are tried-and-true in other industries context, nerveless, the innovation comes from
their use in a Telco environment and delivering VAS that promote customers business revenue
with a fair share for the CSP.
The current whitepaper will focus solo in the business models that are focus on:




Exploring Telco assets in an Internet context
Mitigating the gap between CSP and over-the-top players, turning over-the-top players
into customers/partners
Catching the long tails
Enabling third parties
The business models that fulfill the requirements above are:
Brokerage Model: It brings buyers and sellers together enabling business transactions. Usually
a broker charges a fee or commission for each transaction that enables. Typically the
brokerage model covers scenarios, like:



Marketplace exchange where the CSP offers infrastructures and platform services that
cover all that's related with the business transactions - Fulfillment, Assurance and Billing
(FAB)
Order Fulfillment where it takes the sell/buy order from its customers and execute it. This
model suites on online stores that are enabled by the CSP infrastructure a platform
services
Transaction Broker where the CSP provides its payment services and does the settlement
(in real time or differed) between the buyer and seller
Advertising Model: Is an extension of the traditional media broadcast model. The CSP or a
media partner has a pool of advertisers that want to target customers and the CSP delivers the
V1.1 14 April 14, 2012
7
ads. The end application that embeds the ads is responsible to capture customer’s streams.
Usually, the end application owner gets paid in a pay-per-click or in a pay-per-view model. The
CSP can add real value to this business model because it has a strong and wide intimacy with
customers allowing strategies based in behavior and contextual targeting or providing
audience measurement services.
Merchant Model: It wholesales and retails services/products. The CSP is specialized in
providing a wide range of services for both the supplier as well as the costumers, reducing the
burn required by the supplier on distribution issues, providing vast market coverage to his
products/service and after sale services. CSP as a wholesaler provides services/products to
third parties (retailers) in order to them enhance their business with VAS. Strategies like
revenue share and real time charging to the ultimate customers are good approaches to gain
traction among third parties. This only occurs when the product/services used to build the final
product/service are not from the CSP, if so; the business model is Manufacturer Model. When
a CSP acts like a retailer it has to develop and package the product/service to the customer.
Manufacturer Model: Is the actual business model that a CSP operates. The CSP creates a
product/service and delivers it directly to its customers controlling all the value chain with high
efficiency.
Affiliate Model: It has its base on a pay-for-performance model which takes advantage of the
affiliate referral and it presents to his customers/visitors the opportunity to purchase a
product or services. Typically, the revenue share is the method for returning value to the
affiliate.
Community Model: The user (typically developers) explores the CSP marketplace platform and
brand equity in order to deliver its products/services. The application stores are a very good
example of this business model put into practice where the community develops applications
to the end user and delivers it by the service provider platform services. The service provider
and the CSP obtain revenue from this model by making revenue share with the application
developer.
Subscription Model: The customer is charged periodically for a service usage. The subscription
model can be combined with others business models assuming a role of mitigating the
operational service cost.
Utility Model: This model is based on pay-as-you-go approach and sometimes is called as "on
demand" model. The customers only pays for what he uses but the unit price can be highly
personalized. For instance, the customer could pay higher rates per units if contracts an
aggressive SLA. Actually, this model is supporting the cloud computing services by letting the
customers adapt their business to their IT needs. It's also possible to combine it with other
business models, and thereby, better fitting with the customer needs.
V1.1 14 April 14, 2012
8
Business strategy into practice
Putting into practice the new business strategy is quite challenging, because, it adds new
stakeholders to the CSP value chain; entering in unknown markets is an empirical experience;
customer intimacy takes a long time; some business models are tough to put into practice in
large scale environments; it requires a systematic SOA business approach; legacy services need
to be repackaged into services that fulfill standards; turning vertical services into broad
spectrum services might need some effort from the vendor/CSP; composing, exposing and
managing services carries not trivial issues; BSS/OSS integration can be a heavy task; costs
mitigation of concept-to-cash in highly demanding time-to-market expects high agility from
the CSP; operational issues can be brought up in a scale market; the landscape of today’s
information and communications market is very volatile; etc.
From a business perspective, some structural changes are needed, changes that enable market
responsiveness and higher customer intimacy.
From a technical perspective, a software platform (federate or not) based on standards that
enables and ensures the requirements is the way to put into practice the new business
strategy.
SAPO has developed a best-of-breed platform, a Service Delivery Broker that gives the
business and technical answer.
SAPO Service Delivery Broker has the ability to efficiently provide a flexible and compelling
service-enabling platform to CSPs or other business like healthcare, insurance companies, etc.
It brings management capabilities to service enablers aligned with the industry standards, TM
Forum Software Enabled Services Management Solution (SES-MS), as well
services/applications productization into marketplaces of the service provider, Microsoft
Marketplace or even a third party portal with the best user experience for all the user roles.
V1.1 14 April 14, 2012
9
What is SAPO Delivery Broker
SAPO’s Service Delivery Broker (SDB) is a complete end-to-end solution for software-enabled
services delivery management, API Inventory management, and products commercialization
that allows service providers to expose services to third parties with full control. For 6 years,
the solution has grown and been in operation at PT SAPO. The SDB has proven to be reliable,
robust, and flexible, fulfilling all the requirements asked by the current users.
Fig. 1 - SDB logical architecture
SAPO's SDB encompasses the following components running on the Windows Azure cloud
platform:



SDB Runtime – The engine that exchanges the messages between service consumers and
service enablers. It provides crosscutting features to the service enablers like:
authentication, authorization, data model transformation, data transformation,
intermediate routing, throttling, load balancing, policy enforcement, protocol bridging and
much more.
SDB Support Application – Is a web application that is built on top of the SDB Support
Services enabling the management of the SDB runtime, MSS, ISS, the marketplace services,
services SLA, product lifecycle and the services lifecycle. This application is crucial because
it makes the enforcement of the patterns and best practices over the services and
products.
SDB Marketplaces – Are a set of services that allow third parties to buy and sell products.
The product are typically a wrap to services that are delivered with a commercial offer,
however, a product could be web applications, native mobile application, etc... On top of
the marketplace services, was developed a web application that the service provider can
use without having the need to develop his own marketplace, he can also build or
integrate the services on his commercial context.
V1.1 14 April 14, 2012
10

Service Enablers – Are the set of services, composed or not, that expose its capabilities to
third parties. All service enablers must implement SES Management interface and the
SDBA ensures that they are fully interoperable among all programming languages. Some
services enablers expose Telco related capabilities; an example is SDB delivery of One API
v1.0 services.
SAPO SDB is available to be hosted on premises, in the Cloud, as a hybrid-cloud solution or as a
PaaS.
SDB history: SDB makes the difference
The SDB was the starting point in SAPO's SOA adoption. It started five years ago where all
solutions were vertical, silos, locked in their selves, thus, the contents and functionalities had a
very strict landscape. The mind set was each solution was built using the technology that best
suited into the project scope, such as: PERL, PHP, C#, Java, Python, C/C++, etc. not having any
services at all. When the value of mesh up contents and functionalities was required, SAPO
needed to create an integration project that was painful in terms of human resources as well
as financial.
Today SOA is not only an architectural style at SAPO, but a cultural characteristic. Every single
developer knows that the solution must be supported by services; services must be designed
in the SDBA, must be discovered in the SDBS Catalog (ISS) and must be consumed through the
SDB Runtime.
When mobile smart phones, IPTV, internet connected TVs, and smart devices arrived, SAPO
already had a substantial portfolio of services that were used to build SAPO Mobile Portal. In
three months Portugal Telecom was able to deliver SAPO Mobile Portal to its Mobile
customers. It was a record time-to-market and a very cost-effective concept-to-cash.
Portugal Telecom released its triple-play offering in 2009, called MEO. The biggest challenge
was the TV offer because there are well established cable operators operating in Portugal for
quite long time. Hence, it is imperative a distinguished offer not only focus on TV channels and
user experience but taking part of the strong relation that Portuguese's have with the "TV
time" by adding all sorts of functionalities, from
information news to pure entertainment, that explore
all the TV potential. The same model used on SAPO
Mobile Portal was used to enrich MEO offer —
content and functionalities — turning the solution in
the most innovative IPTV offer in Portugal, a true
interactive TV. As a result, MEO solution currently
offers various features that significantly differentiate
its offer from its competitors including: electronic
programming guide (EPG); TV channel recording,
which can be remotely programmed through the
internet or through the mobile phone, allowing easy
V1.1 14 April 14, 2012
Fig. 2 - SAPO Mobile web portal
11
recording of series and offering multi-room PVR for those customers with more than one settop-box; social networks, gaming, karaoke and several interactive applications and service
areas; access to personal photo folders, and customized contents and features for children;
MEO@PC that enables the TV experience on PC; MEO Music Box that allow listen to music on
the TV, PC and smart devices that run on Android and iOS; Gaming on demand; etc.
Portugal Telecom has also invested in smart devices, delivering all kind of applications for all
types of operating systems, from iOS to blackberry, increasing customer’s loyalty and intimacy.
SAPO's SDB has a crucial role in MEO offer by exposing and managed more than 200 VAS with
more than 1000 operations. The VAS offer comes from all kind of suppliers and the VAS
execution environment may be on the VAS supplier or at SAPO premises.
Along with the VAS used internally, in the latest 5 years, SAPO has exposed some of the
services in a public service catalog for third parties. This brought lots of experience how to
boost a third party community and strong intimacy with them.
With the time pass, VAS design and execution came with more and more consistency and
reliability. Thereby, it became obvious to SAPO that the next step was to start the
development of a marketplace platform where the services became products that third parties
can buy them in order to use in a commercial context.
Hence, SAPO developed a marketplace and the support ISS/MSS that allow bundling products
into product offers as well the product lifecycle management. The first products were services
enablers and applications that anyone can buy access to. An example is the ability to buy
OneAPI SMS product offers SMS packs or real time charging.
The final step was observing that Telco industry was demanding the same requirements that
SAPO had tried-and-true. Hence, SAPO packaged the SDB to be available on premises, on cloud
or as a hybrid cloud solution fulfilling all the usage scenarios for SDB operate.
SDB alignment with SES Management Solution
The PT SAPO SDB team joined TM Forum SES Management Solution1 workgroup in February
2010 and has been working towards alignment ever since. The first step was to align SDB
implementation architecture with SES Reference Architecture (SES-RA TMF 061). Nowadays,
the current effort is to implement the latest version of the SES Management Interface (SES-MI)
in every service enabler, ensuring a common and standard way to managed them. The next
step is to contribute to Service Management Metadata that will allow a standard way to
describe service dependencies, service characterization, etc.
The key benefits that the SDB achieved with the SES-MS alignment are:
1
The TM Forum SES Management Solution was formerly known as the TM Forum Service Delivery
Framework or SDF. Readers should not be confused by TM Forum documentation such as TMF061 that
uses the term SDF instead of SES.
V1.1 14 April 14, 2012
12








Strong control of the service lifecycle management across all service enablers
Minimize the cost and cycle time to translate service ideas into market offerings
Reduce cost by repurposing existing content and applications
Adapt swiftly to market changes and customer preferences
Ensure the best practices and industry patterns at design time.
Mitigate the burn of service designer and developers work
Deliver a standard-based, consistent and full interoperable offer of services enablers to
third parties
Leverage service composition with full control of its dependencies and resources
Along with the SES-MS alignment, SDB team is working the alignment with SID and eTOM TM
Forum Frameworx.
SDB Runtime
The SDB Runtime is a message exchange platform that mediates all interactions between
service enablers and their clients (applications or other service enablers). As a mediator of all
interactions, the SDB has the opportunity to provide crosscutting features to service enablers,
like logging, authentication, caching or even encapsulate internal corporate subsystems hiding
it complexity to both clients and services enablers.
Clients interact with service enablers, by sending messages to the SDB, typically SOAP, XML,
and JSON over HTTP protocol. SDB is responsible to forward them to the service enabler
instances. For each message received, the SDB extracts from the message the user, service and
operation name to elect the behavior that the SDB will execute to that particular message.
This behavior is named "strategy" an it’s defined in a XML based Domain Specific Language
(DSL) that informs the SBD what's the endpoint instance, the binding supported, etc. of the
service enabler.
The SDB implements several critical patterns in support of message and protocol
transformations; administrative configuration of heterogeneous communications between
consumers, services and underlying resources; and contributes to the overall governance by
enforcing the management decisions.
V1.1 14 April 14, 2012
13
The following diagram represents the main architectural patterns present in the SDB Runtime:
Fig. 3 - SDB Runtime architectural patterns
Inventory Endpoint
By abstracting capabilities from a collection of services into a single Inventory Endpoint, the
SDB offers several benefits, including:

Increased governance freedom for the underlying services, as they can be changed and
extended without affecting the endpoint service contract. Even if underlying service
functionality needs to be altered, logic could be introduced into the endpoint service
to accommodate for the changes so that external consumers remain unaffected and
unaware.

The endpoint service contract can be fully customized to accommodate the external
clients programs. This allows the addition of data and security constraints, policy
assertions and alternatives, and even the support of additional transport protocols
unique to the consumer interaction requirements. By abstracting these
implementation requirements into a single service endpoint, underlying inventory
services are not required to change.

A separate endpoint service can be created for each group of external consumers. This
allows the customization to be specific to a range of consumer types. For example, one
endpoint service can be created for clients from a different domain inventory, and a
separate endpoint service can be positioned for client programs residing outside of the
organization itself.

Beyond providing alternative contract representation for inventory services, an
endpoint service can also provide Protocol Bridging for consumers that use disparate
protocols or data exchange technologies.
V1.1 14 April 14, 2012
14
Intermediary Routing
The larger and more complex a service composition is, the more difficult is to anticipate and
design for all possible runtime scenarios in advance, especially with asynchronous, messagingbased communication. The SDB offers a solution to this issue by allowing to dynamically
determine the routing of every message path. Various types of intermediary routing logic can
be used to create message paths based on message content or on runtime aspects.
The SDB runtime currently supports the following forms of routing functionality:

Content-Based Routing – This type of routing determines a message’s path based on
its contents. Content-based routing can be used to model complex business processes
and provide an efficient way to recompose services on the fly.

Load Balancing – Is capable of directing a message to one or more identical service
instances in order to help the service activity be carried out as efficiently as possible.
Random, Fallback and Multicast routing are supported operating modes for this
feature.

One-to-One (1:1) Routing – When messages arrive, the SDB runtime is capable of
routing them to different service instances or redundant service implementations. This
accommodates standard fail-over requirements and allows services to be maintained
or upgraded without risking “disruption of service” to customers.
Brokered Authentication
The SDB is capable of validating consumer credentials without having to interact with the
service enabler. Both consumers and services trust the authentication broker, allowing it to
become a centralized authentication and credential issuing mechanism.
The Security Token Service (STS) is an internal SDB runtime service made available to external
consumers that wraps the brokered authentication functionality.
Depending on consumers' authentication information, the SDB chooses an Authentication
Provider. The providers are available to the SDB through a provider pattern implementation
that is decoupled from specific Authentication Provider implementations and there is no need
to recompile the SDB to add new providers. The providers’ configuration is managed by the
SDB configuration.
This centralized security platform simplifies the development of individual services and further
reduces the governance burden associated with identity management.
Protocol Bridging
When the SDB receives a message, transforms it and performs all the work required to make
the message comply with the target protocol (or protocol version).
V1.1 14 April 14, 2012
15
This bridging logic is made available by the SDB to enable communication between different
communication protocols by dynamically converting one protocol into another at runtime. The
feature eases integration efforts because instead of having to support connecting directly to
each other, consumer programs and services can use the SDB protocol bridging capability,
which provides bridging logic that carries out the protocol conversion.
The SDB protocol bridging layer is highly extensible and comprised of several transformation
adapters that act as translators for a given protocol. There are already several common
transformation adapters available (e.g. all kind of transformations between SOAP 1.1 and 1.2,
REST, JSON and XML protocols). It is also possible to extend the natively supported set with
new adapters that will be executed in the SDB runtime pipeline as any other native adapter.
Data Model Transformation
Even when the communications protocol and data formats are compatible, for software
programs to exchange any form of structured data (such as business documents), the
definition of the model that the data structure is based on (the data model) can be different at
transmitting and receiving ends. This leads to a requirement for the runtime transformation of
information from one data model into another.
Data model transformation logic can be introduced so that the SDB carries out conversion of
data complying with one data model to comply with a different data model. This enables
dynamic overcoming disparity between the schemas used by a service contract and the
messages transmitted to that contract.
When services are implemented as Web services, XSLT is generally used to define the mapping
logic that is subsequently executed to perform the transformation at runtime. Using the
Service Delivery Support Application, it is possible to easily define custom (user-defined) XSLT
transformations to be easily integrated in any message processing path.
Data Format Transformation
A service consumer that communicates using a data format different from a target service will
be incompatible and therefore unable to invoke the service (for example, if the service
consumer is using XML to communicate with a service that only accepts CSV). To overcome
this problem, the SDB runtime introduces data format transformation capabilities in order to
dynamically translate one data format into another.
By allowing the combined use of Protocol Bridging, Data Model Transformation and Data
Format Transformation capabilities, the SDB runtime reduces common integration efforts to
an administrative task via the Service Delivery Support Application. This way, the SDB provides
the implementation of another pattern, Concurrent Contracts. A service enabler from its
ultimate contract can have several contracts exposing only the functionalities and data model
adequate for a particular consumer.
V1.1 14 April 14, 2012
16
Exception Shielding
In order to guarantee that unfiltered exception data outputted by a service will not contain
internal implementation details that can compromise the security of the service and its
surrounding environment, the SDB runtime by default “sanitizes” all exception data by
replacing it with exception data that is safe by design before it is made available to service
consumers.
Sanitized exception’s information can make the tracking of errors more difficult due to the lack
of detail provided to consumers; to minimize this difficulty, the service enabler, on exception
situation, can sent an identifier to map it into a more detailed description that will be included
in the sanitized exception. Every exception is returned with a unique identifier that can be
used for consult on the Service Delivery Support Application (SDSA) which gives access to full
exception’s description, if the person who is tracking the exception has enough permission
over it.
The default behavior can be overridden by configuration. In case the consumer is using HTTP in
order to use a service enabler, the returned HTTP Status Code, the description and the detailed
information of an exception can be configured.
There are static built-in exceptions description and detailed information that are mapped to
identifiers or custom identifiers can be created a suitable exception response.
The SDB runtime basic exception shielding process occurs as follows:




The consumer submits a request message to the SDB which flows it to the service enabler
The service enabler attempts to process the request and throws an exception. The
exception may contain safe or unsafe information
Exception shielding routines residing in the SDB runtime replace the exception data
returned by the service enabler with safe exception information. A unique identifier is also
added to the exception message returned that will allow for an authorized consumer (e.g.
operation staff or a developer) to query the original exception data
The SDB runtime returns a message containing safe exception data to the service
consumer
Message Exchange Pattern
SDB supports four types of message exchange pattern: Request-Response, One-Way,
Notification and Publisher-Subscriber. Others types of message exchange patterns can be plugin on the SDB in order to fulfill consumers or service enablers requirements.
SDB Pipeline
The SDB pipeline is an execution of a sequence of tasks for one particular message. A task is a
logical module with a well-defined scope that realizes a generic capability. Is through strategies
that pipelines and task settings are specified.
V1.1 14 April 14, 2012
17
Fig. 4 - SDB Runtime components
The main native SDB tasks are presented in the following list:
 Authentication: it makes the enforcement of authentication decision by the
authentication provider.
 Authorization: it makes the enforcement of the authorization decision that the policy
service responds. The policies may be related with user access authorization as well
commercial authorization. The task is configured to know what information has to be
extract from the message and pass it to the policy service.
 Cache: Although completely optional to use, many times it is desirable and even required
to configure caching at SDB level for a specific service enabler operation responses. By
caching those responses, the SDB offers greater scalability to service enabler, because it
will only make requests to an underlying service enabler whenever its responses are not
already cached.
 Choose: The SDB Choose task makes possible to have decision trees within a strategy, with
any nesting level. Is the basis for many possible micro-workflow related activities, making
possible to configure a decision point structure where multiple option are present. The
values tested in those options can be static or dynamically retrieved at runtime from the
SDB runtime context or from any part of the currently processed message.
 Diagnose: The SDB Diagnose task dynamically updates Windows Management
Instrumentation performance counters that can be monitored in the SDSA Reports and by
the monitoring service.
 Log: The SDB Log task makes possible to log any request or response at any time during
the processing of a strategy. The task can execute synchronously or asynchronously, and
target a designated file system path, database server, HTTP URL, or email address. It can
also be configured to run only for a specific request or response message of a specific user
(or user role) targeting a specific operation of a specific service enabler. These granularities
V1.1 14 April 14, 2012
18





together with the possibility to deliver the log information in different channels offer great
flexibility for both operation and debug scenarios.
Market: The SDB Market implements itself some commercial policies. For example it can
count requests for any given request or response, and optionally make the SDB to refuse
serving any more requests for a specific user if a configured request limit per service
consumer or if a configured time frame is reached.
Protect: The SDB Protect task may impose access restrictions to some service consumers,
in order to protect service enablers from abuse or undesired usage. Some common
examples are the configuration of an IP address range restriction and limit the maximum
message size accepted.
Route: The SDB Route task is the most commonly used task in the SDB. A service enabler
consumer issues a request to a given service; the SDB Route task is responsible for
forwarding that request to its underlying service enabler. Beyond the basic behavior of
routing, it allows the parameterization of request timeout, HTTP keep alive connection,
HTTP basic or digest authentication, URL decode, HTTP X-Forwarded-For/Host/Server,
HTTP referrer, exception shielding configuration, HTTP status code, content based routing
by regular expressions or xPath, etc.
Transform: Being able to convert messages between different data models and formats is
a critical feature of the SDB. By using this feature, it is common to have a service enabler
which only natively supports SOAP, to be able to support HTTP GET, JSON or any other
custom format. The native transformations are: HTTP Get or Post to Soap; HTTP Get or
Post to XML; SOAP to HTTP Get; SOAP to HTTP Post; SOAP to SOAP 1.2; SOAP to XML;
SOAP 1.2 to SOAP 1.1; SOAP 1.2 to XML; Ws Security to SOAP; XML to HTTP Get; XML to
HTTP Post; XML to JSON; XML to SOAP; XML to SOAP 1.2; and custom XSTL.
Validate: The SDB Validate task ensures that only valid messages (according to their
contract’s schema) are routed to the remote host. This capability lowers dramatically the
number of malformed messages that are presented to a given service enabler, and by
doing so contributes to maximize the performance and scalability of that service enabler.
SDB Quality of Service (QoS)
The CSP has user friendly management skills through Service Delivery Support Application
(SDSA) to ensure Quality of Service (QoS). SDB supports several approaches in this matter,
mostly because its high available and reliable environment demands – currently available in a
best effort model.
One huge issue is synchronous communications, which requires an immediate response to
each request and thereby forces two-way data exchange for every service interaction. When
services need to carry out synchronous communications, both service and service consumer
must be available and ready to complete the data exchange. This can introduce reliability
issues when the SDB cannot guarantee its availability to receive the response to its request.
Because of its sequential nature, synchronous message exchanges can further impose
processing overhead, as the service consumer needs to wait until it receives a response from
its original request before proceeding to its next action. Prolonged responses can introduce
V1.1 14 April 14, 2012
19
latency by temporally locking both consumer and service, hence; put in danger the SDB
availability to serve other request even with more priority.
Synchronous communication can origin on the service enabler several issues, because services
enablers are expected to process request as soon as they are received, usage thresholds can
be more easily reached, thereby exposing the service to multi-consumer latency or overall
failure. These issues are solved in the SDB, completely transparent to both the consumer and
service enabler, implementing:






Asynchronous message exchange. In other words, a synchronous request is converted into
an asynchronous request in the SDB scope releasing it to accept more requests and
therefore increasing its availability.
Making cache when possible for the responses of the service enabler.
Definition of different behavior in the same service enabler or service enabler operation.
Differentiated treatments can be addressed by defining different message handling
strategies to different users, enabling two groups of users to have differentiated behavior
to access the same functionality. This management is made by the Service Delivery
Support Services (SDSS). Via the SDSS different strategies can be created based on the
user’s roles or on the user account name. With differentiated strategies by users or users
groups, less privileged users can have strategies that provide cached information, when
applied, reducing the charge upon the end service enablers.
Service enablers can be deployed in different environments so less privileged users do not
compete for the service enabler’s resources.
Having dedicated instances of SDB and service enablers for a certain contexts.
Releasing the SDB and service enablers on Windows Azure gaining unlimited scalability,
availability and reliability.
The SDB has two levels of throttling ensuring the healthiness of the platform. The first level of
throttling is given by the web server (IIS - Internet Information Services) that has dynamic
request queuing based on the system load, which is highly tuned for internet demands. The
last level of throttling is implemented by SDB ensuring the service enablers SLA and business
rules.
SDB Tackling of overload
An overload situation can attain a given service enabler or, in case of an abnormal high traffic,
surpassing the planned capacity of the system, the SDB itself. For both situations, different
measurements need to be taken. The detection of overload situations is performed by the
Monitoring Service (ISS) that receives events from the services enablers SES-MI, from the
service execution environments and SDB Runtime. The events are collected and processed
(Complex Event Processing techniques) being available in a standard format (e.g. SNMP) so
they can be further analyzed and integrated in other solutions.
One examples of the monitoring information is the Operator dashboard in the SDSA that
exposes load metrics (for the SDB and each individual service enabler) and fault situations, so
the Operator can take the appropriate measures. As an example of a countermeasure that an
V1.1 14 April 14, 2012
20
operator may take in the case of a service enabler overload, is to instruct the runtime to cache
requests of a given overloaded operation (if the operation response is cacheable). In the case
of an extreme abnormal high traffic, that sets the SDB in an overloaded state, hot spares or
Windows Azure instances can be activated to cope with the extra charge. In the case of a
service enabler fault situation besides the appropriate measurements to set the service
enabler in a non-faulted state (e.g., using it SES-MI), an Operator can take measurements at
the SDB level to decrease the impact of the problem, for example: activate an alternative
strategy to handle requests to a given faulted service enabler so it can contact other
compatible available service enabler.
V1.1 14 April 14, 2012
21
SDB SDBSS
The Service Delivery Support Services (SDSS) is all the set of services that allow the SDB to be
managed and encompasses three components:
Fig. 5 - SDSS logical blocks



Service Delivery Support Application
Infrastructure Support Services
Management Support Services
SDB Support Application
The Service Delivery Broker Support Application (SDBSA), it’s a web application that runs on
top of SDB Infrastructures Support Services (ISS) and Management Support Services (MSS)
allowing management of the SDB Runtime and services’ lifecycle and product Lifecycle. It
promotes services reutilization and composition, achieved only due a true and strong
enforcement of governance’s policies. The actors have "click-through" experience in order to
perform all management decisions.
Fig. 6 - SDBSA
V1.1 14 April 14, 2012
22
The services’ lifecycle management goes from the concept to the retire phase enforcing the
best practices and the industry guidelines. The process of service creation, provisioning and
operation is visualized in the Management World Orlando 2010 Demos section on the present
document (Demo 1 and 2).
The Products' lifecycle management (PLM) implements the TM Forum Holistic PLM (PLM
Strategy, PLM Process, Product Architecture and PLM IT Architecture). The Product Lifecycle
Management leveraging the SDB was explored in detail during the Multi-Cloud Developer
Experience Catalyst showcased during Management World 2011 Dublin.
Infrastructure Support Services
Infrastructure Support Services (ISS) are services that support the entire services’ lifecycle
management. This is made by managing the service metadata through all the service phases
and states. Some of the ISSs present on the SDB are: Service Design Management, Monitoring
Service, Services Catalog Service, Alarm Service, Resource Management Service, Services
Lifecycle Metadata Service, Usage Monitor Service, etc.
Management Support Services
Management Support Services are those who abstract the execution of a given capability that
can be performed through one or the combination of SES-MI, Infrastructure Management
Interface or other known means to accomplish the capability in order to business process
(eTOM) are accomplished. The exact tasks that a Management Support Service shall execute
are defined in the Service Enabler Metadata, managed by the SDSS. The SDB provides all the
information and functionalities required to use them. Some examples of MSSs presented in
the SDB are: Deployment Management Service, Provisioning Service, Quality and Problem
Management Service, Reporting Service and Usage Monitor Service.
SDB Marketplaces
The SDB Marketplace is a set of services and a web application on top of them that allow the
business transactions between sellers and buyers.
It allows the CSP and the third parties sell products that might be an API, a web application or
even a physical product like a phone. The buyer will have access to a product offer catalog
where he can discover the products; the products characteristics; the product terms and
conditions; the buying options that can be from PayPal to other payment systems; accounting
functions; usage reporting; and billing.
The third party that sells a product in the marketplace has to define the product and the
products offers. If the product is an API it must use the service lifecycle management user
interface ensuring the service interoperability, manageability and good practices in order to
bundle the API into a product offer. In his user area he will have their customer relation and
their usage.
V1.1 14 April 14, 2012
23
Since, the SDB Marketplace has a suite of services, it is possible for a third party to integrate
the marketplace in his store. For example, one use of these services is to enable integration
with Microsoft Azure Marketplace.
SBD on Windows Azure
SDB was designed to have high availability and reliability on premises. Since the SDB will be
attending a world wide scale market, having it running on premises is not cost-effective
because the hardware and IT resources needed to operate millions of request per second is
too much expensive. Therefore, a cloud computing platform is the best way to mitigate the
costs and to increase the availability in an "on-demand" model. The chosen cloud computing
platform was Windows Azure.
The release of the SDB on Windows Azure was obvious because:




The SDB is developed over Microsoft stack products, from .Net 4 to SQL Server.
The SDB development team has its expertise's focus on Microsoft technology.
Windows Azure has the best experience for the developers due the integration with Visual
Studio 2010 for debugging and releasing it.
Windows Azure has a massive scale ability worldwide; has elasticity by providing scale up
and down; is fault tolerant; has self-healing capabilities; and it has all the software
components needed by the SDB to operate.
Choosing Windows Azure PaaS/IaaS was truly worthwhile, and the evidence was the SDB
Development only took a couple of days to have a prove-concept running and two months to
take part of all the features that the Windows Azure provides improving the SDB.
The current SDB logical architecture on Windows Azure is in the following figure:
Fig. 7 - SDB logical architecture on Windows Azure
V1.1 14 April 14, 2012
24
Integration with BSS/OSS and network resources
The SDB, as just as the PT SAPO implementation, must not be seen only as a exposure layer to
third parties, it must be seen as part of the CSP SOA adoption, exposing services internally as
well. Meaning that all kind of IT systems are assets for the CSP, being part of the CSP services
portfolio. This will in the first moment will leverage the enterprise system integration and
management reduction costs and in the second moment becoming them eligible for being
wrapped in a product available in the CSP Marketplace.
Thereby, all BSSs/OSSs and network resources must start do expose their functional and
management interface as web services empowering the CSP new business strategy. Having the
services published in the SDB, the SDB itself will take advantaged in terms of integration in a
cost-effective way.
PT Inovação Service Enablers
PT Inovação has provided IP-Raft Payment Service Enabler exposing powerful real-time service
charging and rating capabilities, allowing different business models to be implemented,
according to 3GPP definition for the Online Charging System. At the backend, IP-Raft interfaces
with PT Inovação’s BSS solution, NGIN, which is currently serving more than 100 million
subscribers worldwide.
The IP-Raft usage has demonstrated how TM Forum SES-MS concepts can support Telecom
Operators in leveraging and monetizing the existing core services, by exposing network
capabilities to third parties, via industry agreed interfaces as GSMA OneAPI with SLA control
and management.
The following IP-Raft payment operations were published on the SDB:







Charging an amount to an end user’s account
Reserving a charge for an end user’s account
Adding/subtracting a charge to/from an existing reservation
Charging to a previously made reservation
Releasing funds left in a previously made reservation to the account from which the
reservation was made
Credit an end user’s account enabling revenue sharing like business models
Get end user’s account balance
In addition, IP-Raft partially implements TM Forum SES-MI interface by sending charging
events towards SES Usage Monitor.
Several Use Cases (shown below), focused on the “massification” of upstream revenues from
SMEs and end-users with agile and flexible concept-to-cash approaches, were successfully
demonstrated by using IP-Raft payment features.
These Use Cases can be enriched with other SES Enablers from PT Inovação, spanning across
legacy and NGN/IMS based networks, providing a true convergent framework.
V1.1 14 April 14, 2012
25
The Location Service Enabler provides the position of mobile terminals independent of
underlying network technology. This enabler serves as the interface between the applications
and the GMLC (Gateway Mobile Location Centre) allowing a service and a management
interface.
The Messaging Service Enabler is a system that allows the network operators to manage
message broadcasts that are sent by SMS or MMS. Besides that, it also manages VAS that may
implement whatever logic the operator needs. It is also capable of “relaying” message
requests that can be used by legacy applications.
The Group Enabler provides unified Group Management features by aggregating different
sources of Group Data from different Network Resources, including LDAP Servers, XDM
Servers, XMPP Servers, SynchML Servers and Social Networks like MSN, Google, Linkedin, etc.
The Context Enabler handles context information and offers APIs to the other context-aware
enablers, services and applications that want to use somehow context information. The
Context Enabler offers access to a global context framework; it provides unified Management
of Context Data by aggregating different sources of context data from different Context
Providers, including Presence (IMS, XMPP), Location, Sensors or status information from Social
Networks like MSN, Twitter, Linkedin, Facebook, etc.
The Conversation Enabler provides a new breed of functionalities to build business friendly
collaborative communications, by enabling the usage of the Web 2.0 Collective Intelligence
power combined with emerging new collaboration and communication paradigms. The
Conversation Enabler offers a rich and complete synchronous and asynchronous extensible
resource sharing experience including Conversation members voice, image (video) and text
messages (Chat), Photos, Video or any File sharing, Whiteboard, Slideshow, Desktop sharing,
Document edition.
The Content Store Enabler provides contents management and distribution functionalities
designed for mobile operators, wireless ASPs or any other operational area whose objectives
involve the effective management and distribution of contents. This solution has been
developed using robust, flexible modules that allow it to operate in the largest and most
demanding of markets. It combines up-to-date information technology and open source
application servers with the objective of maximizing return on investment. Those mobile
operators who are currently using this platform have witnessed significant increases in both
traffic levels and value added content purchases.
The Live TV enabler facilitates management of user subscriptions and video content access
(live streaming), including seamless channel switching. Other value added functionalities are
also provided, regarding EPG (Electronic Programming Guide) and IPTV convergent services,
such as remote account access, video recording and parental control.
The Mobile Advertisement enabler provides integrated mobile advertisement functionalities
that can be used by any value added service or application for instant retrieval of the most
suitable contextualized publicity for a given client which is then delivered via the most
appropriate channel.
V1.1 14 April 14, 2012
26
The Content Selection Enabler has the capability of selecting the most suitable content to be
transmitted, based on user context and content metadata.
The Identity Manager Enabler exposes a set of interfaces to the applications for identities and
privacy management, identity authentication/authorization and identity federation. The ID
Manager Enabler extends the latest OMA specifications on Identity Control (NGSI-10) to
provide new functionalities and operations over user’s identity
The Media Service enabler exposes basic and enhanced media processing capabilities for
delivering media rich interactive services including Announcement Service Capability,
Recording Service Capability, Conference Service Capability, Prompt and Collect Service
Capability, Outbound Call Control Service Capability.
Business Models as a Service
In the SDB perspective, Business Models are commercial policies. These policies are defined by
configuration allowing the CSP to apply them to their products and to pre-define them to third
parties.
Supporting natively all the business models above mentioned (Business Models section) and
provide them through configuration lead to "Business Model as a Service".
At the product design time, the Product Manager, that can be a third party or a CSP, defines
the product and product offers. Among the product characteristics, SLA, etc. he will establish
the commercial policies that each product offer will have.
In case of a CSP, if the service enabler already exists, the service characterization metadata
feeds the Product Manager SDBA user interface with the service capabilities in order to him
decide which are the capabilities will be bundle in a product offer and which are the
commercial policies that are supported by the service enabler. If the service enabler doesn't
exists it's generate a service order to the Service Designer where the Service Designer must
design the service enabler in order to fulfill all the requirements made by the Product Manager
or decline the specification arguing which are the requirements and why they cannot be fulfill.
At provisioning time, the Provisioning Engineer will make the provisioning for aspects that
need to be made to the service operate. One particular aspect that needs to be made is
through the SDB service enabler strategy the definition how the SDB Runtime captures the
commercial policy data that will feed the Policy Service decisions. The provisioning can be fully
automated.
When a third party wants to sell a product in the marketplace he will defined his terms and
costumer obligations based on the CSP available business models and the service economics
demands. He can mesh up his service with order services available, however, using other
services, the third party will need to have into account the services business model cost as
well.
V1.1 14 April 14, 2012
27
The execution of the commercial policies depends also on the service enabler requirements.
Its occurs in two steps: First the SDB Runtime intercepts the request and extracts all the
commercial data that will be used by the Policy Service in order to decide if there's clearance
to proceed the request to the service enabler instances or not — authorization. At this time
the Policy Service can, for instance, make the reservation of credit in the customer mobile
phone account and if the reservation is made with success gives the order to the SDB Runtime
to proceed with the request. The second step occurs after the service enabler report its usage
through the SES-MI. After a usage report from the service enabler, the Monitor Service will
invoke the Policy Service and, following the previous example, execute the charging on the
customer mobile phone.
With this approach, the business models implementation complexity is strongly mitigated
ensures the customer service enabler usage will be correctly made, and the reporting will be in
near real-time (event driven approach).
The use of a generic Policy Service is essential in order to encapsulate the BSS that will in fact
take all the actions and decisions. The Policy Service itself has built-in a rule engine that uses a
Domain Specific Language XML-based; it presents great performance that can execute the
commercial policies by traditional BSSs.
Policy Service is crucial for the CSP or the SDB service provider to have Business Model as a
Service approach.
Management World Americas 2010 Orlando Catalyst
In TM Forum Catalyst program, the SDB demonstrated real-world scenarios using the concepts
of TM Forum Software-Enabled Services (SES) Reference Architecture TMF061, SES-MI (Service
Management Interface) and several industry standards through a multi-tenant (PaaS/SaaS)
solution for managing the services lifecycle.
The SDB Catalyst involves SAPO encompassing the SDB platform; PT Inovação providing the
oneAPI service enablers; and Microsoft with Microsoft Windows Azure.
The experience proved to be worthy in several aspects:





The industry feedback
Profitable discussions about service management and delivery
Several leads for the SDB product from major industry players
An extraordinary communication opportunity
Opportunity to see other projects and their relevance to the SDB
The following items will present the Management World Americas 2010 SDB Catalyst demos.
Demo 1 - Create a SES (reusable and managed service)
V1.1 14 April 14, 2012
28
Context: Create a Web service that reuses existing data types and is in alignment with service
creation best practices, WS-I Basic Profile 1.1 and TM Forum SES-Management Interface.
1. Schema-first approach: The service designer defines the schema and searches in the
schema catalog if there’s a possibility of schema reutilization
2. Contract-first approach: The service designer defines the service including the
previous defined schema and defining the service operations. The service is tested
against WS-I Basic Profile 1.1 and TM Forum SES-MI
3. Stub Generation: The developer gets a service stub in the programming language that
he chooses (C#, Java, Perl, PHP, Python, etc.). The stub is a skeleton of the service and
it includes data types and operations
Fig. 8 - Service Creation Workflow
V1.1 14 April 14, 2012
29
Demo 2 - Service composition
Context: Search, discover and reuse services to compose a new service
1. A Service Designer uses the Service Catalog to search and select the services involved
in the service composition
2. Service Designer designs and configures composed services
3. Service Catalog Manager makes the provisioning on the SDB
4. Service Designer ensures that the results of the relevant SES-MI operations of the
service composition members propagate to the composed service
SES
MS
Fig. 9 - Service Composition Cycle
V1.1 14 April 14, 2012
30
Demo 3 - Policy-based Management
Context: The SDB Product Manager defines a service enabler commercial policy.



Support to different Policy types: Authorization, Usage and Charge
Policies can be changed anytime through the Policy Service
Rule-based application of policies at runtime (e.g. if a costumer sends 1000 SMSs the next
SMSs that he sends have a lower price)
Send SMS
Get Commercial Policies
Yes
SMSs
Sent > 3
No
Charge 10 cents
Charge 5 cents
SMS Sent
Fig. 10 - Commercial policy workflow
V1.1 14 April 14, 2012
31
Demo 4 - Monitor and Manage Services
Context: The SDB Operator has a user interface where he monitors the services enablers and
SDB platform.
Monitoring Service





Throughput
Exceptions
Response Time
Clients
SLA
Management Services
 Documentation
 Cross-cutting features that can be assigned or unassigned to the service (Load
Balancing, accepting new binding, etc.)
 Full service lifecycle throughout the MSSs and ISSs in place
 QoS reactions (e.g. throttling)
Fig. 11 - SDBSA Monitorization Interface
V1.1 14 April 14, 2012
32
Demo 5 - Marketplace registration
Context: A user registers in the SDB Marketplace
1. The third party registers on the market place providing his personal information and
MSISDN
2. The third party associates a MSISDN to his marketplace (web) account
Fig. 12 - Third Party SDB Marketplace registration workflow
V1.1 14 April 14, 2012
33
Demo 6 - Online (Real-time) Application Provider Charging
Context: A third party creates an application that uses the OneAPI SMS Real-Time where his
mobile phone account is charged by the SMS usage.
1. Third party is already registered in the marketplace along with his MSISDN account
association.
2. The third party browses the product catalog, subscribes the OneAPI SMS Real-Time
Charging product offer and develops an application that sends SMS.
3. The third party application sends a SMS using OneAPI SMS and the SMS value is
charged on the MSISDN account (pay-per-use).
Fig. 13 - Operation stage of OneAPI SMS with real-time charging in the third party mobile phone account
V1.1 14 April 14, 2012
34
Demo 7 - Online (Real-time) Revenue Sharing by the CSP
Context: The third party subscribes the OneAPI SMS Real-time Revenue Sharing where the
application user is charged by the CSP and the CSP makes the settlement with the third party
in real-time
 The third party subscribes the OneAPI SMS Real-Time Revenue Sharing product offer
 He will send SMSs through OneAPI SMS SES
 The revenue sharing is made by the CSP, crediting sharing amount in the third party
mobile account
Fig. 14 - Operation stage of OneAPI SMS with real-time charging in the application end user mobile phone account
and revenue share with third party executed by the CSP
V1.1 14 April 14, 2012
35
Demo 8 - Online (Real-time) Revenue Sharing with the application using directly the
OneAPI Payment SDF Service
Context: The third party subscribes the OneAPI SMS Real-time Revenue Sharing where the
application user is charged by the CSP and the third party makes the settlement with the CSP
in real-time by using the OneAPI Payment Service.
 The third party subscribes the OneAPI Payment product offer
 The third party is responsible for making the amount reserve and debit of the usage
with OneAPI Payment SES
 The SDB make the enforcement of the service policies, for example: the revenue
sharing policy
 The end user goes to the third party app store and buys a music to download
Fig. 15 - Operation stage of OneAPI SMS with real-time charging in the application end user mobile phone account
and revenue share executed by the third party using OneAPI Payment SES
V1.1 14 April 14, 2012
36
Demo 9 - Pre-paid SMS Pack and OneAPI SMS SES Service usage
Context: The third party buys a SMS pack to be used by an application. The SDB make the
usage authorization and monitoring
1. A marketplace costumer buys a SMS pack (pre-paid business model) available for a
time period through the payment service
2. OneAPI SES will be used to send SMSs
Fig. 16 - Operation stage of OneAPI SMS SES with a pre-paid SMS pack commercial policy
V1.1 14 April 14, 2012
37
Demo 10 - Subscribe the access to a web application (SAPO GIS Studio) and use SESMI to manage the application
Context: A third party sells its application in the CSP marketplace. In order to do so, it has to
implement the SES-MI in order to the SDB manage his application (e.g. provisioning)
 A marketplace costumer subscribes an application available in a SaaS model that’s may
or not be running in the CSP domain
 The costumer makes the payment throughout the CSP payment service
 The CSP make the settlement
 Through the SES-MI that the application provider implemented the marketplace MSSs
make the provisioning on the application
Fig. 17 - Provisioning workflow of a web application sold out on the SDB Marketplace
V1.1 14 April 14, 2012
38
Conclusions
Regarding the actual momentum of the CSPs it's imperative to implement the business
strategy that will leverage new revenues; the SDB presents itself as a trustful, best-of-breed
and tried-and-true platform that gives the technical answers to the business requirements.
The SDB also respond to all companies that needs to expose and manage services (internally or
externally) in a cost-effective model — SDB PaaS/SaaS, running in Windows Azure.
The SDB has clear benefits to every company that adopts it as its service and products delivery
platform.
Business Benefits
 New revenue streams by sharing CSP position on the value chain collaboratively
 Operate a two-sided business model - retail and wholesale services
 Ability to more quickly meet customer demands and therefore get costumer intimacy
 Lower costs associated with the acquisition and maintenance of technology
 Enable third party business and drive them to success. With the SDB, SDB provider can get
a fair share of the third party revenue.
 Provides real-time decision-making applications
 Reduces custom development costs
 Manage software-enabled services in a standard way, in an unified platform toward
getting a cost-effective concept-to-cash and faster time-to-market
 Reduce costs of service management and delivery by using SDB in a PaaS/SaaS model
 Adjust business demands and infrastructures with Windows Azure Cloud Platform pay-peruse business model
 CSP has available all the business models as a service leveraging the new business strategy
 The World Management Americas 2010 Orlando SDB Catalyst putted into practice TM
Forum TMF525 Business Agreement use cases; real-time charging; revenue sharing
between the operator and application provider; and the delivery of a SaaS application that
uses SES Management Interface (SES-MI) proving to the industry the commitment and
expertise's of the SDB team
 The SDB is a platform from services to market, enabling the SBD provider to spread its
business beyond his landscape
Technical key facts
 More flexible architecture by decoupling services from its clients
 Every applications must expose services and therefore integration of existing
applications is faster and easiest
 Improved data integration by SDB capabilities of data transformation and data model
transformation
 Supports business process by having MSSs that use the SES-MI to manage the services
 Speeds custom application development because reuse and publish services is quick and
easy
 SDB is based on standards and industry best practices: TM Forum, W3C, WS-I, etc.
V1.1 14 April 14, 2012
39










SDBA ensure services exposure with full interoperability among the most used
programming languages and leads the Service Designer to design services within the best
practices of service design
Every service can be bundle into a product offer due the SDB design
SDB is a modular, reliable and robust platform operating for five years
SDB is developed over Microsoft stack and therefore has a legion of developer capable to
maintain and evolve the platform
Running the SDB on Windows Azure augment the SDB availability and performance
SDB is built based on services but it provides web applications that simplify its use by
having a user friendly interface
SDB is policy driven and policies are defined by configuration
Windows Azure provides a flexible, full capable, reliable platform for running the SDB and
services enablers
SDB promotes SOA adoption by the SDB provider
SDB promotes SOA Governance with services dependencies management, services
lifecycle management and service inventory
Contacts
V1.1 14 April 14, 2012
www.portugaltelecom.pt
www.sapo.pt
http://sdb.sapo.pt
António Cruz
antonio.j.cruz@telecom.pt
www.ptinovacao.pt
Paulo Ramalheira
paulor@ptinovacao.pt
www.microsoft.com
www.windowsazure.com
Eric Troup
etroup@microsoft.com
40