The following diagram shows the main components of the ACMEBank architecture to support the disputes process:
There are two
partners in this architecture, both of which are external to ACMEBank
and communicate with it by SOAP over HTTP. The partners are the dispute
network (which connects ACMEBank to both merchant banks and the VISA
association) and the customer channel (a self-service web interface that
allows customers to raise and update disputes). These partners
communicate with ACMEBank's orchestration processes through the ESB. MOM
queues sit between the ESB and the orchestration processes. The ESB
places requests originating from partners on a queue which is read by
the orchestration process; when the process responds, it places a
message on a queue, which the ESB picks up and sends back to the
partners over HTTP.
The
orchestration processes use BPM processes to manage the operational
review activities. They also interface with two databases: the account
database (to post conditional credits) and the dispute database (which
keeps the state of current disputes).
The following figure sketches the interactions between processes in a typical BPM-based implementation.
In this design,
there is a single BPM process which manages the overall flow of events.
The BPM process can inherently manage whatever manual work needs to be
performed, but it uses orchestration processes to perform automated
tasks and to communicate with partners.
There are
three types of orchestration processes in the BPM-based approach:
inbound, outbound, and internal services processes. Inbound processes
are responsible for receiving events from partners and injecting them
into the controlling BPM process. An inbound event can either create a
new instance of the BPM process or update an existing instance. The
inbound orchestration process understands the difference and uses a
different method to start an instance than to update an instance.
Outbound processes send events to partners on behalf of the BPM process.
Internal service processes perform services, such as updating databases
and interfacing with the mainframe, that the BPM process, with its
limited integration capabilities, cannot perform.
There are two
sets of ESB processes, one to handle inbound messages (that is, messages
coming from partners), and the other for outbound messages (that is,
messages sent to partners). ESB processes perform simple transformation
and routing. When an inbound ESB process receives a message, it decides
where to route it internally. In effect, the ESB process decides which orchestration
process should handle the message and sends the message to the queue on
which that process listens. When an outbound ESB process receives a
message (which comes from an outbound orchestration process), it decides which partner should receive the message and routes it there accordingly.
The next figure sketches the SOA-based approach:
In this design, it
is an orchestration process rather than a BPM process that controls the
end-to-end flow. The orchestration process sends messages to its
partners through ESB outbound message flows. It receives inbound events
from inbound ESB flows. These events can either start a new instance of
the orchestration process or update an existing process. It is the
responsibility of the ESB message flow to route these two types of
requests differently. Like the BPM process in the BPM-based design, the
orchestration process is fundamentally event-driven; it requires the
ability to listen for events during the course of its execution. Chapter
4 discusses in detail how this routing works.
There is no
requirement for internal service processes in the SOA-based approach.
The controller orchestration process performs integration services as
part of its larger execution. Granted, it might separate these out into
reusable processes, but this is not an essential part of the design.
When the
orchestration process needs to perform manual work, it calls on a BPM
process to oversee that work. There is one BPM process instance for each
manual task that is performed. As manual tasks need some time to
complete (perhaps hours, days, or longer), the BPM process is
responsible for notifying the orchestration process when the task is
complete and to indicate its outcome.
