"Why is SOA taking so long?" asks a report by ZapThink consultants. "Pitfalls On The Path To SOA" and "Hidden Hazards In Getting To SOA" are headlines that seem to be appearing in different places at the same time. InformationWeek on Oct. 31 offered its assessment in "SOA, Work In Progress," which cited the increased complexity imposed by SOA and the slow progress toward completed projects.

Is SOA an architecture that is going to be achieved?

I was talking over that issue with Miko Matsumura, VP of technology standards at Infravio Inc., recently. Matsumura points out that the initial enthusiasm for SOA has given way to the trough that inevitably follows such optimism. A term gains currency, people turn to it as a cure-all for their problems, and then a wave of disappointment sets in as the cure-all begins to look like a new set of problems. "We are in the trough of disillusionment," he says,

Do technical cycles really proceed this way, with predictable peaks and valleys? Sometimes it seems to me as if they do.

If so, Matsumura's next analogy is to a group of climbers, coming out of the trough and going up the side of a mountain. We're learning with SOA that we are tied together, and no one can proceed unless the group proceeds, following the standards of good climbing practice. If you don't and one person falls, then all those roped together are pulled down the mountainside. So far, the bodies are piling up at the base of the mountain.

What needs to happen is that some of the intelligence, buried in applications or hidden in middleware integration, needs to come out on the network, where it can work for everybody using the network.

The Web-services standards, like WS-Reliable Messaging and WS-Distributed Management, pronounced "wisdom" for WSDM, are ways of moving that intelligence, buried in a previous generation of software, out to where it's more useful.

As SOA architects do so, they still need a way to centralize management of such intelligence, and early adopters are debating how to do it. It's a stumbling block for which there is no one solution. Or perhaps more accurately, there are several solutions suggested and no one is sure which will win out.

Matsumura thinks it will be the services registry, which can manage services and supply governance -- apply the policies that dictate when the services are to be invoked and at what resource level. Reactivity is putting policies and management capabilities into its XML firewall, a message accelerator that sits on the network and performs its functions without adding overhead to the other moving parts of the network. AmberPoint's SOA Validation System monitors message traffic invoking services, assesses response times, and determines from pre-set parameters whether the services are delivering as promised. Actional Corp.'s SOAPstation and Looking Glass are likewise monitoring message traffic and assessing responses, in view of service-level agreements.

Systinet and Infravio place the governing intelligence in their service registries and believe the registry is the key building block of SOA's future. Time will tell.

In the mainframe era, all this governing intelligence was found in the mainframe itself. In the world of client/server, intelligence started spreading out on servers on the network, which became a problem.

Now the intelligence is migrating away from servers and onto the network itself, and one of the final steps to SOA is figuring out how to centralize, maximize, and maintain that intelligence when it wants to disappear into a jungle of services.