A Web Service Framework Supporting Multimedia Streaming

A Web Service FrameworkSupporting Multimedia Streaming

Gibson Lam and David Rossiter

Abstract—The transfer of streaming data is not well supported by current web services standards. To include multimedia streaming

support in the web services domain, this paper presents a novel multimedia streaming web services framework for the transfer of

streaming multimedia content. First, the framework includes an implementation of a query service for publishing a description of the

multimedia content that is input to or output from a multimedia web service. This query service is specified in an extension of WSDL.

Using MPEG-7 metadata, content descriptions can be queried before the invocation of a multimedia web service. Second, two new

MEPs and their SOAP HTTP bindings are created for the exchange of streaming data between two SOAP endpoints. The

implementations of these new MEPs use the MIME multipart/related structure and MTOM packaging when transferring the

multimedia packets as SOAP messages. To reduce the transfer overhead introduced by the packaging method, this paper

investigated extensively the application of various compression schemes for the SOAP messages as well as for the packaging of the

binary packet data. Experiments show that the proposed framework can achieve a performance comparable to a simple HTTP

multimedia streaming method.

Index Terms—Binary XML, multimedia streaming, service-oriented architecture, web services

Ç

1 INTRODUCTION

SERVICE-ORIENTED architecture (SOA) is a collection ofprinciples related to the development of systems using

capabilities provided by services in a distributed environ-ment. SOA emphasizes the reusability, growth, and inter-operability of solutions developed as a composition of thedistributed services. This facilitates better scalability andmanageability and less cost for the development of large-scale systems such as multimedia systems. One of thecommon implementations of the SOA model is webservices. Web services allow machines or software tocommunicate over the network on different platforms in astandardized manner, using a set of XML-based standards.Data is commonly encapsulated and transmitted usingSOAP, which is a lightweight protocol for exchangingstructured information in an XML-based format. Under theweb service architecture, a given task can be achieved byconsuming a set of services from one or more differentservice providers.

Multimedia systems are typically monolithic systems

that are expensive and challenging to maintain and develop.

Given the advances of SOA, the development of complex

multimedia systems should be expected to reap the benefits

of using SOA. Using SOA concepts, a complex multimedia

system can be built from the composition of multiple small

reusable components. In the web services architecture, these

components are multimedia web services, which process

and/or provide multimedia data as a service.

As opposed to a monolithic system, this approachsupports reusability of the individual services and flex-ibility in the development of multimedia applications. Fig. 1shows an example scenario.

In Fig. 1, both devices request a video stream from aparticular video provider. They also need to have subtitlesadded to their video. Because of limitations such as displaycapability, the handheld device may choose to receive a videostream of a lower quality. To add subtitles, the video streambeing sent to the desktop computer goes through a subtitleservice before reaching the destination. The video streamdestined for the handheld device goes through an additionaltranscoder service before having the subtitles added.

However, because of the complexity of multimediaworkflow and the rich semantic structure of multimediadata, SOA has yet to make significant impact on multi-media application development [1]. In particular, real-timeapplications such as multimedia streaming systems arenot well supported by web services standards. A keyproblem is the lack of support for the transfer ofstreaming data between two web service end points.

1.1 Objective

This paper proposes a novel web services frameworksupporting multimedia streaming. The proposed frameworkallows multimedia web services to be published, composed,and consumed just like other web services. Development oflarge multimedia systems can be achieved using a composi-tion of services within the web services framework. Thisdistributed component-based development has the benefitsof the SOA paradigm such as maintainability, reliability,reusability, and scalability of the systems and their compo-nents. To support multimedia streaming in the web servicesframework, several fundamental issues have to be investi-gated, which are the main focus of this paper.

400 IEEE TRANSACTIONS ON SERVICES COMPUTING, VOL. 6, NO. 3, JULY-SEPTEMBER 2013

. The authors are with the Department of Computer Science andEngineering, Hong Kong University of Science and Technology, ClearWater Bay, Kowloon, Hong Kong. E-mail: {gibson, rossiter}@cse.ust.hk.

Manuscript received 17 June 2011; revised 28 Nov. 2011; accepted 21 Feb.2012; published online 13 Mar. 2012.For information on obtaining reprints of this article, please send e-mail to:[email protected], and reference IEEECS Log Number TSC-2011-06-0060.Digital Object Identifier no. 10.1109/TSC.2012.11.

1939-1374/13/$31.00 � 2013 IEEE Published by the IEEE Computer Society

1.1.1 Multimedia Metadata

To sustain the interoperability of services, the serviceinterfaces have to be well defined and described. Thesedefinitions and descriptions are typically contained insideWSDL that are published in service registries. Therefore,these WSDL interface descriptions could also be applied tomultimedia web services. However, XML Schema, thelanguage used to describe data in WSDL, is not sufficientfor the description of multimedia resources. Because of that,a specialized metadata scheme [2] such as MPEG-7 andDublin Core is used so that a better description ofmultimedia data can be facilitated.

One of the issues of using multimedia metadata schemesis that the metadata created by these schemes are relativelylarger than the XML Schema of an ordinary web serviceoperation. Moreover, since the inputs and outputs ofdifferent web service operations may have their owndistinct metadata, the growth of the size of WSDL willmake it unmanageable if all metadata information is storedwithin WSDL. To solve this problem, the proposed frame-work provides a simple query mechanism so that servicerequesters can obtain multimedia metadata efficiently.

1.1.2 Streaming Data Transfer between Web Services

Endpoints

In multimedia applications, when the multimedia data islarge or contains live data, streaming is typically used as thedelivery method. However, current web services standardsdo not support streaming data transfer between two webservice endpoints. That implies multimedia web serviceshave to transfer multimedia data in its entirety, whichreduces the efficiency of the application and sometimescannot be achieved because the total size of the data is notknown at the start.

Various studies [3], [4], [5], [6], [7], [8] have investigatedthe development of multimedia applications in the contextof SOA. These studies consider different ways to separate amultimedia application into a control path and a data path.Messages for controlling the flow of the application aretransmitted using standard web services implementation.The multimedia data is transmitted in another channel suchas raw TCP connection, which is not part of the webservices architecture. One of the advantages of theseapproaches is that they can take advantage of some readily

available technologies for multimedia transfer, and at thesame time, a service-oriented development can be em-ployed. However, the major shortcomings of these ap-proaches are that, because of the need to maintain externalentities, the interoperability, maintainability, and scalabilityof the application are compromised. Moreover, some WS-*specifications such as WS-Security are not applicable to themultimedia data, which hinders the extensibility of theunderlying multimedia system.

