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 .”
“A Web Service is seen as an application accessible to other applications over the web . “
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” . 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.
If you need assistance with writing your essay, our professional essay writing service is here to help!Essay Writing Service
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” .
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” .
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
Leveraging the architecture of the World Wide Web
1.2 Web Service Properties
Web Services can be described by using two sets of properities, functional and non-functional properities . 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 . 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 .
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 . 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 . According to W3C, performance is defined in terms of throughput, response time, latency, execution time and transaction time . Both execution time and latency are sub-concepts of the W3Cs definition of response time .
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 . 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 .
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 .
To measure the development effort of web service, we adopt the number of lines of code (LOC) assessment method .
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 . 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 . 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 .
The major performance bottlenecks in Web services [10, 22] are
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.” 
Gottschalk, S. Graham, H. Kreger, J. Snell defines “SOAP is the standardized mechanism for communicating document-centric messages and remote procedure calls using XML.” 
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.” 
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
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  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.
Cite This Work
To export a reference to this article please select a referencing stye below:
Related ServicesView all
DMCA / Removal Request
If you are the original writer of this essay and no longer wish to have your work published on UKEssays.com then please: