|
In many regards the name "Web services" is confusing. There is no need to think about Web services versus what you describe as the "conventional Web" in terms of devices and browsers. Actually, I know of very few browser-based applications that access Web services directly (with the possible exception of thick clients written in Java Applets, complex Javascript, or Flex). There's also no reason to think that the "conventional Web" cannot work for smart phones and other devices.
The main difference between Web services and the conventional Web lies in the programming model. The conventional Web is built around hypertext transfer (HTTP) and resources (URIs) - in other words, a so-called conventional Web application is simply a set of resources that a client talks to using the HTTP protocol. On the other hand, Web services applications provide interfaces described by WSDL (Web Services Description Language) and they communicate using SOAP (Simple Object Access Protocol). Web services are transport-independent: For example, beside HTTP, there are many Web services that use the JMS transport protocol. In addition, the architecture of Web services protocols is composable. This means that it is possible to extend SOAP messages with a lot of additional information like security, reliability, routing, quality of service (QoS), transactional content, expiration time, and so on. All these aspects of SOAP are carefully developed under the auspices of various standards bodies such as W3C and OASIS.
The most important advantages of this approach are greater flexiblity and interoperability. In the future, the semantic Web and Web services will happily coexist and will enrich each other. This makes Web services an ideal choice for machine-to-machine communication.
|
