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
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
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
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
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
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;
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;
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;
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;
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);
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”;
N°17
All
rig
hts
re
serv
ed
BPEL for Parental Control Service
NotificationDesign Pattern
Request StartedTransaction
Design Pattern
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
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;
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)
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