Transcript Parlay APIs

Open Service Access(OSA)
Application Programming
Interface(API)
Framework
ZTE (USA)
Contents
Overview of the Parlay/OSA
What/Why Parlay/OSA Framework
How Architecture Look Like
Framework Features and Advantages
Overview of the Parlay APIs
Framework Access Session APIs
Framework-to-Application APIs
Framework-to-Service APIs
Framework-to-Enterprise Operator APIs
2
Overview of the Parlay/OSA
Starting from early 90s, Internet Telephony
emerged, which completely changed the
cost structure of offering long distance
service.
Commercial VoIP build-out began with
H.323. Defects Discovered.
Next Generation Network will be based on
Softswitch Technology.
3
Overview of the Parlay/OSA
What is Parlay Framework?
Is a set of Open Network APIs, which allows 3rd Parties to
develop and run services external to operators’ networks.
Application/Service
Provider
Parlay
Service
IP/GSM/PSTN/Data
Network
Network Operators’ Domain
Enterprise Domain
4
Why? Business & Technical Drivers
 Regulatory bodies are asking network operators to open up their
networks to third party service providers
 Consequently, the number of service providers is increasing
rapidly

The IT World
Rich in Applications
and Developers
Parlay APIs
The Converged Networks
Rich in Capabilities
The model for delivery of communication services is
moving towards that of a Service Provider Architecture. 5
Why? Business & Technical Drivers
• New Service Delivery Model:
A change in the network centric service delivery
communication services are moving
ever outward from the core network
Examples are SCP based services (IN services), IN services at
the periphery (CTI and CSTA based services), IP based Call
Centres.
6
Why? Business & Technical Drivers
• New Service Delivery Model:
A change in the edge of service delivery
Enterprise and personal functionality requirements
are pressing ever inward the core network
examples are switch based CTI extensions, TAPI, PBX based
services.
7
Parlay Architecture
Call Control
services
Mobility
services
Messaging
services
IN services
UpLoc CAMEL
E-mail SMS
Service Domain
Open Network Interface, e.g.
Parlay Framework: Authentication, Authorisation, … .
Parlay Services: An abstraction of network capabilities.
Resource
Interface
Resource
Interface
Resource
Interface
Network
Interface
Resource
Interface
SGSN
IP
PSTN
BS
MSC
BS
Network Domain
BS
GGSN
GPRS
UTRAN
8
UMTS
Architecture of Parlay APIs
Enterprise
operator
admin tool
Not in scope of
Parlay Phase 2
Not in scope of
Parlay Phase 2
Framework
operator
admin
Not in scope of
Parlay Phase 2
Client
Application
44
11
22
66
Service
supplier
admin tool
33
55
Telecom Network
Source: www.parlay.org
9
Client Application
2
3
4
5
7
Framework
Registration
Initial
Auth
Access
1
8
Service
Supplier
Tool
Service
Factory
6
Discovery
9
10
Call
Control
Manager
123456Register
7Initiate
8Authenticate
910
Request
Obtain
Authentication
and
Discovery
Access
Announce
Interface
Service
Discover
Select
Request
Create
Create
Service
Services
new
creation
a new
Service
andCall
that
of
sign
Service
match
Manager
agreement
needs
Manager
10
Parlay Framework Features- General
 GUI based Framework Management Tool
 Addressing through application support broker, string object reference
 Support for authentication by underlying distribution technology mechanism; can
operator specific
 Support encryption/decryption capabilities for authentication
 Create, modify and query EntOp accounts, App-Client accounts, SAG
information, and Supplier accounts
 Service supplier can register, un-register, announce, un-announce and describe a
service
 Add, remove, enable, disable service types
 Select, sign, terminate an agreement for a service by an App-Client
 Event notification
 Heartbeat Management
11
Parlay Framework Advantages- General
 Single process, multithreaded application
 Data integrity with persistency and in-memory maintained
 High availability in clustering, load sharing, scaling, real-time
resource monitoring, fault detection, redundancy, and service
continuity
 SCE and OSA gateway vendor independent
 Available as network building block on commodity and
