Towards Automated Composition of Convergent

Services a Survey

Armando Ordonezalowast Vidal Alcazarb Oscar Mauricio Caicedo RendoncelowastPaolo Falcarind Juan C Corralese Lisandro Zambenedetti Granvillec

aIntelligent Management Systems Group - University Foundation of PopayanCalle 5 No 8-58 - Popayan CA Colombia

bPlanning and Learning Group - Universidad Carlos IIIAv Universidad 30 28911 - Leganes MA Spain

cInstitute of Informatics - Federal University of Rio Grande do SulAv Bento Goncalves 9500 - Porto Alegre RS - Brazil

dSchool of Architecture Computing and Engineering - University of East London4-6 University Way E16 2RD London UK

eGrupo de Ingenieria Telematica- Universidad del CaucaCalle 5 No 4-70 - Popayan CA - Colombia

Abstract

A convergent service is defined as a service that exploits the convergence ofcommunication networks and at the same time takes advantage of features ofthe Web Nowadays building up a convergent service is not trivial becausealthough there are significant approaches that aim to automate the servicecomposition at different levels in the Web and Telecom domains selectingthe most appropriate approach for specific case studies is complex due tothe big amount of involved information and the lack of technical consider-ations Thus in this paper we identify the relevant phases for convergentservice composition and explore the existing approaches and their associatedtechnologies for automating each phase For each technology the maturityand results are analysed as well as the elements that must be consideredprior to their application in real scenarios Furthermore we provide researchdirections related to the convergent service composition phases

lowastCorresponding authorEmail addresses armandoordonezdocentefupeduco (Armando Ordonez )

valcazarinfuc3mes (Vidal Alcazar) omcrendoninfufrgsbr (Oscar MauricioCaicedo Rendon) falcarinuelacuk (Paolo Falcarin) jcorralunicaucaeduco (Juan C Corrales) granvilleinfufrgsbr (Lisandro Zambenedetti Granville)

Preprint submitted to Computer Networks June 25 2015

Keywords Automated composition Computer Networks MashupsTelecom20 Web Services

1 Introduction

The telecomunication and computer network industries are facing a greatshift from atomic services (eg voice and email) towards much more dy-namic convergent services such as unified social networking and integratedvideo conferencing Under this premise telco and computer network opera-tors need to transform themselves from simple operators into services aggre-gators carrying the duty of providing services that bring together numerousapplications from a variety of sources [1]

The term ldquoconvergentrdquo has been used widely in telecommunication andcomputer networks with two meanings to describe the fusion of fixed andmobile services [2] or as a synonymous of the Next Generation Network(NGN) that is a packet-based network able to transport all type of informa-tion and services like voice data and video integrating traditional telephonynetworks and Internet [3] In this paper we use the term ldquoconvergentrdquo as ef-ficient coexistence of services available on the Telecom (eg voice and videocalls with reverse charging offered by telco operators like Orange and Movis-tar) and Web (eg services of maps and RSS feeds offered by big Internetplayers like Google and Yahoo) domains to provide more services to the user

Telecom services can be created by using Services Creation Environments(SCE) [4] and Mashup Development Environments (MDE) [5] [6] that allowthe users (eg programmers and administrators of telco andor computernetworks) to combine the functionalities of heterogeneous services using drag-and-drop and wire tools for composing new services Such a way of carryingout service composition is valid as long as the number of traditional commu-nication services is low and the reliability of services is high enough (gt 99)so they do not change continually [7]

In the case of the convergent service composition that involve atomicservices from the Web and Telecom domains such services may change theirinterfaces become available or unavailable and their number may also growto unmanageable sizes Both the dynamic nature of services offered by theWeb and the sheer amount of relevant services that may be available on itfor a given task hinder greatly the use of approaches offering semi-automated

2

service composition (ie composition based on MDEs and SCEs) If time isa crucial factor semi-automated service composition may become inefficientwhich raises the need of approaches able to perform fully-automated servicecomposition

Automation is defined as the delegation of tasks to machine or computersystems thus reducing procedural load and freeing operators from vigilanceover routine and tedious tasks [8] Several approaches have appeared tofully automate the composition of services available in the Web from bothacademia [9] [10] [11] [12] [13] [14] and industry [15] [16] Similarly some re-search has revolved around fully automation of communication service com-position coming mainly from European Projects [17] [18] Considering theevolution of service composition in the Telecom and Web domains we raisethe first research question addressed in this paper Which is the level of au-tomation that has been achieved to date from previous service compositionapproaches

In addition to the aforementioned automation it is important to considerthat the service composition carried out in the Telecom fundamentally dif-ferent of the conducted in the Web which means that some technical issuesmust be contemplated when combining services from both domains [19] [20]Moreover several other characteristics pertaining to specific application do-mains like user preferences response time adaptability and scalability mustbe taken into account This is because the fact that convergent service com-position often involves the challenge of merging two areas of knowledge withtheir respective concepts technologies and architectures For this reason asystematic way of analysing the strengths and weaknesses of each existingsolution for a particular application domain is needed In this way we raisethe second research question addressed in this paper Which elements mustbe considered for applying automated services composition in different specificdomains

Convergent service composition is also a complex process that often in-volves several elaborated steps or phases from processing the input to selec-tion of services to its execution As these phases often focus on one or moreaspects of the service composition process it is needed to classify them Inthis way we raise the third research question addressed in this paper Whichare the phases for convergent service composition and the approaches usefulin each one of them

The above raised research questions indicate that building up a conver-gent service is not trivial because although there are significant approaches

3

that aim to automate the service composition at different levels in the Webtelco networks and computer networks selecting the most appropriate ap-proach(es) for specific case studies is complex due to the big amount ofinvolved information and the lack of technical considerations Thus in thispaper we identify the relevant phases for convergent service compositionand explore the existing approaches and their associated technologies forautomating each phase For each technology the maturity and results areanalysed as well as the elements that must be considered prior to their ap-plication in real scenarios Furthermore we provide research directions inthe convergent service composition phases

The research conducted to answer the raised questions led to the followingcontributions

bull Identify the relevant phases for convergent service composition

bull Explore and analyze the existing approaches and their associated tech-nologies for automating each phase

bull Provide research directions in each one of convergent service composi-tion phases

The remainder of this paper is organized as follows In Section 2 wepresent the methodology followed to build up this survey In Section 3 wereview foundations about service composition In Section 4 we introducethe phases for convergent service composition In Section 5 6 and 7 wedescribe and discuss each phase and its associated approaches In Section8 we present research directions Finally in Section 9 we provide someconclusions that help to select approaches for convergent service composition

2 Methodology

To solve the research questions we follow the next steps [21] (i) formalizethe service composition process by defining different phases (ii) classify theexisting approachess under the umbrella of requirements and criteria for theirapplication in convergent composition and (iii) define the guidelines foremploying diverse approaches and their technologies in convergent servicecomposition

In this paper we carry out a comparative literature review [22] aimingto identify the existing approaches in service composition in recent years

4

through the lens of its applicability in convergent composition of services Inorder to select the works presenting the approaches useful for our study weintroduced search keywords on three electronic databases ACM IEEE andScience Direct As convergent composition is a relatively new field we do notexpect to find many publications using the exact keyword Therefore we usedthe following keyword phrases ldquoconvergent service compositionrdquo ldquoautomaticservice compositionrdquo ldquoautomated service compositionrdquo ldquoTelecom 20 servicecompositionrdquo and ldquomashup compositionrdquo We found 250 works Afterwardswe looked through the titles of such works to eliminate those not related tothe field for the rest we browsed the abstracts to estimate their relevanceand whether they have experimental results We selected both recent worksfrom recognized conferences and relevant ones from high impact journals Asa result 65 works were selected for a full-text review

Table 1 and Table 2 present in no order of relevance the works selectedfor reviewing These works are analysed according to the phase (ie adap-tation creation execution and generation) the origin of the proposed (ieacademy industry and from both in alliance) the domain (ie Web Tele-com and convergent - deals with methods for convergent composition) thelevel of automation provided to users (ie high medium low when usersparticipate little in the process or needs to know little about technical is-sues higher is the automation) the use of semantic in any of the phasesabove mentioned and the result of the work (ie prototype model prod-uct and standard) The detail of the literature review as well as the rest ofthe analysis carried out in this paper are presented in the following chapters

Table 1 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[23] Creation Both Convergent Medium Prototype[24] Creation execution Both Convergent Medium X Prototype[25] Creation Academic Convergent Medium Prototype[26] Creation execution Both Convergent Medium Prototype[27] Creation execution Both Convergent Medium X Prototype[28] Adaptation execution Academic Convergent High X Prototype[29] Adaptation execution Academic Convergent High X Prototype[30] Creation execution Academic Convergent Medium X Prototype[31] Creation execution Academic Convergent Medium X Prototype[32] Creation execution Both Convergent Medium X Model[33] Creation execution Industry Convergent Medium X Prototype[34] Creation execution Academic Convergent Medium Model[35] Creation execution Academic na High X Prototype[36] Creation execution Academic na High X Prototype

5

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Keywords Automated composition Computer Networks MashupsTelecom20 Web Services

1 Introduction

The telecomunication and computer network industries are facing a greatshift from atomic services (eg voice and email) towards much more dy-namic convergent services such as unified social networking and integratedvideo conferencing Under this premise telco and computer network opera-tors need to transform themselves from simple operators into services aggre-gators carrying the duty of providing services that bring together numerousapplications from a variety of sources [1]

The term ldquoconvergentrdquo has been used widely in telecommunication andcomputer networks with two meanings to describe the fusion of fixed andmobile services [2] or as a synonymous of the Next Generation Network(NGN) that is a packet-based network able to transport all type of informa-tion and services like voice data and video integrating traditional telephonynetworks and Internet [3] In this paper we use the term ldquoconvergentrdquo as ef-ficient coexistence of services available on the Telecom (eg voice and videocalls with reverse charging offered by telco operators like Orange and Movis-tar) and Web (eg services of maps and RSS feeds offered by big Internetplayers like Google and Yahoo) domains to provide more services to the user

Telecom services can be created by using Services Creation Environments(SCE) [4] and Mashup Development Environments (MDE) [5] [6] that allowthe users (eg programmers and administrators of telco andor computernetworks) to combine the functionalities of heterogeneous services using drag-and-drop and wire tools for composing new services Such a way of carryingout service composition is valid as long as the number of traditional commu-nication services is low and the reliability of services is high enough (gt 99)so they do not change continually [7]

In the case of the convergent service composition that involve atomicservices from the Web and Telecom domains such services may change theirinterfaces become available or unavailable and their number may also growto unmanageable sizes Both the dynamic nature of services offered by theWeb and the sheer amount of relevant services that may be available on itfor a given task hinder greatly the use of approaches offering semi-automated

2

service composition (ie composition based on MDEs and SCEs) If time isa crucial factor semi-automated service composition may become inefficientwhich raises the need of approaches able to perform fully-automated servicecomposition

Automation is defined as the delegation of tasks to machine or computersystems thus reducing procedural load and freeing operators from vigilanceover routine and tedious tasks [8] Several approaches have appeared tofully automate the composition of services available in the Web from bothacademia [9] [10] [11] [12] [13] [14] and industry [15] [16] Similarly some re-search has revolved around fully automation of communication service com-position coming mainly from European Projects [17] [18] Considering theevolution of service composition in the Telecom and Web domains we raisethe first research question addressed in this paper Which is the level of au-tomation that has been achieved to date from previous service compositionapproaches

In addition to the aforementioned automation it is important to considerthat the service composition carried out in the Telecom fundamentally dif-ferent of the conducted in the Web which means that some technical issuesmust be contemplated when combining services from both domains [19] [20]Moreover several other characteristics pertaining to specific application do-mains like user preferences response time adaptability and scalability mustbe taken into account This is because the fact that convergent service com-position often involves the challenge of merging two areas of knowledge withtheir respective concepts technologies and architectures For this reason asystematic way of analysing the strengths and weaknesses of each existingsolution for a particular application domain is needed In this way we raisethe second research question addressed in this paper Which elements mustbe considered for applying automated services composition in different specificdomains

Convergent service composition is also a complex process that often in-volves several elaborated steps or phases from processing the input to selec-tion of services to its execution As these phases often focus on one or moreaspects of the service composition process it is needed to classify them Inthis way we raise the third research question addressed in this paper Whichare the phases for convergent service composition and the approaches usefulin each one of them

The above raised research questions indicate that building up a conver-gent service is not trivial because although there are significant approaches

3

