Building an SOA usually means leveraging a loosely coupled-type architecture. While the benefits of a loosely coupled SOA with many services are apparent, the operational characteristics can be a nightmare. However, with a bit of planning, and the use of some standards, your SOA will be both reliable and functional.

The key problem is to make many services, some you own and some you don't own, work and play well together. The objective is to leverage many services, and do it in a way that makes them appear like a single application, although the services could be running anywhere in and outside your organization. In short, making many appear as one.

Okay, now that we know what the problem is, how do we solve it? First, you need to remember that this is largely an architectural problem, and not something you can toss products and standards at. Indeed, you need to define the capabilities of your SOA based on the requirements of the domain, and back the appropriate solution set (standards, tools, technologies) into it. For instance, too many fine grained services and all of the technology and standards in the world won't help you.

What's key here, at least from an architectural perspective, is that you make the right calls in terms of what services are going to make up your SOA in support of critical business events. This is where most SOAs go off track, typically attempting to bind too many services, and at the wrong granularity. You can consider services that make up your SOA like links in a chain, each defining the reliability and performance.

Having stated that obvious problem, there are techniques, technologies, and standards that you can apply that provide your SOA with better capabilities to manage a loosely coupled and distributed SOA. Although they're just getting off the ground, I believe they're some of the most important emerging capabilities.

Look at Standards
Of course any weaknesses in Web services and SOAs always have a WS* standard associated with them, and this problem is no exception. For our purposes, the most relevant are: WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity. Note that the last two are dependent on the first, more on that below.

The WS-Coordination specification describes a framework for providing protocols that coordinate the actions of distributed services. Such coordination protocols are used to support a number of applications, including those that need to reach consistent agreement on the outcome; in other words, the ability to make many services function as a single service, and to do so through close coordination using standard communication and state mechanisms.

The WS-Coordination framework enables an application service to create a context needed to propagate an activity to other services. This is done through the registration of coordination protocols. The framework enables existing transaction processing, workflow, and other systems for coordination to hide their proprietary protocols and to operate in a heterogeneous environment. This specification describes a definition of the structure of context and the requirements for propagating context between cooperating services.

The problem WS-Coordination is looking to solve is that Web services increasingly tie together a large number of participants, forming large distributed computational units that are known as activities. In many SOAs, the resulting activities often leverage a complex structure, with complex relationships between their participants. Therefore, the execution of such activities often takes a long time to complete due to business latencies and user interactions. The use of the coordination framework isn't restricted to transaction processing systems; a wide variety of protocols can be defined for distributed applications.

The WS-Coordination specification describes a framework for a coordination service (or coordinator) that consists of these component services: an Activation service, a Registration service, and a coordination type. An Activation service enables an application to create a coordination instance or context. A Registration service enables an application to register for coordination protocols. A coordination type specifies a set of coordination protocols to use in a distributed application instance.

The WS-AtomicTransaction specification defines an atomic transaction coordination type for use with WS-Coordination. It defines three specific agreement coordination protocols for the atomic transaction coordination type: completion, a volatile two-phase commit, and a durable two-phase commit. Those building an SOA can use any or all of these protocols when building solutions that require consistent agreement on the outcome of short-lived distributed activities that either work or don't work - all or nothing.

The WS-BusinessActivity specification defines the business activity coordination type that leverages the WS-Coordination specification. The specification defines two specific agreement coordination protocols for the business activity coordination type: BusinessAgreementWithParticipantCompletion and BusinessAgreementWithCoordinatorCompletion. Developers can use any or all of these protocols when building applications that require agreement on the outcome of long-running distributed activities.

The essence of this problem, and the solutions, is the ability to make many different behaviors existing on all kinds of environments and at all locations appear to be a single, well structured, and reliable application. This is a problem we've been wrestling with for years, and have put specific types of technologies on it, such as transactional systems and state machines. There is really nothing new here, just new tools and standards.

With the advent of Web services we have both an opportunity and a problem. The opportunity is to build applications with reusable services that we may or may not have built ourselves. Thus you should end up with an IT infrastructure that's both adaptable and inexpensive through the notion of reuse. The management of distributed services carries its own set of issues, as discussed above. However, with a bit of good architectural forethought and the good use of standards and technologies, I think we can have our cake and eat it too.