Top Banner
Session 7b Future Ideas Analysis of Design Patterns for Composite Telco Services Corrado Moiso - Strategy & Innovation, Telecom Italia R. Minerva, A. Manzalini - Strategy & Innovation, Telecom Italia P. Baglietto, M. Maresca, M. Stecca - CIPI University of Genoa and Padua All rights reserved
22
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Design patterns - ICIN 2010

Session 7bFuture Ideas

Analysis of Design Patternsfor Composite Telco Services

Corrado Moiso - Strategy & Innovation, Telecom Italia

R. Minerva, A. Manzalini - Strategy & Innovation, Telecom ItaliaP. Baglietto, M. Maresca, M. Stecca - CIPI University of Genoa and Padua

All

rig

hts

re

serv

ed

Page 2: Design patterns - ICIN 2010

N°2

All

rig

hts

re

serv

ed

The issue• IT-based interfaces to monitor and control Telco capabilities are a

consolidated approach:– services defined as a combination of functions offered by them;

• Telco composite services strongly rely on:– processing of asynchronous events generated by the capabilities; – executing (concurrent) activities;– handling long-running transactions with several interactions with

the capabilities; • The languages adopted for Telco composite services must:

– dynamically create, destroy and synchronize execution threads;– receive and process asynchronous events;– build and maintain logical contexts to execute long-running

transactions; • The complexity of these mechanisms suggests to define a set of

(language independent) design patterns;

Page 3: Design patterns - ICIN 2010

N°3

All

rig

hts

re

serv

ed

Composite servicesa reference model

CompositeService

Component

Service

Component

Service

Component

Service

TelcoCapability

Telco Capability

Telco Capability

Heterogeneous protocols(e.g., capability specific)

Interfaces based on basic interaction primitives

CommandAssistEvent

Basic interactionprimitives

Page 4: Design patterns - ICIN 2010

N°4

All

rig

hts

re

serv

ed

Basic interaction primitives

• Command: – the application issues a request (e.g., an action

invocation, or a data access); the capability processes it and immediately returns a response;

• Event: – the capability notifies an event to an application which

previously expressed an interest;

• Assist: – the capability sends a request to an application

(previously registered) which returns a response with the instruction on how to perform an action;

Page 5: Design patterns - ICIN 2010

N°5

All

rig

hts

re

serv

ed

Composite Service Component Service

Command

Commands processed by the Component Service

CommandResThe Composite Service waits for the result

Command

CommandRes

Request-Response interaction pattern

Client-Server interactions

Page 6: Design patterns - ICIN 2010

N°6

All

rig

hts

re

serv

ed

Command (Subscribe: EventDescr, CBref)

CommandRes (SubscribeRes: SubID)

Subscription to a specific event class to start notifications

Command (UnSubscribe: SubID)

CommandRes (UnSubscribeRes: SubID)Unsubscription to stop notifications

Event1Event (Notify: Event1, SubID)Processing of

events performed by Composite Service according to the logic of CBref

Eventn

Events of the Component Service (notified to all the subscribed application)

Event (Notify: Eventn, SubID)

Composite Service Component Service

Notification interaction pattern

Pub-Sub model

Page 7: Design patterns - ICIN 2010

N°7

All

rig

hts

re

serv

ed

Event (ChangeStatus, SessID)

Command (ModifyExecution, SessID)

Monitoring and control (in pull and/or push mode via CBref) of the activity

Execution of the activity performed by the Component Service

Assist (InstructionRequest, SessID)

The Component Service starts of a new “activity”

Command (StartActivity: Descr, CBref)

CommandRes (StartRes: SessID)

Composite Service Component Service

Request-started transaction interaction pattern

Application-started Transaction

Page 8: Design patterns - ICIN 2010

N°8

All

rig

hts

re

serv

ed

Command (Subscribe: ActivityDescr,CBref)

CommandRes (SubscribeRes: SubID)

Subscription to a specific class of activities that the application has to monitor/control

Notification of an activity to be controlled by the subscribed application

Assist (Activity, SubID, SessID)

AssistRes(Instruction)

Composite Service Component Service

Solicit-started transactioninteraction pattern

Component Service-started Transaction

Monitoring and control (in pull and/or push mode) of the activity

Execution of the activity performed by the Component Service

Event (ChangeStatus, SessID)

Command (ModifyExecution, SessID)

Assist (InstructionRequest, SessID)

Page 9: Design patterns - ICIN 2010

N°9

All

rig

hts

re

serv

ed

Interaction Patterns and existing interfaces – some examples

Interaction Pattern

Examples from OSA

Examples from Parlay X

Examples from Ribbit

Examples from Ringful

Request-Response

User Location (pull mode)

Short Messaging - Receive (pull mode)

API – Messages(send and retrieval)

SMS API - SendSms (without response)

NotificationUser Location

(periodic/ triggered events)

Terminal Loc. (periodic/ triggered

events)

API - Messages (reception of events)

Request-started trans.

Multi-Party Call (appl. initiated)

  API - Calls Conference Call API

Request-started trans.

(only pull)Charging Session Third Party Call

Solicit-started transaction

Multi-Party Call (network initiated)

Call Direction

Page 10: Design patterns - ICIN 2010

N°10

All

rig

hts

re

serv

ed

MakeCallSessionReq(Leg1, Leg2)

MakeCallSessionRes(CallSessionIdentifier)

EndCallSessionReq(CallSessionIdentifier)

EndCallSessionRes()

Composite Service Third Party Call Service

The thread periodically

polls the state of the

call

GetCallSessionInformationRes(CallInfo)

GetCallSessionInformationReq(CallSessionIdentifier)

GetCallSessionInformationRes(CallInfo)

GetCallSessionInformationReq(CallSessionIdentifier)

Request-started transactionin Parlay X 3rd Party Call

• Parlay X 3rd Party Call does not support notification:– the call are monitored/controlled in pull-mode;

The Component Service starts of a new call

Page 11: Design patterns - ICIN 2010

N°11

All

rig

hts

re

serv

ed

Composite Service Call APIApplication API

PUT /apps/mydomain:myapp/ { "notificationUrl" : Ref}

200 OK {Appl-Info}POST /rest/1.0/calls/… { "legs":[Leg1, Leg2]}

201 CREATED LOCATION Call-Id

POST Json={Call-Event}Event processed by Ref

Events on call evolution

POST Json={Call-Event}

PUT /rest/1.0/calls/Call-Id { "active":false }

200 OK { Call-Info}

Request-started transactionin Ribbit Call Control

• Ribbit allows to control calls also in push-mode:– combined use of Call and Event APIs;

Page 12: Design patterns - ICIN 2010

N°12

All

rig

hts

re

serv

ed

Design Patterns

• Provide guidelines on how to implement composite services interacting with component services;

• A design pattern for each interaction pattern:– describe the structure of an orchestrator

defining the composition logic;

• Language independent:– possible mappings on Java and WS-BPEL;

Page 13: Design patterns - ICIN 2010

N°13

All

rig

hts

re

serv

ed

Request-started transactionDesign Pattern

• The orchestrator has to perform the following operations: – setup a Software Listener to handle push-mode control– send the request that initiates the transaction:

• the request include the callback URL to the Software Listener• the response returns a Context_ID;

–manage the creation/interaction of threads:• for each (new) Context_ID the orchestrator activates a long

running thread in charge of:– managing and monitoring the resource activity and– proactively performing some operations;

• a long running thread:– is executed in parallel with other long running threads;– is triggered by events tagged with the associated Context_ID;– works on its own data and on some information shared with other

threads;

Page 14: Design patterns - ICIN 2010

N°14

All

rig

hts

re

serv

ed

Design Patterns mapping

• BPEL based solution:– need to follow the BPEL syntax and organization;

– support developers through low level features (e.g., automatic correlation event - CS instance);

• Plain Java object based solution:– more flexible than BPEL based solution;

– significant skill and effort to the developers;