that aim to automate the service composition at different levels in the Webtelco networks and computer networks selecting the most appropriate ap-proach(es) for specific case studies is complex due to the big amount ofinvolved information and the lack of technical considerations Thus in thispaper we identify the relevant phases for convergent service compositionand explore the existing approaches and their associated technologies forautomating each phase For each technology the maturity and results areanalysed as well as the elements that must be considered prior to their ap-plication in real scenarios Furthermore we provide research directions inthe convergent service composition phases

The research conducted to answer the raised questions led to the followingcontributions

bull Identify the relevant phases for convergent service composition

bull Explore and analyze the existing approaches and their associated tech-nologies for automating each phase

bull Provide research directions in each one of convergent service composi-tion phases

The remainder of this paper is organized as follows In Section 2 wepresent the methodology followed to build up this survey In Section 3 wereview foundations about service composition In Section 4 we introducethe phases for convergent service composition In Section 5 6 and 7 wedescribe and discuss each phase and its associated approaches In Section8 we present research directions Finally in Section 9 we provide someconclusions that help to select approaches for convergent service composition

2 Methodology

To solve the research questions we follow the next steps [21] (i) formalizethe service composition process by defining different phases (ii) classify theexisting approachess under the umbrella of requirements and criteria for theirapplication in convergent composition and (iii) define the guidelines foremploying diverse approaches and their technologies in convergent servicecomposition

In this paper we carry out a comparative literature review [22] aimingto identify the existing approaches in service composition in recent years

4

through the lens of its applicability in convergent composition of services Inorder to select the works presenting the approaches useful for our study weintroduced search keywords on three electronic databases ACM IEEE andScience Direct As convergent composition is a relatively new field we do notexpect to find many publications using the exact keyword Therefore we usedthe following keyword phrases ldquoconvergent service compositionrdquo ldquoautomaticservice compositionrdquo ldquoautomated service compositionrdquo ldquoTelecom 20 servicecompositionrdquo and ldquomashup compositionrdquo We found 250 works Afterwardswe looked through the titles of such works to eliminate those not related tothe field for the rest we browsed the abstracts to estimate their relevanceand whether they have experimental results We selected both recent worksfrom recognized conferences and relevant ones from high impact journals Asa result 65 works were selected for a full-text review

Table 1 and Table 2 present in no order of relevance the works selectedfor reviewing These works are analysed according to the phase (ie adap-tation creation execution and generation) the origin of the proposed (ieacademy industry and from both in alliance) the domain (ie Web Tele-com and convergent - deals with methods for convergent composition) thelevel of automation provided to users (ie high medium low when usersparticipate little in the process or needs to know little about technical is-sues higher is the automation) the use of semantic in any of the phasesabove mentioned and the result of the work (ie prototype model prod-uct and standard) The detail of the literature review as well as the rest ofthe analysis carried out in this paper are presented in the following chapters

Table 1 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[23] Creation Both Convergent Medium Prototype[24] Creation execution Both Convergent Medium X Prototype[25] Creation Academic Convergent Medium Prototype[26] Creation execution Both Convergent Medium Prototype[27] Creation execution Both Convergent Medium X Prototype[28] Adaptation execution Academic Convergent High X Prototype[29] Adaptation execution Academic Convergent High X Prototype[30] Creation execution Academic Convergent Medium X Prototype[31] Creation execution Academic Convergent Medium X Prototype[32] Creation execution Both Convergent Medium X Model[33] Creation execution Industry Convergent Medium X Prototype[34] Creation execution Academic Convergent Medium Model[35] Creation execution Academic na High X Prototype[36] Creation execution Academic na High X Prototype

5

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

service composition (ie composition based on MDEs and SCEs) If time isa crucial factor semi-automated service composition may become inefficientwhich raises the need of approaches able to perform fully-automated servicecomposition

Automation is defined as the delegation of tasks to machine or computersystems thus reducing procedural load and freeing operators from vigilanceover routine and tedious tasks [8] Several approaches have appeared tofully automate the composition of services available in the Web from bothacademia [9] [10] [11] [12] [13] [14] and industry [15] [16] Similarly some re-search has revolved around fully automation of communication service com-position coming mainly from European Projects [17] [18] Considering theevolution of service composition in the Telecom and Web domains we raisethe first research question addressed in this paper Which is the level of au-tomation that has been achieved to date from previous service compositionapproaches

In addition to the aforementioned automation it is important to considerthat the service composition carried out in the Telecom fundamentally dif-ferent of the conducted in the Web which means that some technical issuesmust be contemplated when combining services from both domains [19] [20]Moreover several other characteristics pertaining to specific application do-mains like user preferences response time adaptability and scalability mustbe taken into account This is because the fact that convergent service com-position often involves the challenge of merging two areas of knowledge withtheir respective concepts technologies and architectures For this reason asystematic way of analysing the strengths and weaknesses of each existingsolution for a particular application domain is needed In this way we raisethe second research question addressed in this paper Which elements mustbe considered for applying automated services composition in different specificdomains

Convergent service composition is also a complex process that often in-volves several elaborated steps or phases from processing the input to selec-tion of services to its execution As these phases often focus on one or moreaspects of the service composition process it is needed to classify them Inthis way we raise the third research question addressed in this paper Whichare the phases for convergent service composition and the approaches usefulin each one of them

The above raised research questions indicate that building up a conver-gent service is not trivial because although there are significant approaches

3

that aim to automate the service composition at different levels in the Webtelco networks and computer networks selecting the most appropriate ap-proach(es) for specific case studies is complex due to the big amount ofinvolved information and the lack of technical considerations Thus in thispaper we identify the relevant phases for convergent service compositionand explore the existing approaches and their associated technologies forautomating each phase For each technology the maturity and results areanalysed as well as the elements that must be considered prior to their ap-plication in real scenarios Furthermore we provide research directions inthe convergent service composition phases

The research conducted to answer the raised questions led to the followingcontributions

bull Identify the relevant phases for convergent service composition

bull Explore and analyze the existing approaches and their associated tech-nologies for automating each phase

bull Provide research directions in each one of convergent service composi-tion phases

The remainder of this paper is organized as follows In Section 2 wepresent the methodology followed to build up this survey In Section 3 wereview foundations about service composition In Section 4 we introducethe phases for convergent service composition In Section 5 6 and 7 wedescribe and discuss each phase and its associated approaches In Section8 we present research directions Finally in Section 9 we provide someconclusions that help to select approaches for convergent service composition

2 Methodology

To solve the research questions we follow the next steps [21] (i) formalizethe service composition process by defining different phases (ii) classify theexisting approachess under the umbrella of requirements and criteria for theirapplication in convergent composition and (iii) define the guidelines foremploying diverse approaches and their technologies in convergent servicecomposition

In this paper we carry out a comparative literature review [22] aimingto identify the existing approaches in service composition in recent years

4

through the lens of its applicability in convergent composition of services Inorder to select the works presenting the approaches useful for our study weintroduced search keywords on three electronic databases ACM IEEE andScience Direct As convergent composition is a relatively new field we do notexpect to find many publications using the exact keyword Therefore we usedthe following keyword phrases ldquoconvergent service compositionrdquo ldquoautomaticservice compositionrdquo ldquoautomated service compositionrdquo ldquoTelecom 20 servicecompositionrdquo and ldquomashup compositionrdquo We found 250 works Afterwardswe looked through the titles of such works to eliminate those not related tothe field for the rest we browsed the abstracts to estimate their relevanceand whether they have experimental results We selected both recent worksfrom recognized conferences and relevant ones from high impact journals Asa result 65 works were selected for a full-text review

Table 1 and Table 2 present in no order of relevance the works selectedfor reviewing These works are analysed according to the phase (ie adap-tation creation execution and generation) the origin of the proposed (ieacademy industry and from both in alliance) the domain (ie Web Tele-com and convergent - deals with methods for convergent composition) thelevel of automation provided to users (ie high medium low when usersparticipate little in the process or needs to know little about technical is-sues higher is the automation) the use of semantic in any of the phasesabove mentioned and the result of the work (ie prototype model prod-uct and standard) The detail of the literature review as well as the rest ofthe analysis carried out in this paper are presented in the following chapters

Table 1 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[23] Creation Both Convergent Medium Prototype[24] Creation execution Both Convergent Medium X Prototype[25] Creation Academic Convergent Medium Prototype[26] Creation execution Both Convergent Medium Prototype[27] Creation execution Both Convergent Medium X Prototype[28] Adaptation execution Academic Convergent High X Prototype[29] Adaptation execution Academic Convergent High X Prototype[30] Creation execution Academic Convergent Medium X Prototype[31] Creation execution Academic Convergent Medium X Prototype[32] Creation execution Both Convergent Medium X Model[33] Creation execution Industry Convergent Medium X Prototype[34] Creation execution Academic Convergent Medium Model[35] Creation execution Academic na High X Prototype[36] Creation execution Academic na High X Prototype

5

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

that aim to automate the service composition at different levels in the Webtelco networks and computer networks selecting the most appropriate ap-proach(es) for specific case studies is complex due to the big amount ofinvolved information and the lack of technical considerations Thus in thispaper we identify the relevant phases for convergent service compositionand explore the existing approaches and their associated technologies forautomating each phase For each technology the maturity and results areanalysed as well as the elements that must be considered prior to their ap-plication in real scenarios Furthermore we provide research directions inthe convergent service composition phases

The research conducted to answer the raised questions led to the followingcontributions

bull Identify the relevant phases for convergent service composition

bull Explore and analyze the existing approaches and their associated tech-nologies for automating each phase

bull Provide research directions in each one of convergent service composi-tion phases

The remainder of this paper is organized as follows In Section 2 wepresent the methodology followed to build up this survey In Section 3 wereview foundations about service composition In Section 4 we introducethe phases for convergent service composition In Section 5 6 and 7 wedescribe and discuss each phase and its associated approaches In Section8 we present research directions Finally in Section 9 we provide someconclusions that help to select approaches for convergent service composition

2 Methodology

To solve the research questions we follow the next steps [21] (i) formalizethe service composition process by defining different phases (ii) classify theexisting approachess under the umbrella of requirements and criteria for theirapplication in convergent composition and (iii) define the guidelines foremploying diverse approaches and their technologies in convergent servicecomposition

In this paper we carry out a comparative literature review [22] aimingto identify the existing approaches in service composition in recent years

4

through the lens of its applicability in convergent composition of services Inorder to select the works presenting the approaches useful for our study weintroduced search keywords on three electronic databases ACM IEEE andScience Direct As convergent composition is a relatively new field we do notexpect to find many publications using the exact keyword Therefore we usedthe following keyword phrases ldquoconvergent service compositionrdquo ldquoautomaticservice compositionrdquo ldquoautomated service compositionrdquo ldquoTelecom 20 servicecompositionrdquo and ldquomashup compositionrdquo We found 250 works Afterwardswe looked through the titles of such works to eliminate those not related tothe field for the rest we browsed the abstracts to estimate their relevanceand whether they have experimental results We selected both recent worksfrom recognized conferences and relevant ones from high impact journals Asa result 65 works were selected for a full-text review

Table 1 and Table 2 present in no order of relevance the works selectedfor reviewing These works are analysed according to the phase (ie adap-tation creation execution and generation) the origin of the proposed (ieacademy industry and from both in alliance) the domain (ie Web Tele-com and convergent - deals with methods for convergent composition) thelevel of automation provided to users (ie high medium low when usersparticipate little in the process or needs to know little about technical is-sues higher is the automation) the use of semantic in any of the phasesabove mentioned and the result of the work (ie prototype model prod-uct and standard) The detail of the literature review as well as the rest ofthe analysis carried out in this paper are presented in the following chapters

Table 1 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[23] Creation Both Convergent Medium Prototype[24] Creation execution Both Convergent Medium X Prototype[25] Creation Academic Convergent Medium Prototype[26] Creation execution Both Convergent Medium Prototype[27] Creation execution Both Convergent Medium X Prototype[28] Adaptation execution Academic Convergent High X Prototype[29] Adaptation execution Academic Convergent High X Prototype[30] Creation execution Academic Convergent Medium X Prototype[31] Creation execution Academic Convergent Medium X Prototype[32] Creation execution Both Convergent Medium X Model[33] Creation execution Industry Convergent Medium X Prototype[34] Creation execution Academic Convergent Medium Model[35] Creation execution Academic na High X Prototype[36] Creation execution Academic na High X Prototype

5

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

through the lens of its applicability in convergent composition of services Inorder to select the works presenting the approaches useful for our study weintroduced search keywords on three electronic databases ACM IEEE andScience Direct As convergent composition is a relatively new field we do notexpect to find many publications using the exact keyword Therefore we usedthe following keyword phrases ldquoconvergent service compositionrdquo ldquoautomaticservice compositionrdquo ldquoautomated service compositionrdquo ldquoTelecom 20 servicecompositionrdquo and ldquomashup compositionrdquo We found 250 works Afterwardswe looked through the titles of such works to eliminate those not related tothe field for the rest we browsed the abstracts to estimate their relevanceand whether they have experimental results We selected both recent worksfrom recognized conferences and relevant ones from high impact journals Asa result 65 works were selected for a full-text review

Table 1 and Table 2 present in no order of relevance the works selectedfor reviewing These works are analysed according to the phase (ie adap-tation creation execution and generation) the origin of the proposed (ieacademy industry and from both in alliance) the domain (ie Web Tele-com and convergent - deals with methods for convergent composition) thelevel of automation provided to users (ie high medium low when usersparticipate little in the process or needs to know little about technical is-sues higher is the automation) the use of semantic in any of the phasesabove mentioned and the result of the work (ie prototype model prod-uct and standard) The detail of the literature review as well as the rest ofthe analysis carried out in this paper are presented in the following chapters

Table 1 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[23] Creation Both Convergent Medium Prototype[24] Creation execution Both Convergent Medium X Prototype[25] Creation Academic Convergent Medium Prototype[26] Creation execution Both Convergent Medium Prototype[27] Creation execution Both Convergent Medium X Prototype[28] Adaptation execution Academic Convergent High X Prototype[29] Adaptation execution Academic Convergent High X Prototype[30] Creation execution Academic Convergent Medium X Prototype[31] Creation execution Academic Convergent Medium X Prototype[32] Creation execution Both Convergent Medium X Model[33] Creation execution Industry Convergent Medium X Prototype[34] Creation execution Academic Convergent Medium Model[35] Creation execution Academic na High X Prototype[36] Creation execution Academic na High X Prototype

5

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Table 2 Works selected for reviewing

Work Phase Origin Domain Automation Semantic Result

[37] Creation Both Convergent Medium X Prototype[38] All except adaptation Academic Convergent High Prototype[39] All except adaptation Academic Convergent High X Prototype[11] All except adaptation Academic Web High X Prototype[15] Creation Industry Convergent High Product[16] Creation Industry Convergent High Product[40] Creation Industry Convergent Low X Standard[41] Creation Industry Web Low X Standard[42] Creation Industry Web Low X Standard[43] Creation Industry Telecom Medium Product[44] Creation Both Convergent Medium X Prototype[45] Execution Academic Convergent na Prototype[46] Execution Academic Convergent na X Prototype[47] Creation Industry Web na X Standard[48] Execution Academic Convergent na Prototype[49] Adaptation Academic Convergent High Prototype[50] Adaptation Academic Convergent High Prototype[51] Creation Industry Convergent Medium X Prototype[52] Adaptation Academic Convergent High Prototype[53] Adaptation Academic Convergent High Prototype[17] Creation Academic Convergent Medium X Prototype[54] Execution Industry Convergent na Product[55] Execution Industry Convergent na Product[56] Execution Industry Convergent na Product[57] Execution Industry Convergent na Product[58] Execution Industry Telecom na Product[19] Execution Industry Convergent na Prototype[59] Execution Industry Convergent na Prototype[60] Execution Academic Convergent na Standard[61] Execution Industry Communication na Standard[62] Execution Industry Convergent na Standard[63] Execution Industry Convergent na Standard[10] Generation execution Academic Web High Prototype[12] Creation execution Academic Convergent Medium Prototype[13] Creation execution Academic Convergent Medium Prototype[14] Creation execution Academic Convergent Medium Prototype[6] Creation execution Academic Convergent Medium Prototype[64] Generation Academic Web High Prototype[65] Generation Academic Web High X Prototype[66] Generation Academic Web High X Prototype[67] Generation Academic Web High X Prototype[68] Generation Academic Telecom High X Prototype[69] Generation Academic Web High X Prototype[70] Generation Academic Web High Prototype[9] Generation Academic Web High X Prototype[71] Generation Academic Web High X Prototype[72] Creation generation Academic Web High X Prototype[73] Generation Academic Web High X Prototype[5] Creation execution Academic Convergent Medium Prototype[74] Creation execution Academic Convergent Medium Prototype[75] Creation execution Academic Convergent Medium Protoype[76] Creation execution Academic Web Medium X Protoype[77] Creation execution Academic Web Medium X Protoype[78] Creation execution Academic Web Medium X Protoype

3 Foundations on Service Composition

In this section we introduce the concepts of service composition and con-vergent service composition Furthermore we present the differences amongthe services offered in the domains of Telecom and Web as well as current

6

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

approaches for describing such services

31 What is a service

The term ldquoservicerdquo is a commonplace in many fields and therefore dif-ferent definitions can be found in the literature in the workflow area theconcept of e-service is commonly associated with the completion of a task[79] meanwhile in the Web a Web service can be seen as a way to exposethe functionality of an information system and make it available throughstandard Web technologies [80] More precisely the World Wide Web Con-sortium (W3C) - an organization for developing Web standards - defines aWeb service as a software system identified by a URI whose public inter-faces and bindings are defined and described using the eXtensible MarkupLanguage (XML) or the JavaScript Object Notation (JSON) Such a servicecan be discovered by other software systems which in turn may then inter-act with the Web service in the manner prescribed by its definition usingXML or JSON based messages conveyed by Internet protocols [81] Usu-ally in computer science most authors refer to both rdquoe-servicesrdquo and ldquoWebservicesrdquo by simply ldquoservicesrdquo [82]

On the other hand the term ldquoservicerdquo in the Telecom domain can beunderstood as the capability to exchange information through a telecommu-nication medium provided to a user by a service provider [83] Differentstandardization associations in this domain have created similar definitionsOne of the most important associations for standardization in Telecom is theTele-Management Forum (TMF) that describes a service as a set of indepen-dent functions being an integral part of one or more business processes Thisfunctional set consists of the hardware and software components as well asthe underlying telecommunication medium The user sees all these compo-nents as a fusion a service can be a service component of another service [84]Other association of standards for mobile technologies is the 3rd GenerationPartnership Project (3GPP) The 3GPP defines a service a component ofthe portfolio of choices offered by service providers to a user in the sense offunctionalities provided to a user [15]

Basic Telecom services (ie networking services) provide connectivity toa network like voice over the Internet Protocol (IP) and basic signalling forexample Added-value services a broader concept of service provide otherfunctionalities such as voicevideo connectivity community tools presenceconferencing gaming and TV broadcasting The added-value services arebased on NGN [82] whose purpose is to deploy next generation architectures

7

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

that allow the access to independent services over converged fixed and mobilenetworks

To sum up the fundamental objective of services is to have a collectionof network-resident software services accessible via standardized protocolswhose functionality can be discovered used individually or composed to formmore complex services [79]

32 How can a service be described

As stated before an atomic service consists of a set of network-accessiblefunctionalities described using a machine understandable description Theset of methods that allow accessing these functionalities is known as theinterface of the service The description of service interfaces will be usedafterwards for service discovery compatibility verification and compositionThe first step to take when describing a service is to analyse its inputs andoutputs Figure 1 shows diagram of the input and output of a service thatperforms the sum of two integers Currently such description depends onthe architectural style (ie the Service Oriented Architecture - SOA - andthe the REpresentational State Transfer- REST) and the technologies usedfor implementing the service

Figure 1 Description of services using inputs and outputs

The Web Services Description Language (WSDL) [85] is the facto stan-dard for describing services based on SOA that are usually implemented usingthe Simple Object Access Protocol (SOAP) and XML WSDL [86] providesa computer-understandable description of Web services and describes Webservices as collections of communication end points that can exchange certainmessages This description language includes atomic method calls (also calledoperations) in terms of input and output messages where each operation canbe a one-way operation request-response solicit-response or notification

8

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Listing 1 WSDL Exampleltd e f i n i t i o n s name=rdquo g r e e t i n g s e r v i c e rdquo

targetNamespace=rdquo h t tp www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlns=rdquo ht t p schemas xmlsoap org wsdl rdquoxmlnssoap=rdquo ht t p schemas xmlsoap org wsdl soap rdquoxmlns tns=rdquo h t t p www unicauca edu co wsdl g r e e t i n g s e r v i c e wsdl rdquoxmlnsxsd=rdquo h t tp www w3 org 2001XMLSchemardquogtltmessage name=rdquo SayHel loRequest rdquogt

ltpart name=rdquonamerdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltmessage name=rdquo SayHelloResponse rdquogt

ltpart name=rdquo g r e e t i n g rdquo type=rdquo x s d s t r i n g rdquogtltmessagegtltportType name=rdquo greet ing portType rdquogt

ltopera t i on name=rdquo sayHe l lo rdquogtltinput message=rdquo tns SayHe l loRequest rdquogtltoutput message=rdquo tns SayHel loResponse rdquogt

lt opera t i ongtltportTypegtltbinding name=rdquo g r e e t i n g b i n d i n g rdquo type=rdquo tn s g r e e t i ng po r tType rdquogtltsoap b ind ing s t y l e=rdquo rpc rdquo

t ranspor t=rdquo ht tp schemas xmlsoap org soap http rdquogtltopera t i on name=rdquo sayHe l lo rdquogt

lts oap ope ra t i on soapAction=rdquo sayHe l lo rdquogtltinputgt

ltsoapbodyencod ingSty l e=rdquo h t tp schemas xmlsoap org soap encoding rdquonamespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt inputgtltoutputgt

ltsoapbody encod ingSty l e=rdquo ht tp schemas xmlsoap org soap encoding rdquo

namespace=rdquo u r n e x a m p l e s h e l l o s e r v i c e rdquouse=rdquoencodedrdquogt

lt outputgtlt opera t i ongtlt bindinggtlts e r v i c e name=rdquo G r e e t i n g S e r v i c e rdquogt

ltdocumentationgtWSDL Desc r ip t i on f o r Greet ing S e r v i c elt documentationgtltport binding=rdquo t n s H e l l o B i n d i n g rdquo name=rdquo He l l o Por t rdquogt

ltsoap addre s s l o c a t i o n=rdquo h t t p www unicauca edu co Greet ing rdquogtlt portgtlt s e r v i c egt

lt d e f i n i t i o n sgt

Listing 1 depicts an example of WSDL The code starts with the defi-nition of the namespaces and the definition of messages to exchange (ieSayHelloRequest and SayHelloResponse) The portType includes the al-lowed operations (ie SayHello) The Binding (ie greeting binding)specifies a particular protocol and the encoding style for provision of theservice Finally the service element (ie greeting service) includes infor-mation about the concrete address of the service

9

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Unlike the services based on SOAP and XML there is still not a widelyaccepted standard for describing services based on the architectural styleREST that are usually implemented using the HyperText Transfer Protocol(HTTP) and JSON or XML Relevant efforts for describing REST-based ser-vices are (i) the Web Applications Description Language (WADL) [87] thatoffers a machine process-able protocol description format for services usingHTTP and XML (ii) the WSDL 20 [88] that provides a machine-readabledescription for SOAP and HTTP based services by accepting the bindingto all the HTTP-request methods (not only GET and POST) and (iii) theHTML for REST (hREST) [89] that offers a XHTML-based microformatfor representing and describing Application Program Interfaces (APIs) andservices based on REST

The second level of service description is concerned with pre- and post-conditions As aforementioned description solutions such as WSDL (11or 20) WADL and hREST describe a single interaction with a service interms of request and response messages However to assess whether a servicecan be used by other services it does not suffice to know the type of datagenerated or received by a service but also the change in the world that itproduces Pre-conditions must be true in the input in order to the service tobe executed at the same time post-conditions are conditions that becometrue after the service is successfully executed For example a service calledsend message may require as input a well-formed email address and mayhave the effect (post-condition) of informing someone of something whichrepresents the change in the world

Figure 2 Description of services using pre and post-conditions

Figure 2 depicts the service pay that has as input the payment value andthe payment data (eg card number and customer) as well as an additionalpre-condition Such precondition ensures that the available credit is higher

10

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

than the amount to pay A post-condition for the service pay may be tochange the state of the transaction to payed for instance Some languagessuch as the Web Ontology Language for Services (OWL-S) the SemanticAnnotations for REST (SA-REST) and the micro Web Service ModelingOntology (microWSMO) [90] [89] allow the annotation of services with pre-and post- conditions apart from the inputs and outputs It is important tohighlight that currently any of these languages is dominant in the secondlevel of service description

