WIXLIB

This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENTSERIES, December 2011. This is an author copy for personal record only.II.2REST PRINCIPLESREST adopts the client-server architecture of the web.REST does not restrict client-server communication to aparticular protocol, but REST is most commonly used withHTTP because HTTP is the primary transfer protocol of theWeb. RESTful Web services can be described using the WebApplication Description Language (WADL) [7]. A WADLfile describes the requests that can legitimately be addressedto a service, including the service’s Uniform ResourceIdentifier (URI) and the data the service expects and serves.REST relies on three main design principles [8]:addressability, uniform interface, and statelessness. Foraddressability, REST models the data-sets to operate on asresources, and identifies each resource via a URI. A resourceis any form of information that can be named and that isimportant enough to be referenced (e.g. a document, a row ina database, a search result).REST resources are accessed via a uniform and standardinterface. A uniform interface offers a number of advantagesamong which are familiarity (i.e. the set of operations aRESTful Web service may expose are known) andinteroperability. Statelessness means that each REST requestis self-contained with all the information that the server needsto fulfill the request. No client-session data is stored on theserver and the server never relies on information fromprevious requests to answer a new request. The followingadvantages are usually associated with statelessness: easyapplication development, good scalability, and easy loadbalancing.REST is not an architecture, but a set of design criteria.Resource-Oriented Architecture (ROA) is a RESTfularchitecture that provides a commonsense set of rules and astep-by-step procedure for designing RESTful Web servicesfollowing these design criteria. The fundamental mindset ofROA is the concept of resources. Each resource has a name(i.e. a URI) and a representation, and it may be linked to otherresources via hyperlinks. A resource representation is what theclient receives when it sends a request concerning a resource.The representation can be defined as any useful informationabout the current state of the resource. An example in the caseof conferencing is the list of participants.REST (and ROA) supports a wide range of representationformats, including plain text, HTML, XML and JavaScriptObject Notation (JSON). ROA uses HTTP as thecommunication protocol. Therefore, the ROA uniforminterface consists of HTTP operations, the most commonlyused being GET, PUT, POST, and DELETE. We can design aRESTful Web service using ROA in the following steps. Wefirst figure out the data set on which the service will operate,and split it into resources. After that for each resource weproceed as follows. First, we name the resource using a URI. Second, we identify the subset of the uniform interfacethat is exposed by the resource. Third, we design the representation(s) of the resource asreceived (in a request) from and sent (in a reply) to theclient. Fourth, we consider the typical course of events byexploring and defining how the new service behaves andwhat happens during a successful execution.For a detailed description of these steps, the reader canconsult [8].II.3RESTFUL WEB SERVICE EXAMPLEThe proposed illustrative service provides the samefunctionalities as the SOAP-based Web service described inParlay-X Multimedia Conference specification [6].Conferencing is one of the main services in NGNs.The Parlay-X conferencing service is technology neutraland allows applications to create and manage a multimediaconference. The underlying model of the Web service is basedon three entities: conference, participant and media. Theconference is the uniquely-identified context, to whichparticipants can be added and removed. The participant is anyparty that participates in the conference. The media representsthe media stream to support a participant's communication(e.g. audio, video, chat) and the stream direction (i.e. in, out,bidirectional).In this example, ‘conference’, ‘participant’ and ‘media’ arethe data set on which to operate. For sake of simplicity, wefocus on conference and participant. The data-set is then splitinto three resources: ‘conference’, ‘list of participants’, and‘participant’. The first resource represents a specificconference. The second lists the participants of theconference, and the last represents individual participants.The ‘conference’ resource is named with the URI:http://www.confexample.com/{confId}/, confId being theunique identifier of the conference, the ‘list of nts/{participantURI}/, since every participant is identified by his/her URI.The three resources can be read, created and deleted atruntime. The first column of Table 1 lists the resources, andthe second lists the subset of the uniform interface that isexposed by each resource. The last column gives therepresentations accepted from the client and those served bythe server for each operation.

