In my previous post regarding Web Services I mentioned why besides their name Web Services have nothing to do with the Web. In this post we will discuss them in detail as why it makes me and everybody else who researches Web Services to come to this conclusion. While Web Services as a technology is been great for ordinary users there are several disadvantages which becomes obvious when the researchers look at it.
Current Web Services Technology
Current Web service technology is based on tightly coupled message exchange. The sender and receiver has to be online during the whole communication period. It will fail if one of them is offline. This situation is similar to the situation faced by scientist community in the pre-Web age, where one had to send an e-mail message to a scientific colleague, asking for a specific paper or piece of information. With the introduction of web it became simpler. In the current Web as an infrastructure for humans, this pattern of communication has widely been replaced by persistent publication and asynchronous retrieval. We no longer request the biggest share of information in lengthy, synchronous communication cycles with the originators, but fetch it from persistent sources, e.g. the scientist’s personal Web page. We don't have to be online all the time to ensure that whoever wants our page can get it. We can just publish the article on a web page and let others download it from there. We argue that this has significantly contributed to the success and scalability of the Web, since it freed the sender from the need to handle individual requests, and it made resources identifiable and thus referable.
Imagine what will happen if Web was not there today. In such a situation one will have to handle individual requests from all your scholarly colleagues who visit your Web site. You might soon become the main bottleneck for the dissemination of your own ideas. The shift from information dissemination based on message exchange not only made the Web scale tremendously, it has also sped up the dissemination process.
On the contrary when we compare Web services with this important principle of the Web it becomes very obvious that Web services are not following the core idea of the Web. It is true that Web services use the Internet infrastructure as the transport medium. However, that is more or less all they have in common with the Web. The idea of publishing data and accessing it asynchronously is lacking. Web services failed to work in asynchronous mode. Instead of publishing the information based on a global and persistent URI, Web services establish (1) stateful conversations based on the (2) hidden content of messages.
The negative effect of such distributed applications that communicate via message exchange is that they require a strong coupling in terms of reference and time. This means that traditional Web services require that the sender and receiver of data:
The two major criticisms around Web services today are about the improper usage of URIs and the violation of the stateless architecture of the Web. It is one of the basic design principles of the Web and REST architecture to not provide stateful protocols and resources.
In real-world(where we live in) this means that when sending and/or receiving SOAP messages, the content of the information is hidden in the body and not addressed as an explicit Web resource with its own URI. Therefore, most Web functionality dealing with caching or security checks is disabled, since using it would require parsing and understanding all possible XML schemas that can be used to write a SOAP message. Thus, when a stateful conversation is required, this should be explicitly modelled by different URIs. Moreover, referring to the content transmitted via an explicit URI in an HTTP-request would allow the content of a message to be treated like any other Web resource.
Summary:
In this post we discussed how Web-Services failed to realize the Web part of its name. What is missing ie stateless architecture and using URIs to refer to the resources. In next post we will discuss what is Semantic Web Services and how they are better than the Traditional (syntactic) Web Services.
Until Next Time....:)
Current Web Services Technology
Current Web service technology is based on tightly coupled message exchange. The sender and receiver has to be online during the whole communication period. It will fail if one of them is offline. This situation is similar to the situation faced by scientist community in the pre-Web age, where one had to send an e-mail message to a scientific colleague, asking for a specific paper or piece of information. With the introduction of web it became simpler. In the current Web as an infrastructure for humans, this pattern of communication has widely been replaced by persistent publication and asynchronous retrieval. We no longer request the biggest share of information in lengthy, synchronous communication cycles with the originators, but fetch it from persistent sources, e.g. the scientist’s personal Web page. We don't have to be online all the time to ensure that whoever wants our page can get it. We can just publish the article on a web page and let others download it from there. We argue that this has significantly contributed to the success and scalability of the Web, since it freed the sender from the need to handle individual requests, and it made resources identifiable and thus referable.
Imagine what will happen if Web was not there today. In such a situation one will have to handle individual requests from all your scholarly colleagues who visit your Web site. You might soon become the main bottleneck for the dissemination of your own ideas. The shift from information dissemination based on message exchange not only made the Web scale tremendously, it has also sped up the dissemination process.
On the contrary when we compare Web services with this important principle of the Web it becomes very obvious that Web services are not following the core idea of the Web. It is true that Web services use the Internet infrastructure as the transport medium. However, that is more or less all they have in common with the Web. The idea of publishing data and accessing it asynchronously is lacking. Web services failed to work in asynchronous mode. Instead of publishing the information based on a global and persistent URI, Web services establish (1) stateful conversations based on the (2) hidden content of messages.
The negative effect of such distributed applications that communicate via message exchange is that they require a strong coupling in terms of reference and time. This means that traditional Web services require that the sender and receiver of data:
- maintain a connection at the very same time, that they
- agree on the data format, and
- know each other and share a common representation.
The two major criticisms around Web services today are about the improper usage of URIs and the violation of the stateless architecture of the Web. It is one of the basic design principles of the Web and REST architecture to not provide stateful protocols and resources.
In real-world(where we live in) this means that when sending and/or receiving SOAP messages, the content of the information is hidden in the body and not addressed as an explicit Web resource with its own URI. Therefore, most Web functionality dealing with caching or security checks is disabled, since using it would require parsing and understanding all possible XML schemas that can be used to write a SOAP message. Thus, when a stateful conversation is required, this should be explicitly modelled by different URIs. Moreover, referring to the content transmitted via an explicit URI in an HTTP-request would allow the content of a message to be treated like any other Web resource.
Summary:
In this post we discussed how Web-Services failed to realize the Web part of its name. What is missing ie stateless architecture and using URIs to refer to the resources. In next post we will discuss what is Semantic Web Services and how they are better than the Traditional (syntactic) Web Services.
Until Next Time....:)
0 comments:
Post a Comment