33 What are the differences between services available in the Web and Tele-com domains

Telecom services are fundamentally different from Web services based onSOA or REST [17] Next the most remarkable differences are analysed

Standard language for service description In the Web domainfor services based on SOAP there is a large consensus on the main standardfor service description WSDL Unlike for services based on REST there isnot a widely approachstandard accepted for describing them In the samedirection of REST-based services and contrary to SOAP-based services inspite of some initiatives such as ONEAPI [61] and Twilio [58] for standard-izing service interfaces there is no standard language for service descriptionin the Telecom domain A review of proposals shows that service descriptionlanguages in Telecom are often protocol specific not extensible nor reusable[53]

Level of detail of services In the Web the details of atomic servicesare most of the time open to the world by means of REST and SOAP APIswidgets and Web front-ends That is to say that the users are often aware ofthe parameters of the demanded services Two prominent examples of highlyparameterized Web services whose APIs are public are for example GoogleTranslator and Google Maps On the other hand Telecom operators offerservices without authorizing the user for configuring them in deep or evennote that heshe is working with them For example services such as callforwarding or billing processes are often completely opaque to users

Availability of services Availability refers to the ability to access asystem or service In the case of Web services provided through the Internetthe availability depends highly from the underlying networks Converselythe percentage of availability of Telecom services is very high and termssuch as 5 x 9 (ie 99999 availability) and fault tolerance are commonlyused [91]

11

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Time constraints In the Telecom domain there are tight real-timerequirements in protocols and user requirements (eg post-dial delay is typ-ically bounded [19]) In contrast a best-effort response time is typicallyoffered by services available along the Web

Number of protocols In the Web most of the communications arebased in synchronous protocols mostly in HTTP Conversely in Telecomthere is a broad range of protocols each one specific for some services (egvoice transfer and video) or networks (eg Wi-Fi mobile and fixed) Inspite of the efforts for integrate all the protocols over the Session InitiationProtocol (SIP) that allows phone calls to be made over the Internet [92]current technologies require the implementation of diverse protocols in orderto be able to be integrated with legacy hardware and software

34 What is service composition

In a broad sense the process of creating a composite service by combin-ing atomic services is known as ldquoservice compositionrdquo This composition isrequired when the request of a client cannot be satisfied by any single serviceDue to the differences in standards service descriptions and formalization ofthe involved processes service composition is subsequently described sepa-rately for the Web and Telecom domains

Service composition in the Web domain According to the previ-ously given description service composition in the Web consists of joiningthe individual services and defining the control flow and the data flow sim-ilar to workflow approaches The resulting composition can be viewed fromtwo perspectives orchestration and choreography Orchestration describesthe executable process that can interact through messages with both inter-nal and external Web services Orchestration includes business logic andtask-execution orderings from one partner perspective

Choreography tracks the sequences of messages among multiple partnersrather than in a specific process executed by a single partner Choreographyis more collaborative that orchestration and allows to describe the public mes-sage exchange between services Also choreography is useful for establishingthe rules for the exchange of messages in order to guarantee interoperabilityamong different agents In summary orchestration describes an executableprocess while choreography specifies the protocol of peer-to-peer interactionsFigure 3 illustrates the relationship among both concepts

The main language for describing the composition of SOAP-based servicesis the Web Services - Business Process Execution Language (WS-BPEL)

12

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

[47] often shortened to BPEL in many works Business process is a termused to describe the interaction between services in terms of work and dataflow BPEL is an orchestration language that models business processes thatinteract with external parties In BPEL each part is a service describedusing WSDL BPEL includes representation in XML of concepts such asdata control flow data flow error handling and partners among others

Figure 3 Orchestration vs Choreography

Listing 2 presents an example of a whole process in BPEL In this ex-ample a process called AmericanAirline defines the partnerLinks (servicesinvolved in the process) as well as the variables of the process The BPEL-based workflow of process is a sequence of task that includes receive assignand invoke (make a call-back) It is important to note that the elementinvoke includes parameters related to the service description defined in theWSDL such as operation and portType

BPEL does not include any graphical representation for business pro-cesses so other standards have appeared to provide such functionality Themost used notation for graphical representation of business processes in ser-vice composition is the Business Process Model and Notation (BPMN) [93]BPMN is a standard that provides a graphical notation for specifying busi-

13

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

ness processes and is very similar to the activity diagrams of the UnifiedModelling Language (UML) [94] The goal of BPMN is offering a represen-tation tool for both technical and business users To do so BPMN providesa notation that is intuitive to business users yet able to represent complexprocess semantics The BPMN specification provides also a mapping to par-ticular languages such as BPEL Figure 4 depicts an example of modellingwith BPMN

Listing 2 Example of a BPEL processltproce s s name=rdquo AmericanAir l ine rdquo targetNamespace=rdquo h t t p packtpub com

s e r v i c e a i r l i n e rdquoxmlns=rdquo h t t p schemas xmlsoap org ws200303 bus ines sminusproce s s rdquoxmlns a ln=rdquo ht tp packtpub com s e r v i c e a i r l i n e rdquo gt

ltpartnerL inksgtltpartnerLink name=rdquo Amer icanAir l ines rdquo partnerLinkType=rdquo a l n f l i g h t L T rdquo

partnerRole=rdquo a i r l ineCustomer rdquo myRole=rdquo a i r l i n e S e r v i c e rdquogtlt partnerL inksgtltv a r i a b l e sgt

lt minusminus input minusminusgtltv a r i a b l e name=rdquo F l i g h t D e t a i l s rdquo messageType=rdquo

a ln F l ightTicketRequestMessage rdquogtlt minusminus output from American A i r l i n e s minusminusgtltv a r i a b l e name=rdquoFlightResponseAArdquo messageType=rdquo

alnTravelResponseMessage rdquogtlt v a r i a b l e sgtltsequencegt

lt minusminus Receive the i n i t i a l r e que s t minusminusgtltr e c e i v e partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo

a l n F l i g h t A v a i l a b i l i t y P T rdquooperat i on=rdquo F l i g h t A v a i l a b i l i t y rdquo v a r i a b l e=rdquo F l i g h t D e t a i l s rdquo

c r e a t e I n s t a n c e=rdquo yes rdquo gtlt minusminus Prepare the output minusminusgtlta s s i g ngt

ltcopygtltfromgt

ltFlightNogt123lt FlightNogtltReturnDateTimegt2004minus01minus05ltReturnDateTimegtltApprovedgtt rueltApprovedgt

lt conf i rmat ionDatagtlt fromgtltto v a r i a b l e=rdquoFlightResponseAArdquo part=rdquo conf i rmat ionData rdquo gt

ltcopygtlt a s s i g ngtlt minusminus Make a c a l l b a c k minusminusgtltinvoke partnerLink=rdquo Amer icanAir l ines rdquo portType=rdquo aln F l ightCal lbackPT rdquo

operat i on=rdquo Fl i ghtT icke tCa l lback rdquo inputVar iab l e=rdquoFlightResponseAArdquo gt

lt sequencegtlt proce s sgt

Unlike the SOAP-based services for composing REST-based servicesthere is still no a language standardized or broadly accepted Significantresearches are (i) BPEL for REST [95] proposes an extension of BPEL

14

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

that covers the composition of Web Services based on SOAP and REST byadding specialized activities as lt get gt lt post gt and lt resource gt (ii)Bite [96] presents a lightweight and extensible composition language to createworkflows where the main entities of compositing are REST-based servicesand (iii) the Lightweight Process Modeling Language (LPML) [97] allows tomodel a business process that uses Web 20 solutions by means a subset ofBPMN

Figure 4 Simplified example of a process modelled using BPMN

On the other hand regardless of the method used to represent the com-posite service service composition in the Web is commonly performed atdesign time In this sense recently non-technical users have begun to playan active role in service composition especially by creating their own servicescalled mashups in the Web 20 Mashups are composite Web applicationsfocused on end-users and created by combining different resources availablealong the Web [98] [99] In this sense MDEs like Yahoo Pipes (see Figure 5)allow users to create their own services by assembling service building blocks

MDEs work with a rather limited set of services in comparison with allones available on the Web but at least offer some degree of personalization-customization to users Still service composition made by users has someproblematic issues such as the heterogeneous dynamic and spontaneous na-ture of their needs [37] which current development environments directedtowards them cannot address yet

Service composition in the Telecom domain In Telecom servicecomposition is known as feature application composition [19] that is as aprocess inherent to the establishment of any communication For instance abasic call service between two subscribers involves multiple features such as

15

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

Figure 5 Service composition using yahoo pipes

voice mail call forwarding and call waiting All these features are invokedin a sequence even if the user is never aware of the feature composition

Similarly to the individual service description in the Telecom domainthere is a shortcoming related to the little consensus about standard de-scriptions for service composition In recent years the TelcoML [40] andDiagen [100] were proposed for coping with such shortcoming TelcoMLhas been proposed by the Object Management Group (OMG) [40] offeringa UML Profile for designing advanced and integrated telecom services Inturn DiaGen is a framework based on the implementation of a declarativelanguage over Java that provides service discovery and high-level communi-cation mechanisms Such a framework also generates the class skeletons ofcomposite services

16

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

On the other hand some standards such as the IP Multimedia Subsystem(IMS) [62] Parlay X [101] and OneAPI [61] aim to carry out composition ofindividual Telecom services into new more complex services leveraging thereuse and standardization of subjacent technologies [19] In general terms(i) IMS can be seen as an architectural framework for delivering IP multi-media services by permitting the integration of services based among otherson SOAP REST and SIP (ii) Parlay X introduces the concept of TelcoWeb services to allow the creation of composite services and (iii) ONEAPIexposes network facilites as services aiming to facilitate the combination ofthese facilities with services from the Web domain

Figure 6 The Radisys SCE [43]

Like service composition in the Web the service composition in the Tele-com domain may also be carried out by using SCEs [4] and MDEs [5] [6]These environments allow the user to combine services functionalities usingdrag-and-drop and wire tools that hide the technical details of technologieslike IMS Parlay X and ONEAPI Figure 6 depicts a screenshot of Radisys[43] that is an example of a typical SCE In the user interface of Radisys thefunctionalities to be composed graphically in the central canvas are located

17

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50

at the left pane

35 What is convergent service composition

The term ldquoconvergentrdquo has been used widely in telecom and computernetworks with different meanings to describe the fusion of fixed and mobileservices [2] or as a synonymous of the NGN that represents the integrationof the Internet and the Public Switched Telephone Network (PSTN) [3] Aspreviously stated we use the term ldquoconvergentrdquo as efficient coexistence ofservices available on the Telecom and Web domains to provide innovativeand more complex services to the user

The rise of composition of services appears in the midst of a growingexpectation of traffic volume by telecom operators This is due to the in-creasing offer of added-value services to customers in addition to traditionalvoice and data communication [102] Novel added-value services combinefeatures from the Telecom with technologies of the Web this combination isknown as ldquoconvergent compositionrdquo [23] or ldquounified compositionrdquo [19]

To illustrate what the process of convergent composition is we presentan example in the Early Warning Management domain in which an environ-mental manager must make decisions regarding the environmental alarms ofa region Heshe can request information from sensor networks deployed atseveral spots and can also use services available on a telecommunication net-work and the Web to process basic data and send information to both farmersand actuators Figure 7 presents a sketch of an environmental managementsystem

As the environmental manager may come from fields like biology or agri-culture hisher technological background may be low Also electronic de-vices in the area may be scarce and not reliable or obsolete Furthermore thedata network coverage may be deficient too Thus the preferred way to en-ter information to the system is by voice and in natural language This wayusers do not have to know how the system internally works and can makerequests from regular mobile devices or landline phones Commonly the userexpresses hisher request informally Here are two examples of requests innatural language (i) ldquoI need to compute the hydrological balance of zone1rdquo (ii) ldquoIf the river flow of zone 2 is greater than 15 of the safety limit onaverage send a warning to every farmer within a radius of 2 miles from theriver and create an action map including emergency and rescue groupsrdquo

In the first request a service composition could be gathering informationfrom the sensors in zone 1 using hydrological services from the Internet

18

to process the sensed data obtaining the hydrological balance map fromGoogle maps composing the final image and sending it to the user by theMultimedia Message Service (MMS)

Figure 7 Architecture for management of environmental early warnings

In the second request a service composition could be sensor data isevaluated and if necessary an emergency map is created The map is createddrawing a radius of 2 miles around each sensor reporting danger To do so thesystem may search for geographical services available in the Web Finallythe system informs about the alarm to the farmers inside the emergencyarea The most convenient way to send the information is selected SMSCell Phone call fixed telephone call or voice message

