AW: [jbpm-dev] BPMcenter interesting links

[Ronald van Kuijk]

Tom Baeyens schreef:
> Check at the bottom of the page.  It says "Last updated: 05/19/05."  :-)
It sais that on the front-page as well, which is clearly more up to 
data. Most likely manual stuff, no CMS
>
> But now seriously:
>
> Workflow patterns is nice background information, but (as many things 
> in BPM) takes a lot of interpretation in order to claim you support it.
>
+1
> So I started with supplying them unit tests on the first workflow 
> pattern and then asking whether they acknowledged the support for this 
> pattern.  They didn't really acknowledge how we supplied just snippets 
> of a unit test and they didn't want to read the semantics that way.  
> Also I felt that they don't consider you to be a real bpm system if 
> you don't have persistence.  For some of the patterns like deferred 
> choice they sayd something like "3 tasks should be offered to 
> participants and when the first participant takes the task..." which 
> implies a lot of infrastructure around the plain control flow.  That's 
> where it became too fuzzy for me.
>
It was to for me (e.g. how the assignment to different actors for the  
Multiple Instances with a Priori Design-Time Knowledge 
<http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp13.php> 
is left in the dark, but when lookin a little more detailed at the data 
and resource patters (talking about vage... some of those are more vage 
than the original controlpatterns) the console of a BPM is seen as an 
integral part of the system (see Cancel Task 
<http://www.workflowpatterns.com/patterns/control/cancellation/wcp19.php>) 
funny... And Tom is right, the ui-stuff (or any interface) needed for a 
lot of those patterns is left in the dark (see my blog entry on 
milestones again where I already mention this)
> I didn't have a new look to their second version of the patterns for 
> which they have claimed to have solved the vagueness critique.
>
The controlflow patterns have been made more clear, the others not 
(yet), but they have a group on google 
<http://groups.google.com/group/workflow-patterns/> now where we can 
participate more openly in discussing the vagueness or our 
implementations/proposal
> In summary: It is good to check jPDL against the patterns and get some 
> inspiration from that.  Probably between the last alpha and the first 
> beta release, that could be a good timing.
Already working on it s, privately , since I want to write a blog entry 
on it, so do not expect to much to soon. In some cases it is fairly 
simple to support more patterns in language constructs (e.g. the NOutOfM 
join) by making one field that is already in the node implementation 
persistent, add it to the xsd as optional and parse it in the JpdlXmlReader
>
> But we should not handle this work as a dogmatic basis.  Then your 
> resulting process language might become too complex.  As some of the 
> patterns (depending on the interpretation) might create unnecessary 
> complexity.
Exactely. We've never been against the patterns (that's why we 
"acknowledge the work on patterns"), it's more a differenct view in how 
they should be supported. e.g. flexibility with some (reusable) javacode 
or strict language constructs. I'm currently thinking on how we can 
combine the two without having to extend the schema (xsd and db) each 
time. That is one of the items of my blogentry (Hmmm..... this jBPM 
thing is costing me more and more of my free-as-in-beer time.... ;-)) 
I'm thinking along the line of pre-packaged actionhandlers which you do 
not have to include in the processdefinition(where you can 'ref-id' 
them, BUT you should be able to override param values from the location 
they are used (currently you cannot do this, only params in the 
declaration are used, so globally)

Btw, I'd like to add a column on 
http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMSupportedPatterns vor 
3.2/3.3 but also see 
http://jbpm.dyndns.org/jbpmwiki/index.php?title=BPMPatterns. This latter 
is a more textual page, but imo does not add that much info (besides the 
"intro's") Any proposal to combine those?

Ronald