proprietary hardware
12
Overview of the Parlay APIs
The Parlay APIs are object-oriented and consist of several categories
of interfaces as shown in previous slide
All Applications, Framework and Services Interfaces inherit from the
base Parlay Interface Class, ‘IparlayInterface’
Unified Modelling Language, UML, has been used to specify Interface
Classes
The Architecture is based on client/server
Each Interface consists of a number of Methods. Each Method has a
number of Parameters
Common Data definitions and Interfaces are also defined in OMG IDL
13
Parlay API Specification- General
 Both synchronous and asynchronous methods are used in APIs:
• Asynchronous method requests are suffixed by ‘req’
• Asynchronous method responses, if applicable, are suffixed
by ‘Res’ and ‘Err’
 The Service and Framework interfaces for client applications are
denoted by classes with name Ip<name>
 The callback interfaces to the applications are denoted by
classes with name IpApp<name>
14
Parlay API Specification– Two Main Interface Sets
1. Framework Interface Set:
Provides 'surround' capabilities necessary for the Service
Interfaces to be open, secure, resilient and manageable
2. Service Interface Set:
Offers applications access to a range of network capabilities
15
Parlay API Specification- General
 For the interfaces between a Service and the Framework:
• The Service interfaces are typically denoted by classes with
name IpSvc<name>
• The Framework interfaces are denoted by classes with
name IpFw<name>
• Some methods within Authentication and Access Interfaces
are exceptional to this, e.g. IpClientAccess
16
Parlay API Specification– Framework Interfaces
 Authentication
Online Authentication of User Application and Network.
 Authorization
Access management and Control to Network Services.
 Discovery
Capability by which Network Service(s) identity is exposed to a User
Application.
 Event Notification
Capability by which user application is notified of service related events.
 Integrity Management
Capability by which information on events which affect the integrity of the
API is shared with the Framework interface and the user application.
17
Parlay API Specification– Service Interfaces (3.X)
 Call Control
Call Management by User Application. Consists of Generic CC, MultiParty
CC, MultiMedia CC (SIP enabled CC), and Conference CC.
 User Interaction
Management of User Application interaction with Network Services, e.g.
Prompt&Collect DTMF, WAP push, etc.
 Mobility
Capability to access Mobility information, e.g. Location, Status.
 Terminal Capability (New in 3.X, adopted from 3GPP OSA)
Capability to access user’s terminal information in the format specified in
W3C and adopted in WAP UAProf Specification.
 Data Session Control (New in 3.X, adopted from 3GPP OSA)
Management of data sessions in Packet Switching networks, e.g. PDP
Context in GPRS.
18
Parlay API Specification– Service Interfaces (3.X)
 Generic Messaging
Capability to send, store, and receive message.
 Connectivity Management
Management of IP based connections, including QoS. Partially overlap with
Policy Management.
 Accounting (New in 3.X)
Capability to get subscriber accounting information for external billing
engines.
 Charging (New in 3.X)
Capability to update or monitor a balance and generate CDRs for postpaid
and prepaid subscribers.
 Policy Management (New in 3.X)
Management of static (SLA) and dynamic (per call) policies for network
service providers and for 3rd party application service providers.
19
Parlay API Specification – Service Interfaces (3.X, 4.0)
 Presence & Availability Management, PAM
Capability of getting presence information, subscriber availability, and also
registration of presence reports.
 Directory/User Profile
Capability to access subscriber information. In general to access any
information held in database.
20
Parlay & other standardisation bodies
 Java APIs for Integrated Networks (JAIN)
•
JAIN initiated about the same time as Parlay 1.0. The same space. They
found each other very quickly. Close cooperation on CC. On the other
hand, Parlay is an architecture, which can be filled in by many
component based JAIN technologies, like JSLEE
 ETSI
•
A main contributor to telephony standards. At a point, decided to leave
out the most 3G standardisation to 3GPP
 3GPP