To have a streaming data transfer compatible with theWS-* extensions, the data has to be carried inside theXML infosets of the SOAP messages. However, streamingdata by definition is a collection of time-dependent smalldata packets. To transfer these small packets, the webservices communication needs to have the capability totransmit multiple objects. Ruth et al. [9] suggested that aproxy service can be used to incorporate a single-request/multiple-response message exchange pattern (MEP) inweb services. However, this approach is not designed fortime-critical message transmission. When multiple mes-sages are required, a separate request has to be made foreach message, which is time-consuming.

In this paper, the proposed framework removes thedependency on any external entity by streaming multi-media data encapsulated in SOAP messages. A combinationof MIME structure and message transmission optimizationmechanism (MTOM) attachment scheme is used to transmitthe streaming data in a single connection. This transmissionarrangement is created in a new HTTP SOAP binding.Because the streaming data is transmitted within the webservices architecture, the multimedia web services in theproposed framework can be published, composed, andconsumed just like any other web services. In addition, WSextensions can be applied to the transmitted data becausethe data is encapsulated in the XML infoset.

1.1.3 Inefficiency of XML-Based Data Communication

Web services, because of their reliance on XML-basedprotocols, have suffered from performance issues for time-critical applications. Heinzl et al. [10] studied the perfor-mance of SOA-based multimedia applications by transmit-ting multimedia data using various SOAP schemes. Theycompared the performances of multimedia data transmis-sion using Flex-SwA [11], SwA, and normal SOAPmessages with base64 encoding. Flex-SwA, which isessentially an attachment scheme that works by puttingthe attachments in external locations, excels against SwAand normal SOAP messages. However, this comparison didnot take into account the various ways to apply compres-sion to the SOAP transmission.

The videoconferencing system discussed by Oh et al. [12]used SOAP messages to encapsulate and transmit asequence of pictures, which is transmitted as frames of avideo stream. To improve the efficiency of the system, theauthors used fast web services [13], a binary encodingscheme for SOAP messages based on ASN.1, whentransferring the SOAP messages. However, in their study,they do not have a detailed comparison of performancesbased on the use of the ASN.1 representation.

The transfer overhead of the streaming data transferincludes both the transmitted SOAP message content and

LAM AND ROSSITER: A WEB SERVICE FRAMEWORK SUPPORTING MULTIMEDIA STREAMING 401

Fig. 1. An example scenario of two users using three multimediaweb services. The dark arrows show the data flow to the handhelddevice, whereas the light gray arrows show the data flow to thedesktop computer.

the overhead in the packaging method. If an appropriatecompression scheme is applied to one or both of these, theefficiency of the data transfer will be improved. In thispaper, a comprehensive investigation has been carried outon the application of compression schemes to the streamingdata transfer in the proposed framework. A wide variety ofcompression schemes have been tested. They includegeneric text compressors, XML compressors, SOAP com-pressors, and binary XML representations. The compres-sion methods are applied to a single package, whichincludes the packaging overhead, the SOAP message, andthe binary data, of a packet. Given the results, the bestcompression scheme is then applied to a multimedia webservice in the proposed framework. The performance of theproposed framework, both with and without using acompression scheme, is compared against a simple HTTPstreaming method.

The rest of this paper is organized as follows: Section 2discusses related work on multimedia applications usingthe SOA model. The design of the proposed multimediaweb service framework is presented in Section 3. Section 4discusses the use of multimedia metadata for the descrip-tion of multimedia web services. Section 5 describes thetransmission mechanism for streaming multimedia datawithin the web service architecture. An investigation intothe use of compression techniques for the proposed frame-work is presented in Section 6. Section 7 gives details of themodels used in the experiments. Results are presented inSection 8. Finally, conclusions are given in Section 9.

2 RELATED WORK

Yu and Lin [3] investigated the use of a quality-of-service(QoS) broker to make decisions in service selection andservice composition in multimedia web services. In thiswork, multimedia data is transmitted through a separatesocket connection established between the client and theserver. The authors of this work believe that it is best to usea separate socket connection as the size overhead isenormous under the current web service standards.

Zhang et al. [4], [5] proposed a SOAP-orientedcomponent-based framework for multimedia web service.In this work, a multimedia web service is separated into acontrol flow and a data flow. The control flow istransmitted via ordinary web services, whereas the dataflow is managed by the existing multimedia infrastructure.The study proposed a SOAP enhancement so that multi-media data can be alternatively transmitted using SOAP.The enhancement includes the use of “boxcarring” andbatching of messages. However, since the transfer of eachpart of a big chunk of multimedia data requires a separateweb service request, the transfer may be too costly andinefficient when streaming multimedia is transmittedusing one separate request per packet.

Decneut et al. [6] discussed the use of multimedia webservices on heterogeneous multimedia environments. Thework is targeted at the distribution of multimedia data fora variety of client configurations and network conditions.The transmission of multimedia content is achieved usingthe now obsolete DIME attachment scheme over HTTP,TCP, or UDP channels. A multimedia web service is only

allowed to send multimedia content within one singlepackage. That means streaming data is not supported, or ithas to be transmitted as if the packets are a big chunk ofmultimedia content.

Two studies [7], [8] looked into the determination ofservice workflow and system performance in multimediaapplications providing personalized adaptation of multi-media content. In these studies, the multimedia webservices are responsible for the control, notification, andmonitoring of multimedia streams, whereas the multimediacontent is exchanged in a separate TCP connection.

3 DESIGN OF THE MULTIMEDIA STREAMING WEB

SERVICE FRAMEWORK

A multimedia web service should be able to be published,discovered, and consumed like any other web service.However, there is a major difference between a multimediaweb service and an ordinary web service in the way that thedata is transmitted between the two endpoints of a service.A multimedia web service involves multimedia content. Ifthe size of the multimedia content is small, it can bedelivered as a binary attachment within the response. If thesize of the content is large, it will not be reasonable to transferit in its entirety within the response. For large multimediacontent, it is appropriate to have a streaming capabilitybetween the two endpoints of the multimedia web service.

In this paper, the design of our proposed multimedia webservice framework has two main parts. First, in the publish-ing and discovery of a multimedia web service, a descriptionof the input and output of multimedia content has to besupplied by the service provider. This is to ensure that theservice consumers understand the expected qualities andinformation of the content that they need to send to orreceive from the provider. In a multimedia web service, thisis necessary because different devices may require differentdelivering qualities. It is highly desirable that a serviceconsumer can select a multimedia web service with the mostsuitable qualities for the underlying device. Second, afterselecting the appropriate multimedia web service, themultimedia content has to be transferred between theservice provider and the service consumer. In the case ofstreaming multimedia, the two endpoints of the serviceconnection have to be capable of transmitting the streamingmultimedia data between themselves. The proposed frame-work provides a mechanism for the transmission ofstreaming multimedia between two service endpoints.

