A Retrospective Look At Web Services

A Retrospective Look At Web Services

After a considerable break from reading about the web services technology, I once again visited the subject
with a view to look at it retrospectively.
1.1 SOAP Web Services
SOAP Web Services is the original style of web services. It started with a specification about the web
service: the WSDL file. This file had the same function as an IDL file had in the days of COM. And not
surprisingly, because the SOAP web services have evolved from component technologies like COM and
CORBA. So, the WSDL file defines the contract between the client of the web service and the web service
itself.

In order to make the web service independent of the programming languages and their types, and also of
the network transport, the WSDL became a detailed specification based on XML Schema that defined the
data types, the operations and their parameters and the bindings.

The advantage of the detailed specification of the contract was that it allowed the client and even the web
service to be written independently. That is, given the WSDL, a developer could write the web service to
adhere to the WSDL spec and another developer could write the client to such a web service.
1.2 A C++ Example
Eventually what happened was that Soap Toolkits became available that could read a WSDL specification
and generate the client side and server side code. For example, I had once a need to invoke a SOAP web
service from a C++ program and there wasn't any standard IDE option to do this automagically. Therefore,
I looked for and found a SOAP toolkit library called gsoap that would generate C++ code when it was
supplied with a WSDL file.

For the client side, the gsoap library generates a set of files that contain the methods on the web service.
These methods act like proxies to the client program. Internally, the generated code converts the parameters
to the method calls to the appropriate request xml and make the call over the network to the web service.
Consequently, from my source code, I could make the call to the web method in the generated code and the
actual call to the web service would be made under the covers, so to speak.

For the web service side too, the gsoap library would generate a set of files that contain the methods of the
web service. This code needs to be invoked by a transport handler like IIS or Apache web server. Once the
call is passed on to the generated code, it converts the request xml into parameters and invokes a method in
your code.
1.3 Microsoft .NET and Java
With MS .NET, it became trivial to write SOAP web services since the IDE took care of practically
everything. All you needed to do was to select a Web Service project and annotate the web method with
[WebMethod] and the IDE did everything else.

What was happening behind the scenes is that the IDE generated the WSDL for the web service and it
generated the code to translate the request xml into parameters (much like in the C++ case) and at run time,
it would make the appropriate call to the web method. And the response xml would be generated similarly.

On the Java side, there were frameworks like Axis from Apache that did much the same thing for java
programs that MS .NET did for C# programs.
1.4 XML Requests and Responses
With the SOAP specification, there was a great amount of detail involved in generating the xml for the
request and response for a web service method. There were four possible variations:
RPC / encoded
RPC / literal
Document / encoded (never used)
Document / literal

What these variations mean is that the xml generated for the request and response is different. The choice
of which xml variation is used is what the WSDL specifies. In general, it doesn't matter much which
variation is used. From the programmer's point of view, it doesn't matter at all because the SOAP toolkit
deals with the details. From the point of view of performance or other such consideration also, the
difference isn't great. After all, it is a few more or less characters to be transmitted.

A toolkit like SoapUI will generate the correct request xml structure for any given WSDL taking care of the
xml variation specified.
2. REST Web Services
On looking at all the infrastructure required to create SOAP web services, it became clear that a lot of it
was quite unnecessary. What SOAP web services were providing is the ability for the programmer to write
web services and their clients in terms of native data types. The infrastructure took care of converting the
data from raw xml on the wire to native data types.

However, there was no good reason for this. Programmers had good libraries at hand to read the data in the
xml themselves. So, what emerged is the practice of clients building the request xml in the code and
parsing the response xml using DOM or SAX parsers. And likewise on the web service side.

In order to bring some kind of uniformity to this practice, a few standard mechanisms were proposed for
the requests in terms of the common database operations:
C - create: http POST request
R - read and list: http GET request
U - update: http PUT request
D - delete: http DELETE request

This standardized use of the different HTTP verbs for different operations is referred to as the REST
protocol for web services.

Basically, what was changed was two things: (1) the practice of xml being created and interpreted in the
code of the web method itself instead of relying on an infrastructure to convert xml to native data types, (2)
the call to the web method being made from the client directly using a library that allows making a TCP/IP
call instead of letting the infrastructure do it behind the scenes.
3. Conclusion
What a lot of web service implementations do today is to use the practice of REST web services without
the use of the REST convention. For example, they may use only the POST method for all the operations
supported by the web service. We refer to such web services as REST-style web services.

The shift from SOAP to REST style web services has simplified the development process by removing all
the "under the hood" kind of processing and making xml exchange explicit between the client and the web
service.