Introducing Web Services

I talked about WCF in brief in one of my earlier postings, but that brought forward a need for a posting on the basics of web services. So, today I am going to talk about web services at a simpler level using a scenario about foreign exchange rates. I am not talking about forex process and it’s just for example’s sake…so don’t post back saying forex rates are not decided that way! ;-)

The central bank in the country decides the forex rate for every particular day. So let’s say, today the US Dollar to Indian Rupee is 46.01 and Euro to Indian Rupee is 56.99. These rates change every day. There are numerous other websites where these rates are displayed and they need to be updated on a daily basis. It is natural that the owners of these websites will request the Central Bank to provide them some automatic mechanism so that the websites can automatically get themselves updated by the changed rates every day.  If I were the system admin at the Central Bank, what would be my options? Give them a read-only access to a file or a table? Or send them this info every day? Or put the rates on some server, some xml file for them to read?

No convincing solution? What about giving them access to some code that is on my server, but the code will return the rates to them by accessing my database? I have to make sure that they access the code in the most secure way possible. Why not give them an HTTP URL that will access our code and return them some data? Even better, why not put some restriction in code so that the incoming data and outgoing data follow the standards posed by the restrictions? And of course, the best way to receive and send data will be XML!

SOAP stands for Service Oriented Access Protocol.  As it is a protocol, it is a standard in which messages are sent across in XML format. Each SOAP message contains a SOAP envelope that has a SOAP header (optional) and SOAP body. I won’t deviate from topic explaining more about SOAP here, but if you want to get a glance of what SOAP is, you can visit this simple tutorial on W3Schools or SOAP on W3C if you are serious about it. It suffices now to understand that SOAP uses XML as a mode of communication; it is an obvious choice for our scenario. What we now need is some sort of application or code running on our server that can interact using SOAP as the protocol. That is what web services are for. So, web services are applications (chunks of code) that reside on the server (the host) and can be invoked by a client by sending a request.

Web services can be written in any language which is obvious because XML is the mode of communication. The client need not know which language the service is written in as long as the request is accepted in XML and the response is sent in XML. You can create an ASP.NET web service in Visual Studio.

Note that I have not used the file system to create the web service; instead used HTTP since I will be using an HTTP based URL to access the service. The picture below should give you enough insight on the web service created. Note the method GetConversionRate that accepts two strings as currencies and returns the rate as double.

Btw, if the images are not clear, you can always click on them and it will open in its original size.

If you run the solution, you should see the page as below. The page just explains that you have accessed the ForexService web service that has only one operation exposed i.e. GetConversionRate.

Click on the method name GetConversionRate and the screen that follows is worth diving into detail. It gives us a test screen where I can type in the required values and invoke the service. Good enough. Let’s look what is below the test module. You notice the SOAP message formats for both 1.1 and 1.2 versions.

When the client sends a request for service to server, the following message is being sent. The data types in blue and bold will be replaced by the appropriate values. You notice that it has got a soap body in a soap envelope, as I mentioned above. The rest should be pretty understandable.

POST /Forex/ForexService.asmx HTTP/1.1
Host: localhost
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<soap12:envelope xmlns:soap12="http://www.w3.org/2003/05/soap-envelope" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soap12:body>
  <getconversionrate xmlns="http://tempuri.org/">
   <currencytoconvertfrom>string</currencytoconvertfrom>
   <currencytoconvertto>string</currencytoconvertto>
  </getconversionrate>
 </soap12:body>
</soap12:envelope>

Similarly, when the server has received the request and processed it, the result is sent in the following message format. This again has an envelope and a body.

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: length
<?xml version="1.0" encoding="utf-8"?>
<soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope">
 <soap12:Body>
  <getconversionrateresponse xmlns="http://tempuri.org/">
   <getconversionrateresult>double</GetConversionRateResult>
  </GetConversionRateResponse>
 </soap12:Body>
</soap12:Envelope>

So you see, the message formats used when a client sends a service request to a web service and the server responds to the request is based on the SOAP protocol. Since the communication does not have any language specific restrictions, the client and the server (host) in a Service Oriented Architecture can be in different languages. Wonderful! Cross-language, cross-platform freedom!

Now is the time to see how a client can consume this web service. Check this post.