I’ve finally decided on a usable pattern for general service orchestration in SOA.
I’ll be using this for the T-ORCH set of updates mentioned previously. As well as probably in every other solution I ever create when I have a choice, to be honest.
Here’s a fabulous diagram made by a fabulous person:
You’ve got a controller, an API, and the service you want to control. Behind the API is an MQ, a consumer service and a database.
Here’s how it works:
Controller
The controller registers a request or cancels a request. It also can check on the state of a request.
API
The API does all kinds of stuff: It reports on state for the controller, it receives request registrations and request cancellations from the controller, which it relays to the MQ, it polls the state of a request from the DB, it sends new requests to the service being controlled, as well as sending request state updates from the service to the MQ.
SERVICE
The service, besides performing it’s normal function in the environment, gets new requests once they’ve been registered, it also acknowledges requests, and also marks requests as complete.
MQ
The MQ receives request registrations, request updates (state changes), including request cancellations from the API.
CONSUMER
The consumer relays same from the MQ and inserts them into the database. This greatly simplifies the interactions in the whole design.
DB
The database receives creation, update, or cancellation requests from the consumer only. It also provides the table used to report on request state to the API.
Request Lifecycle
The request lifecycle is: registration, acknowledgment, and completion.