Service Instance Routing (Karmarkar)
How can consumers contact and interact with service instances without the need for proprietary processing logic?
When required to repeatedly access a specific stateful service instance, consumers must rely on custom logic that more tightly couples them to the service.
The service provides an instance identifier along with its destination information in a standardized format that shields the consumer from having to resort to custom logic.
The service is still required to provide custom logic to generate and manage instance identifiers, and both service and consumer require a common messaging infrastructure.
This pattern can introduce the need for significant infrastructure upgrades and when misused can further lead to overly stateful messaging activities that can violate the Service Statelessness principle.
ArchitectureInventory, Service, Composition
Service A, acting as a service consumer, issues a request message to Service B. Instance X of Service B is created (1), and a new message containing a reference to the destination of Service B (which includes the Instance X identifier) is returned back to Service A (2). Service A issues a second message that is routed to Instance X of Service B (3) without the need for proprietary logic. The instance identifier is located in the header of this message and is therefore kept separate from the message body.