How do you declaratively specify the behavior of a service?
It's easy, or at least possible, to specify the declared interface for a service. A service's interface captures the signatures for invoking it and defines the data formats for exchanging parameters and return types between the service consumer and service provider. Such well-defined interfaces make integration between components (objects, services, applications) much less error-prone and problem determination much more definitive. But as the name "interface" implies, this only captures how to invoke a service; it does not provide an objective description of what the service does.
Right now, the best way I know to capture intended behavior for a service is using use cases and unit tests. In "Streamline SOA development using service mocks," I call these service use cases and service tests. Service use cases are a human-language description of a service that people understand. Service tests are a programmatic equivalent of the observable effects of those use cases; tests measure the behavior of a service and judge whether it conforms correctly to the intentions described in the use cases.
However, specifying behavior really needs to be more declarative than use cases and unit tests can be. An interface is declarative; either an implementation fulfills the contract or it doesn't. There seems to be no similarly declarative way to specify the behavior of a service. I think that business semantic modeling may be very helpful for capturing the behavior of an SOA service.
"Business semantic model" is a term getting tossed around in SOA circles these days. Unfortunately, I can't find a simple definition that says exactly what it is. The best source I've found for it is a paper that seems to be from 2004, "Unifying Data, Documents, and Processes." Yup, those sound like good things to unify. The business semantic model develops a uniform data model for the enterprise and captures the meaning of the data objects. What seems to be the key is the meaning of the objects (hence the word "semantic").
A similar term is "business process semantic model" (BPSM), which is being developed by the BPMI part of the OMG. According to Essential Business Process Modeling, BPSM is a metamodel for business process definition model (BPDM), a common model for all business process models. A Google book excerpt shows BPMI's recommended BPM stack. This is all very interesting; but will it lead to being able to declaratively describe the behavior expected of a service?