•
3GPP CN5 started to define OSA specs for UMTS R’99 in Nov ‘99. Due
to aggressive time scale, they decided to base their OSA API on the
existing industrial Parlay APIs. 3GPP OSA API set is a subset of Parlay
API set with some modifications and additions (e.g. Terminal
Capability)
21
Parlay & other standardisation bodies
 OMG
• Its contents strongly influenced by TINA-C and Parlay
• Parlay Framework 2.0 influenced by OMG Telecom Service Access &
Subscription, TSAS.
• Parlay Interfaces are defined in OMG IDL
• OMG & Parlay have worked together to keep two standards in synch
Since Oct 00, Parlay CC WG, ETSI SPAN12 (OSA) and
3GPP CN5 (OSA) have formed a Parlay/ETSI/3GPP joint
WG. This WG was expanded to cover FW and some other
areas. As a result, Parlay 3.X, 3GPP OSA R’4 and ETSI OSA
201-915 have a big common denominator (i.e. the same OSA
API set).
22
Are there any concerns, yes there are …

phase 1, 2 and 3 are not backward compatible. Has been
mandated that the subsequent releases must be backward
compatible

In Author’s opinion, phase 3.X is the first version the
industry can rely on. Phase 1 was only a proof-of-concept,
phase 2 was a prototype subject for major Parlay players
(mainly a number of Parlay members)

Data types and some interfaces like Call Control are
complex

Lack of implementation experience, especially on
performance and dimensioning

Still concerns and comments about security and integrity
23
Framework Access Session APIs
Initial Access
1.
2.
3.
4.
5.
6.
7.
8.
Initiate Authentication
Select Authentication Mechanism
The Client authenticates the Framework with issuing a
challenge
Authentication Successful indication from the Client
The Framework authenticates the client each other
Authentication successful indication from the
Framework
Request Access
Obtain the Framework’s interface reference
24
Framework Initial Access
: IpClientAPILevelAuthentication
Client
: IpInitial
Framework
: IpAPILevelAuthentication
1: initiateAuthenticationWithVersion( )
This is an example of the
sequence of
authentication
operations. Different
authentication protocols
may have different
requirements on the
order of operations.
IpClientAPILevelAuthentication
reference is passed to framework
and IpAPILevelAuthentication
reference is returned.
3: selectAuthenticationMechanism( )
7: challenge( )
8: requestAccess( )
IpClientAccess reference is
passed to Framework, and
IpAccess reference is
returned.
25
Framework Access Session APIs
Non-API Level Authentication
1.
2.
3.
Initiate Authentication by using the underlying
distribution technology mechanism
Request Access
Obtain the Framework’s interface reference to its
service discovery interface
26
Framework Non-API Level Authentication
:
IpClientAPILevelAuthentication
Client
: IpInitial
: IpAPILevelAuthentication
: IpAccess
Framework
1: initiateAuthenticationWithVersion ()
3: selectAuthenticationMechanism( )
5: authenticationSucceeded( )
7: authenticationSucceeded( )
8: requestAccess( )
9: obtainInterface( )
27
Framework Access Session APIs
API Level Authentication
1.
2.
3.
4.
5.
Initiate Authentication by using the type of
authentication process the client specifies
Choose the authentication algorithm supported by the
client
The client and Framework Interact to each other by
using the challenge method
Request Access
Obtain the Framework’s interface reference to its
service discovery interface
28
Framework API Level Authentication
Client
: IpInitial
Framework
: IpAuthentication
: IpAccess
1: initiateAuthenticationWithVersion( )
Underlying Distribution Technology Mechanism is used for client identification
and authentication, or both the client and the framework recognise each other
as trusted parties not requiring API level authentication.
There is no requirement as to when authentication should take place using the
Underlying Distribution Technology Mechanism: before initiateAuthentication()
is invoked, after requestAccess() is invoked, or between the two.
2: requestAccess( )
3: obtainInterface( )
29
Framework-to-Application APIs
Event Notification
1.
2.
3.
4.
Create an event notification IpAppEventNofication in
application
Obtain a reference to the object IpEventNotification
and set the callback interface
Enable an event notification on the Framework
Notify the availability of new SCFs of the requested
type(s)
30
Framework Event Notification
AppLogic
: IpAppEventNotification
: IpAccess
: IpEventNotification
1: new()
2: obtai nInterfaceWithCal l back( )
3: new()
4: createNotifi cation( )
5: reportNoti fi cati on( )
31
Framework-to-Application APIs
Integrity Management
o
Load management