In both request examples services from the Web and Telecom are used forattending user request Additionally the context of the user for both farmersand managers must be considered in order to get a service composition thatfulfills the needs of the user adequately For instance if the user is currentlydriving then a service could automatically provide information through voicesuch as SIRI [16] and Vlingo [103] instead of text Another way of taking intoaccount the context of the user is allowing services that can be triggered underspecific conditions for example it might be possible to determine whethera rescue vehicle is close to an affected area in which case an emergencynotification would be triggered [102]

19

4 Convergent Service Composition

In a general sense the process for carrying out convergent service compo-sition can be decomposed in several relatively independent steps beginningwith the user request and ending with the execution of the composite ser-vice The whole process (see Figure 8) can thus be divided in four phasescreation generation adaptation and execution

Figure 8 Phases for automated convergent composition

An important consideration to be noted is that the automation of eachphase is independent of the automation of the rest of the other phases Thismeans that the automation of the whole service composition can be describedas the sum of the automation of its parts Next each phase is described aswell as the automation level expected

41 Creation phase

In this phase the user (advanced or novice) specifies the user request(ie ru) in a natural way in order to be solved by the system (see Figure 8phase a) The user specifies ru through a device or computer that hides anytechnical (platform or language) detail and allows him to clearly state hisnecessities with his own words Such ru needs to be translated to a machineunderstandable representation (ie rm) An example of the input and outputof the creation phase may be ru ldquoI want to receive the route to the closestATM in my cell phonerdquo and rm get(calMap(myPositionATM))

20

In the creation phase the automation is associated with the capabilityof the system to extract rm from ru without the intervention of the userThis type of automation is mainly required when the expertise of the user isnot advanced so heshe cannot specify the request directly in the machineunderstandable format

42 Generation phase

The next step in the process for convergent service composition consistson translating the machine understandable request rm into an abstract com-posite service (ie CSa) CSa represents a set of atomic activities that needto be performed in order to satisfy ru (see Figure 8 phase b) This set ofatomic services can be described as a business process or an algorithm

Figure 9 Graphical representation of the composite service

Figure 9 depicts a possible graphical representation for a CSa that followsthe following actions sequence (i) myPos = calLocation(here) - the locationof the user is obtained and stored in a variable (ii) dest = calLocation(ATM)- the destination location is found (iii) map = calMap(myPos dest) - thedrawing of the map from the location of the user to the closest ATM isachieved and (iv) finally sendMMS(map phoneNumber) - the drawn mapis sent to the mobile phone by MMS This is also an example of service com-position in which Telecom services (eg calLocation sendMMS) and Webfunctionalities (eg calMap) are needed

The process of automation of the generation phase may be carried out intwo ways from scratch or using predefined templates The former impliesthat a basic composite service does not exist at all and therefore must becreated The second type of generation is based on templates which meansthat a basic template of the composite service describing the flow of activitiesis already defined and the user request triggers an adaptation of this flowfor example by selecting the implementation services in each occasion

In both ways of automation the generation of convergent service com-position requires the selection of discovery of services for each task of the

21

composite service This process consists on the identification of a servicethat can potentially be used in the context of a new convergent service Thisincludes the comparison of expected services with the existing ones whichis called matching Since individual services are commonly isolated theirformat and semantics are also heterogeneous even if their purpose may besimilar so it is necessary to employ matching algorithms

Researchers have developed diverse matching approaches [104] (i) exactsyntactic equivalence in which a word comparison of names of services andattributes is performed looking for an exact matching (ii) approximatematch that offers functions to consider acceptable differences between wordsand (iii) semantic match that uses semantic distance which is associatedwith the conceptual similarity using concepts networks named ontologies

43 Adaptation phase

In this phase the abstract service composition (CSa) is translated toan executable plan called CSx (see Figure 8 phase c) This translationis conducted to enable the execution of convergent services in technologicalplatforms Listing 3 depicts using the Java Language the CSx of the aboveexemplified CSa

Listing 3 Example of Java executable composite servicepub l i c c l a s s CompositeService

pub l i c void Request ( ) c a l c u l a t e coo rd ina t e s o f cash machine and my p o s i t i o nhere = Locator g e tActua lPos i t i on ( ) cash machine = Locator g e t P o s i t i o n ( Gzzter get ( here

cash machine ) ) Locat ion my pos i t ion = Locator getLocat ion ( here ) Locat ion d e s t i n a t i o n = Locator getLocat ion ( cash machine ) Generate the map in an imageMapImage map= MapService render ( my posit ion d e s t i n a t i o n ) Send the message to the userTelcoApi senSMS( user getPhoneNumber map rdquo r e s u l t rdquo )

The automation of the adaptation phase consists on creating the exe-cutable or interpretable code in a programming language like JavaPythonor in an declarative language like BPELBite without requiring the interven-tion of a developer

44 Execution and reconfiguration phases

The execution phase (see Figure 8 phase d) is responsible for manag-ing the lifecycle of CSx Therefore in this phase the convergent service is

22

deployed into an execution environment (eg a server) to be subsequentlyexecuted The execution phase is inherently automatic once the user deploysthe service it runs in the execution environment without human intervention

The reconfiguration phase is required for instance when a malfunction(eg server failure) or an error (eg a Web service becomes offline) hap-pens during the execution of CSx The usual procedure for reconfiguring aconvergent service consists in notifying the developeruser who must go tothe corresponding SCEMDE for re-examining the whole composition pro-cess Complete automation of this phase requires the composite service tobe monitored and reconfigured automatically in case of failure [105]

5 Service Creation

As afore defined Service creation is the process of translating the userrequest to a language or descriptor understandable by the computer Forinstance the translation may be done from the request expressed in naturallanguage to BPELBite language or to executable code This phase dependslargely on the level of expertise and the device used by the user If the useris an expert and uses a desktop personal computer a graphical interface forcreating workflows is very suitable On the contrary the same interface isnot suitable for a non-expert user or for another user who may be drivingwhen needs to compose a service for satisfying hisher needs

In terms of academic research a clear separation between programmer-sdevelopers (aka professional users) and end-user needs to be done ac-cording to the conclusion of European SPICE [31] and OPUCE [27] projectsIn this way in the following subsections the main approaches for servicecreation will be exposed considering focus on professional users (ie SCE-based approaches) and end-users (ie approaches using natural languageprocessing - NLP - and mashup-based approaches) Most of them comesfrom academic initiatives

51 SCE-based approaches

SCEs ease the service creation by offering mechanisms for integratingservices and functionalities graphically This idea was initially suggested byresearchers that proposed the use of Integrated Development Environments(IDE) able to visually integrate atomic components representing Telecomand Web 20 services [30]

23

The SCE proposed by the European OPUCE project offers intuitive toolsfor graphical creation of composite services [30] [26] [27] This SCE allows theintegration of Web and Telecom services taking into account some user profilecriteria Furthermore the SCE of OPUCE includes a semantic browser anda translator to BPEL

HSCEE is other research work that carries out SCE [28] This workapart of providing a low latency execution environment for convergent ser-vices offers also a template-based service creation platform An importantshortcoming of HSCEE is that it is based on BPEL templates where mostof the design tasks must be done manually which makes it ill-suited forautomatic service composition

Another SCE-based approach was proposed in the field of the Artifi-cial Intelligence (AI) [11] Such approach aims at automating the Web Ser-vices composition under semantic awareness by AI planning techniques anda graphical environment in which even non-expert users (ie end-users) cancreate composite services One of the most striking characteristics of thisapproach is that the expertise required by non-experts for carrying out com-position activities is essentially similar to discover and invoke an atomic WebService

In the TeamCom project arose other SCE-based approach that describesthe development of added-value services through a tool based on BPEL [53]This tool additionally allows to translate to Java and deploy on a Telecomexecution server the developed added-value services

Finally regarding SCE-based approaches it is important to highlight thatin recent years the concept of Service Delivery Frameworks has also beenproposed to provide service creation in convergent scenarios [25] We considerthese frameworks just like other form to refer a solutions using SCEs

52 Mashup-based approaches

As an alternative to SCEs an important trend of research has emergedaround the mashup technology that allows creating solutions named mashupsThese mashups are composite Web applications centered in end-users andcreated by combining different resources available along the Web [98] [99]End-user centric means that mashups may be developed by users who usuallydo not have advanced programming skills [37] leveraging MDEs that tendto be user friendly and hide technical details [34] Furthermore mashupsencourage the cooperation among end-users and the reuse of existing Webapplications [106] [107]

24

The proponents of the use of mashups for creation of convergent servicespromote the generation of mechanisms for service composition from bothWeb and Telecom using friendly interfaces This is done following the Webmashups philosophy based on the fact that a large number of services areaccessible over the Web through open interfaces

An example of mashup-based approach for service composition is a frame-work that introduces the concept of mobile mashups [33] This frameworkproposes a device-independent architecture applicable to both the server andthe device side that allows integrating device capabilities (eg camera andBluetooth) with Telecom features and Web accessible services

MARIO [51] is a tool that implements a ldquopursuit of desiresrdquo pattern inwhich users set their preferences by selecting tags describing services to whichthey want to subscribe The internal composer of MARIO makes the corre-spondence between the tags and the existing services Such correspondenceis in turn refined by the user until heshe gets the final composition

In the domain of added-value convergent services a reference architecturewas proposed to facilitate the provisioning of telco mashups for end-users [20]A telco mashup is a composite service that combines functionalities fromtelecomunication networks (eg streaming quality of service and billing)and device capabilities (eg geographic location and health information)with services (eg instant messaging and IP telephony) accessible via Web-based protocols In the literature we did not find a prototype of a mashupsystem or a telco mashup that implements this reference architecture

In the network management domain a mashup-based approach was pro-posed to deal with the security problem of botnets in an more flexibleextensible and usable way [74] This approach was carried out in a mashupapplication The mashup built (called botnet mashup) integrates dinam-ically botnet information collected from existing mitigation tools such assandboxes and antiviruses with geographic location retrieved from onlinemapping and geolocation APIs

A mashup system was also introduced to evaluate qualitatively the fea-sibility of using Web 20 technologies on network management [108] Usingthe proposed system prototype a mashup (called BGP mashup) was built inorder to monitor the traffic of the Border Gateway Protocol (BGP) amongtwo autonomous systems by integrating traffic router information This inte-grated information was collected by using the Simple Network ManagementProtocol (SNMP) and presented by combining images retrieved from a gen-erator of traffic graphs and maps generated from a mapping service

25

As a continuation of the two works above cited a generic architecture wasproposed to support the composing of network management applications [5]This architecture was carried out in a MDE that allows network administra-tors to design their own management applications through the compositionof network management and services available in the Web The qualitativeevaluation of the proposed architecture was conducted by analyzing the de-velopment of the BGP mashup and the botnet mashup previously referred

As an evolution on using mashups for network management arose theconcept of mashments [13] [14] Mashments are solutions based on the Sit-uation Management (SM) discipline and the mashup technology that aimto facilitate the work of network administrators when facing unexpectedheterogeneous and dynamic situations To achieve such aim mashmentscombine diverse types of resources (data application logic and user inter-faces) from multiple providers (from the Web and the network management)and automate the investigative and control aspects of SM

An important shortcoming of the mashup-based approaches above cited isthat the selection of atomic services used for creating mashups is performedmanually by using mainly searches based on keywords In this sense andwith the goal of overcoming such shortcoming in the literature of servicecomposition arose diverse and relevant semantic mashup approaches Forinstance SensorMashup is a semantic-based platform aimed to facilitate thecreation of mashups by following the linked open data principle [76] thatenables the dynamic discovery integration and querying of heterogeneousdata sources This platform provides a visual composer that allows end-users to easily publish sensors as data sources identified by URIs and torapidly combinelink such sensors for building up mashups

In service composition other groundbreaking approach was proposed forimproving the process of developing mashups by adding semantic service dis-covery capabilities [77] In a general way these capabilities were added bycombining semantic Web Services discovery frameworks Universal Descrip-tion Discovery and Integration (UDDI) repositories and existing mashuptools

In the Cloud Computing domain a semantic-based approach was pro-posed to make the engineering process of creating mashups more agile andflexible [78] In particular this approach uses the Cloud Computing technol-ogy to increase the number of public REST APIs and further introduces theSemantic Annotation for Web Application Description Language (SAWADL)to carry out the semantization of such APIs SAWADL is a WADL extension

26

that enables the annotation combination and deployment of REST APIsaiming to facilitate the development of mashups in a cloud environment

