Endpoints, State, and Correlation

The language of SOA is a bit messy, with the same terms having different meanings in different contexts and in different minds. This section tells the relatively absolute truth.

An endpoint is a location: the addressing details that are necessary and sufficient to access or provide a service at run time. If service A is on both machine 1 and machine 2, you can speak of two endpoints, and in this case, endpoint is synonymous with service location.

The endpoint is a step removed from the implementation. The operating system

• receives inbound data at the endpoint and presents that data to the implementation code. The implementation is said to be listening at the endpoint.

• accepts outbound data at the endpoint and transmits that data to a service at another endpoint.

From the point of view of a network administrator, a service instance is an implementation that is listening at a particular endpoint. If service A is on machines 1 and 2, two service instances are available. When a request arrives at run time, the service instance dispatches the request to a thread of execution, which is an operating-system facility that runs the service. If two requests arrive at the same time, each request is given its own thread.

Most services (specifically, most service implementations) are stateless, which means that the runtime code never relies on data from a previous invocation. A stock-quote service, for example, receives a trading symbol and returns a quote, and the data used in one invocation is independent of the data used in the next.

A stateful service, in contrast, sometimes needs access to values that were assigned in a previous invocation of the same or another service. The need arises because the service participates in a multi-step conversation, which is a sequence of invocations that constitute a relationship between the service and a requester.

In the usual situation, a requester's invocation initiates the conversation, and subsequent requests from the same requester are valid only if they arrive in a specific sequence. The service has a technology-specific way to ensure that each request is directed to the appropriate conversation rather than to a conversation occurring at the same time between the service and a different requester.

A conversation can be based on a persistent connection, but two other options are far more likely, especially in services that run for days or months. In one option, an SOA runtime product uses the input message or a system value to direct the message to the appropriate conversation. In a second option, the service implementation itself uses the input message. In either case, state is a processing status - the sequential position of the last received message in the sequence of messages that are expected on the service's side of the conversation.

Figure 2.8 illustrates a service conversation over time. As shown, a purchasing service establishes a conversation with a manufacturing service and expects a sequence of messages (confirmed, shipped, invoiced) for a specific order. When the endpoint of the purchasing service receives the confirmed message, for example, the service implementation ensures that

Figure 2.8: Conversation over time

• the message applies to the appropriate conversation

• the state of the purchasing service changes so that at the next receipt of data from the requester, only a shipped message is considered valid

When a business analyst talks about "directing a message to the correct service instance," the meaning is really to direct a message to the appropriate conversation. We'll accept this point of view, using the term service instance (or process instance) to mean the runtime logic that handles a conversation with a specific requester.

To ensure that a message is directed appropriately, you often need to include specific IDs in the message - for example, a customer ID, an order ID, an invoice number, or some combination of identifiers. Those identifiers also correlate the processing done by the instance of one service (for example, the service that sends a purchase order) with the processing done by instances of other services (to confirm an order, send a shipment notification, and so on).

We say more about correlation in the chapters on Business Processing Execution Language (BPEL).