Chapter 10. Web Services


Web Services are an amazing technologyon the server side. So what does this have to do with client-side JavaScript? Well, there is a way to call server-side scripts from the client side. Actually, there are two ways: one for Mozilla-based browsers, one for Internet Explorer. These two options are covered in this chapter; the next chapter then provides you with some interesting alternatives to the methods presented in this chapter.

Understanding Web Services

Some people say Web Services are just old wine in new bottles because the idea behind this is far from new. The basic principle is that two machines talk to each other. For instance, one machine contains some business logic or, more generally, some information, and the other machine requests this information (or wants to use the business logic).

This has been done for many years, but only a few years ago the major players sat together and started to work on protocols to put the whole communication on top of standards. Some of these standards are now under the aegis of the World Wide Web Consortium (W3C), whereas others are managed by the Organization for the Advancement of Structured Information Standards (OASIS) consortium.

A multitude of books are available on Web Services, with quite a lot of pages. However, in accordance with the concept of this phrasebook, this chapter keeps it simple but still gives you all you need to know. A protocol is used to transfer both the request to the Web Service and its response. There are several possibilities, but these three are the most common:

  • XML-RPC stands for XML Remote Procedure Call. XML-RPC uses a simple XML dialect to transport function calls, parameters, and return values.

  • REST stands for REpresentational State Transfer. REST basically uses HTTP requests (GET most of the time, but other HTTP verbs are also possible) as a Web Services call. The data returned via REST is plain XML.

  • SOAP once stood for Simple Object Access Protocol, but because it is neither simple nor has too much to do with object access, today SOAP just stands for SOAP. It is a rather complex protocol but it overcomes many of the limitations of XML-RPC (which was, by the way, created by some parties who also worked on SOAP).

There are some fierce debates about which is better, this protocol or the next one. To make a short and ugly story short: All have advantages (and disadvantages).

Most of the time, REST or XML-RPC or SOAP calls are transported via HTTP as the carrier protocol. However, other protocols are also possible, including Simple Mail Transfer Protocol (SMTP) or even User Datagram Protocol (UDP).

There is one more important aspect regarding using SOAP. When you know exactly how a Web Service is implemented, you also know how to call (access, or consume) it. However, many times this information is not available, so there must be a kind of self-description of the Web Service that contains all relevant information, such as which methods or functions are exposed, which parameters and data types they expect, and what they return. This can be done using a specifically crafted XML file as well. The standard behind that is Web Services Description Language (WSDL). Today, WSDL is used for all relevant Web Services because it makes using Web Services quite simple. Most server-side technologies offer one (or more) means to just read in the WSDL and then access the Web Service like you would access a locally available class.

Using all this XML can become quite complicated. The next chapter covers XML as one of the aspects of the AJAX technology and gives you additional pointers. However, Mozilla browsers and Microsoft Internet Explorer feature their own way to access Web Services. This removes at least a bit of the complexity, but unfortunately it is not browser-agnostic.





JavaScript Phrasebook(c) Essential Code and Commands
JavaScript Phrasebook
ISBN: 0672328801
EAN: 2147483647
Year: 2006
Pages: 178

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net