Instead of relying on the expertise of the user as the above mentionedmashup-based approaches other ones focus on capturing the user requestdefined in a specificproprietary description language of composition andtranslating it into composite services In the approaches using these specificor proprietary languages the composite service description made by the useris translated into a process definition language (eg BPEL andor BPEL forREST) before being executed For instance in the SOA4All project [97] non-expert users interact with a graphical process editor called SOA4All Studio tocreate new composite services This editor directly interacts with a reasoningengine that creates a composed service by inferring in a semantic way themost suitable connection among parameters of the services exposed on it

53 NLP-based approaches

Recent approaches have also explored the application of NLP techniquesto automate the composition of services These approaches have been usedmostly in intelligent home environments [35] [36] and offer mechanisms tomap words to basic functionalities of the system The goal of a NLP-basedsystem is to extract the workflow of the composite service from the userrequest expressed in natural language

In the domain of environmental early warnings a NLP-based systemnamed AUTO was proposed for composite service creation [38] [39] InAUTO the user defines hisher demand and context information using natu-ral language This demand is handled by a request processing module that isresponsible for transforming natural language and context information intoa plan of composite service This plan combines services from the Web andTelecom domains

In the SPICE project a specialized language called SPATEL [31] wasproposed to describe service compositions formed by RESTful services (ieRESTful is a Java implementation of the REST architectural style) and Tele-com features These descriptions are interpreted by a translator module [32]that is responsible for generating code for specific execution technologiesSPATEL and the translator module are the core of the generation and exe-cution of composite services offered by the SPICE platform

27

54 Comparison

After surveying the previous approaches it can be stated that the worksin the service creation phase can be classified in three groups SCE-basedmashup-based and NLP-based Each one of them has different particularelements that make them suitable for distinct environments Table 3 sum-marizes the differences between the three approaches

Table 3 Comparison of approaches for service creation

Approach Access Automation Expertise required

Mashup-based Any Web-enabled device Low Medium

SCE-based A personal computer with the SCE installed None High

NLP-based Any personal computer or phone High Low

SCE-based approaches offer an incomparable technical detail for conver-gent service composition When employing SCEs the limit on the intricacyof the service composition depends only on the number of available servicesand the knowledge of the user However this obviously requires the user tobe an expert in the specific application domain Furthermore because thecomplexity and nature of SCEs usually they must be installed in a desktoppersonal computer which greatly restricts the mobility of the user

SCE allows to create convergent services with a remarkable level of detailthese interfaces allow to customize different aspects of the services and thesubjacent protocols Unlike Web services the protocol in telecom environ-ments is very important for the provision of the service and may directlybenefit the quality of services Therefore SCE might be a very good al-ternative for technical and experts when defining the template of convergentservices that could be used later in further phases of automated composition

Mashup-based approaches in turn offer more alternatives by enablingservice creation from Web graphical interfaces that do not need to be installedin any desktop personal computer Additionally the usability as well as therange of audience for these interfaces is bigger than for SCEs The main

28

disadvantage over SCEs is the loss of expressive power when creating complexcompositions which may be too simple for the needs of some users

Some approaches create Mashups automatically from natural languagerequest and allow to refine some details at a later time On the other handMashups are generally open an may be shared and reused which may lead toa collaborative creation of convergent services

The aproaches based on SCE and mashups allow creating composite ser-vices that may be defined using different languages such as BPEL BiteLPML and BPEL for REST In these approaches the core of the servicecomposition task is completely carried out in a manual way In this way thenovelty of the application of NLP-based approaches is that in some scenar-ios the user just requests hisher desire or goal in natural language and doesnot define the workflow of the composite service This workflow is obtainedautomatically from the user request by the NLP system Furthermore byusing voice as the primary input medium a NLP system may be used withany kind of calling device

Existing research results have shown that creation phase have been auto-mated significantly when natural language is used However several impor-tant issues are open

i) To map user request and context to a service is a big challenge espe-cially a when the service does not have a standard interface description likein telecommunications domain many semantic approaches translate requeststo formal representations using natural language processing techniques andontologies These approaches have good performance in specific domains[109] The main idea is extract concepts from the user request and matchthem with service concepts [110]

ii) There exist some differences between finding services on Telecom andon the Web The main challenge of finding a service in telecom environmentis the lack of standard descriptions for the functional properties of servicesSome approaches for automated creation uses traditional Web representa-tions for Telecom environments such as WSDL however the trend of movingtelecom facilities to the Web such as Skype or Twillio allow to glimpse theuse of semantic representations of Services

6 Service Generation

As above described the service generation is related to the creationcom-position of a chain or a linked set of services that can be represented as a busi-

29

ness process encoded for instance in BPEL or BPEL for REST There existsa broad range of research approaches around the topic of automatedsemi-automated service composition in the Web domain most of which is ap-plicable to convergent composition Such approaches can be divided intotwo categories workflow-based approaches and approaches that employ AItechniques

61 Workflow-based generation

The approaches on service generation using workflow-based techniquesassume that a composite process can be perceived as a workflow The work-flow of a composite service includes a set of atomic services along with a dataand control flow [104] Workflow-based approaches can be subdivided intotwo groups static template and dynamic composition

Figure 10 Static workflow-based composition

The static composition (see Figure 10) means that user builds an ab-stract process model or template at design time and then at execution timeatomic services are selected automatically from a set of candidate servicesGraphically the composite service is depicted as a directed acyclic graphwith control and dataflow [111] This graph defines the order of execution ofthe nodes of the process in which the nodes are automatically bound withparticular services This automation focuses mainly on the automation ofthe instantiation process [73]

The use of template-based composition is located at the middle of staticand dynamic composition Using templates the user retains control over the

30

process and automatic techniques can be employed to customize and imple-ment the process achieving very good performance and quality [112] [113]The template-based composition depends on whether standard proceduresare available for the particular domain of application such as in medicalprotocols [111] The templates can be parameterized with respect to somevariables to allow customization based on user needs and preferences [92]

A concept that uses templates is the Hierarchical Task Networks (HTN)[64] HTN planning is especially promising for service composition becauseits concept of task decomposition is very similar to the concept of compositeprocess decomposition In HTN planning a task represents the activities toperform A task may be either primitive or compound (which in our caserepresents an individual and composite service respectively) A compoundtask is one that needs to be decomposed into smaller tasks using a methodMethods indicate how to decompose a compound task into a partially orderedset of subtasks each of which can be again compound or primitive Thelowest level task that cannot be decomposed further is called a planningoperator In service composition the highest level task or goal is extractedfrom the user request and the lowest level planning operator represents aprimitive service directly associated with implementation services

The dynamic composition proposes the generation of the service abstractmodel automatically In this way individual services are selected in an au-tomatic way (see Figure 11) Some relevant approaches on dynamic compo-sition are first a rule-based solution for semi-automated composition thatoffers the user the ability to guide the composition process [71] In this solu-tion the user defines the flow and the rules that allow automatically buildingthe composition Second a mechanism that works by synthesizing its work-flow based on the semantics of the components and the context of users [72]This mechanism composes applications requested in natural language consid-ering in addition to the context the preferences of the user These preferencesare extracted from user-specified rules and also via learning

Important shortcomings of the workflow-based composition is that it usu-ally requires extensive domain knowledge and at least some degree of man-ual implementation by developers making it difficult time consuming anderror-prone [111] In order to overcome such shortcomings arose the servicecomposition based on AI

31

Figure 11 Dynamic workflow-based composition

62 AI-based generation

One important group of approaches is focused on semantics Semanticcomposition has been used widely for services composition The main idea isto add semantic information to methods and IO parameters in order to judgethe matching degree between services by calculating semantic similarity ofconcepts in ontology tree [114] Furthermore some authors extract conceptsfrom user goal description and matched them with ontology concepts so as toguide the services composition [115] For example Slaimi et al [116] presentan approach called OVWSC (Ontology based Web Service Composition) thatincludes two phases first the domain service ontology is filtered for reducingthe services researchrsquos space Secondly an abstract workflow representingthe composite service is generated

In spite of the high precision that might be achieved with semantic tech-niques for services composition some limitations exist i) this process istime-consuming due to the inference required during search ii) The lack ofunified ontologies in different domains prevents its spread ii) It requiresusers to have enough domain knowledge to perform semantic annotation andsearching which is not feasible in real application [117]For improving per-formances of semantic search some approaches present structures such asquick Extended Quick Service Query List (EQSQL)[117] these structuresassociate service and request concepts at design time in order to decrease thesearch time In [118] the author present a platform for context-aware servicecomposition based on user-defined rules The platform interprets ontologydescriptions of services and creates user-defined rules based on the ontology

32

description of services Zhang et al [119] present a review of the recentresearch methods on Semantic Web service composition

Nowadays many approaches for service composition integrate diverse AItechniques such as rule-engines and logic reasoning for example Tang etal [120] present a method for automatic Web service composition basedon logical inference of Horn clauses and Petri nets The problem of servicecomposition is transformed into the logical inference problem of Horn clausesby exploring the dependency relations among services Besides the authorspresent an algorithm for determining if the composite service exists in lineartime Li et al [121] present a novel composition mechanism by extend-ing OWL-S model This mechanism consider user preferences and combinesthe strong knowledge representation and reasoning capabilities of Descrip-tion logic with the modeling capability of action state transformations inAI planning and finally testifies its availability in DL Finally Priya et al[122] present an approach for QoS based web service selection The authorsaddress the composition of Web services using a Fuzzy rule based systemThis composition allows imprecise information to be considered and help tomodel highly complex problems that have multi dimensional data

Different techniques from AI have been applied in automated composi-tion the most successful up to date being automated planning [121] [10]Figure 12 depicts the general automated service composition in which theprocess model (ie service model) is created automatically

Figure 12 Automated service composition

Automated planning can be defined as the task of coming up automati-cally with a sequence of actions that achieve a goal [123] In planning thereare three types of elements states goals and actions Given an initial statethe goals and the set of possible actions a planning system must find a se-

33

quence of actions (called plan) that leads to some state in which the goalsare true

An action in automated planning is specified in terms of preconditionsand effects The preconditions are the facts that must hold true before theaction can be executed while the effects depict how the state changes whenthe action is executed In this way a service can be seen as an action andthe composite service as a plan [73] This kind of composition is automaticand does not require knowledge about some predefined workflow

Several approaches have emerged from AI strengthened by the fact thatOWL-S [90] the language of choice for the semantic description of Webservices based on SOAP maintains a similar structure to the descriptionlanguages used in Automated Planning [10] In this sense for instance anadaptation and extension of Golog was proposed to allow automated con-struction of composite services [66] Similarly an approach that combineHTN and automated planning was introduced for generating service compo-sition [69] This approach allows the implementation of preferences duringservice composition

Other relevant AI-based approaches are first a proposal that includesa semantic description of the composition process and of the discovery ofthe atomic services [11] Second a framework for composition based on au-tomated planning that uses an algorithm for service discovery for considerQoS requirements as well as transactional constraints during the service gen-eration process [65] Third a solution that propose to employ planning inNGN by modelling Telecom services using situation calculus and reducingthe composition problem to a planning task [68]

63 Comparison

For service generation there are a lot of manual (ie workflow-based)and automatic (ie AI-based) approaches The service generation basedon workflow requires that the users to know the domain in order to definethe workflow Thus in a broad sense a workflow-based approach may be-come cumbersome error-prone and infeasible for large or even medium scaleservice composition

Contrary to manual composition AI-based automatic generation tendsto scale better as the size of the composition increases Most of the workso far has been done on automated planning a small description of thebasic planning algorithms and their application to the service composition

34

problems can be found in the survey ldquoCurrent State and Challenges of Au-tomatic Planning in Web Service Compositionrdquo [124] In general terms theautomatic service composition problem can be reduced in some cases to theboolean satisfiability problem [125] a well-known NP-complete problem Inthis sense algorithms that carry out exhaustive search may work for smallscale compositions but for larger problems approximate algorithms that findsub-optimal solutions are more desirable [104]

To finish this comparison it is also important to highlight that for ser-vice generation approaches based on AI and workflow can be combined (iethese approaches can be complementary) For instance a framework wasintroduced for intelligently navigating service composition [70] This frame-work consists of two primary processing modules the Planning Module andthe Constraint Satisfaction Problems (CSP) Solving Module Taking advan-tage of the functional attributes of the services the Planning Module aimsto produce referred composite plans that function as general patterns TheCSP Solving Module focuses on selecting qualified services to implement thecomposite plans based on their non-functional attributes evaluation

7 Service Adaptation and Execution

In this section at starting we present approaches about the service adap-tation phase Later we present research addressing the service execution andreconfiguration phases

