Service Delivery Broker

linencharmΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

87 εμφανίσεις





Service
Delivery
Broker

Whitepaper

v1.1

January

2012

V1.1 14 April 14, 2012


2



Executive
S
ummary

Communications Service Providers business
is facing challenging times
due the arrival of new
over
-
the
-
top players, telecommunications market struggle and regulator
y 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 so
f
tware
-
enabled services
delivery,
management

and products commercialization.
Moreover, t
he SDB
is
an

important
infrastructure in a Service Oriented Architecture (SOA) environment providing all the features
that an Enterprise Service Bus (ESB) must implemen
t 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.

B
eing based on standards
recognized by the

TM Forum, W3C, etc.
,

the
SDB
is a platform that
fits in ever
y 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, s
ervices
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.

T
he 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


3




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


4


Management World Americas 2010 Orlando Catalyst

................................
...........................

28

Demo 1
-

Create a SES (re
usable 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
-
tim
e) 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


5



Figures Ind
ex


Fig. 1
-

SDB logical architecture

................................
................................
................................
...

10

Fig. 2
-

SAPO Mobile web por
tal

................................
................................
................................
.

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 Mark
etplace 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
-

Oper
ation 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


6



Introduction

Communication Service Providers (CSP
s
) are facing challenging

times
, where the
digital
econom
y
is getting wider
due
to
the Internet explosion, the rise of broadband capacity, the
widespread of wireless connections,

massification of

alway
s
-
connected smart devices
and
Telco related product commoditization trend
s
. All that brought
new players with
new valued
-
added services

(VAS)
over
CSPs

core business (network services)

such
as Apple, Google
,
Facebook

and Netflix
. CSPs trend is to be seen o
nly 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 over
-
the
-
top services providers
,

that have lightweight structures

agnostic to the ne
twork
infrastructure layer,

giv
ing

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 provide
s

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
bundle
d

with
competitive
prices.

Hence, CSPs need to shift

their business strategy
,

from a product
-
centric offer to a customer
-
centric offer and take
over

the over
-
the
-
top services, explore niche markets, lightweight their
structure toward
s

faster time
-
to
-
market and
cost
-
effective
concept
-
to
-
cash.

Repacking pro
ducts into
services

and

collaboration
,
exploring CSP
s

knowhow and credibility is
the way to escape from product commoditization. The shift time is now!


Shifting toward new revenues

T
he core business for CSPs
is

on top of one
-
sided
market
(retail, enterpri
se 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 therefor
e 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 accepta
nce

against product
investment risk. So, why should their business strategy pass by sharing their dominant position
on the value chain or split
ting

revenue with SMEs or even
to
operate in
niche markets
?

Due the shrinking margins
coming out from the aggressive market war, regulatory and over
-
the
-
top players
pressure
s

brought in
to

the
CSPs

ecosystem

the
need to
adopt a broader
business stra
tegy
, 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


7


intimacy and exploring
their

expertise's toward
s

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 pi
pe 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 b
e translated in
to

business models
.
Those
are one of the most
important

business strategy

dimension
s

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 bus
iness re
venue

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
,
t
urning over
-
the
-
top player
s
into customers
/partners



C
atching 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
:



M
arketplace 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 cus
tomers and the CSP delivers the
V1.1 14 April 14, 2012


8


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 busine
ss model because it has a strong a
nd

wide intimacy with
customers allow
ing
strategies
based in

behavior and
contextual targeting

or providin
g
audience measurement services.


Merchant Model
:
It wholesales an
d retails services/
products
.

The CSP

is
specialize
d

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 p
rovides services/products to
third parties (retailers) in order to them enhance their business

with VAS
.

S
trategies like
revenue share and real time charging
to the ultimate customers are good
approaches
to gain
traction among third parties.
This only occu
rs 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 Mod
el
:
I
s 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 t
akes 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 dev
elopers
) 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. T
he subscription
model can be combined with others business models assuming a role of mitigating the
operational service cost.

Utility Model:

This model
is
base
d

on

pay
-
as
-
you
-
go

approach
and sometimes is called as "on
demand" model.

The customers only pa
ys 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 th
eir 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


9



Business strategy into practice

P
utting into practice
the

new business strategy
is quite challenging
, beca
use, 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 s
ystematic 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 trivi
al 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 c
ommunications
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
-
bree
d platform,
a
Service Delivery
Broker that

gives the
business
and
technical

answer.

SAPO Service Delivery B
roker has t
he ability to efficiently provide a flexible and compelling
service
-
enabling platform
to

CSPs
or other business like health
care, 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
service
s
/application
s

productiz
ati
o
n
into marke
tplaces of the service provider,

Microsoft
Marketplace or even a third party
portal

with the best user experience for all the user role
s.


V1.1 14 April 14, 2012


10



What is SAPO Delivery Broker

SAPO’s Service Delivery Broker (SDB)

is a complete
end
-
to
-
end
solution for sof
tware
-
enabled
services delivery management,

API Inventory management,
and products
commercialization
that allows
service provider
s to expose

se
rvices to third parties

with full control. For 6

year
s,

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 enforc
ement 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,
h
owever
, 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 o
r
integrate the services on his commercial context.

V1.1 14 April 14, 2012


11




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 ar
e
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 a
ll
solutions were vertical
, silos, locked in their selves
,
thus
, the contents and

functionalities had a
very
stri
ct
landscape
.
The mind set was e
ach solution was built using the technology that best
suited
into the

project
scope
, such as: PERL, PHP, C#,

Java,

Pyt
h
on, C/C++, etc.

not having any
services

at all. When the value of mesh up contents and functionalities
wa
s 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 solutio
n 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
alre
ady had a substantial portfolio of services that were used to build SAPO Mobile Portal
. I
n
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
-
cas
h.

Portugal Telecom
released its
triple
-
play offer
ing

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 distinguish
ed

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 s
ame 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 si
gnificantly differentiate
its offer

f
rom 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
Fig.
2

-

SAPO Mobile web portal

V1.1 14 April 14, 2012


12


recording of series and offering
multi
-
room PVR for those customers with more than one set
-
top
-
box;
s
ocial
n
etworks,
gaming, karaoke and several interactive applications and service
areas; access to personal photo folders, and
customized

cont
ents and features for children;
MEO
@PC

that ena
bles 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
typ
es of operating systems, from iOS to
blackberry
, increas
ing

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 suppli
ers 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 expe
rience 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
m
arketplace and the support ISS
/
M
S
S 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 i
ndustry 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 operat
e
.


SDB alignment with SES Manage
ment Solution

The PT SAPO SDB team

joined TM Forum SES Management Solution
1

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

TM
F 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 tha
t

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 conf
used by TM Forum documentation such as TMF061 that
uses the term SDF instead of SES.

V1.1 14 April 14, 2012


13




Strong
control of the service lifecycle management across all
service enablers



Minimize t
he cost and cycle time to translate servi
ce ideas into market offerings



Reduce cost by repurposing ex
isting content and applications



Adapt swiftly to market ch
anges and customer preferences



Ensure the best practices and i
ndustry patterns at design time
.



M
itigat
e

the burn of service designer and developers

work



Deliver a standard
-
based, consistent and full interoperable offer of service
s

enablers
to
third parties



Leverage service composition with full control o
f its
dependencies and resources


Along with th
e SES
-
MS alignment, SDB team is working the alignment with SID and eTOM TM
Forum
F
rameworx.


SDB Runtime

The SDB
Runtime
is a
message exchange platform
that mediates all interactions bet
ween
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 an
d services enablers.

Clients interact with service e
nablers
,
by sending messages to the SDB
, typically SOAP, XML,
and JSON

over HTTP protocol. SDB
is
responsible
to forward

them to the
s
ervice
e
nabler

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, ser
vices and underlying resources
;

and contributes to the overall governance

by
enforcing the management decisions
.

V1.1 14 April 14, 2012


14


The following diagram represents the main architectural patterns present in the
SDB R
untime:



Fig.
3

-

SDB Runtime ar
chitectural 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 change
d 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 consumer
s remain unaffected an
d
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 proto
cols
unique to the consumer interaction requirements. By abstracting these
implementation requirements into a single service endpoint, underlying inventory
serv
ices are not required to change
.



A separate endpoint service can be created for each group of ex
ternal consumers. This
allows the customization to be specific to a range of consumer types. For exampl
e, one
endpoint service can be created for
clients
from a different domain inventory, and a
separate endpoint service can be positioned for
client

progra
ms 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
protocol
s or data exchange technologies
.


V1.1 14 April 14, 2012


15


I
ntermediary 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, messaging
-
based communication. The SDB offers a solution t
o 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 foll
owing forms of routing functionality:



Content
-
Based Routing


T
his 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 o
n 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 m
aintained
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 authentica
tion 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 as
sociated 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


16


This bridging logic is made available by the
SDB to enable communication between different
communication protocols by dynamically converting one protocol
in
to another at runtime. The
feature eases integration efforts because instead of having to support connecting directly to
each other, consumer pro
grams 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 trans
lators 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 ada
pters 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 bu
siness 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 anot
her.

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 contr
act 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 ser
vice 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 ca
pabilities 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 ad
ministrative 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 functionalitie
s and data model
adequate for a particular consumer.


V1.1 14 April 14, 2012


17


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 erro
rs 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.

T
he 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 sta
tic 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 requ
est 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 con
tain 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 qu
ery the original e
xception 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 t
ypes of message exchange patterns can be plug
-
in on the SDB in order to fulfill consumers or service enablers requirements.


SDB Pipeline

The SDB pipeline is a
n

execution of a sequence of tasks for one particular message. A task
is a
logical module with a

well
-
defined scope th
at
realizes

a generic capability. Is through strategies
that pipelines and task settings are specified.


V1.1 14 April 14, 2012


18



Fig.
4

-

SDB Runtime components


The main native SDB tasks are presented in the following

list:



Authent
ication
:
it makes the enforcement of authentication decision by the
authentication provider
.



Authorization
:

it makes the enforcement of the authorization decision that the policy
service respond
s
.

The policies may be related with user access authorization
as well
commercial authorization. The task
is
configure
d

to know what information
has

to
be
extract from the message and pass
it
to the polic
y service.



Cache
:

Although completely optional to use, many times it is
desirable
and even required
to configure ca
ching 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
alr
eady 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 multip
le 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 Manage
ment
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 syn
chronously 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 ope
ration of a specific service enabler. These granularities
V1.1 14 April 14, 2012


19


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 com
mercial 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 r
eached.



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 enab
ler.

Beyond the basic behavior of
routing, it allows the parameterization of request timeout, HTTP keep alive connection,
HTTP bas
ic or digest authentication, URL

decode, HTTP X
-
Forwarded
-
For/Host/Server,
HTTP
referrer
, exception shielding configuration, H
TTP 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 enable
r
which only natively supports SOAP, to be able to support HTTP GET, JSON or any other
custom format.

The native transformations are: HTTP
Get

o
r

Post

t
o

Soap
;

HTTP
Get

o
r

Post

t
o

X
ML
; SOAP t
o

H
TTP
G
et; SOAP t
o

HTTP
Post
; SOAP t
o

S
OAP
1
.
2
; SOAP t
o

X
ML
;
SOA
P

1
.
2

t
o

S
OAP 1.1; SOAP
1
.
2

t
o

X
ML;
Ws

Security

t
o

S
OAP; XML t
o

H
TTP
Get
; XML t
o

H
TTP
Post
; XML t
o

J
SON; XML t
o

S
OAP; XML t
o

S
OAP
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 Qualit
y 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 environmen
t 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.
Becaus
e 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 int
roduce
V1.1 14 April 14, 2012


20


latency by temporally locking both consumer and service,
hence;

put in danger the SDB
availability to serve other request even with more priority.

S
ynchronous communication can origin
on the service enabler several issues, b
ecause services
enable
rs
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
:



A
synchronous 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
.



Mak
ing 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 dif
ferent 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 charg
e upon the end service enablers
.



Service enablers can be deplo
yed 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 unlimi
ted 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 b
ased 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
s
ervice
e
nable
r or, in case of an abnormal high traffic,
surpassing the planned capac
ity 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 r
eceives 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 app
ropriate measures. As an example of a countermeasure that an
V1.1 14 April 14, 2012


21


operator may take in the case of a
s
ervice
e
nabler 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
s
ervice
e
nabler fault situation besides the appropriate measurements to set
the
s
ervice
e
nabler 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:
a
ctivate an alternative
strategy to handle requests to a given faulted service enable
r so it can contact other
compatible available service enabler.


V1.1 14 April 14, 2012


22


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 l
ogical 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 Infrastructure
s 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 gove
rnance’s
policies.
The actors have "click
-
through" experience
in order to

perform

all management decisions.


Fig.
6

-

SDBSA

V1.1 14 April 14, 2012


23


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 For
um Holistic PLM (PLM
Strategy, PLM Process, Product Architecture a
nd PLM IT Architecture). The Product Lifecycle
Management leveraging the SDB was
explore
d

in
detail during the Multi
-
Cloud Developer
Experience Catalyst showcased during
Management World 201
1 Dublin.


Infrastructure Support Services

Infrastructure Support Services

(ISS)

are
s
ervices 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 Se
rvices 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 Enable
r Metadata, managed by the SDSS. The SDB provides all the
information and functionalities required to use them.
Some
examples of MSSs presented i
n
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 a
llow the
business transactions between sellers and buyers.

It allows the CSP and the third parties sell products that might be a
n

API, a web application

or
even
a

physical product like a phone.
The buyer will have access to a product offer catalog
where h
e 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 t
he 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


24


Since, the SDB Marketpla
ce 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
-
e
ffective
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 Azu
re 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
-
concep
t running and two months to
take part of all the features t
hat 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 W
indows Azure


V1.1 14 April 14, 2012


25


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 eligib
le 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 p
ublished 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 capabi
lities, allowing different business models to be implemented,
according to 3GPP definition for the Online Cha
rging System. At the backend, IP
-
Raft interfaces
with PT Inovação’s BSS solution, NGIN, which is currently serving more than 100 million
subscriber
s 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 On
eAPI 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 conc
ept
-
to
-
cash approaches, were succe
ssfully
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


26


T
he
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 managem
ent
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 N
etwork 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 infor
mation 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
p
ower 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 i
nformation 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 conten
t 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 ins
tant 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


27


The
Content Selection

Enabler has the capability of selecting the most suitable content to be
transmitted, based on u
ser 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
M
anager

Enabler extends the latest O
MA 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 A
nnouncement 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 commerc
ial 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 thro
ugh 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, define
s

the product and product offers. Among the product characteristics, SLA, etc. he will establish
the commer
cial 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 t
he 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
d
esign 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 pr
ovisioning 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 Ser
vice 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


28


The execution of the commercial policies depends also on the service enabler requir
ements
.
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 no
t


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 p
hone.

With this approach, the busi
ness models implementation complexity
is st
rongly
mitigated

ensures the custo
mer service enabler usage will be correctly made
,

and the reporting will be in
near real
-
time (event driven approach).

The use of a generic Pol
icy 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 execu
te the
commercial policies by traditional BSSs.

Policy Service i
s 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 demonst
rated

real
-
world scenarios using the concepts
of TM Forum
Softw
are
-
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 servi
ces 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



Profita
ble discussions about service management and delivery



Several leads for the SDB product from major industry player
s



An extraordinary communication opportunity



Opportunity to see other projects and their relevance to the SDB


The following items will prese
nt

the Management World Americas 2010 SDB Catalyst
demos.


Demo 1
-

Create a SES (reusable and managed service)


V1.1 14 April 14, 2012


29


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 incl
uding 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


30



Demo 2
-

Service composition


Context:

Search, discover and reuse services to compose a new s
ervice

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 e
nsures that the results of the relevant SES
-
MI operations of the
service composition members propagate to the composed service


Fig.
9

-

Service Composition Cycle


SES
MS

V1.1 14 April 14, 2012


31



Demo 3
-

Policy
-
based Management


Conte
xt:

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)




Fig.
10

-

Commercial policy workflow



Get Commercial Policies

SMSs
Sent

> 3

Send SMS

Charge 10 cents

No

Yes

Charge 5 cents



SMS Sent

V1.1 14 April 14, 2012


32



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, acce
pting 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


33



Demo 5
-

Marketplace registration


Context:

A user register
s

in the S
DB 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 w
orkflow



V1.1 14 April 14, 2012


34



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 mar
ketplace 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 SM
S 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


35



Demo 7
-

Online (Real
-
time) Revenue Sharing by the CS
P


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


36



Demo 8
-

Online (Real
-
time) Revenue Sharing with the application using directly the
OneAPI Payment SDF Service


Context:

The third party subscribes th
e 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


37



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 use
d

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


38



Demo 10
-

Subscribe the access to a web application (SAPO GIS Studio) and
use SES
-
MI to manage the application


Context:

A third party sell
s

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


39



Conclusions

Regarding the actual momentum of the CSPs it's imperative to implement the busin
ess
strategy that will leverage new
revenues;

the SDB presents itself as a trustful
, best
-
of
-
bree
d

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 ma
nage 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 it
s

service and products
delivery
platform
.

Business Benefits



New revenue stream
s

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
. W
ith
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

g
et
ting

a
cost
-
effective

concept
-
to
-
cash and
faster time
-
to
-
market



Reduce costs of service management and delivery by using SDB in a Pa
aS/SaaS model



Adjust business demands and infrastructu
res with Windows Azure Cloud Plat
form pay
-
per
-
use 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 put
ted

into practice TM
Forum TMF525 Busine
ss Agreement use cases; real
-
time charging; revenue sharing
between the operator and application provider; and the delivery of a SaaS application that
uses SE
S 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 t
herefore i
ntegration 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



Spee
ds 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


40




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
deve
loped 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 tha
t 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



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


w
ww.microsoft.com


www.windowsazure.com


Eric Troup

etroup@microsoft.com