This post originated from an RSS feed registered with .NET Buzz by Brendan Tompkins. Original Post: Web Service Thinking - Thoughts on Steve's thoughts on Sahil's thoughts... Feed Title: Brendan Tompkins Feed URL: /error.htm?aspxerrorpath=/blogs/brendan.tompkins/Rss.aspx Feed Description: Blog First. Ask Questions Later. Latest .NET Buzz Posts Latest .NET Buzz Posts by Brendan Tompkins Latest Posts From Brendan Tompkins

Sahil and Steve have been posting some really great stuff on this whole question of “What’s a Web Service.”  I’ve been trying to wrap my head around this myself with my WSMQ project, so I thought I’d add my two cents. 

Sahil is right on the money with his post WebServices - A WHOLE new way of thinking:

You cannot think of web services in the same way as you think of remoting, and even worse regular OOP programming. You have to wrap your head around the request/response model, understand if you ask for an event subscription - what will happen under the seams, and what effect that might have on your application.

Thinking about services as remotable objects can lead you into some pretty dead end thinking.  I've been guilty of this myself.  In fact, it's hard not to think this way when VS really makes them look smell and feel like remotable objects.  Visual Studio may in fact be the application that brings Web Services to the rest of us, but it’s doing so at a price, and confusing us all a bit along the way.  VS should throw up a big dialog box that looks like this:

Now, I think everyone understands this to be the case, but a dialog like this would have certainly helped me! Recently I’ve started to try to understand messaging over different transports, and the whole concept that services aren't objects really hits home when you delve into this stuff...  

There’s also a big fat gem of wisdom to be found in Steve’s comment on Sahil’s post:

The first and biggest mistake is believing the WebService layer exists at the business layer - bad move!

Steve is really on to something else here, IMO.  Web services are not really services either - the way we think of them as middle-tier components (business services). In this way, I think they're mis-named.  They should be called “Message Endpoints” or Message Interface (MI) components or something else, but they're not really services!

But back to Steve’s point, they are  more like a user interface than a service, and if they're more like UI layers, they they should be layered the same way - they should really contain no business logic and should simply be relegated to state maintenance, etc. Steve goes on to say pretty much this:

One approach is to consider the WebService Interface operating at the same level as the WebUI level.  The request/response interaction is nearly identical, "session management" requirements are the same.

This is something that has also taken me time to understand, but now that I do, I also understand that it’s a really important concept.

I’ve just installed the Indigo bits this afternoon, and am really looking forward to seeing how this all fits in with the new way.  Should be an interesting next few years!

-Brendan