Basics: How Web Services Work

Web Services are all about XML:

  1. A Web Service is described by a document in XML format, in the XML language known as WSDL (Web Services Description Language). This describes the service in terms of the operations, messages, and bindings that it contains, and may provide a URL at which the service may be called.
  2. The structure of the messages is described using XML Schema (XSD) which is either contained in, or referred to by, the WSDL
  3. The messages sent to, and received from, the web service are all in the form of XML that complies to the schema, and which follows the protocols described by the WSDL, using an XML protocol known as SOAP (for Simple Object Access Protocol)

The usual way to access a web service in .NET is as follows. Other platforms have similar mechanisms.

  1. The developers of the web service make the WSDL accessible. They can either place it on a web site, or the web service can generate the WSDL automatically.
  2. The developer of a client application will add a Service Reference if using WCF, or a Web Reference if using the older ASMX technology. This amounts to telling Visual Studio the location of the WSDL for the web service.
  3. Visual Studio requests the WSDL. It parses the file to gain an understanding of the web service. From this information, it will create some classes. These are known as proxy classes (not to be confused with an Internet proxy server). These classes stand in for the web service, allowing you the illusion that you are simply calling normal methods on normal classes. But these classes are not normal.
  4. The client code will create an instance of the proxy class for the service. It will call an instance method of the class, perhaps passing some parameters. The proxy class will turn these parameters into properly-formatted SOAP XML and will send them to the service.
  5. On the server side, the XML will likely be turned into parameters again, and a server-side method will be called with those parameters.
  6. The server will do what it was requested to do, and may then return a result. This result will be turned into SOAP XML, which will be sent back to the client.
  7. The proxy class on the client will receive this XML, turn it back into return values and will return that to the caller

The result is that the caller of a web service can treat the service operations just like normal methods on normal objects. In most cases, even the developer of the web service can treat the service like it is a normal object with normal methods. But everything in the middle is happening in SOAP XML, described by XML Schema, referenced by a WSDL in XML.

One of the consequences of this is that only things that can be described by WSDL and XML Schema will ever appear in a client proxy class. Neither WSDL nor XML Schema describe programming language concepts. For instance, note that the term "operation" is used, and not "method", "function", "subroutine", or "procedure". Neither can describe things like constructors, indexers, events, generics, or indexed properties.

Proxy classes are generated by "Add Web Reference", "Add Service Reference", WSDL.EXE or SVCUTIL.EXE. There are two kinds of class that will be generated. One class will be generated as a proxy for the service itself. This class will have methods in it that correspond to the operations of the service. Depending on how the proxy class is generated, there may also be events that will be raised  with the operations complete. The second kind corresponds to custom types used as input parameters to the service, or return values from the service, and of course all of the custom types referred to by these, recursively. These types will only contain properties. They are meant only to aid in communicatng data to and from the service – they share no behavior with the actual types used by the service itself.

One way to think about this is to realize that the Web Services platform is meant to be independant of the programming language or execution platform of the client or the service. With this in mind, it will be obvious why, for instance, a parameterized constructor will not appear on the client due to the fact that the server-side class had one. The client may not even have a concept of constructors, much less parameterized ones!

This entry was posted in Web Services. Bookmark the permalink.

3 Responses to Basics: How Web Services Work

  1. Brian says:

    How do i call java web services from .net?? I mean passing objects from .net to java and receiving the results??

  2. Ravinder Tawni says:

    Good explanation. Really helpful.

  3. Rajesh says:

    Thanks John. It helped me a lot.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s