Choreography versus Orchestration
Choreography
and orchestration, in an SOA context, pertain to the use of processes
that span multiple participants, with message traffic moving in all
directions according to a complex set of rules. Choreography and
orchestration are attempts to coordinate or control all of this
activity. They attack the problem by putting rigor on how message
exchanges are represented, and by organizing the overall process using
the right set of control flow patterns. Use cases in this area can be
inter-organizational (for example, B2B commerce involving buyer, seller,
and wholesaler), or intra-organizational if the organization is large
enough and the participants act as separate organizations (for example,
bank account processes spanning the front office, the back office, and
the fraud department).
By convention, choreography describes the global protocol governing how individual participants interact with one another. Each participant has its own process,
but choreography is a master process that acts as a kind of traffic
cop. Significantly, the choreography process does not actually run. It
is not a central broker in the live message exchange, but merely a
message exchange protocol. If the participants follow the protocol, the
live exchange will run as smoothly as if there were a central broker.
'Traffic cop' is not exactly right then; choreography is more like a set
of traffic rules. To mix metaphors, choreography teaches the participant processes how to dance as a group.
The process for each participant is referred to as an orchestration process, whose principal job is to build a flow of control around (that is, to orchestrate)
its interactions with partners. Orchestration processes are difficult
to model, especially those faced with complex combinations of inbound
events. If the process is subject to choreography, its structure can be
derived from the choreography; in fact, as we'll see, there are tools
that can generate skeletal orchestration processes from choreography
definitions. The idea is simple: the choreography tells the complete
story, so the participant can determine its role by isolating the parts
in which it's involved. Not all orchestrations, alas, have a
choreography to guide them (not all inter-organizational domains have a
precise protocol defined). If the use case is
sufficiently
complex, the participant ought to create its own choreography anyway,
not to share with its partners but simply to improve its own
understanding of its orchestration.
An orchestration
process has public and private activities. The public activities are
those that are required by the choreography. Private activities are
there to meet internal requirements, but are not visible to partners.
The next figure shows the public activities of the orchestration process
for an energy retailer. The steps shown (for example, Send Request to Distributor) are those required by the enrollment choreography, in which the retailer is but one participant.
The next figure shows the same process with private steps (for example, Update Account) included. In the figure, steps marked with a P are public steps.
Web Services Choreography Description Language (WS-CDL) is the leading choreography language; Business Process Execution Language (BPEL)
is the dominant process orchestration language. Although these
XML-based languages feature a similar flow-oriented design style, only
BPEL is meant to have an actual runtime platform: BPEL processes run;
WS-CDL choreographies are protocols.
BPEL
is better known than WS-CDL in part because orchestration is more
prevalent than choreography. BPEL's user community is much larger than
WS-CDL's. Today, every company is building an SOA platform, and if they
don't use BPEL as their SOA orchestration language, they use something
similar. The user community for choreography consists of industry
committees that publish protocols such as the enrollment and funds
transfer choreographies. (Choreography might
also work as part of a large organization's enterprise architecture,
helping to sort out the communication of the organization's numerous
systems.) Few of these committees use WS-CDL to document their protocols
anyway. Choreography is more often documented less formally using
English descriptions, flowchart diagrams, and an XML message schema.
Examples-Energy Enrollment, Email Bank Transfer
Two examples
from industry that showcase our technique for modeling choreography and
orchestration are the enrollment of customers with retailers in a
deregulated energy market and the procedure for transferring funds by
email between two banks.
In the energy market for a state or small country there are
three parties: customers (who use electricity to power their homes),
retailers (who sell electricity to customers), and the distributor (who
supplies the electricity). Before deregulation, the distributor sold
electricity directly to customers; there were no retailers back then.
Deregulation introduced competition and broke up the distributor's
monopoly. Customers can now buy electricity from one of many competing
retailers. The distributor is now merely a supplier, having moved out of
the retail sales business. When a customer enrolls with a retailer, the
retailer uses the following protocol to complete the enrollment:
The retailer submits the customer's request for enrollment to the distributor.
The
distributor responds in one of the three ways. If there is a problem
with the request (for example, the customer has another enrollment in
progress, or the customer has been flagged for fraud), the distributor
sends a rejection to the retailer. If the request is valid and the
customer is not currently enrolled with a retailer, the distributor
sends an acceptance to the retailer. If the customer is currently
enrolled with a competing retailer but intends to switch, the
distributor sends a notice of pending switch to both of the retailers.
In
the acceptance case there is a 10-day waiting period during which the
customer may cancel the enrollment. To cancel, the customer contacts the
retailer, who forwards the cancellation request to the distributor.
Assuming the customer does not cancel, at the end of the waiting period,
the distributor sends a completion event to the retailer. The customer
is now enrolled with the retailer.
In
the switch case there is also a 10-day waiting period. To cancel, the
customer contacts the initiating retailer (that is, the retailer to whom
the customer is switching). The initiating retailer forwards the
cancellation to the distributor, who then sends completion events to
both retailers indicating that the customer will remain enrolled with
the original retailer. Assuming the customer does not cancel, at the end
of the waiting period, the distributor sends completion events to both
retailers indicating that the customer is now enrolled with the
initiating retailer.
Email bank transfer is a protocol for wiring money by email. It works as follows:
The
person sending the money contacts his bank (the Sender bank), specifying
from which account to draw the funds, how much money to send, and the
name and email address of the recipient.
The Sender bank sets aside the amount and sends an email to the recipient with instructions on how to complete the transfer.
The recipient then contacts her bank, known as the Recipient bank, to complete the transfer.
The Recipient bank submits the transfer request to the Sender bank.
The Sender bank accepts, and the funds are moved into the recipient's account, completing the transfer.
At any point
either the sender or recipient may cancel the transfer, and the
transaction is automatically canceled if not completed within 30 days.
On cancellation, the funds are returned to the sender's account. (We
assume both banks are members of the email transfer programme.)
The following figure shows the most common scenarios in these examples:
