This article comes from http://msmvps.com/blogs/manoj/archive/2005/07/10/56839.aspx
Microsoft's vision of the .NET Framework was a that of a platform for developing Web Services; the primary motivation behind this inception being ease and productivity for developers, and performance and scalability for the deployed applications. Developers have been leveraging the .NET Framework to develop Web Services in the form of ASMX. So much are the productivity benefits of ASMX, that developers are more or less absolved from the nitty-gritties of SOAP, WSDL and XML Schema.
In the recent times, a new revolution has been dawning in the form of Service Orientation, and Service Oriented Architecture (SOA) seems to be the talk of the town. SOA is about seeing the world as collaborating services, which are autonomous in nature, and communicate with each other through messages. The format of this exchange is governed by a contract and the compatibility by a policy.
Now, my very brief introduction to ASMX followed by a short note on SOA may seem logical to many. To many developers, SOA and Web Services (a.k.a. ASMX) are synonymous. However, a perusal of the core tenets of SOA would draw the line between the two quite clearly. You would then agree that ASMX is just a way of realizing SOA, nothing more. As much as ASMX lends itself towards SOA, it has one big constraining factor - it is currently appears tied to IIS. This, in a way, takes us away from the notion of ubiquitous "services" in an SOA scheme. In my opinion, SOA requires every conceivable type of application to be inherently capable of exchanging messages using standards like SOAP and HTTP. In other words, applications should be capable of hosting ASMX without having to rely on the services of IIS.
For an application to host ASMX, two things need to be in place: An HTTP listener which can cater to HTTP requests on ports 80 and 443, and the ability to host the ASP.NET's HTTP runtime infrastructure, which is used by ASMX. Now, of the two, the second requirement is already available in ASP.NET 1.1 in the form of classes in System.Web and System.Web.Hosting namespaces. Infact, ASMX was designed from the ground up to be decoupled from IIS. So, the only void at this point is that of an HTTP listener.
Come .NET 2.0 and this need is well addressed. Starting with Whidbey, and running up to the Indigo timeframe, any application would be capable of hosting ASMX, made easy by a few managed classes like HttpListerner. This ability opens the door for a multitude of possibilities and easier ways to realize SOA.
Hopefully, this news has got you exited and left you begging for more technical details. With this note, I would leave it over to this excellent (as always) article from Aaron Skonnard, one of my favorite authors:
Service Station: Run ASMX Without IIS
