The most natural way to create Web services in ASP.NET (this technology is often referred to as ASMX) is to write a facade class or interface using pure OO approach and decorate the class and the public methods with proper attributes (WebServiceAttribute and WebMethodAttribute, respectively). For simple Web services, we may even use ADO.NET DataSet objects (or strongly typed data sets) passed as arguments or as a return value. While this is probably fine for small Web services acting mainly as a very thin gateway to the database, it may not be appropriate for large enterprise Web services that interact with rich business logic layer.

There is also a mismatch between the underlying technology (SOAP and WSDL) that is very much message oriented and the most popular usage style which basically utilizes Web services as yet another RPC (Remote Procedure Call) technology. This kind of approach to designing distributed systems may lead to tight coupling not only between the service and its clients but also between the service and the business logic layer (it probably has something to do with the curious temptation of some developers and architects to transfer serialized business entities across the wire).

The approach one should take when designing new enterprise-class Web service is to think about it in terms of message exchange rather than in terms of distributed objects as we often do now. This may lead us to a whole new world of Web services that support message-based security, asynchronous message exchange scenarios and long-running business processes.

I will try to blog more on topics related to Web services quite often. This post was meant to make a gentle introduction to the way I perceive Web services technologies and their usage. Next posts will probably vary from architecture level musings to code-rich technical posts. More to come soon!