In the proposed framework, the multimedia streams aresent in their entirety. This does not mean that the servicerequester has to wait for the whole stream beforeprocessing its data. On the contrary, the service requestercan process any chunk of data while the entire streamis arriving at the destination. This paper does notconsider streaming control such as RTSP. Nevertheless,an application-specific web service can be added on top ofthe multimedia web service, which can be used to controlthe underlying streaming data transfer transparently. Themain shortcoming of this approach is that the web servicesare not loosely coupled, and this affects the scalability andreliability of the provided services.


4 CONTENT DESCRIPTION FOR MULTIMEDIA WEB

SERVICES

In a multimedia web service, it is important to providea description of the underlying multimedia content.Information such as the streaming format, compressioncodec, resolution, and frames per second are factors thathave to be considered when a service consumer attempts toselect the best possible multimedia service among a set ofpublished services. In addition, during service composition,the multimedia information is required in the determina-tion of the service workflow. For example, an additionalservice such as a transcoding service may be required whenthe ideal multimedia web service in terms of the desiredformat and qualities is not available.

Multimedia content can be described by MPEG-7 [14].MPEG-7 metadata contain a wide range of languages forthe description of different aspects of multimedia data.Since MPEG-7 is an XML-based language, it can be easilyinserted in the web service stack. In our proposed frame-work, a simple method is provided to query the descriptionof the multimedia web service using an extended WSDL ofthe service.

4.1 Metadata Query Services

MPEG-7 metadata can be used to describe the input andoutput multimedia content of a multimedia web service. Astraightforward approach is to insert the metadata insidethe description of a WSDL operation. However, MPEG-7metadata are relatively large compared to the size of aWSDL file. The size of a WSDL file will increasesignificantly if MPEG-7 metadata are inserted. In addition,the multimedia content description may be revised fromtime to time. If an item of metadata is changed, thecorresponding web service has to review and publish itsWSDL to all related service registries.

Instead of including the entire MPEG-7 metadata, anaccompanying metadata query service is provided for eachoperation of a multimedia web service. The sole purpose ofthe metadata query service is to provide a channel for thedistribution of the metadata associated with the multimediaweb service. For example, Fig. 2 shows a description of anoperation “GetMedia” together with the specification of itsmetadata query service “GetMediaDesc.” When a serviceconsumer sees the query service, it can ask for theinformation of the multimedia content and hence choosean appropriate service based on the received information.Furthermore, the metadata query service gives decisionmakers such as service registries and service brokers theability to devise appropriate algorithms so that multimediaweb services can be selected based on the information of themultimedia content.

5 STREAMING DATA TRANSFER

In the proposed framework, streaming data transfer isaccomplished by refining the approach described in [15]and [16]. This involves extending two current web servicestandards: the MEP and the SOAP binding of a MEP [17].The way that web service messages are exchanged betweentwo service endpoints is controlled by an MEP. To support

streaming data transfer, two new types of MEP are createdto handle streaming data. These new MEPs can then beused via a communication protocol such as UDP or TCP.In particular, this paper considers the application of thenew MEPs to HTTP, the most commonly used protocol forweb services.

5.1 Message Exchange Patterns

There are currently two MEPs defined in the SOAPspecification, the request-response MEP and the responseMEP. Both of these MEPs use a single request and a singleresponse structure. In this study, two new MEPs are createdfor two types of multimedia streaming web services. Asingle request-multiple response (SRMR) MEP caters fora web service delivering streaming data in response to asingle request. A multiple request-multiple response(MRMR) MEP is created for a web service receiving astream of data as input and delivering another stream ofdata as output.

5.1.1 SRMR MEP

Fig. 3 presents the state transition diagram of a SRMR MEP.The difference in the new MEP compared to the request-response MEP is the way that data are transferred aftercommunication is established. After the request is trans-mitted from the requesting SOAP node to the respondingSOAP node, both nodes are locked in looping states inwhich the streaming data transfer takes place. Each chunkof data is transmitted and received separately andcontinuously between the two nodes. This process lastsuntil the end of the streaming data transfer.

5.1.2 MRMR MEP

In Fig. 3, the requesting node sends a single request to theresponding node and then receives a continuous stream ofdata. In the MRMR MEP, although a single request is madeby the requesting node, the request body consists of therequest information plus a stream of data, which can be a


Fig. 2. An example WSDL description of the operation “GetMedia”showing an associated metadata query service called “GetMediaDesc.”

multimedia data stream instead of a single chunk ofinformation. To create a state diagram for this MEP, therequest is split into the request information and itsassociated data stream. Fig. 4 shows the replacement forreceiving data and sending data states shown in Fig. 3 forthe MRMR MEP. The processing states handle thecontinuous transmission of the streaming data to and fromthe SOAP nodes. Within these states, the sending andreceiving processes occur in parallel. They can runasynchronously or one after another depending on thenature of the provided web service.

5.2 SOAP HTTP Binding

In Section 5.1, two new MEPs are defined for multimediaweb services. The implementation of an MEP in a webservice program is described by a SOAP binding. Thecurrent SOAP binding in the web service standards is theSOAP HTTP binding, and therefore, it is the most commonlyused protocol in the implementation of web services.

In the current SOAP HTTP binding, a SOAP message isput in the HTTP entity body in each of the requests andresponses of the service. These two SOAP messages containthe request and the corresponding response of a webservice. A SOAP message in either the request or responsecan only be used to store one single item, although the itemcan be of any type such as a number or a data record.However, as shown in Figs. 3 and 4, streams of multimediadata are sent and/or received by the SOAP nodes in thenewly created MEPs. That means using a single SOAPmessage is not sufficient for handling these two MEPs. Thefollowing sections first describe the packaging method usedfor the data packets. Then, new SOAP HTTP bindings areintroduced for transferring streaming data in the SRMRMEP and the MRMR MEP.

5.2.1 SOAP Packaging for a Multimedia Stream

Multimedia streaming is a continuous transmission of datapackets. To transfer a multimedia stream from one SOAPendpoint to another, the stream has to be encapsulated insome form of SOAP packaging. Since each data packetrepresents one piece of information within the stream, a

SOAP message is used to enclose one single packet duringthe transmission. To do that, two issues have to be resolved.

First, the data packet enclosed by a SOAP messagerequires a way to identify itself. This is because a SOAPmessage can be transmitted in a variety of bindings, andtherefore, SOAP messages can arrive at a SOAP endpointasynchronously. If a SOAP message can be identified, theSOAP processor will be able to forward the SOAP messageto an appropriate handler. In this work, the mechanism ofidentification is achieved by using web services addressing(WS-Addressing) [18]. WS-Addressing allows a SOAPmessage to carry header information such as the destinationof the message and the identity of the data packet.

Second, SOAP is an XML-based protocol. That meansbinary data, for instance, multimedia packets, cannot bedirectly inserted into the body of the message. Nevertheless,binary data can be included in a SOAP message using binary-to-text encodings such as base64 encoding. The disadvantageis that a binary-to-text encoding brings a significant increasein data size and processing time. Alternatively, binary datacan be transmitted together with a SOAP message using theSOAP MTOM [19]. Fig. 5 shows a SOAP message with WS-Addressing information and its data packet included in anMTOM serialization. In this example, the identity of thepacket is “[email protected],” the related message,which can be the request message of the multimedia stream,is “[email protected].” The associated action of the webservice is “http://example.org/getmedia.”

