Dealing With SOA
I'm a lover of SOA - at least, to a degree. I don't like to jump on any bandwagon just because it's the cool thing right now. But I know at my last job I certainly went to a lot of effort to try to come up with a decent solution to our needs there. The end result result was a pretty decent n-tier type setup that could optionally call it's back-end service in an SOA type manner - it might use a webservice, it might now, it didn't matter.
Rocky Lhotka has recently posted about how SOA is reaching the bottom of the curve in it's hype factor. I'm glad it's finally got there - SOA to me has been useful (although I admit I haven't strictly adhered to it to the purist level) but like anything that I see as useful I hate to see bandied about as panacea.
Rocky talked about the forms of coupling between your code and some service, and how the more the service might do, the more tightly coupled you really are. So far I think I've been pretty lucky in that I've been the author of both the service and it's callers (at least until I stopped for Telstra a couple of months ago) and we knew in advance that it was only our own code that would call these services, and that we happy to lock in a pretty rigid api that, while each individual method was relatively independent of another (that is, you didn't have to call method A just so that you could call method B, but it did flow easier given that we knew that when calling method B, it was highly likely that we had not long ago called method A...if you get what I mean.
But anyway, give Rocky's post a read. It might make you think about what you're doing a little more. If nothing else, you'll come away wanting to eat some cookies :)