Web Services - Starring SOAP

As we know today..Services today are hot cakes and Web services are even more hotter.Reason being ,access to web services via the HTTP.With HTTP as the transport mechanism in most web browsers, web services are becoming even more attractive.Access to Web services is through standard defined ports, on which listen most of the web servers today.Security is easily provided by the firewalls and web servers too are equally wily.Thats why web services are becoming increasingly popular .They also offer:
1. Functional services(Take for example, I have an application that allows online share transactions for the users.But before I actually allow the user to transact the shares I need to authenticate him or her.For this the Org/Corp where the user is registered usually exposes the authentication system as a web service so that the 'share transaction' Application can utilize the same for authentication.)
2. Web services define implementation agnostic means of consuming services.That is the consumer of the service is hardly aware of the implementation details(you count the golden eggs..not on the hen laying it!!!) of the service.It may be written in Java C++,.net or any other lanaguage,it may be running on any OS platform too ,for that matter!!!.So tommorrow if the implementation of the web service changes, the code of the consumer doesnt break down as the interfaces remain same .
3.Since the world W3C has come out with a set of protocols for invocation of web services via WSDL ,discovery using UDDI etc there is quite an amount of standardization on this front.So it is safe to use web services.
4.Finally Web services make distributed applications working seamlessly a reality

So much for using the web services but ,what are the ways of invoking the web services as of today?.Usually the way its implemented these days is :a SOAP message is wrapped over a HTTP call to the Web service.A proxy class resides on the client side that creates a SOAP message and invokes it over HTTP.There are enough library APIs both in open source world as well as Microsoft.net that help acheive this.On the other side-A SOAP handler resides on the Web server where the call is made .It extracts out the method name to be invoked from the SOAP message and then calls the proper method using this information.Essentially Web services are stateless much like everything on the web,they are request-response mechanisms.Hence each time a request is made a new object is created and on this object proper method to be invoked is determined by the SOAP message .The parameters for this method are also passed through SOAP messages.This way of invoking a web service today also known as RPC style of method invocation is a convinent apporach.But it has its own pitfalls.For one,
A drawback using SOAP messages in this way is that the web services invocation become tightly coupled to the method that they invoke.Consider this follwing scenario:
A SOAP message usually has a header and a body.The header contains the method name and the body the parameters .The SOAP message contains other things like whether its a request message or a response message and so on..we will only concentrate on the coupling part.Look at the SOAP message format

< soap:Envelope >
< soap:Header > < method name="method-name" > func1 < /method >
< soap:Header >
< soap:Body >
< params >
< param1 > ... < /param1 >
.
.
. < param4 > ... < /param4 >
< /params >
< /soap:Body >
< /soap:Envelope >

The above XML is usually the structure of the SOAP mesage in the RPC style of method invocation.Imagine what happens when the implementor of the web service decides that for method 'func1' he will have 3 parameters from say the existing 4 parameters.This simple change will result in the code breaking up on the client side,because remember it has a proxy class that build the SOAP message for the method invocation and that class will now have to undergo a change.This becomes unacceptable espcically when the number of clients are in a huge number and live systems are running.Instead we would want something that can cause no code break on the client side.There is another style of method invocation called as Document style based over SOAP that can also be used for Web Service invocation.Its philosophy is simple-Web services are not just method invocations but a larger service that does a sizeable chunk of data prcocessing that would have otherwise caused the client to spend a sizeable amount of resources as well as time doing the same.Thats how the Web Services should be used too in theory.So instead the SOAP message in the document sytle becomes something like

< soap:Envelope >
< soap:Header > < method name="general-method-name" > GeneralMethod
< /general-method-name >
< /soap:Header >
< soap:Body >
<params >
< param1 > ... < /param1 >
.
.
. < paramN > ... < /paramN >
< /params >
< /soap:Body >
< /soap:Envelope>


The general method based on some more inputs from the client determines the particular method to be called and the parameters now become those of a generic nature without actually coupling the method and its parameters.The server does some more processing to determine what all parameters should go the particular method by parsing through generic parameters list.The actual internal method never and neednt get exposed to the clients this way.This obviously seems a better way of invoking the Web services.