o
o
Suspend/resume notification from application
Framework queries load statistics
Application reports current load condition
Application queries load statistics
Application callback registration and load control
Heartbeat Management
Fault Management


Framework detects a Service failure
Application requests a Framework activity test
32
Framework-to-Application APIs
Load management
Suspend/resume notification from application
Framework queries load statistics
Application reports current load condition
Application queries load statistics
Application callback registration and load control
33
Load Management—Framework queries load statistics
: IpAppLoadManager
: IpLoadManager
1: load change detection and policy evaluation
2: suspendNotification( )
Load balancing service
makes a decision based
on pre-defined policy
This is
implementation
detail
3: load change detection and policy evaluation
4: resumeNotification( )
34
Load Management—Framework queries load statistics
: IpLoadManager
: IpAppLoadManager
1: queryAppLoadReq( )
2: get load information
3: queryAppLoadRes( )
This is the
implementation
detail
35
Load Management—Application reports current load condition
: IpAppLoadManager
: IpLoadManager
1: reportLoad( )
2: evaluate policy
This is the implementation
detail
36
Load Management—Application callback registration and load control
: IpAppLoadManager
: IpLoadManager
1: createLoadLevelNotification( )
Fram ework detects its
load condition change
and initiates load control
action
2: load change detection & policy evaluation
3: loadLevelNotification( )
This is the
im plem entation detail
4: load change detection & policy evaluation
This is the
im plem entation detail
5: loadLevelNotification( )
6: des troyLoadLevelNotification( )
37
Framework-to-Application APIs
Heartbeat Management
1.
2.
3.
4.
Request the application to send its heartbeat
Send heartbeat at specified interval by the application
Detect the application by the Framework via heartbeat within
the specified interval
Take some recovery action
38
Heartbeat Management—Start/perform/end heartbeat supervision of the application
Framework
: IpHeartBeat
: IpAppHeartBeatMgmt
1: enableAppHeartBeat( )
2: pulse( )
3: pulse( )
At a certain point of
time the framework
decides to stop
heartbeat supervision
4: disableAppHeartBeat( )
39
Framework-to-Application APIs
Fault Management


