The document discusses design patterns for composite telecommunications services. It presents basic interaction primitives like command, event, and assist. It then analyzes common interaction patterns like request-response, notification, and request-started transaction. It proposes using these patterns and primitives as language-independent design patterns for composite services. It also discusses issues around handling multiple service sessions and the need to include session identifiers in component service APIs.

1. 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

2. 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;

3. Composite services a reference model Composite Service Component Service Component Service Component Service Telco Capability Telco Capability Telco Capability Heterogeneous protocols (e.g., capability specific) Interfaces based on basic interaction primitives Command Assist Event Basic interaction primitives

4. 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;

5. Request-Response interaction pattern Client-Server interactions Composite Service Component Service Command Commands processed by the Component Service CommandRes The Composite Service waits for the result Command CommandRes

6. Notification interaction pattern Pub-Sub model Command (Subscribe: EventDescr, CBref ) CommandRes (SubscribeRes: SubID ) Subscription to a specific event class to start notifications Composite Service Component Service Command (UnSubscribe: SubID ) CommandRes (UnSubscribeRes: SubID ) Unsubscription to stop notifications Event1 Event (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 )

7. Request-started transaction interaction pattern Application-started Transaction The Component Service starts of a new “activity” Command (StartActivity: Descr, CBref ) CommandRes (StartRes: SessID ) Composite Service Component Service 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 )

8. Solicit-started transaction interaction pattern Component Service-started Transaction Command (Subscribe: ActivityDescr,CBref) CommandRes (SubscribeRes: SubID ) Subscription to a specific class of activities that the application has to monitor/control Composite Service Component Service Notification of an activity to be controlled by the subscribed application Assist (Activity, SubID , SessID ) AssistRes(Instruction) 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 )

9. 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) Notification User 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

10. Request-started transaction in Parlay X 3rd Party Call Parlay X 3rd Party Call does not support notification: the call are monitored/controlled in pull-mode; MakeCallSessionReq(Leg1, Leg2) MakeCallSessionRes( CallSessionIdentifier ) Composite Service Third Party Call Service The Component Service starts of a new call EndCallSessionReq( CallSessionIdentifier ) EndCallSessionRes() The thread periodically polls the state of the call GetCallSessionInformationRes(CallInfo) GetCallSessionInformationReq( CallSessionIdentifier ) GetCallSessionInformationRes(CallInfo) GetCallSessionInformationReq( CallSessionIdentifier )

11. Request-started transaction in Ribbit Call Control Ribbit allows to control calls also in push-mode: combined use of Call and Event APIs; Composite Service Call API Application 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}

12. 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;

13. Request-started transaction Design 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;

14. 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;

15. Some open issues: Composite Service Session ID the Orchestrator Execution Platform should use csSessionID s 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 csSessionID s: they are at service level, and not at CS instance level; they are related to specific component services; csSessionID s are not properly considered in the APIs for capabilities: it is necessary to manage the correspondence between the csSessionID s coming from the Orchestrator and the events issued by the Components; Possible solutions adding a software module between Orchestrator and Component Services: extending callback-based APIs with a general purpose parameter ( extrainfo );

16. 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”;

17. BPEL for Parental Control Service Notification Design Pattern Request Started Transaction Design Pattern

18. Parental Control Service : the role of csSessionID s 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

19. The role of csSessionID s 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;

20. 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)

21. 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

22. Thanks ! Questions?