Last Lap Around ASMX and Stuffs before moving to WCF:-Final Part

Posted: January 8, 2007 in Uncategorized

In PART-I and PART-II of this series we saw what are the webservices challenges and how Asmx 2.0 try to address few of those however there are quite a few things left like  RESTful Services ,WS* stacks [including WS-Security & WSE,WS-AT and WS-RM [transaction],WS-Eventing ….] ,SOA ,Interop etc.; Although each of these topics itself are too vast to cover in a single blog post, I ll try to cover all these in this post [final one of the series] randomly before moving to WCF .The reason I had started this series is because it ll provide you a solid ground on what is available today and what WCF is providing [although WCF is not about Web Svc] and what functionality you might still be looking for some future stack.

However when we discuss about Enterprise webservices[or services itself] there are many more things you might confront with to build a successful Service Implementation like :-the Service layers, Development processes, Testing process ,Deployment, Message Patterns, subscription models, Monitoring,Security,Schema or contract,Provisioning,Discovery,Policies,Auditing,Compression,Transactions,Realibility,Protocols,Collaboration,Interopability ,Metadata Exchanges and so on the list goes on..

You might think why the hell I need to consider all these? Does this much of complexities needed to be incorporated into the services? Certainly not for all scenarios but most of the times you need many of these and all these are requirement driven like security,scalability,performance,realibility and loose coupling etc.; and to provide those aspects to your services you need to fall onto to the ones I ve listed above[there are many more].

Interestingly the list I have provided above becomes more and more complex and more confusing if you start poking around the web to see more and more stuff like the REST Approach[REST guys should read the opposite way of the SOAP and WS* approach] vs SOAP and WS* ,SOA and CodeFirst vs. ContractFirst and I would ask developers to not to delve themselves into this mud at first GO and better Go for feature wise support and if at all possible let this part pass to the architecture team .Let me further tell you that the same is the story in other arena too like Web 2.0,GRID computing and ESB are a great example of this trend. However in the WebService world the major players were Microsoft, IBM, Sun, Google, and Yahoo etc and there are many players in the other arena I ve mentioned above. I ll quickly like to mention here that there are also a significant presence of many Opensource, Research Org and minor players in this Fight.

Now that we saw what all are going around the Service World I ll try to quickly grab few of the important aspects to wrap this article up so that we can have a better view why all these fuss are there and what are those all about.

So, the reason why all these came into the picture is due to the fact that how you provide different features for your enterprise services [let me better say web services] which ll have support for Security, Realiability, Scalability, Event, Transaction and so on   and major vendors [Microsoft, IBM and many others…] came together to form the WS* stack which supports the stack for allowing your Service to provide features for the above. Following the same trends could also have solved the WS interop scenario too but different vendors has different implementation and a true WS-Interop again becomes a design articraft. Further to that the twist come from REST and the heaviness of the WS* stack questioned [I ll discuss the REST vs WS* later and the new twist to this with the WEB 2.0 trend is XML vs JSON which I ll dig in some future post].Now the question was how to expose the WS* standard and functionalities in the services and again major player had provided framework and extension to make this happen and Microsoft with WSE provides support for WS-Security,WS-Policy,WS-Addressing as well as WS-RealiableMessaging and IBM and SUN were also had provided their own way of implementing the WS* stack.

Ok its look fine and I got my Services capable of handling Security, Eventing-addressing and RealibaleMessaging what else? Actually there were a lot more and more and more WS*specs came out to help addressing those like WS-Metadataexchange,WS-AtomicTransaction ,WS-BPEL and so on [see the WS link above for detail list].

Microsoft with WCF and SUN/IBM with SCA has added capabilities to build services which support more WS* stack. However let me point you out here that WCF is not all about the WS* but it does have many enhanced features and I ll cover those shortly. So far I didn’t touched or written on the Interop, SOA and other useful add-ons to Services like the compression and MessagePatterns, Collaboration …so on because it is not possible to complete the entire stuff in this post and I am keeping few spaces for the REST vs WS story .However while Posting the WCF series I ll try to cover these aspects .For now this ll be enough to mention that with the new framework all these have been enhanced, incorporated and still many works is going on for further improvements .


