What is an Endpoint?

For a while now I've been describing the various ins and outs of services using the term endpoint, assuming that the term was well understood by my readers. Although this may be the case for many readers out there, there are many subtleties around the definition of an endpoint that are worth discussing.

Services communicate with each other by way of exchanging messages. Messages travel between services via a channel. An endpoint either sends messages onto or receives messages from a channel. All messages arrive at or leave a service via an endpoint.

Note that although a channel has two or more endpoints, it only has one address. The address is controlled by the service that defines/owns/controls the channel. But with potentially many services communicating over a given channel, who owns the channel?

Well that depends on the type of channel. In the case of a point-to-point channel (one service sending a message to one other service), the receiving party controls the channel. In the case of a publish-subscribe channel, the publishing party controls the channel.

We define the endpoints of a service to be only the endpoints of channels controlled by that service. That is, only the endpoints attached to channels owned by a service are described in that service's contract.

A service endpoint is defined by three components:

• The schema of the messages that pass through the endpoint
• The binding and policy (which describe the channel - that is, the means by which messages are transported)
• The address of the channel used by the endpoint to receive or publish messages

Note that each combination of schema, binding/policy and address determines a unique endpoint. So if a service can receive the same messages via HTTP and MSMQ, then we have two distinct endpoints - one for each transport. Alternatively we could have two different endpoints on the same transport accepting different messages.

One catch though is that a service contract may or may not contain service instancing information. That is, it may or may not contain the endpoint addresses. The argument here is that a service shouldn't really care where it is deployed, so that information shouldn't really appear in its contract. We should be able to move a service without updating its contract.

In scenarios where a service registry is being employed, the service registry will contain the service instancing information and the service contracts will contain only the schema, binding and policy metadata.