David Wheeler, the inventor of the subroutine, once famously said that "any problem in computer science can be solved with another layer of indirection."

	express delivery
	• print  • comment
	When your IT systems need to respond quickly, SOA's new programming layers, via configuration or composition changes, can help you achieve business agility. Miko Matsumura is VP marketing and technology standards at SOA infrastructure vendor Infravio. The company's X-Registry Platform provides a UDDI registry, SOA repository and SOA lifecycle governance features.
	Glossary terms: metadata, development, customization, orchestration, registry, lookup tool Sponsored links: your text link here

In an SOA, indirection — better known nowadays as 'abstraction' — emerges in two separate layers. One of these layers enables services to be composed out of other services (composite applications). The other enables services to be configured using metadata (declarative programming). Combined with the traditional software layer made up of custom software, these three layers comprise the "programming model" for SOA — configuration (metadata), composition (composite applications), and customization (discrete services).

Configuration is sometimes called "declarative programming." By 'programming' (configuring) metadata attributes, changes can be made to running systems. In an SOA, these changes are often related to contracts and policies. Essentially, metadata describes the policies that you want your system to enforce — these policies are usually enforced during runtime on some form of intermediary (aka "policy enforcement point"). Since changes are made to the intermediary, the underlying services do not have to be aware of the change — a form of loose coupling. If you apply different policies to different identities, you get separate 'contracts' that apply to each engagement.

Composition is the second kind of SOA programming, sometimes called "composite application development." These applications can be formed by aggregation (for example, having a service that consumes two or more other services synchronously) or by orchestration (a stateful service, which traverses other services serially). Orchestrated services are often 'workflow' oriented using standards, such as WS-BPEL, and often involve fancy visual tools. Aggregation is the type of composition you most often see in a portal context.

Customization, the third 'C', involves creating new services or modifying existing services underneath the service interfaces. This is, of course, the traditional application platform programming familiar to users of Visual Studio, Eclipse, Emacs and many other such integrated development environments (IDEs) that developers use to create new software code. You don't really need SOA to program at this layer, but it's still part of the overall SOA programming model.

Change time impact

SOA programming has its greatest impact during "change time governance" — when services that have already been deployed need to change to adapt to new customers, new requirements, or changes in the competitive landscape. When your IT systems need to respond quickly, SOA's new programming layers, via configuration or composition changes, can help you achieve business agility.

For example, wire up a new contract to apply a new policy or identify a new consumer to an existing service. The underlying service keeps chugging — it doesn't even know that anything has changed — but the configuration change allows it to fulfil the new contract. Having 100 different contracts specifying 100 different service consumer preferences enables you to have a single service that works for all of those different consumers. This is powerful reuse and agility.

Implemented within a proper management framework, configuration of policies and identities is simple enough to be left in the hands of business users and administrators. The ‘programming' can be done using check-boxes and pull-down menus in an admin screen, with no coding required.

Composition provides reuse, but requires more effort. Because it combines multiple services, composition is capable of much more complex expressions than configuration and can express business process functionality. It requires the skills of an analyst, but with the right development tools it can still be achieved without minimal coding, using visual modeling and drag-and-drop.

Customization sits at the bottom of the SOA programming stack. If you absolutely have to, go ahead and crack open your IDE and write a new service. You will definitely need to call on the help of some experienced code jockeys. You'll probably also need to call in your finance people, to get budget approval to cover the expense.

Registry/Repository

The registry/repository plays an important role in enabling composition and configuration within an SOA.

Composition depends on reuse, and requires a unified way to discover available services. This is needed whether aggregating or orchestrating services.

The role of the registry/repository in configuration is a bit more subtle. Metadata, policies and contracts can live anywhere. Some programming styles put run-time metadata into 'deployment descriptors' that developers create and package with the services themselves. Some styles bind the metadata directly into intermediaries. Another approach believes that metadata belongs in a system of record, called a repository. There are three reasons why a repository is a good place for policies, contracts and run-time metadata:

1. Unified visibility and control of policies and contracts.
2. Business users can configure their SOA through simpler interfaces.
3. Repositories can protect the metadata using access control, security and governance processes.

The third point is crucial — if you have external partner companies expressing their integration preferences in your metadata contracts (such as service level agreements), you don't want any random person changing those contracts!

Best practices

Configuration: It is best practice to model the fastest changing aspects of your business in this topmost layer. This makes changing in response to business requirements faster and easier. One way to think about this layer is that it should contain information about who (identity) consumes the service, where (delivery preferences) and when (service level agreements) do they consume it, and how all of these aspects reflect unique capabilities, limitations and preferences of the service consumer.

Composition: A useful way of thinking about this layer is that it should model how (in terms of business processes) your business services are delivered. These processes should not change as frequently as the configuration layer. Adapting business processes is often evolutionary in nature and a process of optimization.

Customization: Best practices for this layer would have it that this layer should model what business services your organization delivers. Hopefully, the services your organization delivers should be reasonably stable and not changing much over time.

This three-layer model of SOA enables business change to be externalized from your software infrastructure, making the fastest-changing parts of most businesses flexible and easily configurable as metadata. It is a way of modeling business IT management from the perspective of change and adaptability. Within these three layers are the models of who, where, when, how and what services are delivered. Why you deliver your services should be self-evident(!). By modeling your business services using these three conceptual layers, you can build your architecture for change-time governance — externalizing the fastest changing parts of your business as easily reconfigurable metadata.

More on this topic