Confusing Web Services?

Discussing service oriented architectures with a number of developers recently, made me realize that there is real confusion about how an ASP.NET XML Web Service should be implemented architecturally.

Many appeared to think that somehow business logic should be implemented in the Web Service, which would be serviced by the data tier, with one or more presentation layers consuming the service.

Why think this?

The answer is that that's what most articles and examples tend to show. Most show business logic being performed in a service method. Admittedly, it is often shown that way in order to show how to consume an XML Web Service, but does soat the cost of the bigger picture.

Surely examples should more correctly show a Web Service acting as an interface to business logic. Business logic that is serviced by the data tier and ifapplicable, enterprise services. Business logic which is generally represented directly through a presentation layer.

4 Comments

  • I'm not sure I totally understand what you're getting at.


    Can you clarify a bit?





    Are you saying that WebServices should just be wrappers for exposing existing business logic? Or that WebServices are not necessary? Or something totally different?

  • Alex - hooray. Marcie and I were talking about that last night. People are really mixing web services up with dcom.


    I noticed you have the msdn architecture stuff on your links. I wish that was the home page of msdn! Everyone should read that stuff first.

  • Tim,





    What I am saying is that a Web Service should expose the functionality contained in an application's program (business) logic rather than implement the logic itself.





    In that way, it represents an interface to the underlying functionality of an application.





    Does that help - please let me know if this isn't clear.


  • Yes, ok - I kind of thought that's what you were getting at, but I wasn't sure. In that case, I agree with you 100%.





    It's the perfect scenario for reuse. Take some existing business logic and provide yet another way for others to consume it.





    We've done similar stuff with COM components in the past (before the days of SOAP) - exposing them through some generic ASP page that provides an XML-over-HTTP interface to various consumers. One of the only significant differences there was the format of the message.

Comments have been disabled for this content.