Separating BPM and SOA Processes : Disputes on the Model Stack

6/8/2012 11:37:37 AM
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.

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8
Visit movie_stars's profile on Pinterest.