Introduction
Tony Bear says the BPM-folks are from Venus and the WS-folks from Mars
That exactly summarizes a big division in the BPM industry that might not be obvious. The term BPM-folks refers to the people that focus on process modelling. Their starting point is the analysis of procedures that describe how people and systems work together in an organisation. In the modeller's view, the initial focus is not on technology, but on non-technical business analysts that documents how people and systems work together. For many of BPM projects in that category, automation of the processes is not even considered. The final goal is actually to create more insight in how an organisation works by documenting the core business processes. The pure play BPM products that come from this background aim to ease the automation of software support for such business process descriptions. I'll refer to this camp as the BPM modellers.
The WS-folks refers to the people that focus on creating executable processes. Executable processes are software artifacts that serve as input for Business Process Management Systems (BPMS). Executable processes usually have graphical diagram representation. Currently, there is only one executable process language with adoption by big vendors and that is BPEL. BPEL is based on WS-* standards, that's why the people focussed on automation are termed WS-folks above. Service orchestration recently got a boost with the growing consensus around BPEL. I'll refer to this camp as the orchestration developers.
The thing that both movements have in common is the focus on a graphical diagram and inclusion of wait states. The diagram is an important instrument for both the BPM modellers and the orchestration developers. Diagrams have the ability to provide a very quick overview of a certain process. While this is a powerful instrument, be careful with that perceived simplicity. As diagrams that might look similar can have a very different meaning depending of the notation or of the underlying executable process language. Also the purpose of a diagram is a very important consideration. In case of the business analyst, the purpose of a process diagram is to help the explanation to another human. They help to bring the overview across and some level of vagueness is allowed. In case of the executable process languages, the diagrams are part of a process that specifies how a computer system must behave. So those types of processes are exact and have a very precise interpretation.
Inclusion of wait states is more technical in nature, but it is also found in both movements. If a business analyst draws a business process, different activities might relate to different resources. Some activities might translate into tasks for human people and other activities might translate into a piece of software that is executed on a computer system. When such a process is automated, the process engine drives the execution. This means that the engine internally might execute some of the activities automatically. Otherwise, in case the activity is performed outside the scope of the process engine, the process engine will need to keep track of the current state and wait until a signal is received from the external entity. For example, such an external trigger might be a user that clicks a button in a web application to indicate that a certain task is completed. Similarly, an ERP system might notify the process engine that the processing of a certain invoice is completed. The concept of wait states might seem a bit abstract and you might wonder why this is relevant in a discussion about workflow or process languages. It is an important aspect because traditional programming languages like Java don't have support for persistable wait states.
This article arguments that the gap between the analysis and the implementation of business processes is far bigger then the marketing of today's workflow tools might suggest. Also it will propose a much more realistic way of dealing with this situation. The current standards and initiatives will be explained with enough depth so that you can see how they relate to the movements and why. In the discussions, I'll identify the strengths and weaknesses of each discussed technology and describe the proper and improper ways of using them.
At the end, a new type of workflow technology is introduced called process component model. This type of framework can handle multiple process languages and it can support process languages that better support the transition from analysis process diagrams to executable processes.
WS-BPEL
What is BPEL
WS-BPEL is an OASIS standard for service orchestration. Service orchestration means scripting a new service as a function of other services.
Here's the anatomy of a BPEL process in a nutshell: Deploying a BPEL process results in a service being published for that process. The BPEL process specifies what service must be published and it also specifies the implementation of those service operations.
Next we'll explain the most typical BPEL activities to present a good picture of the essence of BPEL in the context of the process shown in Figure 1. Each receive in a BPEL process corresponds to a service operation that is published when the process is deployed. The top receive activity receiveOrder acts as the starting point for new process executions. So when the customer invokes the order operation on the left. That causes a new process execution to start by leaving the initial receive activity.
The subsequent step is an invoke. An invoke will call another WSDL service and collect the response message in a process variable. In our case, the getQuote service operation is invoked on the supplier's service.
Information from incoming messages can be stored in process variables. The whole message can be stored, XML snippets or XSD basic types. An assign activity like the extractProductName can fetch pieces from one variable, which is typically XML based content, and store it in another variable. The variables can then be used to compose messages for other invocations or for the response message to the current receive request.
The receive activity receiveQuote will cause the process execution to wait until the supplier invokes the submitQuote service operation. The service with the submitQuote operation is also published during deployment of the BPEL process. When the supplier sends in a quote related to this order, the process execution will continue and leave the receiveQuote activity.
The reply activity composes a response message for the current outstanding service request. So a reply only makes sense if a receive received a message before in a service operation that has an IN-OUT message exchange.
Note that when the supplier invokes the submitQuote operation, the incoming message must trigger the process execution to continue by leaving the receive activity. This shows another feature of BPEL called correlation. In a BPEL process, correlation means the matching of incoming service request messages with existing process executions that are waiting for such an incoming message. If a receive node is marked as initiating, incoming messages on such operation will lead to the creation of a new process execution. Typically some data item in the incoming document will then be identified as a unique correlator id like for example an order ID. Incoming messages for receive nodes later in the process can then be correlated to the proper process execution based on the order ID that will be somewhere in that incoming message document. In reality, correlation sets can be composed of many individual sets of many properties, but that extra complexity is left our for clarity.
Partner links identify external parties with which the BPEL process is able to communicate. Both service invocations from the BPEL process to a partner and invocations by a partner to the BPEL process are associated with partner links. Both these directions are called roles. Each role corresponds with a port type that identifies the interface for communicating in that direction over the partnerlink. So a partnerlink can declare two roles and it needs an indication of which of the two roles represents the BPEL process side. The service that corresponds to the BPEL process role of a partnerlink is the one that will be published during deployment of a process. The other role will be used in service invocations.
This concludes the most essential parts of BPEL. Other parts like compensation handling, event handling, concurrent paths of execution and timers are more advanced features of BPEL are not included because they are less relevant for the further discussion.
Thoughts and comments on BPEL
Let's zoom in on the control flow of the process above. The combination of these 3 service invocations reveals one of the key motivations for the BPEL language, namely the easy handling of asynchronous service interactions. The client software on the customer side will send the request message and then blocks until the response message for that service invocation is received. This is called an IN-OUT message exchange pattern. In case the service binding uses SOAP over HTTP, this means that the http request should block until the response can be send over the same TPC/IP connection. While on the other side, the process itself needs to wait until the supplier performs the submitQuote callback.
All of this makes great sense in an Enterprise Service Bus (ESB) environment. The idea of an ESB is that many components can connect in a standardized way and then communicate over the bus with any other component. Standardized (usually WSDL/XML based) messages are exchanged on that bus. Then a set of adapters act as gateways between a protocol like e.g. SOAP over HTTP, email, FTP, RMI on the one hand and the message bus on the other hand.
WS-BPEL is also based on WSDL, which binds naturally to XML based technologies like web services.
Also enterprise applications can be connected to the service bus. Once everything is available on the bus as a service, then BPEL makes much sense as it is also based on WSDL, just like interaction with ESB's is also based on WSDL. So the ESB is the ideal habitat for a BPEL engine.
ESB's are mostly focused on exchanging XML based messages between XML based services. BPEL never leaves the XML document level. Typically XPath is used to cut and paste pieces of an incoming document and store it in a process variable. The invoked services, the exposed services and the process variables are all based on XML. The execution logic is directly expressed in the XML world. This is an advantage in the sense that no translation needs to be done between information structured as XML and e.g. objects in a programming language. For complex document and object structures, such translations are never transparent or automatic and hence they require development effort and runtime performance.
BPEL's sophisticated correlation capabilities make it easy to leverage existing message exchanges without any modifications. There is no need for process execution ids to be propagated in the message or in context headers. Instead, a BPEL engine does correlation based on any piece of information in the content of the exchanged documents. The way that the actual data items are identified in each document exchange and how they have to match with other document exchanges is very flexible. This is good because in many integration scenarios like e.g. a communication protocol, where you don't have control over the documents being exchanged.
But where does the association with Business Process Management (BPM) come from? From the viewpoint of the BPM modellers, the association is problematic. The only real link I could find was based on good marketing rather then features. For BPM modellers, BPEL seriously lacks a couple of fundamental features. But BPEL (even without extensions) is very complete when it is used to script new services in an ESB environment where you have no control over the partners with whom you exchange documents. So just like with a Maserati versus a Hummer, the appreciation heavily depends on the use case.
The only association that I could find is that a BPEL process can be shown as a diagram and that the language has support for wait states. This means that some processes models created by business analysts can be turned into BPEL processes. But there are 2 major limitations to this approach. First, the business analyst is supposed to be non-technical. So the chance that the activities in the analysis model correspond to available web services is very small (read: non existent). The second problem is that BPEL is block structured. Analysis models are typically graph based. So usually, it's not possible to keep the analyst's analysis diagram in tact when translating into a BPEL executable process. This is exactly why the mapping BPMN to BPEL is hard and has so many limitations.
The most prominent contradiction for using BPEL for BPM is that analysts supposed to be non-technical and that the activities in a BPEL process boil down to web service invocations. Also, the block structured nature of a BPEL process is too limited for modelling purposes. Analysts need the freedom to draw boxes and arrows, which always leads to graph structures and arbitrary cycles. A BPEL process doesn't have a notion of transitions. Instead, a BPEL process is a composite structure, where the top-level activity is e.g. a sequence. The sequence will contain a nested list of activities. Some of those will be basic (or atomic) activities and some will be complex activities, containing again a nested list of activities. With good tooling, this top down activities can be very handy to create a BPEL process. But mapping an analysis model to a BPEL process is something very different and that is often hard to say the least.
Another problematic aspect of using BPEL for BPM is the limited data manipulation capabilities. Extracting pieces of content from an XML document is most of what you need in service orchestration. But for BPM, often a lot of data processing needs to be done in between steps of the process. XPath and other XML based transformation technologies are simply not enough.
If you as an architect consider using BPEL for BPM, a question you should ask yourself is whether you want your core business process data in the ESB. The IT industry moved from stored procedures to enterprise technologies like JEE to enable easier management of building new applications where the data is in 'the cloud'. The data that the BPEL engine needs to maintain relates to the domain models like customers, clients, suppliers, products and so on. This domain data is usually stored in relational databases in your IT infrastructure. The information in your core business processes must be easily linked to the domain information in the relational databases. What if your Java application needs to know the client reference of a document? Do you want to ask that document as a process variable to the BPEL engine and then extract the reference with XPath from that XML document? The clue is that such information should be included in the domain model in a database. Not inside the BPEL engine. BPEL doesn't prevent that kind of information to be stored in the domain model database, but it makes it harder. You might have to implement a special web service to get the customer reference stored in the domain model. So BPEL seems to make it easy to get your domain model information partitioned. Be careful with that.
David's 'Case against BPEL', Joe McKendrick's story on David Chappell's blog and Jeff Davis's "What's wrong with BPEL", make similar points that BPEL is not well suited for BPM.
Don't get me wrong. This is not BPEL bashing. My opinion on BPEL is that it's a good technology for scripting new services as a function of other services. But that it doesn't deliver on its promises for BPM, for which it is currently known.
BPEL extensions
BPEL4People specifies how human tasks can be included in a BPEL process. BPEL4People uses the BPEL extension mechanism to add human tasks as activities to a BPEL process. The specification defines a message exchange protocol between the BPEL engine and a task component. BPEL4People introduces the notion of a people link. Task assignment is the selection of a person or group that will be responsible for a task. BPEL4People specifies how people or groups can be described. But both the runtime evaluation of the selection as well as the structure of the identity information is outside the scope of the specification. Recently, the companies behind BPEL4People decided to submit the specification to OASIS for standardization. So it can be expected that in the near future BPEL4People will be found in most BPEL implementations.
BPEL4People is often seen as the fix to add workflow capabilities to BPEL and thereby making make BPEL a better fit for BPM. This is not really the case. When an analyst models activities, they will boil down to human tasks or processing a system. BPEL still forces that the communication between those activities is done through XML based process variables. If a developer needs to add a translation with XSLT, this is a new activity that still pops up in the diagram, even in case the business analyst is not interested in that technical detail. The layout of the graphical activities in the diagram of a BPEL process still remains too tightly coupled with web services and XML technologies to keep the analysis diagram in tact while making the process executable.
BPELJ is an old white paper, which is a proposal for standardization for binding Java to a BPEL process. This covers multiple aspects like including snippets of Java into a BPEL process, Java objects as variables and invoking Java beans from a BPEL process. JSR 207 Process Definition for Java in the JCP is an attempt to form this into a Java standard. But since 2003, no apparent movement has been noted around this effort.
Even with these extensions, the main problem with BPEL remains. When it is used for business process management, it doesn't properly support the modelling aspect. Business analysts are not free in their modelling because the diagram has a direct and fixed relation with WSDL services. BPM needs a decoupling between the diagram and the technics underneath. The analyst must be able to draw the diagram in all freedom. And that developer must be able to embed the process execution in the application architecture without touching the diagram. That is simply impossible with BPEL. Does that mean that BPEL is bad? No. If BPEL is used as an integration technology to build coarse-grained services out of smaller grained services, it has all the features you might need.
BPMN
What is BPMN
BPMN is currently adopted as a modelling notation. It defines the looks of the boxes and arrows that can be used to do process modelling. There were and are quite some discussions on whether BPMN should define execution semantics or whether it should only concentrate on the graphical representations.
The specification contains the graphical shapes, descriptions of the meaning and a set of properties for each construct. BPMN envisions mappings that explain how the BPMN constructs and properties map to specific executable process languages. The specification itself contains one such mapping between BPMN and BPEL. BPMN doesn't define an xml or other file format. One of the possibilities is that BPDM (see below) will define such a file format in the future. First I'll give more background in the difference between analysis processes and executable processes before giving thoughts and opinions on BPMN.
Analysis versus execution
When someone draws a diagram with boxes and arrows, this diagram can represent many different things:
- Documentation, explaining to other people how people and systems work together to accomplish a certain goal.
- An executable process, explaining to a computer system how to behave, just like any other pieces of software
- A state machine associated with a software technical artifact like e.g. a Java class, which is maybe unrelated to any business process.
- A communication protocol, describing the exchange of messages between multiple parties.
- A set of pages in a web application, where the arrows represent the navigation options.
Let's look a bit closer to two of these purposes for diagrams: the diagram for analysis and the diagram for an executable process. Firstly, business level people do not consider system boundaries. For the automated blocks of an analysis process, the analyst typically does not yet know how or on which system it will be executed. Secondly, when an analyst documents a business process, the purpose is to explain how people and systems work together to another person. A diagram can then help as a part of the description to give an instant overview. The process description can assume that the reader is aware of the context in which the process is explained. Therefore, the level of detail in the process description can vary.
That is a big difference with an executable process, which is input for a Business Process Management System (BPMS). An executable process defines exactly how the BPMS should behave. In that respect, it is plain software and the only difference with a programming language is the actual language. So an executable process language explains to a system what it should do.
When automating business processes, the link between the analysis and executable process comes from the common requirement that a computer system should keep track of the progress of all the activities in a business process. For that to happen, the system managing that information needs to be informed of the completion of activities. The system might be able to perform some of the activities itself, so called automatic activities.
Even today, a lot of the BPM system marketing goes like this: "Let your business analyst draw how the business process works and that description will run on our BPMS." Which manager would want to put a non-technical business analyst's description into production?! The opportunity of BPM systems lies in the fact that the analysis diagram of a business process can look very similar to the diagram of the executable business process. The diagram improves communication between analyst and developer, but the developer still remains responsible for all the technical details that are a part of the executable process.
When an analyst's diagram is used as the basis for an executable process, the diagram might have to change if the executable process language is not flexible enough to decouple the diagram from the technical aspects. For example, if input needs to be collected from a person and then a piece of Java code needs to be executed with that information as input, the business analyst might model this as two consecutive activities. But if this process is then made executable with BPEL, an assign might have to be added in between to transform the user supplied data into the proper format expected by the Java code. This shows that in general, a transformation is needed when using an analysis process as the basis for an executable process.
Another aspect that I want to highlight here is that process languages can vary significantly in complexity and scope. Some process languages are limited and for a specific purpose. Again, a language for approvals in a document management system is a good example. Such languages can be very simple and don't require a lot of technical details. The diagram is a big part of the process and non-technical people could actually build a full executable process this way. But for general-purpose process languages like BPEL or jPDL, things are different. Those have a much broader scope and therefore those languages are more complex and allow for much more technical details. In those cases, a developer is always needed to manage the technical details.
Process development process
With this in mind, I want to sketch a more realistic version of the analysis and development process for automating business processes. First, an analyst creates a description of the business process including a diagram. Then the translation needs to occur to the executable process language. The impact of that translation will depend on the analyst's technical skills and the capabilities of the executable process language. In any case, the goal is to have a minimal impact on the diagram so that the business analyst recognizes and understands the diagram of the executable process. Note that the diagram is only the tip of the iceberg, because a lot of technical details might be included in the executable process that are of no interest to the analyst. After the translation, the executable process is software, and therefore the non-technical business analyst is only allowed to see it in read-only mode.
The great advantage that BPM brings here is that analyst and developers are given a common language. The diagram helps to speed up the communication between business analysts and developer. This indeed creates the 'agility' that is credited to BPM. But the illusion that business analysts can just edit diagrams and press the 'Publish to production' button is optimistic and unrealistic.
Modelling details
This section is an argumentation for not using too many details in the graphical diagram notation when a direct link is pursued between the analysis diagram and the executable process. People of different background participated to BPMN. When people only see either the analysis modelling or the executable process side of BPM, they're bound for some surprises like Frank McCabe reports from an OMG meeting: There is something of a fracas about the relationship between BPMN and BPDM: is BPMN 'only' a notation or does it have some semantics. This whole thing was news to the BPMN team as they (including me) were blithely assuming that we were trying to define a language. For us, the major issues seem to revolve around the execution semantics of a BPMN diagram; for others, it is only a diagram notation and we needn't worry our little heads about execution. One might guess where that went!
This shows that expert modellers want a very precise notation to put a lot of information in the diagram. As an analysis language to help with the documentation of a business process, I think that BPMN is a very good option. David Chappell advocates that portability at the modelling level is at least equally important then portability on the implementation (executable processes) level: Think about the goals we're trying to achieve. Portability of process logic, the ability to move implementations from one platform to another, is certainly one of them. But portability of people, allowing us to move our skills from one process design tool to another, is also important. BPEL can potentially help with the first goal, but it's not appropriate for the second; the majority of people who create processes will never work directly in this complex XML-based language. ... The emerging standard for specifying processes graphically is the Business Process Modelling Notation (BPMN). If BPMN becomes widely supported, as seems possible, it will make people's process design skills portable.
This leads me to the conclusion that if process modelling is bound to executable processes, the graphical representation of the process should not contain too much information. When using BPMN for process modelling in your organisation, it might be good to introduce a subset of the more basic constructs and only use those. Cause trying to express too much detail in the graphical diagram requires that everyone understands them. The finer details are used in the graphical notation, the less chance there is that they match with the executable language. The complexity of the finer details of the BPMN notation should not be underestimated and only be reserved for usage in large teams of business analysts where there is no direct link with executable processes.
So I think that process languages (executable and non executable) differ too significantly to unify them in 1 graphical process designer based on BPMN. I do think that for each process language, a BPMN subset can be defined that matches well with that language. The designer tool should support the specific structures of the language and the appropriate finer details directly. I envision tooling where one designer can switch personality between different process languages. But in each case, it will be clear for the user in which language a process is being modelled and developed. Also plain BPMN, used as a non-executable analysis language, is one of those separate languages. Between the languages, the tooling can help with proposing a transformation, but each time this will be a lossy, one-way transformation.
Mappings and mismatches
The mapping approach of BPMN has lead to the mistake of round tripping. The idea of round tripping is the continuous switching between the BPMN analysis model and the executable process. The business analyst works in a modelling language like BPMN, using the graphical notation and the BPMN properties and the developer works in an executable language like BPEL. The problem with this approach is that in practice, it turns out to be way too hard to maintain 2 sets of properties. Even if some of the properties are shared between both views, still, this makes it harder for the business analyst and the developer to communicate as a single property might have a different BPMN property name then its BPEL counterpart. Another problem is that it's hard for tool vendors to create a loss-less round trip.
Since BPMN and BPEL are becoming the most mentioned BPM technologies, let's zoom in on the mapping between them. The first and foremost problem is the structure mismatch between both languages. BPMN is graph based, where as BPEL has a composite structure without transitions that corresponds to a tree. Secondly, the concurrency models differ substantially. Bruce Silver sums it up nicely: how to keep process models (e.g. BPMN) and their BPMS implementations (e.g. BPEL) in sync, what we call the round-tripping problem ... If you've been following this thread on BPMS Watch, you'll remember that BPMN lets you draw things that don't map quite so easily to BPEL - or at least the kind of BPEL you'd want to edit and maintain, but there are subsets of BPMN diagrams that can be mapped automatically. If you control the BPMN tool, you can solve the problem by not letting the user draw something that can't map easily to BPEL.
Other BPM technologies
XPDL
XPDL is the effort of the Workflow Management Coalition (WfMC) to unite the BPM modellers behind one standard since 1993. This standard focuses on an XML format to store and exchange process models. XPDL processes are graph based, which means that their more suitable for business analysts then the BPEL tree structure. An XPDL process also includes the graphical information such as the coordinates of the activities in a process diagram. This is handy when exchanging process models between the process modeller and e.g. a simulation tool. XPDL includes task management capabilities including swimlanes. The process language doesn't define exact execution semantics for the different activities like BPEL does.
John Pyke and Keith Swenson keep stressing that XPDL doesn't compete with BPEL. Instead, they point out that XPDL is the file exchange format. In that goal, they might be surpassed by the upcoming BPDM, if that ever sees the light of day.
In contrast to BPEL, which is based on WSDL, XPDL is technology neutral. This means that XPDL has a separate level of indirection introduced to address so-called 'applications'. XPDL 2.0 is explicitly designed to fit with BPMN. By nature, XPDL is graph based, so it fits with BPMN much better. And in XPDL 2.0, the specification makes sure that all the BPMN properties can be matched in XPDL. XPDL is definitely a better match with BPMN then BPEL. But the big differentiator between the XPDL/BPMN tandem and BPEL is the precise execution semantics.
BPDM
Although BPDM is not new, it is still being discussed internally without an official release. Mostly, BPDM should include a model for expressing business processes and a file format. Since both BPMN and BPDM are at OMG, it might become a replacement for XPDL as an exchange file format in the future. Not much has been published yet on this initiative. Fred Cummins describes the high level goals of BPDM: The specification provides an underlying model representation for BPMN graphics. This means that BPMN process models will have a standard representation for exchange between modelling tools based on XMI (XML for Model Interchange). The specification provides formal representations for both orchestration processes (those that are performed as prescribed) and choreography (the specification of exchanges between independent processes as in a Web services exchange).
Keith Swenson goes defensive as BPDM might replace the hard work that has been put into XPDL for the last decade and a half. And Sandy Kemsley reports about a presentation of Fred.
jPDL
jPDL is in fact not a standard, but it is an executable language that we have created as part of the JBoss jBPM project. Note that previously, jBPM was known only for the jPDL language, where now jBPM is a platform for process languages and jPDL is one of the supported languages. The goals of this language are to be an executable language that allows for a clean decoupling between the diagram and the technical details. The technical details are focused on the Java platform.
As we saw above, BPMN is good for analysts, but it isn't executable. BPEL is executable, but it's not suited for supporting BPM. So the tandem BPMN/BPEL is in my opinion still a very clumsy approach to BPM cause they don't match very well.
jPDL on the other hand is an executable process language that puts the focus on modelling freedom. First of all, it's graph based. Second, there are a number of features that enable more decoupling between the process diagram and the technical details. For instance, in jPDL, it's possible to include pieces of Java code hidden from the diagram. This is called actions. Another feature in that category is the possibility of referring to custom Java code for the runtime behaviour of nodes. That way, the developer can freely code the special behaviour that the business analyst wants in a certain graphical node of the process.
Also this language doesn't try to unify the analysis model and the executable process model, but the features discussed above make it much easier to support the software development process outlined in section Analysis versus execution. jPDL has got significant adoption in the Java community.
Choreography
ebXML & WS-CDL are choreography standardization efforts. John Reynolds describes the difference between orchestration and choreography like this:
Orchestration == Executeable Process
Web Service Orchestration relates to the execution of specific business processes. WS-BPEL is a language for defining processes that can be executed on an orchestration engine.
Choreography == Multi-party Collaboration
Web Service Choreography relates to describing externally observable interactions between web services. WS-CDL is a language for describing multi-party contracts and is somewhat like an extension of WSDL: WSDL describes web services interfaces, WS-CDL describes collaborations between web services.
Orchestration is an executable process, where choreography is used to specify multi-party collaboration protocols. So BPEL is an orchestration language. It means that a BPEL process can be executed on a system. Since a choreography process defines how multiple parties collaborate together, a choreography process itself cannot be deployed directly. Instead, a projection has to be taken for one of the participants. Then that projection can be an executable process.
Given the situation in the executable process language market as sketched in the rest of this article. There are not many solid foundations for orchestration languages to build upon. That is in my opinion the most important reason why this type of languages is still marginal.
Process component models
What are process component models
The two technologies that have a process component model are Microsoft's Workflow Foundation (WF) and JBoss jBPM. The foundations of jBPM are documented in The Process Virtual Machine and there are many similarities with the approach taken by MS's workflow foundation.
The idea is that activities in a process graph are linked to a component that implements the runtime behaviour of that activity in a general purpose programming language. Each activity type in a process language corresponds to one implementation component. For example a web service invocation activity, a human task activity or an email activity all correspond to an implementation component.
The novelty of this approach is that a common base layer is extracted from the BPM and workflow technologies. Workflow Foundation nor the Process Virtual Machine can be considered as BPM technologies. Instead, they both provide a common base framework that can be extended to form fully fledged BPM and workflow products. Or as David Chappell formulates it in this MSDN article:
By implementing workflow as a part of Microsoft .NET Framework 3.0, this approach to creating software will be available for any Windows application that needs it. This includes applications running on clients or on servers, as well as applications created by end users, by independent software vendors (ISVs), and by Microsoft itself. Although it will take some time, Windows Workflow Foundation will become the common foundation for workflow in Microsoft products and technologies.
An activity component can define a set of configuration properties. For example, an email activity can have configuration properties for recipient expression, subject and body. This way, the same activity implementation can be configured differently each time it is used.
Implications of this new approach
A first observation is that multiple process languages can be implemented on top of the same activity component framework. Each process language is composed of a number of activity types. For each of those activity types, the runtime behaviour can be implemented in a general programming language like e.g. Java or C#. So an executable process language just becomes a set of activity type implementations. The most important part of such an activity component is the code that implements the runtime behaviour of the process constructs. But also the XML serialization, the designer forms to configure the process construct, persistence and many other aspects can potentially be included in a process construct component.
Because they can support multiple process languages, process component models reduce the importance of the individual process languages. Instead, they let developers select the most appropriate executable process language for each process. This improves the separation of concerns between analysts and developers over a situation where a BPM engine only supports one process language.
Process languages become extensible. If you're using BPEL, jPDL or another language, you can just implement your own activities and add them to that language. It's also possible to only expose a subset of the process language, creating very simple domain specific process languages, for example to specify approvals in a document management system.
In this perspective, we can identify 4 levels of detail, which perfectly fits with a smooth transition from analysis model to executable process model:
- Process graph structure
- Activity type selection (corresponds to the runtime implementation)
- Configuration of the runtime implementation
- Plan B: Custom coding of an activity
So tooling could be envisioned that takes the collaboration between process analysts and process developers to the next level. An analyst could use a designer tool to specify the graph structure without selecting the activity type of the nodes in the diagram. That would allow to model in complete freedom. The next level of detail is selecting the activity type. For instance specifying that a certain step in the process will be a human task or a web service invocation. This associates the runtime behaviour with the graphical node in the diagram. The next level of detail is the configuration properties. Analysts will probably not know the URL of a web service endpoint. That might be a configuration property on a web service invocation node. And as the last level of detail, special custom runtime behaviour could be coded by a developer as an alternative to selecting an activity type from the used process language. This scheme supports much better the analysis to executable development process as outlined in section Analysis versus execution.
Process component models fit very well with the programming language they're based on. jPDL for example fits very well in a Java project cause it is very easy to include Java code into a process to link e.g. your domain model objects into the process. Similarly, windows workflow state machines allow easy integration of C# code.
Operational management of process engines becomes easier. Many aspects of software development can be modelled in some kind of executable process language. Suppose that in one project you use BPEL for service orchestration, jPDL for managing the tasks for people and pageflow to specify the navigation between pages of a web application. Then the ability to run all of these languages on one single framework is definitely a plus.
Conclusion
BPEL is an executable process language, which is good for integration purposes, but it's not suited for supporting Business Process Management cause of its tight coupling with technical service invocations. BPMN serves the analysts in drawing analysis diagrams, but it's not executable. XPDL is a less adopted file format, which might be superseded by BPDM. The gap between analysis languages and executable languages still remains too big to be practical.
In order to create a more realistic approach to BPM for widespread adoption, we need to start by making a better distinction between analysis process models and executable process models. Once we abandon the idea that non-technical business analysts can draw production-ready software in diagrams, we can come to a much more realistic and practical approach to business process management.
When linking an analysis process model with an executable process implementation, the clue is not to include too many of the sophisticated details of the analysis process notation in the diagram. By using only the intersection of what the analysis language and the executable process language offers, a common language can be created for the business analyst and the developers, based on one single diagram.
Different environments and different functional requirements require different executable process languages. The current idea that one process language would be able to cover all forms of BPM, workflow and orchestration is just too ambitious. And if such an effort would succeed, the resulting process language would be way too complex for practical usage.
There is a new approach to workflow technology. Microsoft's workflow foundation and JBoss jBPM's Process Virtual Machine extract the common foundations for runtime process environments. These technologies create a component model so that activity types can be build on top of that common foundation. The foundation defines a runtime environment for the execution of activity components. Each process language is composed of a set of activity types. The runtime behaviour of the activity types can be implemented in a general purpose programming language. An activity becomes a component. Any process languages basically defines a set of activity types. A process language can then be build on top of the process component framework as a set of activity component implementations.
About the Author
Tom Baeyens is founder and lead of JBoss jBPM. He has participated in the expert groups of JSR 207 Process Definition for Java and JSR 208 Java Business Integration. In the blog called Process Developments, Tom shares his passion to find a match between the BPM goals and today's software architectures. He will not rest until all developers have the BPM, workflow and orchestration basics in their repertoire.
