Always for the sake of clarity, I believe that some more words should be spent on in which sense WSs "are another layer in a multi-layer architecture"... They introduce some kind of factorization of the enterprise ecosistem, sure: however I'd say that their taxonomy is somewhat orthogonal to the tier one. They are deeply different in purpose: just think at all the orchestration patterns that WS leverages as opposed to the rigid roles that carachterize the PLBLDAL.

I think that the key concept here is that the design of a business object is supposed to be done exactly like in the past: having WSs today allow you to gather a functional team of objects(components?) that, taken together, supply (guess what?) a service. Such objects can be from both the BL and the DAL, hence the orthogonality.

Regarding the embedding of business logic in the web service: since the WS supply a different coarseness in the offered functionality and can have to coordinate the interaction of different lower level objects, I believe it's perfectly reasonable that such coordination could imply a centain dose of (business) logic. It's not wasted by any mean: by scale selfsimilarity, this could be equivalent to say that the orchestration logic among WSs of one enterprise process is "wasted" as well.

I'm afraid that, more than the articles that for sake of simplicity fail to supply a canonical concept of service, the problem is that it's not entirely clear what a service architecture overimposed on a old fashion one can do for the enterprise: we have the mean before having an exact idea of what what we can achieve with that mean. Such goals are, very often, more business related than pure technical stuff: so the typical situation is that who has the skin in the game can't yet think in term of services and since he can't think in such term he can't as well see the (enormous) advantages specific to his business.

Sorry if my bad English messed up the meaning :-)

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.