This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENTSERIES, December 2011. This is an author copy for personal record only.Table I: Resource description and data representationExposed subset of the uniform interfaceResourceOperationData representationHTTP actionClient- ServerConferenceList ofparticipants/ParticipantServer- ClientCreate: establish aPOST: http://confexample.com/conference conference http://www.confexample/conf23@example.com description discuss project /description maxParticipants 10 /maxParticipants /conference Read: Getconference statusGET: http://confexample.com/{confId}None status Active /status Delete: end aconferenceDELETE: http://confexample.com/{confId}NoneNoneNone participants participant uri alice@ericsson.com /uri status Connected /status /participant . /participants participant alice@ericsson.com /participant participant uri alice@ericsson.com /uri link @ericsson.com /link /participant Read: Get list ofparticipantsGET: : Add aparticipantPOST: http://confexample.com/{confId}/participantsRead: Get aparticipant icipants/{participantURI} status Invited /status Delete: remove fId}/participants/{participantURI}NoneFigure 3 presents a sample sequence diagram that showswhat should happen during a successful execution of theservice. The client (i.e. Alice) sends a POST request to theservice URI, to request the creation of a new conference. Theserver creates a new ‘conference’ resource and sends theresource URI to the client. When the conference is created andthe necessary resources reserved, the server sends a 200 OKmessage. In step 4 of the figure, the client asks for theconference status, which she will get in the 200 OK response.In step 6, the client requests the addition of a new participant.She is first informed that the request is accepted, then she getsa 200 OK when the participant is actually added to theconference.AliceConf AppREST ClientREST ServerBob1 : POST(http://www.confexample.com)2 : 202 ple.com)The server creates the conference3 : 200 OK4 : om)5 : 200 OK6 : com/participants, bob@ericsson.com)7 : 202 AcceptedThe server adds the participant(s) to the conference8 : INVITE9 : OK10 : ACK11 : 200 OKFigure 3: Sample sequence diagramIII.THE STATE-OF-THE-ARTREST has been widely used outside of NGNs. Someexamples are read-only Web applications (e.g. static websitesand search engines), Amazon’s Simple Storage Service (S3),twitter, and most of Yahoo!’s Web services. The use of RESTfor service provisioning in NGNs is rather recent and includesboth standardization efforts and work done outside standardsbodies.III.1STANDARDIZATION EFFORTS

This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENTSERIES, December 2011. This is an author copy for personal record only.Several bodies are attempting to produce standardspecifications for REST-based service provisioning in NGNs.We review here the Open Mobile Alliance (OMA) and theIETF efforts.The OMA is working on a REST binding (ParlayREST) forParlay-X Web services. Thus far, the OMA has focused onrelatively simple non-session based services. Thespecifications include Short Messaging, Multi MediaMessaging, Payment and Terminal Location Parlay-X WebServices. They have defined the resources and use HTTP astheir message transfer protocol. As for resource representationformats, XML and JSON are used for all resources, but otherformats may be used for some specific resources.The ParlayREST specification for Short MessagingService [9] is used in this paper for the purpose of illustration.It provides support to: Send text messages to a terminal and check their deliverystatus. Check, retrieve and delete the incoming messages. Create and delete subscriptions for notifications forinbound/outbound messages.Table II summarizes some of the service resources, theirURIs and the operations they accept.Table II: A subset of ParlayREST SMS resourcesResourcesOutbound SMSmessage requestsOutbound SMSmessage request anddelivery statusInbound SMSmessagesubscriptionsIndividual inboundSMS messagesubscriptionURLBase outbound/{senderAddress}/requestsHTTP actionGET: read pending outbound messagerequestsPOST: create new outbound {requestId}GET: read a given sent message, alongwith its delivery status/inbound/subscriptionsGET: read all active subscriptionsPOST: create new message subscriptionGET: read individual } DELETE: remove subscription and stopcorresponding notificationsFigure 4 presents a sample scenario for sending andreceiving a message. In the first part of the figure (i.e. SMSsending), the application sends an ‘SMS sending’ request tothe URI of the ‘outbound SMS message requests resource’,using the POST operation. The SMS to be sent is included inthe request body. The server creates a new resource and sendsits URI to the application (including the requestId).ApplicationServer1 : POST outbound SMS requestCreate resource and allocate requestIdSMSsending2 : Response with created resource including requestIdShort wait3 : GET delivery status of request using requestId4 : Response with delivery statusInboundSMSnotification5 : POST inbound SMS online subscriptionCreate resource and allocate subscriptionId6 : Response with created resource incl. subscriptionIdSome time later7 : POST notification to the notifyURL specified in the subscription8 : ResponseTo anotherapplicationspecified asnotifyURL9 : DELETE the subscriptionAt later time10 : ResponseFigure 4: Sample scenario for SMS handlingIn step 3, the application checks the delivery status using aGET request sent to the URI of the newly created resource. Inthe second part of the figure, the receiving applicationsubscribes to the notifications for inbound messages bysending a POST request to the URI of the ‘Inbound SMSmessage subscription’. The server creates a new ‘Individualinbound SMS message subscription resource’ and transmits itsURI to the application. The application may use this URI laterto delete or get information about the subscription. When theserver receives a SMS destined to the application, it notifiesthe application whose URI is specified in the subscriptionrequest, using a POST request.The IETF is working on REST-based approach for theCentralized Conferencing Manipulation Protocol (CCMP).CCMP is a stateless, XML-based, client-server protocol forconference control [10]. The CCMP specification includes ageneral (i.e. non-REST specific) discussion of the protocol,and a discussion of a RESTful approach to the protocol.The CCMP allows users to create, manipulate (e.g.add/remove participants, add/remove media streams) anddelete conference objects. A conference object is a logicalrepresentation of a conference instance, representing thecurrent state and capabilities of a conference. The RESTfulapproach for the CCMP uses HTTP as the transfer protocolfor CCMP messages, models the conference objects asresources identified by URIs, and uses XML for datarepresentation.III.2WORK DONE OUTSIDE THE STANDARDS BODIESExamples of work done outside the standardization bodiesare presented in [11] and [12].