Framework detects a Service failure
Application requests a Framework activity test
1.
2.
3.
Ask the Framework to do an activity test
Test done by the Framework
Send result back the application by the Framework
40
Fault Management—Framework detects a Service failure
Client Application : IpAppFaultManager
Framework : IpFaultManager
The framework should detect if
a service instance fails, for
example via an unreturned
heartbeat. The framework
should inform the application
that is using that service
instance.
1: svcUnavailableInd( )
The application must
cease the use of this
service instance.
41
Fault Management—Application requests a Framework activity test
Client Application : IpAppFaultManager
Framework : IpFaultManager
Client application asks
framework to carry out an
activity test. The framework is
denoted as the target by a NULL
svcId parameter value.
1: activityTestReq( )
Framework carries out test and
returns result to client application.
2: activityTestRes( )
42
Framework-to-Application APIs
Service Discovery
1.
2.
3.
4.
Obtain a reference to the Framework Service Discovery interface
List service types
Describe service type with service property (property name,
property value, property mode, parent type, enable/disable)
Discover the service
43
Service Discovery
Application
: IpAccess
: IpServiceDiscovery
1: obtainInterface( )
2: listServiceTypes( )
3: describeServiceType( )
4: discoverService( )
44
Framework-to-Application APIs
Service Selection
1.
2.
Select service for the application
Sign service agreement between the Framework and the
application
45
Service Agreement—Service selection
:
IpAppServiceAgreementManagement
Application
:
IpServiceAgreementManagement
Framework
1: selectService( )
2: initiateSignServiceAgreement( )
3: signServiceAgreement( )
4: signServiceAgreement( )
46
Framework-to-Service APIs
Service Registration
1.
Register service with service type name, service property
2.
list(service property name, service property value)
Announce service availability to the application
47
New SCF Registration
SCS
:
IpFwServiceRegistration
1: registerService( )
2: announceServiceAvailability( )
48
IP800 Parlay Application
IN Application
I want to connect to CC for exchange 333
But where is it?
I can only connect to exchange 333,330
IP network
Parlay
CC 1
333
330
Parlay
CC 2
410
412
Parlay
CC 3
510
512
Parlay
CC 4
667
hardwired
Parlay
CC 5
719
CC
333
330
49
IP800 Parlay Application
IP800 Parlay Application
I want to connect to CC for exchange 333
But where is it?
I can use the framework service to find out the host address
of exchange 333
I want to connect to CC for exchange 333
But where is it?
I can maintain a map of exchange numbers
and hosts address
IP network
Parlay
CC 1
333
330
Parlay
CC 2
410
412
Parlay
Framework
Service
Parlay
CC 3
510
512
IP network
Parlay
CC 1
333
330
Parlay
CC 2
410
412
Parlay
CC 3
510
512
50
IP network
Parlay
CC 1
333
330
Parlay
CC 2
410
412
Parlay
CC 3
510
512
Parlay
Framework
Service
CC 333 330
CC 410 412
CC 510 512
CC1
CC2
CC3
51
Framework-to-Service APIs
Sign Service Agreement
1.
2.
3.
4.
5.
6.
7.
Select service using service ID (from service discovery
interface) for the application
Sign the service agreement by the Framework
Sign the service agreement by the application
Identify the signature of the application
Use the service manager to contact the service
Create a new service manager to be used for callback by the
application
Set the callback interface
52
Sign Service Agreement
AppLogic
:
IpAppServ iceAgreementManagement
: IpAppCallControlManager
: IpInitial
:
IpServ iceAgreementManagement
GenericCallControlServ ice :
IpServ iceInstanceLif ecy cleManager
: IpCallControlManager
We assume that the application is already authenticated and discov ered the serv ice it wants to use
1: selectServ ice( )
2: signServ iceAgreement( )
3: signServ iceAgreement( )
4: createServ iceManager( )
5: new()
6: new()
7: setCallback( )
53
Framework-to-Service APIs
Integrity Management
o
Load management
Service callback registration and load control
Client and Service Load Balancing
o
Heartbeat Management
Start/perform/end heart supervision of the service
o
Fault Management
Service requests Framework activity test
Service requests Application activity test
Application requests service activity test
Application detects service is unavailable
54
Framework-to-Service APIs
Load Management
Service callback registration and load control
Client and Service Load Balancing
55
Load Management—Service callback registration and load control
: IpSvcLoadManager
: IpFwLoadManager
1: createLoadLevelNotification( )
2: load change detection & policy evaluation
3: loadLevelNotification( )
This is the
implementation detail
Framework detects its
load condition change
and initiates load control
action
4: load change detection & policy evaluation
5: loadLevelNotification( )
This is the
implementation detail
6: destroyLoadLevelNotification( )
56
Load Management—Client and Service Load Balancing
Application :
IpAppLoadManager
Fram ework :
IpLoadManager
:
IpFwLoadManager
Service :
IpSvcLoadManager
Fram ework checks
application load.
1: queryAppLoadReq( )
2: queryAppLoadRes ( )
Depending on the load, the
fram ework m ay choos e to s top
s ending notifications to the
application, to allow its load to
reduce.
3: s us pendNotification( )
4: querySvcLoadReq( )
The fram ework m ay then check
the load on the s ervice, and take
action if (according to the load
balancing policy) if required.
5: querySvcLoadRes ( )
57
Framework-to-Service APIs
Heartbeat Management
1. Request the service to send its heartbeat
2. Send heartbeat at the specified interval by the
service
3. Detect the service by the Framework via
heartbeat within the specified interval
4. Take some recovery action by the Framework
58
Heartbeat Management—Start/perform/end heartbeat supervision of the service
Framework
:
IpFwHeartBeat
:
IpSvcHeartBeatMgmt
1: enableSvcHeartBeat( )
2: pulse( )
3: pulse( )
At a certain point of
time the framework
decides to stop
heartbeat supervision
4: disableSvcHeartBeat( )
59
Framework-to-Service APIs
Fault Management
Service requests Framework activity test
Ask activity test done by the Framework
Return the result to the service
Service requests Application activity test
Invoke an activity test on a client application by the Framework
Ask the application to do the activity test
Return the result to the Framework by the application
Pass the result from its application to its service internally
Application requests service activity test
Application detects service is unavailable
60
Fault Management—Service requests Framework activity test
Framework :
IpFwFaultManager
Service :
IpSvcFaultManager
1: activityTestReq( )
The Service requests that the
Framework does an activity test.
2: activityTestRes( )
61
Framework-to-Service APIs
Fault Management
Service requests Framework activity test
1. Ask activity test done by the Framework
2. Return the result to the service
62
Fault Management—Service requests Application activity test
Service :
IpSvcFaultManager
Framework :
IpFaultManager
1: activityTestReq( )
:
IpFaultManager
Application :
IpAppFaultManager
The Framework identifies the service
instance to conclude which
Application the test is directed at, and
comunicates internally to Framework
interface to the Application.
2: appActivityTestReq( )
3: appActivityTestRes( )
The application
carries out the
activity test and
returns the result to
the Framework.
Internal Framework
Communications.
4: activityTestRes( )
63
Framework-to-Service APIs
Fault Management
Service requests Application activity test
1. Invoke an activity test on a client application by the
Framework
2. Ask the application to do the activity test
3. Return the result to the Framework by the application
4. Pass the result from its application to its service
internally
64
Fault Management—Application requests Service activity test
Client Application :
IpAppFaultManager
Framework :
IpFaultManager
:
IpFwFaultManager
Service :
IpSvcFaultManager
The client application asks the
framework to carry out the
activity test on a service.
1: activityTestReq( )
The Framework identifies which
service the test is directed at by the
svcID parameter, and
communicates internally with the
appropriate framework interface.
Which invokes the call on the
service.
2: svcActivityTestReq( )
Service does test and
returns the result.
Framework passes result
internally from service facing
part to application facing part,
and sends the result to the
application.
3: svcActivityTestRes( )
4: activityTestRes( )
65
Framework-to-Service APIs
Fault Management
Application requests service activity test
1. Invoke an activity test on a service by the
Framework
2. Ask the service to do the activity test
3. Return the result to the Framework by the service
4. Pass the result from its service to its application
internally
66
Fault Management—Application detects Service is unavailable
Client Application :
IpAppFaultManager
Framework :
IpFaultManager
:
IpFwFaultManager
Service :
IpSvcFaultManager
The application detects that
the service is not responding,
so it informs the framework via
the svcUnavailableInd method
and then ceases use of the
service.
1: svcUnavailableInd( )
The framework informs the
service that the application
is no longer using it.
2: appUnavailableInd( )
67
Framework-to-Enterprise Operator API
Service Subscription Model
Enterprise Operator
Client Applications
Subscription Assignment Group(SAG)
Service Contract
Service Profile
Relationship Between Client Applications/SAG,
Service Contract and Service Profile
Behavior of Service Subscription
Service Discovery
Subscription Management
68
Framework-to-Enterprise Operator API
Enterprise Operator
A role of subscriber/customer of services
For example: A financial institution such as a Bank or
Insurance Company, or possible an Application Service
Provider
69
Framework-to-Enterprise Operator API
Client Applications
The role of user/customer of the services
70
Subscription Business Model
Enterprise Operator (In the role
of Service Subscriber)
Signs contract about service usage
Framework (In the role
of Service Retailer)
Authorises
Uses service
Client Application (In the role of
User or Consumer of Services)
71
Framework-to-Enterprise Operator API
Subscription Assignment Group
A sub-set of client applications in an enterprise
operator domain on the Framework
One or more SAGs in enterprise operator domain
A client application in one or multiple SAGs
72
Framework-to-Enterprise Operator API
Service Contract
A number of services subscribed by the
enterprise operator
The restriction usage of a service at subscription time
73
Framework-to-Enterprise Operator API
Service Profile
A restriction of the service contract in order to
provide restricted service feature to a SAG
One or more service profiles in a service contract
One service profile each SAG in the enterprise operator
domain
Different service parameters (or service properties) of a
service for restriction of SAG’s needs
74
Framework-to-Enterprise Operator API
Relationship Between Client Applications/SAG,
Service Contract and Service Profile
Client Applications is related to the enterprise operator for
usage of a service (subscribe first)
Each client application is part of at least one SAG
A SAG can have multiple Service Profiles associated it
A Service Profile per service defines the preferences of the
SAG members for the usage of that service
Enterprise operator can group client applications in a set of
SAGs and assign a particular Service Profile to each group
A client application can be assigned to more than one
service profile for a given service without date overlap in
the service profiles
75
Relationship between Client Applications/SAG, Service Contract and
Service Profiles
Client Applications and SAGs in the Enterprise Domain
Service Contracts for Individual Services
Subscribed by Enterprise Operator
ca1,
ca2,
ca3
SAG1
ca4,
ca5, ca6,
ca7, ca8,
ca9
SAG2
SC2
ca10, ca11,
ca12, ca13,
SC1
SC4
SC3
SAG3
Assignment of ClientApps/ SAGs to Service Profiles
SP2
SP3
SP1
SP5
SP4
Service Profiles in a Service Contract
76
Framework-to-Enterprise Operator API
Service Discovery
Enterprise operator knows the existence of the service
Obtains a list of service types
Find out the set of properties applicable to a particular
service type
Discover the desired service
Subscribe the service with service contract
Access the subscribed services by the client applications
Select the services to initiating the use later
Sign the service agreement to avoid the repudiation
Start the service
77
:
EnterpriseOperator
:
ClientApplication
: IpAccess
: IpServiceDiscovery
: IpServiceContractManagement
: IpServiceContractInfoQuery
: IpServiceProfileManagement
: IpServiceProfileInfoQuery
Auth. phase
followed by
1: obtainInterface( )
2: listServiceTypes( )
3: describeServiceType( )
Find desired
Services
4: discoverService(
)
5: obtainInterface( )
Subscribe
the Services
6: createServiceContract( )
create more
SPs in SC
7: createServiceProfile( )
8: assign( )
9: modifyServiceProfile( )
10: assig n( )
11: describeServiceProfile( )
12: deleteServiceProfile( )
13: modifyServiceContract( )
14: listSubscribedServices( )
15: listSubscribedServices( )
16: describeServiceContract( )
17: createServiceContract( )
78
Framework-to-Enterprise Operator API
Subscribe the service with service contract
Create an account for the enterprise operator
Create accounts for all of the client applications in
enterprise operator domain
Obtain interfaces to manage the subscription accounts
Register the client applications associating a service
profile
Assign the related client applications to a Subscription
Assignment Group (SAG)
Manage the SAG
79
Enterpri se
Ope rator
Framework
Ope rator
: IpAccess
:
IpEntOpAccountMana gement
:
IpEntOpAccountInfoQuery
:
IpCl i entAppManagem ent
:
IpCl i entAppInfoQuery
T he Enterpri se Operator
account has al ready been cre ated.
Auth. Phase fol l owed by:
1: obtai nInterface( )
2: descri b eEntOpAcco unt( )
3: modi fyEntOpAccount( )
4: obtai nInterface( )
5: createCl i entApp( )
Create more cl i ent
apps
6: createSAG( )
7: addSAGMem bers( )
8: modi fyCl i entApp( )
9: modi fySAG( )
10: del ete Cl i entApp( )
11: removeSAGMembers( )
12: modi fySAG( )
13: obtai n Interface( )
14: l i stSAGs( )
15: l i stSAGMembers( )
16: del ete EntOpAccou nt( )
80
Thank You!
81