Though BPMN 2 supports transactions (in notation form) their implementation requires some additional work with regards to details – effort being a method for managing distributed transactions across heterogeneous service providers. A natural fit is called a “saga” where the transacted activity is broken down into a sequence of steps which are pared, via event association, with compensating tasks. If any of the activities within the transaction context fail, these compensating tasks then undo the work, in reverse sequence, in an attempt to reverse the changes defined within the BPMN transaction[1][4].
However, in certain situations, this approach isn’t practical due to the fact that a “compensating transaction” is really just another transaction – all of which could end up potentially building upon an already congested logjam of pending work. Scaling the “saga” method therefor leads to some concern in context to busy, volatile data-stores.
Another more serious problem is that we’re still left without transaction isolation. This isn’t necessarily an issue so long as your process follows a pattern of creating records (or documents) as apposed to updating existing. Though, avoiding updates is a tricky affair given that most, if not all, “create new” implementations first check for pre-existing and/or potentially duplicate instances.
Collaborating with Business Object Services
My attempt towards a more ideal solution starts first with a process-oriented view – one where we address the problem as a question about two collaborating systems defined by their roles: either needing or managing business objects. This collaboration then helps illustrate interaction requirements between the two domains.
Business Object Consumer: Service Client
The client (example: “Task 1”) starts work by first sending a business object request into the instance manager. Only after the client receives the requested instance does work begin. The client is then responsible for both monitoring transaction related messages and committing changes upon completion. Transaction related messages include: rollback, timeout, etc..
There is obviously room for some aspect-oriented modularization[3] here to help break out the eventually repeating behavior associated with fetching and monitoring object state. And, I do intend to follow-up on Aspect Oriented Programming (AOP) – for now we’ll skip past this topic and continue onto object instance and context management.
Business Object Manager: Service Provider
Object instance and context management responsibilities are broken out into two collaborating processes. Instance management first evaluates locking (object management) rules. Rules can include: authorization, concurrency, logging, and regulatory requirements. Instance creation then follows with implied interaction with object stores (data-services). Objects are then delivered to both the requesting client and associated context manager. The Context Process keeps track of objects associated with activities surrounded by the client’s Transaction group (BPMN Transaction). Transactional information is relayed back to registered clients involved within the transaction’s context – this insures all participants either commit or rollback changes.
Enforcing Transaction Protocol: ACID Model
The ACID model has the following properties:
- Atomicity: Either all activities commit or none
- Consistency: Work begins and completes at a consistent state
- Isolation: Transactions do not interfere with each other
- Durability: The effects of a completed transactions are guarantied reliable persistence
We enforce transaction protocol through event communication between Client and Service Provider. The Client “requests” objects and transactions from the Object Manager. Object Instance and Context Management processes collaborate to enforce protocol. A key feature of this arrangement are the “locking rules” that insure a uniformity of constraints are followed across all type instances (e.g. “Customer”, “Account”, etc).
Due to the long-running nature of BPM transactions, we avoid traditional “hard-locking” (XA) transactions. As a work-around, “soft locks”[2] are issued and manageable so long as we constrain object activities to the protocols enforced by the Object Instance and Context models.
References
[1] Weske, Mathias. Business Process Management: Concepts, Languages, Architectures. Second ed. : Springer, 2012.
[2] Jang, Julian, Alan Fekete, And Paul Greenfield. “Delivering Promises For Web Services Applications Technical Report 605.” (2006).
[3] Jalali, Amin, Petia Wohed, and Chun Ouyang. Aspect oriented business process modelling with precedence. Springer Berlin Heidelberg, 2012.
[4] Bernstein, Philip A., and Eric Newcomer. Principles of transaction processing. Morgan Kaufmann, 2009.
