Source - Grady Booch's blog at IBM Developer site
Having said that, there follow a multitude of hard technical and process decisions that must be made, which the Snake Oil-oriented Architecture showmen often neglect to tell you about: what distinguishes a good service from a bad one? what should the granularity of a service be? when should I offer up a stateless service versus a stateful one? as for the stateful ones, how to I express their semantics, and how do I ensure their their misuse doesn't corrupt my system? how do I express the semantics of a society of services (only the most trivial services work in isolation)? how do I decide upon the semantics of the information transmitted by these services so that locally they are efficient and useful but that also globally they are consistent? how do I expose some services to some clients and hide them from others? how do I offer up variants on a service, so that different clients see a different face to that service? how do I ensure the security of critical services, such that I am confident I'm not opening up holes in my enterprise that will let the bad guys in? what services should I expose to the world, and what services should I keep hidden? where are services appropriate, and where are they not? how do I best expose services in a legacy system? who should own/maintain these services? are there alternative architectural patterns I should employ instead of services, and where, and why?
