I find it remarkable (well, at least in the sense that I am remarking about it) that restricting services to being autonomous does little to scope their granularity. As an example, -- and not that you would want to, mind you -- but you *could* conceivably represent an entire enterprise's collection of systems via a single WSDL, and you could deploy and version the services as a singluar entity. So what, exactly, does it mean to restrict your services to be autonomous? At this point, it is worth stating that services do not explicitly *have* to be autonomous. I think that Don Box offers the sage advice "Services are autonomous" more to say "If you do it this way, it won't hurt as much." So, in my mind, I am using autonomy as a guideline for modularity. I am asking myself questions like "what is the smallest autonomously deployable unit for which I can manage performance, for which I want to manage security, etc?"
The scale invariance of autonomy is similar, in my mind, to component and object development, in that you could have an object or component that represents an entire enterprise, but of course, that also becomes unwieldy, and other forces drive you to not manage in that manner. I find it useful to scope services to use cases or actor-specific interfaces for a given use case, where use cases are defined along the lines of Mr. Cockburn's essay on Structuring Use Cases with Goals -- a must read regardless of your affinity for use cases.
Posted by: Todd Girvin | 2004.04.28 at 12:56 PM