Evaluation of Big Web Services
According to Hayn and Schreier (2017) the web services are considered as a software component delivered over a network-accessible endpoint between the receiver and the sender. The consumer and provider of the services use messages in order to interchange the service invocation request by the consumer and the resultant response for the requested service. This response is provided to the consumer in the form of a self-containing documents. This self-containing documents are unaware about the technological capabilities of the consumer end and thus makes very few assumptions about it (Dudhe and Sherekar 2014). Specifically it can be said that this mechanism does not have any kind of notion of a remote object reference. This reference is required for any object broker to handle a common distributed memory space.
This different sections of this essay are organized in the following way, analysis of the big web services, its critical evaluation and the characteristics of the RESTful web services. Furthermore, the RESTful different segments of this report also consist of arguments for RESTful web services as an alternative to the big Web services.
The Big web services are mainly designed and implemented based on the Simple Object Access Protocol or the SOAP. Web services are mainly aimed to integrate different enterprise applications in order to get or process the data easily from different applications and reducing the time required for it. In case of the Big Web services depends on the technology stack WSDL, SOAP, WS-Reliable Messaging, WS Security, WS-Addressing (Navarro and da Silva 2016). This technology stack is helpful in providing interoperability for both messaging integration styles and the RPC (Remote Procedure Call).
In this architecture the integration of the applications are dependent on the shred database which uses the batched file transfer for reducing the required time to send the response for a specific requested by a service consumer. This kind of web services uses the RPC (Remote procedure call) and asynchronous messages through a dedicated message bus for the communication between the service provider and the consumer.
From the technological perspective, the SOAP is a XML language. This is used to define a message formats and message architecture, therefore it is helpful in providing a rudimentary processing protocol for the consumer service requests. The SOAP based XML document outlines a top level XML element that is often known as the “envelope” to the consumers and the service providers (Dudhe and Sherekar 2014). This contains a header and a body for request or the response message. It helps the receiver to understand the start and end point of a particular message. The header of the SOAP envelope is an extensible container or packaging mechanism for message-layer infrastructure.
Characteristics of RESTful Web Services
The information in the header part of are mainly used for routing purposes as well as improving the Quality of Service (QoS) for the consumers like the data security, transactions and reliability of the services. The message body contains the payload of the service request or response message. XML Schema in the message body is used to define the structure of the SOAP (Request and response) messages (Navarro and da Silva 2016). The use of the XML schema helps the SOAP engines at the endpoints (Sender end or receiver end) can organize the content of the message and route the message to the suitable implementation process.
As the SOAP is an older web service protocol. This protocol transfers the XML format in order to send and receive the data related to the services through the SMTP and HTTP protocols. The quality of big web services reduces drastically when the amount of data increases (Hayn and Schreier 2017). This happens as the SOAP adds up extra header and configuration parts with the main body of the service messages.
The REST is the abbreviation of the Representational State Transfer. This is web service architecture that is developed in order to overcome the constraints that are faced by the users or the web service providers in using the SOAP based big Web services. This architecture of the web services are easy to deploy and maintain thus contains lesser amount of overhead for the developers as well as for the users (Navarro and da Silva 2016). This architecture also helps in reduction of the duplication of the resources as HTTP already embodies the operations required for the web services such as PUT, DELETE, GET and others which are mainly represented in an envelope in case of SOAP architecture for the web services.
The REST architecture uses different uniqueness URI’s for the available resources in the used API’s. In addition to that, the resources are represented in different representations such as text, PDF and images (Hayn and Schreier 2017). The users can specify the format in which they want to get the result of query. As an example we can consider the following code snippet.
ACCEPT: application/json, application/xml
Depending on the requirements of services, the users uses the above HTTP request as a part of the RESTful services. For any services that requires specific customer information in the JSON format then the response format will be,
RESTful Web Services as an Alternative of Big Web Services
{
“ID”: “1”,
“Name”: “J Smith”,
“Email”: “[email protected]“,
“Country”: “Australia”
}
Again if the users need the same data in the XML format, then the web services based on the REST are sent in the xml format with the suitable tags.
The REST architecture of the web services provides each resource at least one Uniform Resource Identifier or URI. RESTful webs services always maintains a directory hierarchy of the URI’s to invoke the resources whenever they are required in a human readable format for its resources. The main objective of the unique URI’s is to help the web services to identify a specific collection of resources or a single resource depending on the user’s request (Dudhe and Sherekar 2014). The main operation for the response of the requested service is implemented by a HTTP action. The URI explicitly does not describe anything about the HTTP action to get the resource. This helps the end users to request or call the similar URI using multiple HTTP commands in order to perform different operations required for the implementation of the web services.
Figure 1: Request and Response mechanism of a RESTful architecture
At the end it can be added that, REST architecture for the web services consist of clustering, caching and load balancing techniques. This techniques or the mechanisms of REST Web service encourages and helps the service providers to serve large number of users at a given instance or moment. The use of JSON data format by the REST architecture based web services makes it lightweight compared to the SOAP based big web services and even plain text in order to send request messages for the services reduces the server load resulting into the reduction in the total cost.
According to researches completed by the University of north Florida, the response speed are compared for both of the SOAP based big web services as well as REST based web services. The results of the research depicted that when a SOAP client sends a service request to the SOAP service provider, it chooses and appends data to the specific database, based on the type of the forwarded request (Navarro and da Silva 2016). The response time to serve the request was measured from the time the request for the service is received by the provider. Similarly the service requests over the REST service were also made. The result of the experiment showed that, the REST provides the response in shorter time period after the request for the service was received along with enhanced data throughput compared to the SOAP protocol based big webs services.
From the above discussion it can be concluded that SOAP based big web services are not suitable for slow data transfer rates or if the used network consist of a large data load (Hayn and Schreier 2017). This response time measurement trail was conducted by the simulation of a simple client-server scenario where the client requests for a service to the provider. The experiment included, creation of a user, user sends a request message and service request is made to query the end users requirement. After the completion of the experiment, the results of this experiment depicted that t the SOAP based web services takes 4–5 times higher processing time when compare to the compared to the RESTful web service from the perspective execution speed (Navarro and da Silva 2016). This speed increases in case of the SOAP based web services as it requires a large amount of redundant activities in order to serve the service request whereas this redundant activities are avoided in the web services based on the RESTful web service.
Xquery code Snippet
(: The following Xquery script accesses mondial database for producing the output. This database is acccessible at dbis.informatik.uni-goettingen.de/Mondial/ 🙂
for $country in /mondial/country
let $cities := (for $city in $country//city[population]
order by xs:double($city/longitude[1])descending
return $city)
order by $country/longitude
return
{
subsequence($cities, 1, 8)
}
The execution of the above code snippets accesses the mondial database in order to generate the result through the web service. Following is the part of the result that is achieved after executing the above code snippet we get the result according to the given conditions.
The above is the part of the total output when the code is executed on the console of exist-db.
On the other hand, technically the SOAP based web services are mainly bounded and are restricted to serve the service request data in the XML format, whereas the web services that are based on the REST are not restricted by any specific kind of data format. The developers develop web applications that are able to send or receive data in different formats such as Image, text, JSON and other data formats (Dudhe and Sherekar 2014). In order to have better efficiency for the web services it requires extensive bandwidth and other resources, on the contrary the RESTful web services requires lesser amount of bandwidth when compared to the SOAP based big web services.
In addition to that, the architecture of the RESTful web services are lightweight as its architecture is not restricted to the XML data format (Navarro and da Silva 2016). Moreover, the SOAP based web service are not cacheable which causes increased resources utilization on the other hand the RESTful services are cacheable and thus when a similar data or service requested by the user, it can easily send the response with the use of the lesser amount of resources which makes it economically feasible to use it for the integration of the different applications used in a enterprise or organization.
Conclusion
REST architecture was intended to use and implement a simple and easy technological infrastructure, which will be helps the organization and developers to develop web services and integration with optimal or (in some cases minimal) development tool usage. In this way the cost for the development and maintenance automatically reduces. When the same functionalities are tried to achieve using the SOAP approach or the big web service approach it requires lot more investment and overhead for the user as well as for the service provider.
References
Chung, T.Y., Mashal, I., Alsaryrah, O., Hsu, T.H., Chang, C.H. and Kuo, W.H., 2014, July. Design and implementation of light-weight smart home gateway for Social Web of Things. In Ubiquitous and Future Networks (ICUFN), 2014 Sixth International Conf on (pp. 425-430). IEEE.
Dudhe, A. and Sherekar, S.S., 2014. Performance Analysis of SOAP and RESTful Mobile Web Services in Cloud Environment. International Journal of Computer Applications.
Hayn, D. and Schreier, G., 2017, May. The Use of RESTful Web Services in Medical Informatics and Clinical Research and Its Implementation in Europe. In Health Informatics Meets EHealth: Digital Insight–Information-Driven Health & Care. Proceedings of the 11th EHealth2017 Conference (Vol. 236, p. 80). IOS Press.
Kakavand, M., Mustapha, N., Mustapha, A., Abdullah, M.T. and Ahmadi, B., 2016. Towards a Defense Mechanism Against REST-Based Web Service Attacks. Advanced Science Letters, 22(10), pp.2827-2831.
Kumari, S. and Rath, S.K., 2015, August. Performance comparison of soap and rest based web services for enterprise application integration. In Advances in Computing, Communications and Informatics (ICACCI), 2015 International Conference on (pp. 1656-1660). IEEE.
Lee, S., Jo, J., Kim, Y. and Stephen, H., 2014, June. A framework for environmental monitoring with Arduino-based sensors using Restful web service. In Services Computing (SCC), 2014 IEEE International Conference on (pp. 275-282). IEEE.
Mumbaikar, S. and Padiya, P., 2013. Web services based on soap and rest principles. International Journal of Scientific and Research Publications, 3(5), pp.1-4.
Navarro, A. and da Silva, A., 2016. A metamodel-based definition of a conversion mechanism between SOAP and RESTful web services. Computer Standards & Interfaces, 48, pp.49-70.
Paik, H.Y., Lemos, A.L., Barukh, M.C., Benatallah, B. and Natarajan, A., 2017. Web Services–REST or Restful Services. In Web Service Implementation and Composition Techniques (pp. 67-91). Springer International Publishing.
Pautasso, C., 2014. RESTful web services: principles, patterns, emerging technologies. In Web Services Foundations (pp. 31-51). Springer New York.
Purnomo, H.D., Saputro, D.A., Somya, R. and Fibriani, C., 2017. The Application Of Restful Web Service And Json For Poultry Farm Monitoring System. Journal Of Electrical Engineering And Computer Sciences, Vol 1 Number 1, 1(1).
Order an Essay Now & Get These Features For Free:
Turnitin Report
Formatting
Title Page
Citation
Outline