5.2.2 SOAP HTTP Binding for the SRMR MEP

In contrast to the request-response MEP, the SRMR MEPsends the response from the responding SOAP node to therequesting SOAP node as a stream of data instead a singleitem. This stream of data is transmitted in the looping statein the responding node as shown in Fig. 3.

In the request-response MEP, its SOAP HTTP bindingtransmits the response as a SOAP message within the bodyof a HTTP response. If a multimedia stream with multipleitems is to be continuously transmitted along a HTTP


Fig. 4. The modified state transition diagram of Fig. 3 for the MRMRMEP. The two processing states shown above replace the receivingdata state and the sending data state in Fig. 3. The unshown upper andlower parts are the same as those shown in Fig. 3.

Fig. 3. The state transition diagram of the SRMR MEP.

response, the SOAP HTTP binding will need to be

modified. In this study, a MIME multipart/related package

is used to put the multimedia stream in a HTTP response

body. The result is shown in Fig. 6.Using this organization, the response can carry as many

SOAP messages as required. The requesting SOAP node is

then responsible to read each SOAP message continuously

when the SOAP messages are received from the responding

node, as shown in the looping state in the requesting SOAP

node in Fig. 3.

5.2.3 SOAP HTTP Binding for the MRMR MEP

The MRMR MEP involves two channels of data streaming.

One is from the requesting SOAP node to the SOAP

responding node and another one in the opposite direction.

The SOAP HTTP binding for the SRMR MEP described in

the previous section allows a data stream to be received by a

SOAP endpoint in a HTTP response. The same technique

can be applied to the SOAP HTTP binding for the MRMR

MEP. The remaining part of the SOAP HTTP binding for

the MRMR MEP then focuses on how to transmit streaming

data when the request is made.In the request-response MEP, the request is sent via the

HTTP request body. If the request involves multiple items,

these items can be put in the HTTP request body, again

using the MIME multiple/related package. However, HTTP

is a synchronous protocol. The HTTP process has to receivefully the HTTP request before sending the HTTP response.This poses problems for multimedia web services becausethe SOAP node may have to wait for a long time beforestarting to send out the response. For example, withreference to the transcoding service shown in the examplescenario in Fig. 1, it is not desirable for the handheld deviceto wait for the entire duration of the multimedia streambefore it can receive a transcoded version of the stream.

As mentioned in Section 5.2.1, WS-Addressing formspart of the information carried by the SOAP messages of amultimedia stream. Using this information, an asynchro-nous transfer mechanism can be employed when transmit-ting streaming data from the requesting SOAP node to theresponding SOAP node. The sequence diagram of themechanism between the two SOAP nodes is illustrated inFig. 7. The processing state in the MRMR MEP shown inFig. 4 is then handled by the sender thread and receiverthread in Fig. 7.

6 COMPRESSION OF SOAP MESSAGES

The SOAP HTTP binding described in Section 5.2 intro-duces a considerable amount of transfer overhead to themultimedia transfer. The overall structure of the streamingdata transmission mechanism described in Section 5.2.2 forthe SRMR MEP, in the case when MTOM is used, is shownin Fig. 8. A first level of MIME multipart/related structurecontains the SOAP messages of the data packets. For eachSOAP message, a second level of MIME multipart/relatedstructure is used to separate the textual SOAP message andthe binary attachment of the message. For each of the MIMEpackages, headers are required to specify information suchas the length and the type of content associated with thepackage. Additional transfer overhead, compared to theoriginal multimedia stream, is also required when eachdata packet is transmitted together with a SOAP message.

6.1 Compression Techniques for SOAP Messages

A SOAP message is an XML-based communication proto-col. With headers and namespace specifications occupyinga considerable portion of the entire message, the actualpayload is only a small part of the transmitted message. In


Fig. 5. An example MTOM serialization of a data packet of a multimediastream. WS-Addressing is used to indicate the destination and theidentity of the packet.

Fig. 6. A sequence of SOAP messages encoded using the MIMEmultipart/related content type in a HTTP response. The content of SOAPmessages is not shown.

the context of a time critical application, such as streamingmultimedia transmission, the size overhead is hugecompared to other specialized multimedia transmissionprotocols. To improve the efficiency of SOAP transmission,various compression and encoding techniques can beemployed.

One of the simplest approaches is to use a generic textcompressor such as gzip, PPM, or bzip2 to reduce the size ofa SOAP message. However, generic text compressors do notconsider the structural information of XML messages,which can be exploited for increased compression rates.XML compression techniques such as XMLPPM [20] andXMill [21] can achieve a slightly better compression rateover generic text compressors by separating and compres-sing the content and hierarchical structure. A summary ofgeneral XML compression techniques is shown in [22].

SOAP messages, on the other hand, have a highlyrepetitive structure. For instance, a lot of namespaces usedby a sequence of SOAP messages are potentially the same.Also, the structure of the header and payload is likely to bethe same across a similar type of web services. To takeadvantage of these redundancies, Werner et al. [23] haveintroduced a SOAP message compression using differentialencoding. Their idea is to transmit only the differencebetween a SOAP message and a skeleton message gener-ated using the WSDL of the web service. Instead of using askeleton message, Rosu [24] proposed A-SOAP, which is adictionary-based technique for the compression of SOAPmessages. A dictionary of commonly used tags is built upincrementally between the sender and the receiver. A SOAPmessage is then transmitted as an encoded entity based onthe current dictionary.

Another class of techniques encodes XML messagesusing a more compact binary-encoded format such as fastinfoset [25] and efficient XML interchange (EXI) [26]. They

aim at minimizing the encoding size and at the same timemaximizing the processing speed of an XML message. Adistinct advantage of the binary XML techniques is thatbinary data can be directly encoded in the SOAP messagewithout the need for any packaging method such asthe MIME package. Thus, this eliminates the need to useadditional headers for the description of the package.

6.2 Performance of Compression Techniques

In this section, the performance of a selected set ofcompression techniques are evaluated when they areapplied to the structure proposed in Section 5.2. The resultis shown in Table 1. The packet size is assumed to be thesize of the payload when the packet is transmitted in a TCPconnection using an MTU of 1,500 bytes. The overhead sizeas a percentage of the packet size is shown in the lastcolumn of the result. The evaluation is based on thecompression applied to the transmission of a single packet,which includes the SOAP message, the packet data, andvarious MIME headers. The first two rows contain the resultwhen no compression is used on a base64-encoded messageand an MTOM package. For all compression techniques,apart from the two binary XML methods listed at thebottom two rows of the table, the transmission of the packetdata is achieved using MTOM. For binary XML methods,they can directly encode base64-encoded content in theirbinary form. Therefore, they do not have an MTOM headersize in their result.

By comparing the overhead size in Table 1, it is clear thatthe binary XML methods are significantly better than theother compression techniques. While the SOAP-specific


Fig. 8. The SOAP response structure of the streaming data transmissionmechanism in the SRMR MEP. Only the first two data packets areshown here.

Fig. 7. The sequence diagram of the asynchronous process of sendingand receiving streaming data between the requesting SOAP node andthe responding SOAP node.

compression techniques perform a few percent better thanthe general XML compressors, all of them still have to carrythe MTOM headers, which occupy a major portion of thetransfer overhead. Without the need to have the MTOMheaders, the binary XML methods, EXI in particular, are theobvious choices in the proposed framework to supportcompression in the transmission.

7 EXPERIMENTAL SETUP

In Section 5, two types of multimedia streaming transfer aredescribed. The SRMR MEP has a single object input and amultimedia streaming output, whereas the MRMR MEP hasmultimedia streaming capability in both input and output.While time criticality is typically associated with viewingstreaming multimedia content, streaming multimedia inputis more tolerable to delay. This is because it is the serviceprovider waiting for the streaming data instead of theservice consumer that means the user. Therefore, in thispaper, the evaluation of the framework is focused on themultimedia streaming performance at the output of amultimedia web service.

It is generally accepted that TCP is not the mostappropriate protocol for the transfer of streaming multi-media content because of the reliability and congestioncontrol mechanisms of TCP. Nevertheless, due to thepopularity of TCP on the Internet, it has been the mostwidely used protocol for multimedia streaming. It is shownin [27] that the performance of using TCP for multimediastreaming is generally acceptable when the achievable TCPthroughput is twice the video bit rate, with a few seconds ofstartup delay. Because web services typically run via HTTP,all experiments in this work are based on HTTP, which isrun on top of TCP. In general, when running web services

on HTTP, the size overhead of the SOAP envelopes and theneed for various headers such as the HTTP headers are notfavorable for time-critical applications. Studies have re-mained critical of using web services for multimediastreaming applications [3], [28]. Because of this, a set ofexperiments has been devised and executed to highlight theperformance of our proposed framework for multimediastreaming. Results show that using our framework togetherwith binary XML, performance is comparable to multi-media streaming using HTTP.

7.1 Simulation Setup

The streaming multimedia transmission was simulatedusing ns [29]. The simulation examines the performance ofthe proposed web service transmission for streamingmultimedia content amidst a background of real-worldtraffic. The network topology used for the experiments isthe simple single bottleneck network shown in Fig. 9.

There are six nodes in the network. s1 and s2 are the datasources. d1 and d2 are the data sinks. They are connected tor1 and r2, which are the routers of the network. Betweenthese two routers is the single link that forms the bottleneckof the network. There are two traffic flows in the network.


TABLE 1Performance of Compression Techniques per Packet for the SOAP Packaging of a Multimedia Stream

aAll compression techniques use the best available compression rate.bThe SOAP message size includes the size of the packet data that is encoded using base64 encoding.cThe backend compressor for XMill is PPM.dThe difference between the SOAP message and its WSDL-generated skeleton message is specified using the Delta Update Language (DUL). TheDUL result is then compressed using XMLPPM.eThe result assumes the dictionary has already been constructed when the SOAP message is transmitted.fBoth binary XML techniques are optimized using the relevant XML schemas of the SOAP message.gThe SOAP message size includes the size of the packet data without enabling compression.

Fig. 9. The simple single bottleneck network used in the multimediastreaming simulation.

s1 generates traffic that is received by d1 and the sameapplies for s2 and d2. Between s1 and d1 is the streamingmultimedia flow. In this study, a streaming video transmis-sion is used as the multimedia flow. s1 is the source of thestreaming video, while d1 is the receiving end of the video.The traffic between s2 and d2 is the interfering traffic. Thelinks connecting the data sources and data sinks to therouters, s1 to r1, s2 to r1, d1 to r2, and d2 to r2, are set with a10-Mbps capacity and a delay of 1 ms. This is to make surethat these links would not have a significant impact on thesimulation result. The bottleneck link has a delay of 50 ms.The bandwidth of the link is varied in the experiments. Thequeue length of the link is set to allow 15 Mbps of traffic,which is more than enough for the transmission of the videoand the background traffic.

Five common video sequences, akiyo, coastguard, contain-

er, foreman, and mother_daughter, were used in the simula-

tion. Each of these videos has a length of 300 frames with a

frame rate of 29.97 frames per second. The resolution of the

videos is 352� 288. Each video is concatenated to itself

10 times so that more statistically respectable results can be

obtained. Therefore, the duration of each complete video

sequence becomes 100 seconds. After concatenation, the

videos are transcoded using H.264 and are transmitted as

RTP streams using the VLC media player [30]. These RTP

streams are converted to RTP traces using the RTP tools [31].

The videos are encoded using a constant bit rate of 300 Kbps.The interfering traffic is a real network trace obtained from

the website of the Computer for Interaction and Commu-

nications Research Group of the University of Naples

Federico II [32]. A traffic trace of TCP port 80 going out from

the university network to the rest of the Internet is selected

for analysis. The interfering traffic is switched on at the start

of the simulation and continues for the entire duration of the

simulation. The average bit rate of the traffic is about

2.2 Mbps, with a maximum bit rate of 4.1 Mbps. The bit rate

of the interfering traffic against time is shown in Fig. 10.

7.2 Transmission Methods

The video RTP trace is transmitted between s1 and d1 using

a variety of protocols and methods. Table 2 lists the methods

that have been modeled and compared in this study.

7.2.1 HTTP Streaming

HTTP streaming is the transmission of streaming data via aHTTP channel. With the correct configurations, putting amultimedia file on a webserver allows modern webbrowsers to progressively download the multimedia con-tent while playing. This is an easy way to achieve multi-media streaming because no additional software other thanthe webserver and the web browser is required. In addition,in the real world, other protocols such as UDP and TCPusing uncommon ports are typically not allowed to passthrough Internet firewalls. This makes HTTP a much saferapproach for streaming multimedia content.

In our experiment, the performance of multimediastreaming in an HTTP connection is analyzed. The RTPtrace is transmitted using the HTTP chunked transferencoding [33]. When a client makes a connection to theserver, the server sends back the RTP packets separatedusing the HTTP chunked transfer encoding. Applying thechunked transfer encoding means that the size of eachpacket is sent before the actual content of the packet so thatRTP packets can be easily considered as separate unitswithin the stream. Using this scheme, the size overhead ofthe transmission is the size of the HTTP headers plus thechunk size transmitted before each multimedia packet.

7.2.2 SOAP-Oriented Component-Based Framework

The SOAP-oriented component-based framework is pro-posed by Zhang et al. [4], [5], which has been discussed inSection 2. In the experiment, a simplified version of theframework has been examined. To transmit streamingmultimedia, a metadata message is first sent to the receiver.The metadata message contains the number of components,RTP packets in this case, and their identifiers. Since there isa huge number of RTP packets in a multimedia stream, wehave simplified the metadata so that only the number ofpackets, and the starting sequence number are transmittedto the receiver. Based on this information, the receiver thenmakes separate requests to the transmitter so that the RTPpackets can be retrieved from the transmitter. Theserequests are sequentially sent to the transmitter. Moreover,each request is sent only after the previous response hasbeen completely received. The RTP packets are transmittedin SOAP messages as base64-encoded entities.

7.2.3 Proposed Multimedia Streaming Web Service

Framework

Table 1 shows the transfer overhead of various packagingmethods and compression techniques. To improve the


Fig. 10. Bit rate of the interfering traffic and the video sequences used inthe simulation.

TABLE 2Transmission Methods Used in the Simulations

performance of the proposed multimedia streaming webservice framework, one of the methods/techniques canbe employed. Table 1 shows that when binary XML schemesare used, the transfer overhead is the smallest comparedwith other packaging and compression techniques.

In our tests, first, the streaming content transmission inthe proposed framework without any compression isevaluated as the base case. That means the streamingcontent is carried using the MTOM packaging methodwithout any compression on the SOAP message. Then, theperformance of incorporating binary XML in the frameworkis investigated. According to Table 1, the appropriate choiceis EXI, which gives the smallest overhead size to packet sizeratio. That means the packet data are put inside the encodedSOAP message in a binary form.

8 RESULTS

In the experiments, each video sequence was transmittedacross the single bottleneck network using the multimediastreaming methods described in the previous section, usingvarious bandwidth values for the bottleneck link. Eachmultimedia streaming method is tested against the samerange of bandwidth values. Given that the average bit rateof the interfering traffic is 2.2 Mbps and the video sequenceshave an average bit rate of 300 Kbps, the assessment startsat a bandwidth value of 2.8 Mbps. This is based on theobservation from Wang et al. [27] that a TCP-basedmultimedia streaming method generally has an acceptableperformance when the available throughput is twice the bitrate of the transmitted video. The maximum traffic isapproximately 4.5 Mbps across the entire duration of thetransmission, and therefore, the upper limit for thebandwidth used during the assessment was 4.5 Mbps.

The performance of the transmission methods areevaluated using two measurements. The first measurementis the RTP packet delay during the transmission. Packetdelay affects the responsiveness of the real-time behavior ofthe provided streaming web service. It is also one of themajor considerations in service selection and composition,especially when a streaming service is composed withanother streaming service. In our experiments, the RTPpacket delay is defined as the difference between the time

when the RTP packet is received at the video traffic receiverand the time when the RTP packet is transmitted at thevideo traffic sender.

The second measurement compares the resulting videoquality using the peak signal-to-noise ratio (PSNR) betweenthe resulting video sequence and the source of the videosequence. PSNR is one of the most widely used videoquality evaluation metrics. It gives a good account of thevideo quality variation when the video content andencoding method are the same [34]. PSNR values areexpressed in dB, where higher PSNR values mean bettervideo qualities. For a video sequence, the mean andstandard deviation of all PSNR values of the video framesrepresent the quality of the video. In the experimentalresults, PSNR is used to compare the changes in videoquality among the various transmission methods for each ofthe video sequences.

The playback buffer when evaluating the PSNR of eachvideo sequence is the maximum RTP packet delay of thecorresponding video transmission using the HTTP method.Any RTP packets arriving later than the size of theplayback buffer are dropped. The HTTP method is thebenchmark transmission method that is assumed to delivera video sequence in perfect quality, whereas othertransmission methods will have varying levels of droppedRTP packets depending on the distribution of the RTPpacket delay values.

8.1 RTP Packet Delay

In this section, the performance of the four transmissionmethods are compared using the RTP packet delay. Fig. 11shows the cumulative distribution function (CDF) of the RTPpacket delay values for each transmission method when theavailable bandwidth is 2.8 Mbps. The results are generatedusing akiyo, one of the video sequences in the experiment.

In Fig. 11, at a bandwidth of 2.8 Mbps, it can be seen thatthe RTP packet delay of SCWS is worst among the fourmethods. Table 3 shows the maximum RTP packet delay ofthe SCWS method is close to 20 seconds. That means if theweb service has to display the received multimedia stream,the playback buffer would have to be almost 19 secondslong to show the resulting video in acceptable quality. Thisresult implies that a bandwidth of 2.8 Mbps is not enoughfor the SCWS method, because the transmission cannotrecover properly from packet losses.

The best performer is understandably the HTTPmethod as it has the least transfer overhead. Theperformances of the two MSWS methods are between


Fig. 11. CDF of RTP packet delay of each transmission method for thevideo sequence akiyo using a 2.8-Mbps bandwidth.

TABLE 3Maximum RTP Packet Delay (in Seconds)of Each Transmission Method for the Video

Sequence Akiyo Using a 2.8-Mbps Bandwidth

the SCWS method and HTTP method. However, theperformance of the proposed multimedia streaming webservice framework using the MTOM packaging method ismuch closer to the performance of the SCWS method.Similar to the SCWS method, the enormous size overheadmakes the transmission requiring more than a bandwidthof 2.8 Mbps to have a reasonable result. Nevertheless,when the MTOM packaging method is replaced withbinary XML, the performance follows the HTTP methodclosely. It is shown in Table 3 that the maximum delayvalue of the HTTP method is 6.82 seconds, whereas theMSWS-EXI method is 7.03 seconds, which is 3 percentmore than the HTTP method. The results show that whenthe available bandwidth is tight, the performance of theHTTP method and the MSWS-EXI method excel againstthe other two methods.

To study the performances of the transmission methodswhen the available bandwidth increases, we simulated themaximum average RTP packet delay of all video sequencesfor the transmission methods against the bandwidthvalues, which is summarized in Table 4. It can be seenthat apart from when the bandwidth value is relativelysmall, the maximum RTP packet delay values of thefour transmission methods are fairly close to each other. At2.8 Mbps, as shown in Fig. 11, the HTTP method and theMSWS-EXI method perform much better than the twoother methods. Clearly, the MSWS method and the SCWSmethod do not have enough bandwidth to transmit theirstreaming data. The two methods get closer to a reasonableperformance level only when the bandwidth reaches3.1 Mbps. That is, at an available bandwidth that is triplethe bit rate of the video sequences. At 4.5 Mbps, with morethan enough bandwidth for the transmission, the perfor-mances of the methods are very similar. Although all ofthe methods possess a very small delay, the HTTP methodand the MSWS-EXI method are still better than the othertwo methods.

