PD4J - Is Process Driven Design the next big thing?

According to the published schedule, the final specification for JSR-207, Process Definition for Java (PD4J), will soon be released.

If you haven’t followed the circus of Web Services standards for the last year or so, you may have missed the significance of PD4J to the Java universe. PD4J will introduce a standardized set of extensions to the J2EE platform that will make it easier to write Business Process (BP) applications.

For those who now work with BPs on a daily basis, this is going to be a godsend, but why should all Java developers take note? The answer lies in the philosophy that is guiding PD4J and the closely related BPEL and BPEL4WS.

PD4J makes it easier to transform business logic into working applications.

Business Analysts are generally not programmers so they express their ideas in terms of graphs and prose. Efforts are underway to standardize this graph notation, most notably the Business Process Management Initiatives’ BPMN which can directly generate BPEL4WS XML notation. These graphs are similar to UML activity graphs in appearance, but they were spawned from a very different mindset. Business Process Managent is inspired by the Pi Calculus, a relatively new way of modelling communication that treats computers and their programs as themselves built from communicating parts.

Howard Smith, the co-char of BPMI, has published a paper that contrasts Business Process Modeling (BPM) with the Object Management Group’s Model Driven Architecture (MDA). In the following quote, Smith is responding to an article by David Frankel entitled “BPM and MDA: The Rise of Model-Driven Enterprise Systems,” published at www.BPTrends.com.

"…when using UML designers have to corrupt the model to better represent processes."

"I say UML is just fine for software engineering, but is a distraction for process engineering. BPM, not UML, provides the required formalism, the process calculi.
Object practitioners respond to BPM by asking how the advantages of object-oriented systems can be realized in the world of processes?
What we face here are two entirely different worldviews, one built on objects as “first-class citizen” and one built on processes as “first-class citizen.” The two do not sit together comfortably, and from a computer science perspective, we are only now learning how to formally represent “objects,” in the world of processes. "

In an earlier blog I confessed that I’ve never been drawn to UML and I believe that Smith has expressed the source of my ambivalence. Much of my career has involved gathering user requirements and developing user interfaces. Both of these activities are heavily dependent on documenting, understanding and implementing processes. UML’s primary concern is the composition of software components; my primary concern is the documentation and implementation of processes. Processes are the first class citizens of my “community”. No wonder I feel like I’ve been using a screwdriver as a hammer.

With the advent of PD4J, the Process will become a first-class citizen of the J2EE community and in the following months we will see a deluge of Process Driven Design tools (following the lead of BEA’s Weblogic Workshop 8.1).

PD4J’s immediate impact will be on the development of Web Services, but I predict that a wider secondary impact will occur. Once Java developers become exposed to Process Driven Design, I think they are going to like it, and I think the paradigm will be applied to many problem domains.

For a good introduction to the various efforts underway, check out Carol McDonald's blog Orchestration, Choreography, Collaboration and Java Technology-based Business Integration.

For more information about Pi Calculus and BPM, follow this link.

Update: See my later thoughts on BPEJ.