71 Approaches for service adaptation

The adaptation phase translates the composite service into an executablecomponent runnable on a Telecom application In this sense the automationof the adaptation phase consists of translating the composite service into anexecutable component without human intervention

The most remarkable approach for automated service adaptation is pre-sented within the scope of the TeamCom project [50] [49] [52] (see Figure 13)which deals with cases in which the developer describes the business processusing BPEL but the resulting BPEL process is not necessarily executable ona BPEL-engine The TeamCom platform translates the resulting BPEL pro-cess in XML next these files are in turn transformed into Java code that isdeployable on a JAIN Service Logic Execution Environment (JSLEE) server[53]

35

Figure 13 Graphical representation of the composite service [50]

72 Industrial approaches for service execution

Regarding composition of services in the Web the predominant visionfor representing composite services is BPEL and its extensions like BPEL forREST (see Figure 14) Notwithstanding such predominance for representingbusiness process BPELBPEL4REST have not been developed for controlof specific communication services [50] particularly in real time like usuallyTelecom services require Consequently BPEL and its associated executionservers are not appropriate in the sense that they cannot provide the avail-ability requirements necessary for convergent service execution [48] In thisway we consider that the best option for executing convergent services mustbe found in the range of approaches coming from the Telecom domain Thefollowing paragraphs present a summary of the Telecom technologies thatprovide alternatives for service composition execution

From the Telecom industrial perspective IMS [62] is the most impor-tant global architecture for service execution IMS is an NGN architecturalframework for delivering multimedia services based on IP and SIP In itsorigins IMS represented an approach to delivering ldquoInternet servicesrdquo overdata services for 2G and 3G mobile networks The purpose of IMS was laterupdated for supporting also Wireless Local Area Networks (WLAN) mobileprotocols and fixed lines An important characteristic of IMS is that it usesstandard technologies for its communications in order to provide convergenceof services Despite the potential that IMS has the migration to IMS-basedplatforms has been overall slow due to the high cost of updating the equip-ment and software for Telecom management necessary to adopt IMS

Figure 15 presents the layers of IMS The Access layer manages the con-nection of users with IMS terminals such as phones personal digital assis-tants (PDAs) and computers through different protocols The only require-

36

Figure 14 Graphical representation of a composite service

Figure 15 Layers of IMS

ment is that these devices must support IP and SIP Most of the protocols ofmobile Telecom networks (eg the General packet radio service - GPRS) andwireless networks (eg WLAN) are supported Other non IMS-compatiblephone systems like traditional telephone devices (ie PSTN terminals) aresupported through gateways

37

The Control layer manages the authentication and routing this layeralso provides the capability of associating or composing services from theServices layer The main element in this layer is called the Call SessionControl Function which orchestrates the interaction between the services inthe service layer IMS uses a simple orchestration mechanism to select theservices that are needed within a Telecom session However this method isnot dynamic so any service that a user might need is placed in the chain ofservices regardless of their actual usefulness for a given session

The Services layer holds all of the actual set of services This set includestraditional Telecom services such as call forwarding and voicemail as wellas services accessible via Web-based protocols The IMS services may beinstalled in application servers or in media servers In the Service layermost of the researchers [50] [49] [52] [126] [127] [128] have focused on theuse of JSLEE as the subjacent application server for executing convergentservices

JSLEE (see Figure 16) is a high throughput and low latency event process-ing application environment It provides a robust platform for rapid develop-ment and deployment of convergent services The access to network resourcesand services available in the Web is offered by the Resource Adapters (RAs)Furthermore the use of RAs allows equipping the JSLEE platform withcapabilities such as Authentication Authorization and Accounting (AAA)among many others [129]

JSLEE includes a component model to structure the logic of convergentapplications where the basic services (from the Telecom andor the Webdomain) are represented as Service Building Blocks (SBBs) JSLEE alsoenables the composition of SBBs by combining two or more basic servicesRecent studies have demonstrated that JAIN SLEE is suitable for provision-ing of convergent services in production environments by using commercialsolutions such as the Mobicents JAIN SLEE [131] and the Rhino Appli-cation Server [132] In this sense for instance some works [130] [128] hasdemonstrated that even for complex services the throughput obtained iscomparable with the traffic handled by a large gateway node of an VoIPoperator

The other type of Java application servers that can be used in the Serviceslayer of IMS is based on the SIPServlet specification [63] SIPServlet con-tains and manages SIP applications and provides access to SIP mechanismsvia a Java API The SIPServlet API defines a component called ApplicationRouter (AR) which is responsible for the selection and composition of ser-

38

Figure 16 Overview of JSLEE architecture [130]

vices In this sense the Ericsson composition platform [59] is a SOA-basedsolution that allows the composition of convergent applications using servicesfrom Web enterprise and Telecom domains for both circuit-switched and IP-based services This solution selects the services to be used and informs IMSabout the SIP service to be executed Other approaches [133] [134] have ex-plored the integration of SIP-based servers (eg Sailfin) with Java EnterpriseEdition Servers (eg GlassFish) to conduct IMS service composition

Parlay X [101] is an important alternative to provide convergent servicesin NGN-based networks permitting the use of Web services in the Telecomdomain Parlay X [60] [135] is an standard that comprises a set of services(from the Web and Telecom domains) offered like APIs that facilitate thecomposition of more complex functionalities to be provided in Telecom net-works An example of a commercial server supporting Parlay X is the UnifiedService Platform ZXUP10 of ZTE Inc [136]

OneAPI [61] appears as an evolution of Parlay X OneAPI is also a set ofsupported APIs that exposes network capabilities such as messaging pay-ments and location on the Internet Using such guidelines any mobile op-erator or service provider may implement or use OneAPI As an exampleany messaging service could be used by any other application for sendingSMS messages Regarding the ONEAPI is also important to note that it

39

already provides simple interfaces for different Telecom and Web protocolsHTTP among them Supporting HTTP ONEAPI can execute convergentapplications formed by SOAP-based services Telecom features and RESTfulservices In this vein some companies provide Telecom services under sub-scription over the internet using SIP protocol among them Hoiio [54] Tropo[55] Twillio [58] CallFire [56] and Skype [57] Each one of these companiesprovides their own languages to describe the offered functionalities

73 Academic approaches for service execution

Recently some academic alternatives have reaffirmed the preponderanceof JSLEE [137] In this sense a service platform was proposed in order to ful-filling the Telecom requirements (ie low latency real time and fine-grainedevents) when convergent services are requested This platform is event-basedarchitecture provides asynchronous iteration and supports JSLEE [45]

Other existing approaches [48] [135] [29] [128] mix JSLEE with Enter-prise Service Bus (ESB) to support convergence service composition overheterogeneous networks ESB (see Figure 17) is an architectural model thatprovides a common connectivity layer between services of the Web Servicessupported by ESBs are not restricted by a protocol like HTTP nor have to bedescribed by a specific descriptor such as WSDL In the ESB world a serviceis a functional component that is used as a meta-data descriptor understand-able by computers Such descriptor is published so it can be used withoutneeding the implementation of the service All clients communicate with theESB in the same way in turn the ESB is on charge of the translation ofmessages (format and structure) between client and provider services [138]

On the other hand some approaches [139] [140] propose the integrationof SIP and BPEL for the execution of convergent services These approachespresent for instance the abstract design of a hybrid multimedia conferenceframework with low latency services which allows the execution of bothprimitive and composite conference services

Finally HSCEE [28] is an approach that employs ESB JSLEE and BPELto carry out template-based service composition HSCEE was employed tobuild a prototype of a typical communication multimedia conferencing systembased on Web services This system can concurrently run multiple instancesof conferences in common public networks being able to support multi-userconferences employing various network terminals from anywhere Authorsalso present promising performance results in the presented prototype

40

Figure 17 General diagram of ESB functioning

74 Comparison

To select a technology for Execution of convergent services different cri-teria must be considered Previous works have focused on the comparisonof these technologies [91] and most of them agree that the best selectiondepends exclusively on of the needs of the user As aforementioned IMSis an architectural framework that defines a series of guidelines for futureimplementation of convergent scenarios In the Service layer of IMS bothSIPServlets and JSLEE are applicable Thus our analysis will focus onthese two technologies

JSLEE and SIPServlets are both standards regarding the execution ofconvergent applications Both standards define a container-based model forapplications which describes how applications may be built and deployedin their respective containers and how services and features can be suppliedby the containers JSLEE is a more complex specification than SIPServletsJSLEE includes mechanisms for fault tolerance and high availability whereasSIPServlets does not Essentially SIPServlets remain only as a programmingmodel whereas JSLEE aims to be a robust application environment

In this paper we are interested in providing guidelines about the conver-gent service composition Such labour establishes a set of basic requirementsthat are the basis of our comparison (see Table 4) in the execution phaseSupport for different protocols Support for reconfiguration and Model forrepresenting the composition

41

Table 4 Comparison of approaches for convergent service execution

Standard Protocols Reconfiguration Model

SipServlet HTTP and SIP Timer Servlet-based

JSLEE Agnostic Timer transactions failure management and JMX Object-based

Support for different protocols Whereas SIPServlet provides sup-port for SIP and HTTP JSLEE is protocol agnostic that is to say thatJSLEE can be extended to support additional protocols (adding RAs) andexternal resources with a consistent event model regardless of protocolre-source As convergent services are formed by atomic services (using a lot ofdifferent protocols) available in the Telecom and Web domains IMS appli-cation servers must support many protocols and APIs (not just SIP)

Support for reconfiguration Consumers of convergent services willexpect high quality of service so an execution environment must be a carrier-grade platform that addresses corresponding requirements of continuous avail-ability and performance To provide an acceptable degree of availability amechanism for monitoring and reconfiguration is mandatory due to the in-herent changing nature of services available in the Web domain

About reconfiguration is important to highlight (i) SIPServlet has nostandard management mechanisms defined until now JSLEE counts withstandard management interfaces based on the Java for Management Exten-sion (JMX) independent of the subjacent management protocol The mainsupported functions are life cycles upgrades profiles and tracing (ii) re-garding the utilities for applications that can be useful for monitoring andreconfiguration SIPServlet has the timer function while JSLEE has TimerTrace Alarm and Statistics among others (iii) JSLEE has a container-managed state and wide support for transactions while SIPServlet has nosuch functionality (iv) SIPServlet cannot define a failure model while JSLEEprovides a robust failure model via transactions and (v) while SIPServletsare stateless and the shared state may be stored in a separate session objectas a name-value (String Object) visible within the session the SBBs maybe stateful or stateless SBB state is private type safe transacted and a

42

property of the SBB itself (ie an SBB is an object) the shared state maybe stored in a separate context via a type safe interface and the access to theshared state may be specified at deploy time

Model for representing the composition As the convergent servicecomposition must be the most automated possible the model of the subja-cent technology must easily support the automation of the composition Inthis sense it is important to noteworthy (i) Services in SIPServlet are repre-sented as entities based in HTTP Java Servlets without a standard model forcomposition and (ii) JSLEE represents services using an Object Orientedmodel that see the services as SBB providing support for composition andreuse

From the previous discussion it is clear that SIPServlet provides supportfor the adoption of the SIP protocol and the development of simple SIPservices However convergent services have requirements that exceed thecapabilities of SIPServlet In contrast JSLEE has been developed to satisfythe requirements of Telecom services in tier-one service providers [91] Thisleads us to declare JSLEE as the better option for executing convergentservices

Regarding the automation of the execution phase JSLEE has still rele-vant shortcomings As mentioned previously the execution phase is inher-ently automatic as once the user deploys the service it runs in the executionenvironment without human intervention The problem arises when a mal-function or an error appears In this vein the role of automated reconfigura-tion in the convergent service composition is very important However littlehas been said about this topic in spite of the existing tools provided by theJSLEE server Some approaches [141] [142] [105] offer alternatives for JSLEEservice reconfiguration based on advanced selection algorithms of services incase of failure Nonetheless we think is important to analyze the feasibilityon using current approaches of Web service recovery [143] for reconfiguringconvergent compositions

8 Research directions

From the above review we can see that many advances have been made invarious research aspects including automated generation graphical creationand execution of convergent services in telecom environments Howeverthere are still many open research issues that need to be solved before theautomated composition can be of practical use This section presents the

43

research directions and how existing approaches can be used or contribute toaddress the challenges of convergent service composition

Availability of services whereas in the Telecom domain the avail-ability of services is close to 100 in the Web domain services can raisechange or disappear continually Recent approaches are focusing its effortson defining approaches for reconfiguring compositions that involve servicesfrom both domains These approaches tackle the ongoing changing in theservice libraries and consider failover mechanisms (eg to replace servicesin failure) that allow the reconfiguration of composite services These ap-proaches can be divided in two groups