This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENTSERIES, December 2011. This is an author copy for personal record only.[11] discusses three approaches for exposing telecomcapabilities (e.g. SMS, presence) with REST. The firstapproach uses an existing service delivery platform (SDP) as amiddle-layer over which the RESTful API is provided (Figure5). The SDP may belong to the NGN network operator or to athird party. The API can be built as an application inside theSDP that provides the necessary mappings to the actualnetwork elements that provide the capabilities to expose. Thisoption has the advantage of lowering the integration effort ofthe RESTful API to the network capability. However, the SDPmay become an unnecessarily heavy middleware if it is onlyused to provide the RESTful API.Figure 5: Integration via an SDPThe second approach is to have the RESTful API deployedon a separate system that is integrated to the appropriatenetwork element as-needed. This approach bypasses the SDPoverhead, but it requires substantial work on integration. Themapping layer is integrated with the RESTful API, which isdirectly integrated to a specific network element.In the third approach, the RESTful interface and the servicelogic are run as a standalone system, with no integration to theoperator network. One example is to provide a RESTful SMSservice by integrating to a third-party SMS service provider.This approach allows for the service to be run by any party,but it has the disadvantage of not allowing access to theresources and information residing on the operatornetwork/system (e.g. subscribers’ information).[12] proposes a generic REST approach to expose thesession-based capabilities of the 3G IP Multimedia Subsystem(IMS). This approach models the sessions (e.g. multimediasessions) as resources, and each resource represents a sessionassociated with a specific service. A conferencing sessioninitiated by Alice for instance is named D. Eachresource considers the session’s state, list of participants,media description and links to the session’s mediacomponents.[12] also proposes an architecture for IMS and Web 2.0convergence, and discusses two guidelines for exploiting Web2.0 services and technologies to enrich telecom operator’sservices. Web 2.0 is a concept that promotes interactiveinformation sharing and collaboration over the Web, as wellas Web application consumption by software programs. Thefirst guideline is to incorporate Web 2.0 content (e.g. usergenerated video) and events (e.g. contextual informationassociated with social networks) into telecom services. Thiscan enhance user experience and increase servicecustomization.The second guideline is IMS services’ delivery via webpages. Web 2.0 technologies are used to build on-lineapplications. The applications use directly the services offeredby the operator. An example is a virtual IMS terminal thatruns in an end-user’s browser. The major benefits here areservice ubiquity, the reuse of the major advances achieved byWeb 2.0 applications in the field of user interfaces, and asignificant simplification of the service development processand deployment.IV.SUITABILITY AND RESEARCH DIRECTIONSWe use NGN service provisioning requirements asidentified by ITU-T to evaluate the overall suitability of REST.The requirements are presented first. The overall suitability isthen discussed in light of the requirements. Researchdirections are discussed last.IV.1 NGN REQUIREMENTSSome NGN requirements impact all layers, including theservice layer, while others impact only specific layers [1]. Themain layer independent requirement deals with QoS andsecurity. A mechanism for end-to-end QoS should be definedand security mechanisms should be provided to protect theexchange and the use of sensitive information, includingauthentication, authorization and encryption. The layerspecific requirements are discussed below.One fundamental requirement of NGNs is the support of awide range of services, and more specifically, making thecreation, deployment and management of all kinds of knownand unknown services possible and easy. This aspect includesenabling service providers (or operators) to find and reuseservices offered by other providers (operators) to build newservices. This requires support for service description, andservice publication and discovery.Still another requirement is to allow for applications to bebased on service building blocks and functional entities. Thisenables the reuse of existing services and allows the buildingof composed applications.NGNs also require the support of a wide range of terminalssuch as telephones, cell phones, PDAs and laptops to accessthe NGN services, which implies that client applications mustbe simple and adaptive.The last requirement is to provide unified characteristics forthe same service as perceived by the user. This can beprovided via the provisioning of standardized and openinterfaces for the provided services.IV.2 REST AND NGN REQUIREMENTS

