Some introduction on Webservices

Web Services are what I'm delving in since more than an year. WS idea is all about how a client on one platform can leverage the functionality of a piece of code written on a differnt platform. Say a java client talking with a .NET server. Earlier there are technologies like CORBA, Java RMI etc, which were very tightly coupled between client and server. They often relied on seperate port connections to communicate between client and server. But enterprises were skeptical about adopting such tightly coupled technologies fearing by enabling extra ports, malicious programs can cause harm etc. So the idea of web services sprout out in this context. There wont be need to enable any extra ports, there won't be transfer of data in any other format than plain text XML.

There are majorly two types of Webservice technologies SOAP based Webservices and REST Webservices. The later I've no idea. Former one is the popular one. Let me elaborate on SOAP based Webservices.
Here the whole idea is whatever client wants to ask, it will ask passing a piece of plain text XML. Whatever the server wants to respond, it will respond by sending another piece of plain text XML.

Request workflow:
Client -> BlackBox1 -> ====XML Request==== -> BlackBox2 -> Server side webservice

Fig:1

Response workflow:
Client <- BlackBox1 <- ====XML Response==== <- BlackBox2 <- Server side webservice Fig: 2 Now there above two black boxes are mentioned, if you observe. These are the web service engines like our open source Axis or gSOAP, or proprietary .NET etc. These actually create the XML request for a call made by client in its program that looks like String answer = localStub.addNumbers(5, 10); But then you would get the natural question of what should the XML request look like and how is it that the server is going to understand whatever piece of XML client sends. There pitches in the WSDL - Web Service Description Language. If you take the black box on the server side, henceforth BB2, it has the ability to look into the webservice (its nothing but a java program for me, or a C# program from somebody else) and come up with a description document (WSDL) saying if anybody wants to request the addNumber method of this webservice their XML request should be sent to me in the following format <>
<>
<>
<>value1 < /param1 >
<>value2 < /param2 >
< /addnumber >
< /BODY >
< /soapenv >
Fig: 3
and I'd respond the answer in the following format
<>
<>
<>
< type="integer">answer< /addnumberreturn >
< /response >
< /body >
< /soapenv >
Fig: 4

Note: The above xmls are just meant to be directive to help understanding and are not actual

BB2 receives the client sent XML requests, parses and processes them and finally calls the webservice method code. It takes the answer returned by the webservice and again wraps it as per the template shown in Fig: 4 and sends it to client.

The client side black box, hence forth BB1, has the ability to read the WSDL and understand that I need to send the request as per Fig:1 template and parse the answer wrapped and sent as in Fig: 4 template.

If you see the XMLs above they are slightly strange in the sense have extra and tags which might seem redundant as per the knowledge given so far, but they are actually place holders for some information as to type of charset-encoding used to send the content etc. This special format XML is generally called SOAP. Essentially on the wire a SOAP request and a SOAP response are transferred.

The WSDL also has in it embedded information in which it can say I'm expecting the XML to be sent to me over http protocol (in which case BB2 will be listening at port 80) or ftp protocol or SMTP mail protocol etc.

This is the way Webservices, XML, SOAP are related.