Rockford Lhotka has posted a very nice article on some tough issues with SOA.  Please read the post and then check my thoughts below:

Very well written.  I have a question, though.  If we need to perform the follwing actions - trigger invoicing, contact the customer, print pick lists, and update the customer's sales history - why would we call a service that *might* do these actions.

Wait, I think I can answer this one myself.  You are talking about systems that are already in place, have been for quite some time, and have evolved to do these things.  Then people start using the service and either need something else done or don't need all the "services" the object provides. 

This is a very common problem and is certainly not limited to SOA.  All developers have had to fix "established" code that has these problems.  What you end up with is code that resembles a ball of twine and you're darned lucky if it doesn't have more than a few knots inside.

How do you solve the problem?  Some would say to force the service objects to perform one and only one service.  This is all well and good.  But then you hit the overhead problem you so very well described.

What I have determined is this.  Each application has a purpose and needs "services" performed.  Other applications may need similar services.  But the second you decide to combine the services provided to both applications into one object, you open the door to unexpected behavior.  Heck, sometimes (usually) even the same application needs a service to behave differently for various situations.