Looking at Fig. 12, the maximum delay values of theSCWS method and the MSWS method are significantlylarger than their counterparts. For increasing values ofbandwidth, the delay values of all the transmissionmethods become very similar although the HTTP methodis almost consistently the best performer among thetransmission methods. At the maximum bandwidth thathas been assessed, the HTTP method and the MSWS-EXIstill possess smaller RTP delay values compared to theSCWS method and the MSWS method.

In summary, based on the RTP packet delay results, themultimedia streaming web service framework using binary

XML is shown to possess a performance that is very close tothat of the HTTP transmission method. In the next section,the focus is on the performance of the systems with respectto the produced video quality.

8.2 PSNR of Video Sequences

In this section, the PSNR values of each video sequence arecompared for each of the investigated transmission methods.

Table 5 shows the average PSNR values and standarddeviations for each video sequence and transmissionmethod when the available bandwidth is 2.8 Mbps. Asexplained at the start of Section 8, the PSNR values areproduced using the maximum delay values of the corre-sponding HTTP method of each video sequence as the sizeof the playback buffer. Therefore, the percentage ofdropped packets of the HTTP method of each videosequence is always 0 percent because all RTP packets arrivewithin the size of the playback buffer.

By examining the percentage of dropped packets forthe remaining transmission methods, it can be seen thatMSWS-EXI performs similarly to the HTTP method. This isbecause the average percentage of dropped packets is only3.6 percent for MSWS-EXI, when all five video sequencesare considered. The other two transmission methods, SCWSand MSWS, have at least 32 percent of dropped packets andas high as 45 percent of dropped packets in the variousvideo sequences. With this high level of packet drop rate,the video quality will be affected severely. This is reflectedby the PSNR values shown in Table 5.

The PSNR values are not correlated among differentvideo sequences. Therefore, the comparison of PSNR is


Fig. 12. The maximum average RTP packet delay for eachtransmission method against different available bandwidth.

TABLE 4Maximum Average RTP Packet Delay (in Seconds) of All Video Sequences

for Each Transmission Method against Different Bandwidth Values

focused on a particular video sequence when differenttransmission methods are used. When the video sequenceakiyo is transmitted, the HTTP method gives the bestaverage PSNR at 39.8 dB. The MSWS-EXI method isextremely close to that with an average PSNR value of39.64 dB. In addition to the average PSNR, the standarddeviation shows the variation of video quality over theduration of the video sequence. With a standard deviationof 3.33 and 3.56 dB for the HTTP method and the MSWS-EXI method, the quality displayed by these two methodscan be considered as very similar. However, the SCWS andMSWS methods, with a percentage of dropped packets ofaround 36 and 32 percent, respectively, have average PSNRvalues which are at least 15 percent less than the PSNRvalue of the HTTP method. Not only do they have loweraverage PSNR values, but their standard deviations arearound 3.5 times larger than that of the HTTP method.

The average PSNR values of all video sequences areshown in Fig. 13. For all video sequences, the SCWS methodproduces the lowest average PSNR compared to the othertransmission methods. Similarly, the MSWS method pro-duces a low PSNR apart from the coastguard video sequence.The MSWS-EXI method, although not always having anaverage PSNR as high as the HTTP method, consistentlyoutperforms the SCWS method and the MSWS method.

For relatively higher values of available bandwidth, theaverage PSNR was predicted to increase for all transmissionmethods, except the HTTP method. The HTTP method hasthe same PSNR value across different bandwidth valuesbecause, in the experiment, the playback buffer is sizedaccording to its maximum RTP packet delay. For the rest ofthe transmission methods, the average PSNR increases asthe number of dropped packets decreases, which was theobserved behavior. This is shown in Fig. 14 that the average


TABLE 5Average PSNR (in dB), Standard Deviation of PSNR (in dB), and Percentage of Dropped Packetsof the Video Sequences and Their Transmission Methods Using a 2.8-Mbps Available Bandwidth

Fig. 13. The average PSNR of each video sequence using differenttransmission methods with a 2.8-Mbps available bandwidth.

Fig. 14. The average PSNR of all video sequences for eachtransmission method against different levels of available bandwidth.

PSNR values for all video sequences when differenttransmission methods are used against different availablebandwidth. It can be observed that the PSNR of the HTTPmethod is constant at around 31.5 dB. The performance ofthe MSWS-EXI method fluctuates just under 31.5 dB. This isexpected as the RTP packet delay is not significantlydifferent to the HTTP method and the MSWS-EXI method,as shown in Table 4. The SCWS method and the MSWSmethod both improve drastically when the availablebandwidth increases. The performance of the two methodscan only match their counterparts when the availablebandwidth is increased to around 3.6 Mbps.

9 CONCLUSION

This paper presented an efficient web service frameworkfor multimedia web services. A simple mechanism forpublishing and discovering multimedia web services isdescribed. A metadata query service is created to helpfacilitate the description of the underlying multimediacontent for a particular web service. The transmission ofmultimedia streams is the result of two new streaming dataMEPs and the implementations of the MEPs using HTTPSOAP bindings. The HTTP SOAP bindings use the MIMEmultipart/related structure to output the multimediapackets. Each packet is then transmitted as a package of aSOAP message and its binary data. The new MEPs andSOAP bindings incur additional transfer overhead in thetransmission of multimedia streaming data compared to asimple HTTP transmission method. To reduce the effect ofthis overhead, various SOAP compression techniques forthe packaging of SOAP messages are compared. We showthat using one of the binary XML schemes is the mostefficient among all the compression techniques that havebeen explored. Experimental results of our proposed systemshow that our web service transmission method has aperformance comparable to an HTTP multimedia streamingtransmission scheme.

At the moment, the multimedia data are transmittedusing the original quality. As a possible future extension,the multimedia web service would be more efficient if thequality of the transmission is adaptable and can becontrolled by some QoS parameters. For example, a SOAPrequest can be bundled with the required QoS parameter inthe form of composite capability/preference profiles (CC/PP) [35]. Given the description in the CC/PP, a multimediastream in an appropriate quality would be returned by theQoS-aware multimedia web service.

REFERENCES

[1] K. Nahrstedt and W.T. Balke, “A Taxonomy for MultimediaService Composition,” Proc. 12th ACM Int’l Conf. Multimedia(MULTIMEDIA ’04), pp. 88-95, 2004.

[2] J.R. Smith and P. Schirling, “Metadata Standards Roundup,” IEEEMultimedia, vol. 13, no. 2, pp. 84-88, Apr.-June 2006.

[3] T. Yu and K.J. Lin, “QCWS: An Implementation of QoS-CapableMultimedia Web Services,” Multimedia Tools and Applications,vol. 30, no. 2, pp. 165-187, Aug. 2006.

