Literature Review Web Service Definition Information Technology Essay
A Web Service is any service that is available over the Internet, uses a standardized XML messaging system and is nottied to any one operating system or programming language [1].”
“A Web Service is seen as an application accessible to other applications over the web [2]. “
However, despite the commonness of the two de¬nition, they are still too rough for practical usage. In a broader sense of the word, anything that has an URL can be considered as a Web Services.
A more precise definition is provided by the UDDI consortium, which characterizes Web services as “self-contained, modular business applications that have open, Internet-oriented, standards-based interfaces” [3]. This definition is more detailed, placing the emphasis on the need for being compliant with Internet standards. In addition, it requires the service to be open, which essentially means that it has a published interface that can be invoked across the Internet. Inspite of this clarification, the definition is still not precise enough. It is not clear what it is meant by a modular, self-contained business application.
A more detailed definition is provided by the World Wide Web consortium (W3C), the group involved in the Web Service Activity. Web service is ” A software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artificats. A Web service supports direct interactions with other software agents using XML-based messages exchanged via Internet-based protocols” [4].
The W3C definition is quite accurate and also hints at how Web Service should work. The definition stresses that Web services should be capable of being “defined, described and discovered,” thereby clarifying the meaning of “accessible” and making more concrete the notion of “Internet-oriented, standards-based interfaces.” It also states that Web services are similiar to the services in conventional middleware. Web services are components that can be integrated into more complex distributed applications. The W3C also states that XML is part of the solution.
More specific defintions exist in Literature. In the online technical dictionary Webopedia, a Web service is defined as “a standardized way of integrating Web based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available, and UDDI is used for listing what services are available” [5].
Specific standards that could be used for performing binding and for interacting with a web service are mentioned in the above definition. These are the leading standards today in Web services. Many applications that are “made accessible to other applications” do so through SOAP, WSDL, UDDI and other Web standards. However, these standards do not constitute the essence of Web services technology.
From the above de¬nitions, we can now derive a clearer perspective of the term Web Services, and this de¬nition can be given as follows:
“A Web Service is a communicating mechanism with standardized interface of XML messaging, integrates loosely coupled and distributed applications via the Internet independent from platforms, programming languages and operations systems.”
XML messaging uses XML as the data standard format. XML is an easy extensible powerful markup language that enables users to create their own vocabularies. This makes increment of interoperability of application services. XML is very popular and widely used today.The use of Web Services enables application-to-application communication.
Based on the above definitions, we can conclude that a Web Service has the following characteristics
Machine-to-machine interactions
Loose coupling
Interoperability
Platform-independence
Operating system-independence
Language-independence
Leveraging the architecture of the World Wide Web
self-describing
discoverable
.
1.2 Web Service Properties
Web Services can be described by using two sets of properities, functional and non-functional properities [6]. Functional properties describe the functional behaviour i.e. What the software does and non functional properties capture the non functionality i.e. the average execution time of a given web service [7]. In the context of web services, the Quality of Service refers to the non-functional properties [9, 13]. To differentiate different web services which offer same functionality, non-functional properties are very critical in selecting the best web service [9, 7, and 14]. Considering loosely coupled distributed systems, waiting for the output of a web service for a long time is useless as not having the system at all [19].
Quality of Service Requirements:-
QoS is defined in various ways and measured by different metrics. After examining the existing research in the area of Web services, the W3C group provides detailed information about defining QoS and its metrics. They clarify that QoS refers to the quality aspects of a web service such as performance, reliability, and scalability. W3C classifies the metrics into four classes, “performance”, “dependability”, “security”, and “application-specific metrics”. The application-specific metrics are specific to a certain domain.
Considering W3C as a primary source, the major Quality of Service requirements are identified. The metrics mentioned below are common ones, which can be applied to most domains.
Availability: The availability aspect of QoS represents the probability that this service is ready for immediate consumption. Smaller values indicate the service may not be a good choice for consumption by an application as it has a high probability of not being available. Low availability of a Web service limits the usefulness of consuming this service.
Availability can be affected by a variety of issues, including the architecture of the program underlying the Web service, the deployment platform, or the service’s overall maintenance.
Accessibility: The accessibility aspect of QoS represents the probability that this service is able to handle a Web service request. A Web service may be available but not accessible by a client application. This can happen if the service is not architected to be scalable in the face of rapidly changing request volumes.
Performance: The performance aspect of QoS represents both the latency and the throughput of a Web service. Latency describes how quickly (roundtrip time in milliseconds) the service responds once invoked by the consuming application. Throughput describes the number of Web service requests that are serviced within an amount of time.
The performance of a Web service is based on the time necessary to access the service as well as the time necessary to execute the service’s business logic. Smaller latency values represent a higher performance service with a speedier response.
Compliance: The compliance aspect of QoS represents how well the service complies with stated features of the service. Since Web services encompass a variety of technologies and standards, compliance measures how fully the implementation of the service complies with those stated technologies. Compliance does not measure whether the service supports the latest standards or versions, but instead how fully it complies with those standards and those versions of standards that it states it supports. The compliance of a Web service is determined by the details of its implementation.
Security: The security aspect of QoS represents the usefulness and strength of the mechanisms the service provides for supporting security and confidentiality throughout an interaction. Security is important for Web services as both the service provider and the service consumer may not be located behind the corporate firewall or communicate over a private network; a significant number of Web service interactions will happen over the public Internet.
Reliability: The reliability aspect of QoS represents a summary measure of the service’s overall ability to maintain its quality. This metric is usually measured in terms of failures per unit time (e.g., day, week, month, or year), and represents the overall reliability of the Web service.
Network-related QoS: This represents the QoS mechanisms operating at the transport network which are independent of the Web service. Network-related QoS parameters are network delays, delay variation and message loss.
Many different definitions of QoS of Web services exist in the literature; performance is one of the important QoS attributes identified by all researchers [12-15]. Performance is a relatively straight forward measurement compared to other QoS attributes [15]. Performance can be measured on server-side and client side. While the server-side performance measurements provide a good indication of the capacity and processing time, client-side performance measurements can provide a more reliable measure of the effective performance experienced at the client end [12]. According to W3C, performance is defined in terms of throughput, response time, latency, execution time and transaction time [16]. Both execution time and latency are sub-concepts of the W3Cs definition of response time [10].
For this research, performance is considered in terms of response time. Response time is the time needed to process a query, from sending the request until receiving the response [10]. Response Time can be further divided into task processing time, network processing time, i.e., time consumed while traversing the protocol stacks of source, destination, and intermediate systems, as well as network transport time itself [16].
The Response time of a single web service is defined as [16, 17]
tresponse(ws)= ttask(ws)+ tstack(ws)+ ttransport(ws)
ttask(ws) is the amount of time for a web service to perform its designated task. tstack(ws) represents the total cost of processing the messages including coding/encoding, security checking and data type marshalling. ttransport(ws) is the total time to transfer a specific amount of messages over network. Furthermore, time for connection setup, for negotiation of the connections parameters as well as the amount of time used for authentication is considered as the parts of a web service response time [16].
To measure the development effort of web service, we adopt the number of lines of code (LOC) assessment method [18].
Web service comparison methods
The literature does not provide a standardized method of comparing between SOAP and REST Web services.
Some comparison, like the one conducted by Michael zur Muehlen1a, Jeffrey V. Nickersona, Keith D. Swensonb focus on comparing the different Web services using coupling as a metric. They used twelve facets in order to evaluate each web service. This multi-faced metric is useful to system designers for making better design decisions and comparing alternative Web service technology options.
Other previous comparisons of web services, like the one conducted by CesarePautasso, OlafZimmermann, FrankLeymann focus on comparing the conceptual and technological differences between RESTful Web services and WSDL/SOAP based “Big” Web services.
This quantitative technical comparison based on architectural principles and decisions helps technical decision makers. They suggest the use of a decision analysis sheet where Web services to be compared would be aligned horiziontally in the colums and Architectural design options would be aligned vertically in the rows.This comparison is useful in accessing the development efforts and technical risks of Web services.
Many research studies states that QoS is an important characteristic in differentiating the web services. The measurement of QoS attributes on Provider’s side is inadequate to estimate the performance of a Web serivce. Therefore, a comparison between Web services should consider both functional and Quality of Services characteristics.
GavinMulligan, DenisGracanin used network-related performance metrics as an important baseline for the comparison. They considered end-to-end response time as primary for comparison.
Alexander Davis, Du Zhang comparative study is very useful for this research. They used performance metric, which is an important Quality of Service attribute for their comparison. They used Lines of Code as cost of effort metric to evaluate the web service development. For performance evaluation, they used a database application with basic CRUD operations. They tried the CRUD operations with single and multiple database records. They also evaluated the SOAP performance during the data conversion from ADO to XML on the server side.
Previous Comparisons of SOAP and REST Web services
According to [Snell,2004] the main difference REST and SOAP is first one uses the resource-oriented approach, the latter uses activity oriented approach. At fundamental REST exposes entities as resource which can be modified by using the standard methods where WS* specification specifies the possible activities on the entities which client can’t understand. In SOA, the service implementations are responsible for the activities on entities. The author [Snell,2004], specified that both integration styles are coexist each other, choosing one over the other depends on the application requirements.
[Richardson/Ruby,2007] compared the two integration styles by considering the functionalities, protocols and its alternatives. Clients send the request which is encapsulated in HTTP POST request to the service end which provides the services. Clients can get the information about the executed operation and its scope in the response. Due to limited use of the HTTP, SOA don’t provide the complete benefits to the service consumers where REST uses the complete functionalities of HTTP as a part of the application.
[Vinoski 2008], compares the approaches of specific interface definitions with the REST uniform interface. All APIs exposed through the WS-* stack have their own unique vocabulary, complicating the semantic knowledge for intermediaries and clients. Moreover, the specificity of a contract, as is the case in WS-* stack, can inhibit its reuse. In ROA, the methods and response codes of HTTP compose the service interface, which uniformizes the access and increases the system transparency, reducing complexity and promoting reuse.
[Cesare Pautasso, Olaf Zimmermann and Frank Leymann] Compares Rest Web services and Soap web services using two quantitative metrics: Architectural principles and Decisions. Their comparison into Architectural Principles, Conceptual decisions, technological decisions and Supporting tools.They concluded the two approaches have similar characteristics at the principal level. At conceptual level, REST has fewer alternatives with more architectural decisions when compared with SOAP which leads to substantial design and development efforts for the developers like design of resources specification and their URI addressing schema. WS* specification provides freedom-of-choice for the developers with more alternatives within strict conceptual boundaries. Moreover, the alternatives are easy to implement because of available tool support today and standard concepts. REST and SOAP are similar when considering same subset of
technological decisions without complex features of WS*.
[Gavin Mulligan, Denis Graˇcanin] Compared the two Integration Styles by developing Interaction Independence Middleware Framework Portal with REST, SOAP web services as an approach for data transmission between client and server. Their evaluation is based on quality of service attributes such as Scalability and Efficiency.
They drawn the conclusions as REST-based implementation has lower latency and average packet than SOAP integration style service. REST adds only HTML headers to the payload without any overhead to the messages being transmitted over the network. On other hand, SOAP adds payload in an envelope with some headers to http packet which contributes to network bottleneck.
REST sends an HTTP DELETE command to URL with the ID not including an XML payload where SOAP includes xml payload according to WS* specifications. They compared the two services by using different size of data. Without including HTTP packet size xml payload dominates the packet sizes, drawn conclusion that latency increase for SOAP implementation caused by underlying SOAP library. REST proves better with slight increase in latency proportion to the packet size for large application profile where as for SOAP implementation Latency rose exponentially in proportional to the packet transaction size.
[Alexander Davis, Du Zhang] compares SOAP and DCOM in terms of features, development effort and application performance. To measure the development effort they adopt the number of lines code required to implement the same functionality in the DCOM-based and the SOAP-based applications. They used load test to evaluate the performance of each web service, one of important QoS attribute of a Web service. They developed two-web based data driven application in their study. They used two types of soap version in the study SOAP with XML/Path and SOAP with XML/ADO. By using two versions of SOAP Web services, they identified the SOAP performance degradation during the conversion of ADO record set to xml string on the server and client side. The performance testing is carried out by performing basic database operations such as Inserting database records, retrieving a single record, retrieving multiple records and deleting one or more records from the database. Each record is approximately 40-60 bytes long.
XML and Web Service:
Web services supplies the XML-based service description, service registry and service invocation mechanisms, and solves the interoperability problems between heterogeneous platforms. Web services are platform-independent, high interoperable compared to other distributed computing components models such as EJB, COBRA and DCOM [20]. However, web services suffers performance penalty which prevents it from widely using in high performance computing. The performance of distributed system is strongly determined by their wire format [21]. Web services use XML as the message format which realizes high interoperability between heterogeneous platforms. More number of software layers needed to fully process XML messages payloads, and also from encryption and decryption. Processing XML-encoded messages can require a very large amount of bandwidth with respect to traditional binary message protocols. Lastly XML Marshalling and parsing dramatically decrease the system performance [22].
The major performance bottlenecks in Web services [10, 22] are
Transport Protocol
XML
SOAP
SOAP
SOAP Definition
Cesare Pautasso, Olaf Zimmermann and Frank Leymann defines “SOAP is an XML language de¬ning a message architecture and message formats, hence providing a rudimentary processing protocol.” [1]
Gottschalk, S. Graham, H. Kreger, J. Snell defines “SOAP is the standardized mechanism for communicating document-centric messages and remote procedure calls using XML.” [2]
Both definitions provide a simple overview about soap without any detailed explanation. Microsoft provides detailed definition about soap and its properties.
Microsoft defines “SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. SOAP uses XML technologies to define an extensible messaging framework, which provides a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics.” [3]
Based on Microsoft SOAP definition, by using xml technology SOAP provides a messaging framework to construct the messages which are inter-exchange between the systems. The message framework is
1) Extensible
2) Independent of transport protocols
3) Independent of programming model
Due to lack of distributed features like security, reliability and routing, soap messaging framework provides a layered extension to add such features. Soap message can be transport over different protocols such as HTTP, TCP, and SMTP etc. SOAP specification provides a messaging framework for binding the messages to different protocols with HTTP binding explicitly because of it wider usage.
SOAP is not particularly tied to any programming model some of developers thinking that SOAP web services are like a RPC model because of the features in distributed computing.
SOAP Message Framework
SOAP Message framework [3] is a set of xml elements for holding the xml data during the transmission between server and client. Message framework consists of mainly four xml elements such as envelope, header, body and fault. <Envelope> is the root element of the soap message which specifies as a soap message and it’s version to the applications during the network transmission.
<Envelope> contains optional <header> element which contains information to network intermediates whether they need to process the message or not. <Body> element contains the payload which is the ultimate message exchanged between sender and receiver. <Fault> element is the child element in <body> element represents the error when anything goes wrong during the message transmission. The following message shows sample soap message format
Soap:Envelope xmlns:soap=”http://schemas.xmlsoap.org/soap/envelope”>
<Soap: Header> <! — Optional –>
<! — Header blocks go here… –>
</soap: Header>
<Soap: Body>
<! — Payload or Fault element goes here… –>
</soap: Body>
</soap:Enveloe>
SOAP and Performance issues
Several studies have evaluated the performance of SOAP and XML [13, 29 and 30]]. These studies all agreed that SOAP and XML incur a substantial performance penalty compared to binary protocols.
[D. Davis and M. Parashar] conducted an experimental evaluation of the latency performance of various SOAP implementations, comparing with other protocols such as Java RMI and CORBA/IIOP. They found that XML processing accounts for about 75% of the processing time when network delays are discounted. They also found the source of inefficiency in SOAP is the use of multiple system calls to send one logical message. A conclusion drawn from these results was that SOAP is orders of magnitude slower, although for some of the slowest SOAP systems this can be partly explained by poor implementation.
[M. Govindaraju, A. Slominski] Evaluated the performance of SOAP for high performance scientific computing. Their experiments compared Java RMI with SOAP by sending large arrays of doubles (i.e. floating point values with 18 decimal digits of precision). The results showed that SOAP is much slower than Java RMI, typically by about a factor of ten. They concluded that SOAP’s XML messages were inherently unsuitable for use in transferring bulk data, but due to the format’s flexibility and accessibility, may be useful as part of a multi-protocol system with SOAP as a `lingua franca’.
[F. E. Bustamante, G. Eisenhauer] Presented the results of experiments that compared the encoding, decoding and network performance of various message formats, including XML. They found that the marshalling and communications costs of XML are staggeringly high in comparison to more traditional approaches, with XML some 2 to 4 orders of magnitude slower in encoding and decoding than CORBA/IIOP and similar binary wire formats. They concluded that XML wire formats are inappropriate for high performance systems, as the baseline performance of all systems is strongly determined by their wire format.
SOAP performance is degraded because of the following [5, 8, and 13]:
Extracting the SOAP envelope from the SOAP packet is a time consuming process
Parsing the XML information in the SOAP Envelope using a XML parser is also time expensive
There is no much optimization possible with XML data.
For XML, an expansion factor of 6-8 times over the original binary data is not unusual [29]. [8] Measured expansion at 4 to 10 times, and [30] found that SOAP’s data representation size is typically about 10 times the size of the equivalent binary representation. This substantially greater size may result in higher network transmission costs and increased latency.
One way to achieve a compact and efficient representation is to compress XML − especially when the CPU overhead required for compression is less than the network latency [5]. A few of the promising XML compression techniques available are gZip, XMill, XGrind, Xpress, and XComp. Nair [7] reports that XMill is the best performer for messages over 20KB, XComp is a better choice for messages that are smaller than 4KB, and gZip is best for messages between 4KB to 20KB in length. The studies reported in this paper used gZip to evaluate the effectiveness of compression because it was widely available, provided better compression rates for the message sizes being tested [7] and required no prior knowledge of the document structure. Although these techniques all produce good compression ratios, results of studies into their effectiveness as mechanisms for improving SOAP performance are not readily available.
SOAP uses XML to marshal data that is transported to a software application. SOAP defines more than one encoding method to convert data from a software object into XML format and back again. The SOAP-encoded data is packaged into the body of a message and sent to a host. The host then decodes the XML-formatted data back into a software object.
There are two types of message styles in SOAP [31, 32]
Document
RPC
There are also two different techniques for serialising the data in the SOAP body [31, 32]:
Literal
Encoding
This gives us four encoding styles: Document/literal, Document/Encoding, RPC/Literal and RPC/Encoding.
The document/literal relies on XML schema to describe what the message looks like. Due to its simplicity and straightforwardness, document/literal becomes de fact standard for developers and toolkits [31]. For RPC/Encoded implementations, the performance of SOAP implementations gets worst proportionally with size and complexity of messages [9]. For large messages, deserialization overhead is larger than serialization [9]. The cost for encoding and decoding the xml does not depend on the data in the message. The complexity purely depends on structural complexity and syntactic elements of xml [12].
The SOAP messages must be parsed and interpreted before they can be invoked, which is done by the XML-parser. XML parsers are too expensive in terms of code size, processing time, and memory foot print because these parsers have to support a number of features like type checking and conversion, wellformedness checking, or ambiguity resolution. All these make XML parsers require more computing resources. Without any network delays 75% of time is spent in xml processing [13]. Xml parsing is the most expensive in xml processing [15]. Currently two types of xml parsers are mostly using today DOM and SAX [12]. DOM and VTD are best suitable for back-and-forth database access. DOM is suitable for complex and frequently data access. VTD consumes less memory and faster than DOM which suitable for simple and rare changes. SAX is not suitable for back-and-forth data access or changes but useful in low memory restrictive conditions. Finally DOM is best suitable for database access. [16].
Encoding the XML document in a binary format reduces the message size. The overall message is smaller than usual text based xml document. Recipients can easily parse and serialize it more quickly [10]. XML is standardized and interoperable because it use text based xml. Moving to binary XML without standardization, it would cost more for interoperability [35].
SOAP poor performance explanation xml is not sufficient [12]. Multiple system calls to send the message contributes to the soap performance degradation along with the xml encoding [13].By implementing the caching technology to avoid the multiple system calls to send the message. The time spent in File I/O has a minimal effect on the SOAP performance for sending large payload messages [14].
The usage of xml compression and parser does not work on the idea of reusing the payload. Better usage of indexing on caching increases the efficiency because of the minimal effort required to lookup on the cache for the required payload [14].
Each of these studies pinpoints the area where SOAP gets slower. Some of them also present optimized versions of SOAP which were conceived as a result of different mechanisms like XML Compression, binary xml etc and achieved a better efficiency.
Introduction to REST -based Web Services
REST stands for Representational State Transfer, and was originally coined by Roy T. Fielding in his doctoral dissertation from University of California, Irvine. REST is an attempt to formalize the architecture of the World Wide Web, and to formally describe those architectural elements, which are most responsible for the success of the web. As Fielding writes in his dissertation:
The Representational State Transfer (REST) style is an abstraction of the architectural elements within a distributed hypermedia system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements. It encompasses the fundamental constraints upon components, connectors, and data that define the basis of the Web architecture, and thus the essence of its behavior as a network-based application.
REST defines a set of architectural constraints that when applies to architecture of a distributed system, induce desirable properties like loose coupling, horizontal scalability, generality of interfaces etc. The constraints are
Client-server
Stateless interactions
Cache
Uniform interface
Layered system and
On-demand code
One of the main constraints that make an architecture Restful is the use of a uniform interface. This is the key principal that differentiates REST from other network based architectures. By using a uniform interface, “the overall system architecture is simplified and the visibility of interactions is improved”.
REST defines a set of constraints to attain uniform constraint
Identification of resources
Manipulation of resources through representations
Self-descriptive messages and
Hypermedia as the engine of application state
Order Now