Todd Biske: Outside the Box

In the latest ZapThink ZapFlash, Ron Schmelzer provides some guidance on services, contracts, and policies. He speaks of the “aha” moment that many of us experienced when learning object-oriented programming languages, and compares this to a migration to service-oriented development.

Ron goes on to discuss the differences between a policy and contract based approach versus an object API-based approach. He discusses the need for a many-to-many relationship between policies and contracts, as well as between contracts and implementations. His analysis is correct, but what he didn’t go into is how the “aha” moment can occur.

In my own case, the key to this was when container-managed code was introduced with the J2EE platform. One of the goals of J2EE was to remove the responsibility for security, transaction management, and more from the developer by declaring the policies surrounding this in a separate configuration file. When J2EE was introduced, Sun also outlined the roles and responsibilities associated with a development project. One of these, the Application Assembler, was intended to create this descriptor file, while the Application Component Provider was responsible for the implementation. In my experience, these two roles were typically played by the same person. There’s even recognition of this in the C# and .NET framework where these policies are implemented by annotating source code. This is also now common practice in the Java camp as well, first through JavaDoc tags, and now through J2SE 5.0 Annotations.

When I began investigating Web Services, the “aha” moment occurred when I realized that the declarative policies that were established in a platform-specific manner can now be utilized independent of the platform. In fact, the entire “container” concept can be externalized from the actual implementation container. Since Web Services are sent as XML messages on the wire, policies can be enforced anywhere between the consumer and provider. Working on the infrastructure side of things helps this understanding, because some policies, typically routing, are already configured on a separate device from the application container.

This truly is a light bulb moment, because of the implications. As soon as policies can be externalized from the source code and execution container, we begin down a path where policy definition can be separated from policy enforcement points. Once policies are separated from the enforcement points, a new breed of tooling can be created for policy definition appropriate to the policy setters, rather than appropriate to the enforcement point.

For example, an organization may have an Information Security department that sets policy, but it may require an IT operations staff member to express that policy in a way that can be enforced by the infrastructure. If that same infrastructure also enforces routing policy, there is a dilemma. The person configuring routing policies should not be able to configure security policies. The key to this, as Ron suggests, lies with standards and tool support. By creating standard policy languages, an interoperability framework for sharing policies between editing, management, and enforcement points can now be created.

One Response to “Aha! It’s an SOA!”