Service Behavior

Here's the definition I tend to use:

Service behavior is the functionality or semantics of a service, i.e. what the service does as defined by the requirements. Two services may have different service interfaces and still have the same behavior. A service's behavior can be validated by service tests.

I'm deciding that a service's behavior is the most fundamental aspect of a service. This is interesting because it's the aspect that us technical people seem to pay the least attention to.

Behavior is the most fundamental part because it defines whether a service provider is working correctly and what a service requestor can depend on a provider to do. Behavior comes from requirements and is ultimately best described as unit tests, what I call service tests. To develop service tests for a service, you need to first define its service interface.

A service's behavior is not the same as the implementation of a provider. Two providers can have different implementations and still have the same behavior. If they both pass the same set of service tests, then they have the same behavior (and interface), even if their implementations are different.

The interface is what technical people often think of as being the service, but a provider that implements the right interface but the wrong behavior is definitely incorrect. A service is more than just its interface, it's at the very least an interface plus behavior. I would say that an even more complete description of the technical design of a service is a service contract.

Also see What Is Behavior?

Blog Posting

From the blog posting Service Behavior:

Lately I'm thinking more about "What is a service?" and deciding that one of the most important aspects is what I'll call "service behavior."

When we talk about services (as in the parts of an SOA), we tend to talk about interfaces a lot. But it doesn't take long to decide that a service is a lot more than an interface. We care more about what a service does than its interface for interacting with it.

So why the focus on interface? Because, I think, an interface is more quantifiable; you can make it machine readable, describing it with a programming construct such as WSDL or a Java or .NET interface. A code compiler can then check code against that declaration for correctness. Inheritance creates rules for how one interface is allowed to extend another. Like I talked about in declared interfaces, interfaces are definite--either they match or they don't. That's easier for us technology types to deal with.

Behavior--what a service does--is more fleeting, which I think explains why us technology types deal with it less. But it's what the users care about most; the business people in an enterprise probably don't care much about the interfaces that services have, but they certainly care about what the services do and whether they do it correctly.

As I discussed in What Is Behavior?, behavior is a bit like dark matter--it can't be measured directly, only indirectly. We measure behavior indirectly through testing--providing known inputs and measuring the outputs to confirm that they meet expectations. There's been some efforts to describe behavior directly the way we do interfaces--declared behavior--but that doesn't really seem to have taken hold thus far. For the time being, behavior can't be described and measured directly like interfaces, only indirectly via testing. (And it doesn't help that testing tends to be treated as computer science backwater.)

So a service is both interface and behavior (and probably more). The technical people focus on the interface while the business people focus on the behavior. To do a good job with services and SOA, we technical people are going to need to focus on behavior as well.