thinking-out-loud

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.

Services are independently deployed

Don Box outlines developing systems using the upcoming Indigo technology. In it, he identifies principles of service orientation, including

• Boundaries are explicit


• Services are autonomous


• Services share schema and contract, not class


• Service compatibility is determined based on policy

In this post, I will discuss the notion of autonomy as it applies to deployment and how (or whether) it is going to change the way you approach development. I will discuss the other bullets in future posts.

Do yourself a favor. If you haven't read it, take a few minutes to read Mr. Box's nice article. If you have read it already, it probably wouldn't hurt to read it again. There -- don't you feel better?

Now.

Let's see if we can't pare it down a bit:

Service orientation does not assume a single point of control.
Services are independently deployed.
Services are independently versioned.
Services may be deployed without a consumer.
Services may fail without notice or notification.
Services may be deployed redundantly.
Services validate trust relationships.
Services do not implement security models internally.

Let's focus for now, just on the deployment aspects.

Autonomy is independence. Autonomous is self-containment. One aspect of that independence of deployment. For the average VS.NET loyalist, this basically boils down to the following: each service is its own project. For the Java monger, this means that a service is a jar/war/ear. For a service oriented architecture, this also [typically] means that you have registered the service with a registry, e.g. UDDI. Given that services often manage data, the data store associated with the service should be designed to easily support incremental deployment. For the largest number of cases, this is going to be a relational database. Does that mean that we need to segment our databases per service? Probably not. But we will probably deploy any necessary ddl changes and stored procedures in lock step with the service deployment. These changes will likely force us to consider whether we are going to need to version, at which point we will have to deal with the fact that xml schema, nice though it is, has some growing up to do.

Deployment is a relatively easy part of independence, all things considered. Challenges associated with independent deployment of services include addressing and managing performance, establishing and maintaining security context outside of the service, and availability of the service (among others). I'll try to visit these topics at a later point.

For what is worth, there is a good chance that you will not always be able to independently deploy services. A common first step to service-orientation is to take an existing [web] application and "service-enable" it. Regardless of whether the application represents several logical services or not, you most likely will start off addressing deployment of the services and application together. Don't sweat it too much. Just try to move yourself toward independent deployment.

Services are definable via WSDL

In an effort to get my head around the notion of services, I am working on my definition of what, precisely, defines a service. Applying the age-old maxim of "When in Rome...," and given that the rome I am in is largely driven by the W3C or Microsoft and IBM, I am going to start with the simplest definition I can think of: a service is a network endpoint that can be described using WSDL that accepts and/or sends messages defined via xml schema. It is hopeful that the messages will be related in some manner.

Services are for integration

Services are inherently a distributed software concept. Services were conceived in the wake of CORBA and DCOM [and their predecessors] taking into explicit consideration the fact that many systems do not grok objects, and those that do do not necessarily agree on exactly what objects are. Services exist primarily as a means of integration of disparate components, processes, applications, or systems. Though Mr. Box with his MS Indigo platform has aspirations of have performant inter-process messaging, and Mr. Glass with his Glue and Fabric strive for a similar fine-grained scalability when it comes to services, the average developer will find it laborious at best to define service interfaces for arbitrary component interactions, when object interactions are typically "just fine." If the details are completely hidden, and the developer doesn't have to care, then so be it. Otherwise, I am sticking to cross-process concerns.

Down with Applications

Service Orientation forces us to change how we think about what exactly an application is. Though more traditional definitions will continue to be valid, as more enterprises become service enabled, the notion of application will apply more to assembled or composite applications that are pulled together from services.