.NET Buzz Forum - The Web services emipre strikes back

What is good?
With the advent of the .NET Framework Microsoft did a very big marketing campaign that tried to intimately marry the .NET Framework with the concept of Web services. A lot has changed since those days, that's for sure. The only thing that holds still true is that the .NET Framework is a very powerful platform that program and leverage XML-based Web services. A developer targeting Web services and loosely coupled communication and integration aspects has several choices of how to approach his goal. With the so called ASMX engine, which sits inside the ASP.NET runtime functionality, you can develop Web services in a very object-oriented fashion if you like. That means that you can just concentrate on your favorite programming language and can leave all the hard to the ASMX system. Hard work means problem spaces like how to serialize your objects to XML and pack into an appropriate SOAP Envelope to send over the wire as well as solving the reverse problem of receiving a SOAP message and mapping it properly to an object's method. Hard work also means that there needs to be a solution to somehow decouple the in- and outbound XML messages from the actual object-oriented implementation inside the service. ASMX and the XmlSerializer provide a quite powerful environment based on .NET attributes to achieve some best practices for service-oriented integration development with today's Web services standards and engines. These are just two prominent examples of ASMX's great work to ease the life of the Web services-addicted developer. A powerful engine combined with a productive tool like Visual Studio .NET can influence whole generations of developers. This is actually what happened.
In my opinion ASMX v1 has caused a revolution, literally. But as you might guess, revolutions are not always good or at least do not always have only good impacts.

What is bad?
Web services are not about objects. SOAP is not just another XML format for enabling XML-based remote procedure calls. No. The scope of this article is of course not to discuss the differences between and advantages or disadvantages, respectively, of objects and services. But a developer and architect does limit himself if he thinks about Web services as just objects communicating through standardized XML documents. Or even worse: the XML that gets exchanged is nothing more than a flattened and serialized method invocation stack. This is still current thinking, as I have experienced in a lot of projects all around. But why is that? Why are a lot of people thinking that way?
Well, part of this answer is: tools. As good as development tools like Visual Studio .NET are, as bad they can be when the wrong focus is communicated to their users. As already mentioned above, ASMX and Visual Studio .NET did influence a whole generation of software developers. It did a great job in that people did not have to think about a lot of manual steps they had to perform in older environments. But the easiness of creating and consuming Web services inside Visual Studio .NET did not help to make Web services' role clear, in my opinion. This approach often lends to not thinking enough about the situation, about the why and how of Web services. Or isn't it just unfortunate to have a context menu entry called "Add Web reference" right beside the "Add reference" item?

What is lacking?
Anyway, no offense and obviously no moaning here. ASMX is great and without it we would not have a penetration of Web services and Web services-related technologies and architectures as we have it today.
But it is still just the first incarnation of ASMX. Albeit the current version of the .NET Framework is 1.1, ASMX is still in v1.0, so to say. There we no obvious changes from 1.0 to 1.1. This leaves some open points a lot of customers are longing for. I do not have the space to list any of the wishes I have come across in the last years, but surely want to name the most important ones. Although the .NET Framework team decided to eventually ship service packs for the framework, we did not yet see any update for ASMX. Now that the latest version of SOAP counts 1.2, .NET programmers seem to be forgotten and fear to lose a lot of interoperability with other platforms. A number of Web services implementation e.g. in the Java world already can cope with SOAP 1.2, but ASMX is still based on the solid and mature but no longer single valid SOAP 1.1 specification.
Another point of complaint has ever been the very limited features in the realm of XML serialization. The somehow passive model provided by ASMX and XmlSerializer based on decorating your .NET code with attributes did not solve all problems. Customers really want their hands on the serialization process and they want to be able to control literally every bit and character. If this improved serialization model and behavior would come with improved serialization speed then the Web services developer would feel like Alice. Paired with some advancements in the underlying network protocol implementations could move ASMX a bit closer to other connected applications infrastructure in terms of pure communication performance. This is actually just a snippet of numerous items I have gathered in the last few years while using ASMX v1 in projects.
So let's see which of the mentioned topics can be solved with ASMX v2 and how. Beginning with the next installment to appear soon ...


	Web Artima.com