– re-implement the patterns every time a new CS is developed;

Page 15: Design patterns - ICIN 2010

N°15

All

rig

hts

re

serv

ed

Some open issues: Composite Service Session ID• the Orchestrator Execution Platform should use csSessionIDs to:

– identify CS sessions/instances executed simultaneously;– associate events to the appropriate CS Sessions, in case of a

Callback based Design Pattern; • SubID and SessID may not be sufficient to handle csSessionIDs:

– they are at service level, and not at CS instance level;– they are related to specific component services;

• csSessionIDs are not properly considered in the APIs for capabilities:– it is necessary to manage the correspondence between the

csSessionIDs coming from the Orchestrator and the events issued by the Components;

Possible solutions1. adding a software module between Orchestrator and Component Services:

2. extending callback-based APIs with a general purpose parameter (extrainfo);

Page 16: Design patterns - ICIN 2010

N°16

All

rig

hts

re

serv

ed

Parental Control Service – a use case

• the service:– it controls the location of a child’s terminal;

– as soon as the user leaves a defined area two third party calls (e.g., to the mother, and to the father) are triggered at the same time;

– as soon as one call is activated, the other is dropped;

• the composite service orchestrates:– Parlay X Location: “Notification Design Pattern”;

– Ribbit Call and Event APIs: “Request Started Transaction Design Pattern”;

Page 17: Design patterns - ICIN 2010

N°17

All

rig

hts

re

serv

ed

BPEL for Parental Control Service

NotificationDesign Pattern

Request StartedTransaction

Design Pattern

Page 18: Design patterns - ICIN 2010

N°18

All

rig

hts

re

serv

ed

Parental Control Service:the role of csSessionIDs• A BPEL-based Orchestrator provides the Correlation Set

concept for csSessionID management (e.g., to dispatch incoming messages);

• Unfortunately it is not possible to take advantage of this mechanism with the current generation APIs:– most of them do not include extraInfo parameter, to exchange

the csSessionID between Orchestrator and external services;

• For instance:– in the parental control service the BPEL engine would

not be able to dispatch the incoming events (e.g., Call instantiated) to the appropriate BPEL instances;

APIs without extraInfo parameter are not suitable to be combined by means of widely used BPEL language

Page 19: Design patterns - ICIN 2010

N°19

All

rig

hts

re

serv

ed

The role of csSessionIDs in Java

• The usage of the extraInfo parameter is very useful also when implementing the design patterns in Java:– it supports the correlation between the incoming events and the corresponding

Orchestration Sessions • For instance:– a Java-based Orchestrator may use a table storing the set of the csSessionIDs of the active

Sessions, e.g.: • an HashMap: <csSessionID, instance_ref>;

– it can be matched with the extraInfo parameter contained in the incoming events notifications;

Page 20: Design patterns - ICIN 2010

N°20

All

rig

hts

re

serv

ed

Lessons learnt (1/2)

• higher degree of flexibility and efficiency in the interactions with Service Components requires the use of a more complex design pattern, e.g.,• notifications in addition to the commands• retrieve information in push mode rather than in pull mode• handling of multiple service sessions

• the complexity of the design patterns does not depend on the protocol used to define the interfaces (e.g., CORBA, SOAP, REST):• it depends on the expression power of the interactions enabled

by the interfaces

The definition of APIs for Telco Capabilities must carefully identify the interaction patterns

(instead of the protocols to adopt)

Page 21: Design patterns - ICIN 2010

N°21

All

rig

hts

re

serv

ed

Lessons learnt (2/2)

• the composition/orchestration of multiple interfaces requires the definition of CS SessionIDs at the level of Composite Service:

• they identify a specific session/instance of the composite service

• they are needed to properly route events to the service session in charge of their execution

Signatures of APIs for Telco Capabilities should be extended with a new parameter to pass “CS Session ID” between Composite Service and Service Components

Page 22: Design patterns - ICIN 2010

N°22

All

rig

hts

re

serv

ed

Thanks !Questions?