WebService Usage
I saw Julie's post that took me to Alex's post and I really like this subject. However, I don't totally agree.
I definitely agree that WebServices are another layer in a multi-layer architecture. What I don't totally agree with is that there should be no logic in a WebService. That it should only act as an "interface" layer. I think in a perfect world, where everybody follows best practices and has all the time they need to do projects, this would be the way to go. A lot of companies have to weigh "the best way to do something" vs. "the fastest and most cost effective way to do something". A lot, I would guess, decide that if the business logic is small enough and will never be reused, that it would be better to just throw it in the WebService. The more OOP-like you make an application, the easier it is to update in the future. It also goes the other way though, and can make updating more tedious.
The last project I worked on (that's not quite done yet actually) had about 1500 lines of code in it. Basically though, all the logic in the WebService is really just to "shape" the data that comes from my DAL. Should I move all that shaping code into another Assembly or even just another class? Maybe. If I don't, am I screwing myself over in the future? Not really.
I just think that there's no difference in programming practice between say WebForms, WebServices & WindowsForms (besides the fact that WebServices don't have UI). It's a "best practice" to not have any business logic in your UI (or in your WebService, stated by Alex), but does everyone follow that? Not at all. Again, I believe the reason being, simply because of time and weighing the benefits.
That said, I agree with Alex, that business logic should be outside of your "layer interface". I don't think, however, that if you don't do it that way, you should be looked at as someone who doesn't know what they're doing. Situations vary.