Another Buzz you must ve dealt with or at least heard about was SOA but SOA doesn’t necessarily Web Services but its more about the Architectural Style to built services which provide more business values, Scalability and reusability etc.; Actually the WS* stack and SOA are quite related from the point of view that SOA tells u about certain servicebehaviors and their impact and usefulness and many of the WS* were generated to provide those features.

Example:-WS-Policy, WS-Metadataexchange etc;

From MS point of view SOA is svc which incorporate different tenats like “boundary are explicit”,”Share Schema or contracts not classes”,”Services are autonomous”,” Service compatibility is based upon policy”.So the question might come can I build a SOA enabled Svc today with ASMX and the answer is of course you can and going fwd all the major FRX will provide more support to built the SOA patterns into your services.No more SOA here as this ll again lead to a long post. 

So , before leaving the WS* here I would like to mention that an Enterprise Distributed Service needed much functionalities and the ASMX alone was not the final stop but was an intermediate stop and there were many challenge required to be addressed with and which lead the major players to create  new Distributed Message Oriented Frameworks. In future post we ll see how these have been addressed in WCF and what all challenges we still needed to dealt with. I ll update the post to provide more details on these later…

 REST vs WS* for the LAST Time:-

I ll now reinvent the Wheel around the REST [vs] the WS* or POX vs SOAP approach and there already a lot of posts around this and basically it’s an architectural style you need to decide which one you should opt for? Although the REST kick started with Fielding’s Work it’s got a new dimension and popularity with yahoo, Amamzon and Google’s WebSvc API implementations which follow this Architectural approach which suggest a URI or resource driven approach with plain XML against the already available http commands [GET, HEAD, PUT and DELETE] which eliminates the need of the SOAP and the thick WS* layers .You can see the approach here is a ResourcesOrieneted Arch [all the services have a specific URI and you are issuing your command against that URI[resources] and since its minus SOAP its lightweight and with the new PNPR its look like a more compelling arch but hangs on before jumping entirely to REST approach.Although it’s a good approach and the ResourceDriven approach might be a compelling one[I m not comparing SOA ve the ROA(Resource Oriented arch) there are still few functionalities lacking in the REST approach ,the primitive one is being a suitable framework and the support for security, reliability ,Metadata exchanges and so on but the question here is do I need these? if not isn’t REST a better approach .Yes it is but there are very little guidance and information available and for incorporating the different addons you need to reinvent the wheel a lot [ I am no discouraging anyone here and if your svc does not need the complexities of various WS* stack you can go for POX and in past you can see quite a few  POX with Http implementations] and you can’t make guarantee that with all these incorporated your svc still remains the thinner .However the REST approach is now supported by WCF and I hope SCA also ve support for this[didn’t verify this though] and you can built a framework with Hybrid approach .There are still a lot discussion and work going on and with the new WEB 2.0 and B2B and P2P technologies more changes in architectural approach are likely to come.

 Here are the resources you ll find useful on this hot debate.

 To understand the WS* or WS-Specifications  from and this msdn articleIntro to WebSvc  Arch and its Specification provide a detail read and also provides the links to primitive websvc specs

 REST vs SOAP / POX vs SOAP /REST vs WS*,7211,35361,00.html

REST and Web Services: The ZapThink Take ZapFlash

Paul Prescod: on REST – Second Generation of Web Services

Don Box: SOAP vs. REST

Dion Hinchliffe: Creating Open Services That Last (And Anyone Can Use)

Danny Ayers – Is REST too complicated?

REST APIs, examples, documentation and bits



Tagtooga’s List of REST APIs

 Rest ful Svc :

John Udell – Amazon’s pragmatic approach to metered infrastructure

The Loyal WS Opposition:-

Service Orientation, the Hype Cycle, and a RESTaurant : Mike Champion:

MS Ignoring developer demand for REST tools?


Understanding the Place of POX, SOAP and WS-* in Building XML Web Services  :


RYAN [the way he has presented is really a good one to watch out for "How I Explained REST to My Wife“and The Highs and Lows of REST for more on REST.

Tim O’Reilly – A Week in the Valley: GData

Optimistic concurrency (versioning)

sqlREST and 15 minutes Guide to sqlREST

Don Box: HTTP, XML, REST and $100

Popular REST tagged articles in



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s