This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENTSERIES, December 2011. This is an author copy for personal record only.Regarding QoS and security, current RESTful Webservices are mostly based on HTTP, and therefore reuse theHTTP best-effort QoS mechanism. In terms of security, theservices rely on Web/HTTP security mechanisms, such asTransport Layer Security (TLS), to secure access to RESTfulWeb services. HTTP defines two authentication andauthorization schemes (i.e. simple challenge/response anddigest authentication), but there is a standard means tointegrate other authentication schemes into HTTP, such as theschemes defined for SOAP-based Web services [8].Regarding the layer-dependent requirements, RESTful Webservices enable a wide range of end-user services because theyenable easier development and deployment of these services.The development paradigm is based on the natural way theWeb works.However, the development of complex session-basedservices may not be so obvious, due in part to the statelessnessof REST. This is especially the case for services for which theserver needs to maintain some states. One example is floorcontrol-based conferencing where a floor is granted to arequester only if nobody already holds it. It is important tomention that REST statelessness does not mean that theservice cannot have a state. The server can store and managethe state of the resources it exposes. For instance, uponreception of a conference creation request, the server createsthe conference and maintains its state (e.g. the current list ofparticipants and the participant(s) that hold(s) the floor). Theclient can ask the server about the new state of the conferenceat any time but the request is independent of any previousrequest. The point here is to draw attention to the fact thatdesigning session-based services with REST principles is notstraightforward. The design does require much more detailedthought and consideration. However, the design of theseservices does not necessarily require extensions to REST.For service publication and discovery, RESTful Webservices can be described using WADL, but no appropriateservice publication and discovery platform has been definedthus far. RESTful Web services also meet the requirement forbuilding blocks. Elementary building blocks can be composedinto more complex Web services through mashups [13].Mashup is a Web concept where data, presentation orfunctionality from two or more sources are combined in orderto create new services. One example is to get a user locationusing a location service and display it using a Google map.However, the lack of an automatic service discoverymechanism limits the number of the composed services (wecan only compose the services we already know about).A RESTful Web service can be accessed by a wide range ofend-user devices, including laptops, cellphones and PDAs.However, service adaptation to different devices without anychanges is not fully achievable. Nevertheless, depending onthe particular service, the adaptation level may be controlledby limiting the client complexity (e.g. a simple service may beexecuted over a Web browser).In regards to open interfaces, there are ongoing efforts toprovide standardized RESTful APIs for telecommunicationservices (e.g. ParlayREST APIs). However, the fact that theRESTful services may use different data models and resourcerepresentation formats may result in interoperability issues.Therefore, the standard should also specify the data modelsand formats supported by each service.In summary, RESTful Web services show a strong potentialfor service provisioning in NGNs. They meet most of theNGN requirements related to service provisioning. However,research remains to be done in certain areas in order to realizeits full potential. It is important to stress that extensions toREST may not always be required.IV. 3 RESEARCH DIRECTIONSResearch directions related to RESTful Web servicesinclude open issues related to REST in general but pertinent toservice provisioning in NGNs, and open issues specific toservice provisioning in NGNs. A general open issue is servicepublic

RESTful Web services. The principles of REST are then presented, followed by the description of a RESTful Web service for conferencing service used for illustration purpose. Readers interested in the comparison between SOAP-based Web services and RESTful Web services can consult [4]. II.1 SOAP-BASED WEB SERVICES IN A NUTSHELL