[4] J. Zhang, L. Zhang, F. Quek, and J. Chung, “A Service-OrientedMultimedia Componentization Model,” Int’l J. Web ServicesResearch, vol. 2, no. 1, pp. 54-76, Jan.-Mar. 2005.

[5] J. Zhang and J.Y. Chung, “An Open Framework SupportingMultimedia Web Services,” Multimedia Tools and Applications,vol. 30, no. 2, pp. 149-164, Aug. 2006.

[6] S. Decneut, F. Hendrickx, L. Nachtergaele, and S. Van Assche,“Targeting Heterogeneous Multimedia Environments with WebServices,” Proc. IEEE Int’l Conf. Web Services, pp. 682-689, 2004.

[7] I. Brunkhorst, S. Tonnies, and W.T. Balke, “Multimedia ContentProvisioning Using Service Oriented Architectures,” Proc. IEEEInt’l Conf. Web Services, pp. 262-269, 2008.

[8] S. Tonnies, B. Kohncke, P. Hennig, and W.T. Balke, “A ServiceOriented Architecture for Personalized Rich Media Delivery,”Proc. IEEE Int’l Conf. Services Computing, pp. 340-347, 2009.

[9] M. Ruth, F. Lin, and S. Tu, “Adapting Single-Request/Multiple-Response Messaging to Web Services,” Proc. 29th Int’l Conf.Computer Software and Applications, pp. 287-292, 2005.

[10] S. Heinzl et al., “A Scalable Service-Oriented Architecture forMultimedia Analysis, Synthesis and Consumption,” Int’l J. Weband Grid Services, vol. 5, no. 3, pp. 219-260, Sept. 2009.

[11] S. Heinzl et al., “Flex-SwA: Flexible Exchange of Binary DataBased on SOAP Messages with Attachments,” Proc. Int’l Conf. WebServices, pp. 3-10, Sept. 2006.

[12] S. Oh, H. Bulut, A. Uyar, W. Wu, and G. Fox, “OptimizedCommunication Using the SOAP Infoset for Mobile MultimediaCollaboration Applications,” Proc. Int’l Symp. Collaborative Tech-nologies and Systems, pp. 32-39, May 2005.

[13] Int’l Telecomm. Union, “X.892: Information Technology—GenericApplications of ASN.1: Fast Web Services,” http://www.itu.int/rec/T-REC-X.892/, 2005.

[14] Introduction to MPEG-7: Multimedia Content Description Interface,B.S. Manjunath, P. Salembier, and T. Sikora, eds. Wiley, 2002.

[15] G. Lam and D. Rossiter, “Streaming Multimedia Delivery in WebServices Based E-Learning Platforms,” Proc. IEEE Int’l Conf.Advanced Learning Technologies, pp. 706-710, 2007.

[16] G. Lam and D. Rossiter, “A SOAP-Based Streaming ContentDelivery Framework for Multimedia Web Services,” Proc. IEEEAsia-Pacific Conf. Services Computing, pp. 1097-1102, 2008.

[17] M. Gudgin et al., “SOAP Version 1.2 Part 1: Messaging Frame-work,” second ed., http://www.w3.org/TR/soap12-part1/, 2007.

[18] M. Gudgin, M. Hadley, and T. Rogers, “Web Services Addressing1.0—Core,” http://www.w3.org/TR/2006/REC-ws-addr-core-20060509/, 2006.

[19] M. Gudgin, N. Mendelsohn, M. Nottingham, and H. Ruellan,“SOAP Message Transmission Optimization Mechanism,”http://www.w3.org/TR/soap12-mtom/, 2005.

[20] J. Cheney, “Compressing XML with Multiplexed HierarchicalPPM Models,” Proc. Conf. Data Compression, pp. 163-172, 2001.

[21] H. Liefke and D. Suciu, “XMill: An Efficient Compressor for XMLData,” ACM Sigmod Record, vol. 29, no. 2, pp. 153-164, June 2000.

[22] S. Sakr, “XML Compression Techniques: A Survey and Compar-ison,” Computer and System Science, vol. 75, no. 5, pp. 303-322, Aug.2009.

[23] C. Werner, C. Buschmann, and S. Fischer, “Compressing SOAPMessages by Using Differential Encoding,” Proc. IEEE Int’l Conf.Web Services, pp. 540-547, 2004.

[24] M.C. Rosu, “A-SOAP: Adaptive SOAP Message Processing andCompression,” Proc. IEEE Int’l Conf. Web Services, pp. 200-207,2007.

[25] Int’l Telecomm. Union, “X.891: Information Technology—GenericApplications of ASN.1: Fast Infoset,” http://www.itu.int/rec/T-REC-X.891/, 2005.

[26] J. Schneider and T. Kamiya, “Efficient XML Interchange (EXI)Format 1.0,” http://www.w3.org/TR/exi/, 2009.

[27] B. Wang, J. Kurose, P. Shenoy, and D. Towsley, “MultimediaStreaming via TCP: An Analytic Performance Study,” ACM Trans.Multimedia Computing Comm. Applications, vol. 4, no. 2, pp. 1-22,May 2008.

[28] S. Heinzl, M. Mathes, and B.M. Freisleben, “A Web ServiceCommunication Policy for Describing Non-Standard ApplicationRequirements,” Proc. Int’l Symp. Applications and the Internet,pp. 40-47, 2008.

[29] “The Network Simulator—ns-2,” http://www.isi.edu/nsnam/ns/, 2013.

[30] VideoLAN Organization, “VLC Media Player,” http://www.videolan.org/vlc/, 2013.

[31] H. Schulzrinne, “RTP Tools (Version 1.18),” http://www.cs.columbia.edu/irt/software/rtptools/, 2010.

[32] “Network Tools and Traffic Traces,” Computer for Interaction andComm. Research Group, Univ. of Naples Federico II, http://www.grid.unina.it/Traffic/, 2013.


[33] R. Fielding et al., “Hypertext Transfer Protocol—HTTP/1.1,”http://www.w3.org/Protocols/rfc2616/rfc2616.html, 1999.

[34] Q. Hyunh-Thu and M. Ghanbari, “Scope of Validity of PSNR inImage/Video Quality Assessment,” Electronics Letters, vol. 44,no. 13, pp. 800-801, June 2008.

[35] K. Graham et al., “Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0,” http://www.w3.org/TR/CCPP-struct-vocab/, Jan. 2004.

Gibson Lam received the PhD degree from theHong Kong University of Science and Technol-ogy in 2012. He is a visiting assistant professorin the Department of Computer Science andEngineering, Hong Kong University of Scienceand Technology.

David Rossiter received the PhD degree fromthe University of York in 1995. He is an associateprofessor of engineering education in the Depart-ment of Computer Science and Engineering,Hong Kong University of Science and Technol-ogy. His research interests include multimediaprocessing, particularly for audio.


Documents

A Web Service Framework Supporting Multimedia Streaming