What’s Wrong With This Picture - Part 3
Even though I made a point of not identifying the author in print, the creator of Figure 3 in my original What’s Wrong With This Picture post takes me to task for not contacting him discreetly with my correction. Welcome to the blogosphere, my man. Anyway, he posts his own correction, basically repeating my explanation.
But if the guy were really engaged, he would have noticed that images 4, 5, and 6 are also his bogus examples. So to accelerate this thing, let’s just post the answers here so we can move on to more interesting stuff.
Figure 4. Here he uses a compensation end event in one pool to “throw” a compensation caught by a compensation intermediate event in another pool. Can’t do that. In BPMN, different pools are different processes. They only communicate by message flows, not events. You can only throw and catch events within a single pool. In this diagram, for example, an unhappy buyer cannot terminate his own process and throw a compensation to the seller’s process that reverses the charge. Instead he would have to send a message to the seller (and return the goods), and the seller’s process could then throw the compensation and reverse the charge. That’s pretty basic.
Image 5. This essentially repeats all the errors of image 3 (e.g. see here), except within a BPMN “transaction” subprocess (double border). Transaction subprocesses and Cancel events (with the X inside) are kind of problematical in BPMN — BPEL doesn’t have a way to support them, and BPMN already supports business transactions even without them. The BPMN 1.0 spec essentially says “we’re still trying to figure this one out.” So in my BPMN training I’m going to recommend best practice is to avoid transaction subprocess and Cancel events entirely.
But just so you can’t say I’m double-counting the errors of image 3, image 5 throws in for good measure an error on the BPMN link event (arrow symbol inside). Here it’s shown as the start event for the Fulfill subprocess, which is incorrect. You would use a link start event for a subprocess in two cases: 1)as a chained off-page connector, e.g. if the main process after Confirm Availability went to an intermediate link event in a normal flow (i.e. with a sequence flow into it); that means go to the next step on another page of the diagram, which would be shown with a link start event. 2)state-based synchronization, typically used when a downstream activity starts based on completion of an activity in one thread of a parallel flow – if this sounds obscure it’s because, yes it is, but it maps to the “link” activity IBM somehow got into the BPEL spec. Anyway, neither of these applies in Figure 5, and the subprocess should not have the link start, just a regular start event.
Image 6. This one is just weird. I’m not sure if it technically violates the spec or not, but it’s not very helpful in explaining BPMN. Here printing a newspaper is modeled as a transactional subprocess. A message intermediate event from the publisher stops the presses in an exception flow, which then throws a cancel event, which does not compensate anything but just recycles the paper (!). In this example you could throw out the transaction subprocess entirely and replace the cancel event in the main flow with the publisher’s message event, leading to stop the presses (actually implicit already in the exception flow so you don’t even need that step) and then recycle paper. The transaction and cancel — the nominal purpose of this “example” — add zero to the semantics. Just bad teaching.
2 comments September 19th, 2006
