2004.02.23

More Service Autonomy

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.

Comments

I read a white paper on MS Shadowfax that made intro'd with a description of the difference between SOA and OOP. (sorry for no ref since I read the word doc offline.) I swear these guys don't get it. They talk about SOA as if all the rules are different from OOP. Frankly, I don't think they get the fundamentals of OOD. Statements like "a web service should be autonomous" are so ambiguous as to not convey anything meaningful. Does it mean a web service shouldn't depend on/call another web service? Does it mean that you shouldn't have a protocol of interaction defined that requires one service to be called before another within the same module? If you can achieve this and therefore embrace a stateless model as did the early Web, yes it's less painful for the service developer. But, haven't we already been there with human interaction and learned that we need session/state management in order to carry on complex conversations?
The white paper on Shadowfax seemed to jump to the other extreme. It seemed to assume that everything was done in a series of messages and that the core abstractions then are messages and handlers along the message channel. This seems to be going way to far since you then lose the self-documenting, type-safe, interface managed interaction we've grown to know and love in OO and basic Web Services.