I’ve finally managed to spend some more time with the OASIS SOA Reference Model committee draft — and my conclusion is that it’s vague, ambiguous, and ultimately useless.

For one thing, there is this well-meant attempt to use some spec-lingo (as defined by RFC2119), probably to give it more tangibility. Here are some examples:

The internal actions that service providers and consumers perform as a result of participation in service interactions are, by definition, private and fundamentally unknowable. By unknowable we mean both that external parties cannot see others’ private actions and, furthermore, SHOULD NOT have explicit knowledge of them.

There is a strong relationship between the shared state and the interactions that lead up to that state. The elements of the shared state SHOULD be inferable from that prior interaction together with other context as necessary.

Best practice suggests that the service description SHOULD be represented using a standard, referenceable format.

While each of these items SHOULD be represented in any service description, the details can be included through references (links) to external sources and are NOT REQUIRED to be incorporated explicitly.

“NOT REQUIRED”, by the way, has no formal meaning in RFC2119.

However, a service description SHOULD include sufficient data to enable a service consumer and service provider to interact with each other. This MAY include metadata such as the location of the service and what information protocols it supports and requires. It MAY also include dynamic information about the service, such as whether it is currently available.

Policy assertions SHOULD be written in a form that is understandable to, and processable by, the parties to whom the policy is directed.

Each of those SHOULDs and MAYs either states something blatantly obivous or underlines some statement that’s as solid as wax. So let’s take a look at the MUSTs:

The initiator in a service interaction MUST be aware of the other parties, the participants MUST be predisposed to interaction, and the participants MUST be able to interact.

You don’t say?

Both the service provider and the service consumer MUST have information that would lead them to know of the other’s existence.

But enough of that …

What does it actually contribute to the discussion about SOA? It defines a bunch of technical terms, but some of them are so abstract that I could start crying. For example

“Awareness — A state by which one party has knowledge of the existence of other party.”

To be fair, there are some valid definitions — service provider, service consumer, policy, contract — but they would fit on maybe two or three pages.

One might argue that if you don’t have anything to say, it’s sometimes better to stay quiet. In this case, I believe the reason is rather that if you want to accommodate too many differing views at once, you might find there’s nothing solid left.