Specs
WS-BPEL

Tools
Eclipse SOA
X-Registry

Programming an SOA By Miko Matsumura

What does it mean to program an SOA? At Infravio, we think of SOA programming in the context of what we call the “Three C’s.” They are:

1) Configuration
2) Composition
3) Customization

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 run time 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 “contracts.”

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 (some of which are envisioned for this Eclipse project). Aggregation is the type of composition you most often see in a portal context.

The third kind of programming is Customization, which 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 systems. You don’t really need SOA to program at this layer, but it's still part of the overall SOA programming model.

The greatest impact of “SOA Programming” is during “change time governance” When you need to change your IT systems in response to new customers, new requirements, or changes in the competitive landscape, you can achieve business agility via quickly responding through configuration or composition changes.

For example, wire up a new contract, and the underlying service keeps chugging — it doesn't even know that anything has changed. 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.

Composition provides reuse, but requires more effort. Composition is capable of much more complex expressions than Configuration and can express business process functionality. At the bottom of the SOA Programming stack is Customization. If you absolutely have to, go ahead and crack open your IDE and write a new service.

Registry/Repository
My company's flagship product is Infravio X-Registry Platform 5, which is compatible with UDDI 3.0. It's no surprise we consider registry/repository to be an important solution for enabling the “SOA Layer” (i.e., Composition and Configuration). Composition and reuse require a unified way to discover available services. This is needed whether aggregating or orchestrating services.

A bit more subtle is the role of the registry/repository in Configuration. 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. Infravio believes that metadata belongs in a system of record, called a repository. We have three reasons why a repository is a good place for policies, contracts and run time metadata.
 

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

I can’t emphasize the third point enough — 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!

Miko Matsumura is VP of Technology at Infravio, Inc. and the Chair of the OASIS SOA Adoption Blueprints Technical Committee. Infravio is a participant in the Eclipse SOA tools project.