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.

Comments

[Todd Girvin]

I agree that's it's unlikely services will truely be deployed independently. Innevitably they will be dependent upon each other or some common data model that will have to change and will cause holesale changes to most of the dependent services. If services should be deployed independently, then Visual Studio needs another containership level so a solution can encompase individually deployable groups of projects. Or does the current project structure support this through dependencies? I wish I had written my Distributed Systems Architecture book a few years ago b/c everything I learned with distributed object systems is all holding true with Web Services and the new awareness of service distribution.