Defining the Service Boundary

I think maybe we need a break from our lengthy thread of discussion on data and its influence on SOA. So I've decided to start off a discussion on service definition and the service boundary.

Perhaps one of the reasons why there has been so much confusion over the definition of SOA, is that we haven't been very clear on the definition of a service itself. A service in any given architecture is defined by its boundary. The boundary tells us what parts make up the service (what is inside the boundary), and how the service interacts with the outside world (determined by the service contract).

One problem is that the WS-* stack has become pretty much ubiquitous, and is used today for pretty much any type of communication between distributed components. WCF as Microsoft's unified communications stack perpetuates this. When we have WCF artifacts such as service hosts, service contracts, endpoints, etc floating around everywhere, people tend to align their definition of a service with these constructs.

As a result of this WS-* proliferation, it is extremely likely that we will have a lot of WS-* communications going on behind the boundary of a distributed service.

A distributed service is one where communications over a network occur between distributed components behind the service boundary. Although these communications are message based and defined by a contract described in WSDL, these components do not sit on the service boundary. Whether the parts of a service are distributed or not is an implementation detail of the service - it does not affect its contract, and as such does not affect its boundary.

So with all these endpoints and WSDL documents flying around, how does one identify the service boundary? Well, we need to classify all distributed components exposed in a service as public or private. The public components define the service boundary. The private components are an implementation concern of a distributed service and must be hidden from the service's consumers.

No system outside the service boundary shall communicate directly with any system behind the service boundary. Data cannot be directly shared between services. It can be shared only by way of message exchange through the explicitly defined public endpoints at the service boundary.

Enforcing this is really a matter of IT governance. Service boundaries must be defined, documented and published by the architect. Only the public endpoints should be known to service consumers. This in turn defines the intended service boundaries.