One group of approaches for reconfiguration aims for solving convergentreconfiguration adapting mechanisms from Web services reconfiguration inconvergent domains These approaches mostly dealt with replacement offailing services and consequently most of the existing related approachesare focused on service selection of potential replacement services In [144]the authors present architectures for automated reconfiguration of conver-gent services in Telecommunication environments In order to reduce re-configuration times while holding the initial constraints the authors presentan iterative algorithm which does not replace individual services but wholeregions of services specified with Hierarchical Tasks Networks (HTNs)

Other group of approaches for convergent reconfiguration adapt servicescomposition according to the changing situation and environment of the usermost of the proposed techniques may be used in the convergent compositionChen et al [145] present a model for service composition in high mobilityenvironments The model for decentralized service composition adapts itselfby composing fragments on-demand as appropriate to the constraints of ser-vices costumers and providers [145] Neiat et al [146] present a failure-proofcomposition model for Sensor-Cloud services based on dynamic features suchas spatio-temporal aspects The authors present a failure-proof compositionalgorithm based on D Lite to handle QoS changes of Sensor-Cloud servicesat run-time

Number of services In the Telecom domain the number of servicesis relatively low (eg messaging phone calls location and video call) Incontrast the number and nature of services in the Web domain is essentiallyhigh and changing (eg shopping translator and social networks) Thishigh number of services turns complex the use of traditional methods suchas SCEs and MDEs for creating convergent services Therefore some of theresearch approaches analyzed here specially the group of approaches based

44

on automated planning may be used for discovering convergent services inTelecom infrastructure for example Ordonez et al [109] present a frame-work for including automated composition approaches based on automatedplanning in Telecommunications scenarios On the other hand recent algo-rithms such as [147] [148] a uses mechanisms for reducing the services searchspace by pruning candidates by dominance relationships and constraint val-idations at candidate level Finally some approaches are focused on the useof data mining in services composition Bayati et al [149][150] use datamining techniques on Web services in order to find the best composition ina set of possible compositions These works use techniques such as associa-tion Classification and clustering are for improving performance of the WebService Composition

With the increasing presence of web services on the Internet Quality ofService (QoS) is becoming important for describing non-functional character-istics of services and is often employed in web service composition [147][151]In [147] a service composition algorithm using partial selection techniquefor QoS-Aware Web Service Composition this algorithm reduces the searchspace due to the fact that it prunes candidates by dominance relationshipsand constraint validations at candidate level [147] Equally Moustafa et al[148] propose two algorithms based on reinforcement learning for composingand adapting Web services in open and dynamic environments the first al-gorithm introduces an offline learning scheme for service composition whereone online learning task is transformed into a series of supervised learningsteps The second algorithm presents a coordination mechanism in order toenable multiple agents to learn the service composition task cooperatively In[152] the authors present a novel multi-objective that addresses QoS-awareWeb service composition with conflicting objectives and various restrictionson quality matrices The approach uses reinforcement learning to deal withthe uncertainty inherent in open and decentralized environments Experi-mental results reveal the ability of the proposed approach to find a set ofPareto optimal solutions which have the equivalent quality to satisfy multi-ple QoS-objectives with different user preferences

The aspect of services discovery is related to the description of servicesthat will be addressed below

Services description Though standardized or broadly accepted lan-guage do not yet exist for describing convergent services the trend indicatesthat as in Social Web and Telecom network management REST-based ser-vices have turned a de facto standard to publish functionalities we consider

45

that existing languages (eg WSDL WADL and hREST) may be adaptedto specific domains Existing languages such as BPEL BPEL for RESTBite and LPML offers the base for unifying description of service composi-tions specially when these compositions include services based on protocolssuch as SOAP-XMLHTTP JSON-XMLHTTP RSS Atom and SIP Re-garding Telecommunication providers different service providers based oncloud computing such as Skype or Twillio may offer its own standard orlanguage In this scenario the option of Enterprise Service Buses (ESB) ac-quires high relevance due to its potential for translating different standardsDespite improvements research for describing Telecom services using wellestablished techniques from the Web services must be expanded These ex-tensions and improvements will be fundamental to facilitate the evolution ofconvergent service composition

Interfaces of user In the Web domain the user interacts with thesystem using mostly interfaces controlled with a keyboard and a pointingdevice or a tactile screen In contrast in the Telecom domain the voice isthe primary element to interact with the phone especially when the user ismoving or driving Therefore existing academic and industrial approachesbased on natural language (both commercial and open source) can be usedfor providing and consuming convergent services with richer user interfacesHere rich user interfaces must be understood as these in which the user canaccess the convergent applications using keyboards tactile screens and voicedepending of the user context For example [153] Natural language processingis used to identify services required to accomplish the user request Thisapproach represent the identified tasks in model and from this model a userinterface (UI) is generated The authors claim that the system can extractthe tasks from how-to instructions Web pages with high precision The workof Ordonez et al [110] present the use of natural language processing inconvergent domains by translating user request and context into automatedplanning representations

Context of user In the Web domain the context and preferences ofthe user considered during service composition rarely change in real timeConversely in the Telecom domain the user is often in constant movementand the type and capabilities of the device cannot be known beforehand inmany cases which means that the user context must be considered modeledand included in the composition process In this regard many research workscan be applied for particular solutions of convergent composition For exam-ple [154] presents an automated composition systems that incorporates SOA

46

paradigm and devices implemented by device profile for web service (DPWS)This approach presents a composition engine that considers context informa-tion composition templates and predefined policiesEqually NGSON [155]is an IEEE sponsored effort to standardize an open service ecosystem thatallows composing and delivering services dynamically across different serviceproviders and network operators domains NGSON uses context informa-tion to drive the interactions of the NGSON overlay nodes with service andnetwork operator infrastructures

Time constraints and number of protocols During developmentof convergent composition solutions the heterogeneity of protocols networksand time restrictions may be tackled by selecting robust environments forservice execution JSLEE offers a high reliable environment for supportingTelecommunications constraints JSLEE provides independence of protocoland interfaces for diverse networks equally JSLEE considers time constrainsproper of telecom domains

9 Conclusions

Selection of technologies for specific convergent composition solutions iscomplex due to the big amount of considerations In this paper we haveidentified the relevant phases for convergent service composition and exploredthe existing approaches for automating each one of these phases It has beenanalyzed that all phases of convergent composition have reached high level ofautomation using different approaches Following as conclusion we providegeneral guidelines that help to select the most suitable approach for eachdomain or problem

Domain knowledge If the user possesses domain knowledge he will beable to create a full specification that details the specific tasks and the data-control flow among them as well as other non-functional requirements Con-versely it cannot be expected of a non-expert user to create a full workflowThus for non-expert users a specification stated in terms of preconditionsand effects should be created and used to perform the composition of ser-vices Such specification should be done with domain-independent planningtechniques that do not require knowledge of the process model

Level of automation required When the number of services and thecomplexity of services composition increase automatic composition becomesmore desirable There are different variations for example a semi-automated

47

approach can generate basic templates automatically that are later presentedto the user so heshe chooses one of them and refines it manually

Context of device and user If the user requires mobility and doesnot have advanced knowledge on programming heshe may use Web-enabledgraphical interfaces provided by mashup-based approaches or alternativelyeven consider voice-based interfaces Conversely if the domain is oriented toexpert users that do not have such constraints SCE-based approaches arethe best choice

Dynamic domains In convergent composition services may becomeunavailable or be redefined by their provider This consideration justifies theneed for continuous monitoring and reconfiguration during the execution Inworkflow-based approaches this means that the user must supervise the ex-ecution process and perform the necessary changes in automatic approachesthe system must react and adapt itself to the circumstances with as littlehuman intervention as possible For convergent domains JSLEE offers a setof features that could ease reconfiguration implementation standard man-agement interfaces based on JMX independence of management protocoland interfaces for managing applications Also it is important to highlightthat some AI-based planning platforms include execution and replanningwhich may alleviate the reconfiguration problem to some extent These AI-based approaches are an interesting alternative but they need to considerthe complexity and performance requirements of the Telecom domain

Acknowledgements

The research of PhD(c) Caicedo is supported by the PECPG (AgreementProgram Students Graduate) of the CAPES (Brazil) and the University ofCauca (Colombia)

References

[1] Z Luo J Wang Q Zhu Self-aware Services of NGSDP UsingBayesian Networks for Measuring Quality of Convergent Services Jour-nal of Internet Services and Information Security (JISIS) 1 (1) (2011)46ndash58

[2] S Moyer A Umar The impact of Network Convergence on Telecom-munications Software Communications Magazine IEEE 39 (1) (2001)78ndash84

48

[3] M Vrdoljak S I Vrdoljak G Skugor Fixed-mobile ConvergenceStrategy technologies and market opportunities CommunicationsMagazine IEEE 38 (2) (2000) 116ndash121

[4] J Simoes S Wahle The Future of Services in Next Generation Net-works IEEE Potentials 30 (1) (2011) 24ndash29

[5] C dos Santos R Bezerra J Ceron L Granville L Rocken-bach Tarouco On Using Mashups for Composing Network Manage-ment Applications Communications Magazine IEEE 48 (12) (2010)112ndash122

[6] O M C Rendon C R P dos Santos A S Jacobs L Z GranvilleMonitoring Virtual Nodes using mashups Computer Networks 64 (0)(2014) 55 ndash 70

[7] M Saadatmand A Cicchetti D Corcoran M Sjodin Toward a Tai-lored modeling of Non-functional Requirements for TelecommunicationSystems in Information Technology New Generations (ITNG) 2011Eighth International Conference on IEEE 2011 pp 1044ndash1045

[8] R Berkan B Upadhyaya L Tsoukalas R Kisner R Bywater Ad-vanced Automation Concepts for Large-scale Systems Control Sys-tems IEEE 11 (6) (1991) 4ndash12

[9] K Sycara M Paolucci A Ankolekar N Srinivasan Automated Dis-covery Interaction and Composition of Semantic Web Services WebSemantics Science Services and Agents on the World Wide Web 1 (1)(2003) 27ndash46

[10] E Kaldeli A Lazovik M Aiello Continual Planning with Sensing forWeb Service Composition in AAAI 2011

[11] O Hatzi D Vrakas M Nikolaidou N Bassiliades D Anagnostopou-los L Vlahavas An Integrated Approach to Automated Semantic WebService Composition through Planning Services Computing IEEETransactions on 5 (3) (2012) 319ndash332

[12] O M C Rendon F Estrada-Solano L Z Granville A Mashup-BasedApproach for Virtual SDN Management in Computer Software and

49

Applications Conference (COMPSAC) 2013 IEEE 37th Annual 2013pp 143ndash152

[13] O Caicedo Rendon F Estrada-Solano L Zambenedetti Granville AMashup Ecosystem for Network Management Situations in GlobalCommunications Conference (GLOBECOM) 2013 IEEE 2013 pp2249ndash2255

[14] O Caicedo Rendon F Estrada Solano L Zambenedetti GranvilleAn Approach to Overcome the Complexity of Network ManagementSituations by Mashments in Advanced Information Networking andApplications (AINA) 2014 IEEE 28th International Conference on2014 pp 875ndash883

[15] P Corporation Voice Controlled Internet Mashups (2012)URL httpwwwzyprnet

[16] Apple Use Your Voice to Do Even More with Siri (2013)URL httpwwwapplecomiossiri

[17] M Belaunde P Falcarin Realizing an MDA and SOA Marriage forthe Development of Mobile Services in Model Driven ArchitecturendashFoundations and Applications Springer 2008 pp 393ndash405

[18] P Falcarin Service Composition Quality Evaluation in SPICE Plat-form in High assurance services computing Springer 2009 pp 89ndash102

[19] G Bond E Cheung I Fikouras R Levenshteyn Unified Telecom andWeb Services Composition problem definition and future directionsin Proceedings of the 3rd International Conference on Principles Sys-tems and Applications of IP Telecommunications ACM 2009 p 13

[20] H Gebhardt M Gaedke F Daniel S Soi F Casati C A IglesiasS Wilson From Mashups to Telco Mashups a survey IEEE internetcomputing 16 (3) (2012) 70ndash76

[21] V Agarwal G Chafle S Mittal B Srivastava Understanding Ap-proaches for Web Service Composition and Execution in Proceedingsof the 1st Bangalore Annual Compute Conference COMPUTE rsquo08ACM New York NY USA 2008 pp 11ndash18

50