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.

Milking Event Brokers

This blog dwells over the idea of event brokers comparing it with a real life sceanario.Most articles that I browsed on the Web were either too technical or were implementations; so I thought that I will start about something more conceptual and introductory than being specific.

Brokers are any agents acting in between 2 or more parties,more specific is the case of brokers in between 'producers' and 'consumers'.Lets call applications that produce the events henceforth as publishers and consumer applications henceforth as subscribers.

It is a well established fact that in an event driven system,paradigm of producers and consumers decoupled are prevalent.Producers and Consumers neednt be aware of each other or dependent on one another.All they may be interested is the produce that exchanges between them.How are brokers mirrored in our day to day life,although one may find many, a simple one is that of which follows.Imagine of the daily 'milkman' who delivers milk packets at your doorstep(I know its hard to imagine a milkman in the context of a software event broker,but read along...perhaps u will find the analogy interesting). Imagine for a minute,what would happen if that milkman was not there.Obviously we would ourselves have to go to the milk dairies for it(but remember we are interested only in getting the milk and not where it comes from.) .Imagine we having to go to the milk dairies everyday to buy milk,isnt that a burden ?.Its the same as the subscribers going and asking the the publishers explicitly for event notfications.This obviously in a distributed envirnoment, results in coupling between the systems.I will tell how;tommorrow if suddenly I decide to go for a different brand of milk ,I cant go to the same milk dairy again and ask for that brand of milk packets ,can I ?.Instead if I had common place ,where in I can inform that I need to be delivered milk packets of any brand that I would want,it would be great.On similar lines ,in distributed systems too..the same problem occurs.If I place my subscription logic in the publishers and tommorrow if I want to add/change the subscription to another event,I will have to add/remove the logic again in the publisher .On the side of the publishers also, this is disadvantageous as the publishers tend to be heavy with the subscriber logic in them ,when many subscribers are interested in being notified about the events it produces(Imagine at a milk dairy thousands of people crowded to get milk packets..it is logistically impossible!!!).Thats exactly where the 'event broker' fits in.

The job of the milk dairies is to produce milk packets and not bother about who uses them.Simlarly the consumers of the milk should only bother about getting the brand and quality of milk they are interested in.That is one should be independent of another.That being the case ,the same applies for applications that are interested in being notified about events,they neednt be aware of who the producer of the events are nor need to be aware of its intricacies..all they are interested is the events(milk packets in our case).This calls for decoupling between the applications and this is where the event broker plays a very important role.Event broker is the "milkman" or rather the 'middleman' who manages the event notifications.Just let the event broker know the events you are interested in and you will be notified about the same(like, let the milkman know what brand of milk packets you want and he will have them delivered at your doorstep).The only thing that needs to be done for event communications is that publishers need to tell the event broker what event they are publishing and subscribers need to tell what events they are interested in being notified about,thats it :) ,the chunk of the event communications will be then done by the event broker.Any change you require with event subscriptions ,just tell it to the event broker(its like telling your milkman[your event broker :) ] to deliver a different brand of milk from tommorrow) ..and voila your jobs done!!!.Its that easy

Event Brokers also offer some exciting features of QOS

• When you are not at home ,the milkman may check once or twice again to see if you are there,if you are ,he will deliver your milk packets then.Its like having lifetime for events,the event broker can keep checking if the subscribers are up,within the life time of the event
• Ensure delivery of events once or twice or as many desired .(Does your mikman dump all the milk packets at your doorstep?!!!!!,he will only deliver as many as would have ordered.).Its the same with Event Broker ,it will only deliver events that you would have subscriber for.
• There may be many milkmen working for a milk dairy(similar to Load balancing,the events broker may be distributed among many servers for purposes of 'load balancing' and 'nearest to the delivery point' features)

This was briefly about some thoughts on how we could mirror event brokers in our day to day life and understand it better.

Will try to put some related code in the next blog :))

Happy blogging

Happier Me