This post originated from an RSS feed registered with Java Buzz
by Paul Brown.
Original Post: BPEL and the Human Element
Feed Title: mult.ifario.us
Feed URL: http://feeds.feedburner.com/MultifariousCategoryJava
Feed Description: Software. Business. Java. XML. Web Services.
NOTE: This is a thought-in-process, and I'll probably update it a few times.When I talk to people about BPEL, especially those who are already familiar with business process management and workflow platforms, the question of how to involve the human element in processes always comes up. My first response is that it's important not to confuse BPEL with a full-blown BPM or workflow system, and that there are ways to model cleanly and externally model human interaction with a BPEL process.Accounting for the human element is a more difficult question than it's normally given credit for, a question worth answering, and a question whose answer most definitely does not belong as part of the BPEL language.
Anecdotal and Historical Perspective
When we built our first-generation orchestration product in 2002, part of the plan was to include a template process for inbox and work queue interactions. The initial attempt was a two-sided service with a set of SOAP interfaces on one side (for participating in the orchestrated process), a session facade on the other (for building web or client/server front-ends), and a shared persistence model for the work items.This inbox-as-a-service approach satisfies basic use cases, and any practical deployment included integrating JAAS, realm-based security, etc., on top of the baseline implementation, writing some custom queries, and writing some JSPs. This approach tends to lead to chunky implementations, because the internals of the inbox service tends accumulate code as requirements change.The task of assigning work to human participants in a process should not be oversimplified, because some systems have corner (as opposed to just edge) requirements. For example, we designed a one-off system for a customer who needed to allocate ~10^6 time-critical work items per day to ~10^3 remote workers according to a matrix of different criteria, and the system dealt with details like multiple assignment of rapid turn-around items, exclusion locking for in-process items, and maintaining minimum queue fullness constraints. The design and implementation was an interesting exercise, complete with one of the few legitimate uses of row-level locking that I've seen.
Work Item Lifecycle as a Process
If work items are encapsulated in messages, the work item lifecycle can be modeled in BPEL by a process with the same two-sided interface (one for the system, one for the client application) described above. One way to approach this with BPEL and a little extra follows; there are others.The following approach focuses on the the key use case of escalation. Escalation can be passive, for example, "if a request is more than three days old, assign it to the department manager". Escalation can also be active, for example, "a manager can increas
1000
e the priority of a service request". The active aspects are modeled in terms of handlers, and the passive aspects are modeled in terms of handlers. There are three additional requirements:
Basic entities like users and work items need to be encapsulated as types.
The organizational hierarchy needs to be modeled as a set of services with operations like getManagerForEmployee.
The process state persistence model has to support the overlay of standard worklist queries like "get all work items assigned to Frank or Frank's workgroup, ranked by priority and required completion time".
Correlation keys serve as handles to work items, and the queries against the state model will support the client application-facing services. (This is where this approach deviates from being purely BPEL-based.) The primary usefulness of BPEL in this context is in providing a clean specification of the escalation logic and in using the internal state model in place of what would normally be manual maintenance of state and metadata for work items.As a caveat, this shouldn't be undertaken lightly, as there are quite a few details hiding under the covers. For example, all of the organizational hierarchy operations may need a date argument to ensure that assignments are made in a way that respects scheduled vacations, business holidays, work hours, and time zones.
Work Item Lifecycle as an Opaque Service
It is also reasonable to implement work list functionality using an opaque service with a two-sided set of interfaces. This is particularly true if a work list implementation already exists, in which case, there is no good reason to rewrite it, as the various programmatic interfaces can be wrapped in protocols (local or network) and used from within a BPEL process.
Conclusion
Because of the depth of possibilities, I see the detailed specification of work item management as the domain of a specific XML dialect as opposed to a simple add-on to BPEL or simply as an opaque service (modeled in BPEL or not) that is specific to individual implementations or BPM/workflow platforms.
Previous Topic
