How can consumers contact and interact with service instances
without the need for proprietary processing logic?
Problem
When required to repeatedly access a specific stateful service
instance, consumers must rely on custom logic that more tightly
couples them to the service.
Solution
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.
Application
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.
Impacts
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 Statelessnes
principle.
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.
This page contains excerpts from:
SOA Design Patterns by Thomas Erl
Foreword by Grady Booch
With contributions from David Chappell, Jason Hogg, Anish Karmarkar, Mark Little, David Orchard, Satadru Roy, Thomas Rischbeck, Arnaud Simon, Clemens Utschig, Dennis Wisnosky, and others.
(ISBN: 0136135161, Hardcover, Full-Color, 400+ Illustrations, 865 pages)
For more information about this book, visitwww.soabooks.com.
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP)
Arcitura IT Certified Professionals (AITCP) 
Arcitura YouTube Channel
This page contains excerpts from:
