[Design of JBoss jBPM] - Re: meeting context
by kukeltje
hmm.... post got cut off... here is the rest:
...
Which is down right incorrect. The difference in the required java code is one line, so at least the statement should have been the same. Just as with the milestone as I demonstrated in my blog. Second thing is that they evaluated 3.1.4 and we are already on 3.2.3, so the evaluation is even old in that regard.
I dare to say that from the control-flow patterns, almost all (and certainly the most used ones) can be easily implemented. And I (as does Tom I'm sure of that) never said or never had the intention that jPDL should not be extended with out of the box support, with real language constructs so without jBPM providing e.g. delegation classes. In fact, jBPM4 is a great moment to supprt more language constructs, certainly with the addition of you and Thomas to the team (remember, for me it just a hobby!!!)
Besides that, they also evaluated the standards and not even those support all of the patterns...
Nice BPMN related article in this regard is from Michael zur Muehlen on "how much BPMN do you need" [7]. If you take the 80/20 rule into account, I think jBPM did great, almost perfect, not with support of BPMN but the tradeoff for the 'patterns'
To make a long story short... it`s all in all not that bad maybe marketing wise, but we can work on that
Ok, now lets switch to BPMN. Up until a year ago, BPMN was not hot (not sure it is now, maybe it skipped the hype state and is going 'mainstream'). Some real business designers supported it. Besides that, there was no executable language so some other suppliers had converters, most one-way, some (limited) round-trip.
jBPM focussed (focusses) not only on the business designers but also at the people implementing the process (a joint-effort). BPMN was just to much overhead with the limited resources. Ok, the graphical representation could (should?) have been used for those parts that are supported in JPDL, but that should have been it.
The eclipse STP-BPMN desiger which is now becomming available might be interesting. Initially with an export function (although that should yield something really usable in the GPD) and maybe they can grow together and JBoss delivers an STP-BPMN-JPDL designer. Heck maybe even JPDL and XPDL grow closer
[3] http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp13.php
[4] http://www.workflowpatterns.com/patterns/control/multiple_instance/wcp14.php
[5] http://www.workflowpatterns.com/evaluations/index.php
[6] http://www.workflowpatterns.com/evaluations/opensource/jBPM.php
[7] http://www.bpm-research.com/2008/03/03/how-much-bpmn-do-you-need/
Shoot... I should have made this into a blog entry.... maybe I still will.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181071#4181071
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181071
16 years, 4 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
Afaik, but could not find it directly, BPMN is based on structured graphs
Well, we just borrow the terminology (i.e. parallel gateway) and need think about what it means for the implementation. This is exactly the kind discussion I'd like to have.
anonymous wrote :
| In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split:
|
Exactly, hence the need for verification.
They leave it open, we decided to make a choice since it impacted implementation and there have not been real problems regarding this choice
"heiko.braun(a)jboss.com" wrote :
| What you said about previous discussions is something I don't agree with at all:
|
| anonymous wrote :
| | This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-)
| |
|
|
Sorry, this statement was mend solely in the context of the nested fork/join
"heiko.braun(a)jboss.com" wrote :
| Let's put it the other way around: Why do all the vendors support workflowpatterns.com [1] and BPMN [2] opposed to jbpm?
|
| [1] http://www.workflowpatterns.com/vendors/
| [2] http://www.bpmn.org/BPMN_Supporters.htm#current
|
Ahh.....this is an interesting one... A really interesting one.... or even two (separate) interesting ones.
Lets get the facts and history straight on the first one.
[1] is 'old' and for the 'original' patterns. That is not very clear to people who are fairly new to these things.
I remember the discussions I had with Tom about the discussions he had with Prof. van der Aalst (I also personally met him twice on workflow non-related events) about the workflow patterns. jBPM 3.0 (look in the source for the pattern tests) engine wise supports them. JPDL language wise not (but most), at least not with writing some small reusable java classes.
They did not want to evaluate jBPM at that time due to the different views on things. They wanted everything in the 'language' while we said that basic things were supported in the language and less used things were possible in the engine with some small java code. In all these years there has been one pattern users in the forum asked me about (well actually two, but the implementation in jBPM is 98% the same, two multiple-instance patterns [3], and [4]. In the wiki we've described how that can be achieved in jBPM. Nobody complained. In fact, we are even more flexible, since these multiple instances can easily be assigned to different actors. But... I won't complain that they did not evaluate us (users in the forum did not, so who am I). We could have implemented language constructs for them, but it was a trade-off between time and the number of times it was requested. Therefore it was not done.
But.. things have changed a little. First of all, on the evaluation pages [5] of the workflowpatterns, they did evaluate jbpm [6]. With some of the patterns they now explicitly that they are supported with some java code. Regarding [3] they state:
"workflowpatterns.com" wrote :
| jBPM does not support this pattern. There is a proposed implementation in Java of a node-type Node to capture this semantics. As the solution relies on java-coding we consider it outside the capabilities of the proposed jPDL language
|
This has (in our opinion) never been a problem and the extensibility is part of jBPM thourgh JPDL.
Regarding [4] they state
"workflowpatterns.com" wrote :
| jBPM does not support this pattern.
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181067#4181067
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181067
16 years, 4 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"kukeltje" wrote : "heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | | Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
| | |
| |
| | Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
| |
| | - One for building a process model from XML descriptors
| | (Similar to what's in the PVM already)
| | - One for invoking on it (Client API)
| | - One for extending the engine capabilities (i.e. new node types)
| | - One to solve integration problems (TX, persistence, etc)
| |
| |
| +10
| I like the use of jaxb as Thomas is doing. Not fully sure why, but it feels right.
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
| |
| To some extend you are correct, but if you search the net for problems regarding mapping bpmn to bpel or xpdl (improved with bpmn 2.0 and xpdl 2.0) it is not that easy and so they are not independent.
|
Oops, forgot to correct this statement after reading (and answering) the last statement in your previous post.
I tend to agree with your statement, it all came down to terminology again ;-)
Implementing an xml based language is then creating a xml binding and in that re-use or extend the building blocks (core elements, base classes for activities in the pvm) to use the pvm api
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181005#4181005
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181005
16 years, 4 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"heiko.braun(a)jboss.com" wrote : anonymous wrote :
| | Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
| |
|
| Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
|
| - One for building a process model from XML descriptors
| (Similar to what's in the PVM already)
| - One for invoking on it (Client API)
| - One for extending the engine capabilities (i.e. new node types)
| - One to solve integration problems (TX, persistence, etc)
|
|
+10
I like the use of jaxb as Thomas is doing. Not fully sure why, but it feels right.
"heiko.braun(a)jboss.com" wrote :
|
| But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
|
To some extend you are correct, but if you search the net for problems regarding mapping bpmn to bpel or xpdl (improved with bpmn 2.0 and xpdl 2.0) it is not that easy and so they are not independent.
"heiko.braun(a)jboss.com" wrote :
|
| Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently?
|
Afaik, but could not find it directly, BPMN is based on structured graphs so a split requires a corresponding join.
In JPDL 3 it is fully clear, you need a fully nested fork-join pair. This differs from the statement in the workflow patterns for parallel split:
"www.workflowpatterns.com" wrote : These branches may or may not be re-synchronized at some future time.
The number of cases that I've came across in the forum where people did
| fork 1
| / \
| | fork 2
| | / \
| join 1 |
| \ /
| join 2
|
Are rare and could in most cases simply be modeled in another way. The reason jpdl requires this are simple. The implementation of a join is more simple then. This has been discussed several years ago, so unless bpmn requires otherwise, the decision for this is simple I think ;-)
"heiko.braun(a)jboss.com" wrote :
| The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API.
|
It indeed influences the transactions (see the issues with the join in jira) and to a lesser extend threading (it was always stated that jBPM was not a thread-control-engine), therefore the async functionality to leverage e.g. jms
"heiko.braun(a)jboss.com" wrote :
| Why an impact on the API? Because if we chose real parallel execution (open graph, independent path's of execution) then client 'signal' (jBPM3) doesn't make sense anymore. Actually it wouldn't even work because the client will not be in control of execution anymore.
|
For that one parallel gateway you are correct, but again, the fork is not something that I ever signalled from the client api, so no change in that area. For each of the legs in a fork (weren't they called teeth ;-)) there can be wait-states again (activities) that need to be signalled
"heiko.braun(a)jboss.com" wrote :
| I believe that there is a small set of core elements, which are not related to the final PDL that, once we got it right, can be used to assemble concrete engines (jBPM4+jpdl) leveraging building blocks.
|
But those are building blocks behind the scenes, reusable to create a new PDL. Sounds nice, JPDL and e.g. an executable BPMN can leverage both, but that is not related (as you also state above, right?) to the client-api and imo that should be the most stable, simple to use etc...
Great.... I get the feeling we are getting somewhere
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4181003#4181003
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4181003
16 years, 4 months
[Design of JBoss jBPM] - Re: meeting context
by heiko.braun＠jboss.com
anonymous wrote :
| Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
|
Interesting question. Maybe we should elaborate on the question how far the actual PDL influences the design of the API. This will probably reveal that different API's are required:
- One for building a process model from XML descriptors
(Similar to what's in the PVM already)
- One for invoking on it (Client API)
- One for extending the engine capabilities (i.e. new node types)
- One to solve integration problems (TX, persistence, etc)
But to answer your question, I'd say that core elements are not language constructs. They are building blocks that predict core runtime capabilities, independent of the actual PDL.
Let's look at a Parallel Gateway for example. To me, this is a core element. But it's semantics are not clear. Does a parallel split require a subsequent join or can both path of execution end differently? The answer to this question has a technical impact on the implementation (i.e. threading, transactions) and thus an impact on the API.
Why an impact on the API? Because if we chose real parallel execution (open graph, independent path's of execution) then client 'signal' (jBPM3) doesn't make sense anymore. Actually it wouldn't even work because the client will not be in control of execution anymore.
I believe that there is a small set of core elements, which are not related to the final PDL that, once we got it right, can be used to assemble concrete engines (jBPM4+jpdl) leveraging building blocks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180995#4180995
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180995
16 years, 4 months
[Design of JBoss jBPM] - Re: meeting context
by kukeltje
"heiko.braun(a)jboss.com" wrote :
| Let's take a different angle: This is not about the process definition language. (It's going to be pluggable anyway, right?)
|
Ok, maybe we already look at it differently here. Executing process languages is the thing that jBPM (ok PVM) does for you and supporting that should be exposed by the API.
Pluggable yes, but you cannot drop-in replace jpdl for bpel or xpdl :-) and in each of these executable languages you can do things you cannot do with the other.
But instead of going into details, I'll read on first, maybe we agree more than I upfront think ;-)
"heiko.braun(a)jboss.com" wrote :
| Building an API doesn't necessarily mean throwing away what's there, it could as well mean refactoring the existing one.
|
| The API will have core elements and terminology. Each core elements has associated semantics which lead to implementation detail. We want the API to be correct, easy to use and easy to learn.
|
| The process of finding these core elements (or core concepts) and establishing names for them is important to get one step closer to 'correctness'.
|
|
Establishing names... great (read my lips: no-more-mapping).
finding common elements or more complex elements (like different gateways) and use those in jbpm... ehh... jpdl, great, but that is process language. The gateway (decision in jpdl) is not something I've ever used from 'the' api...
Basic things I did do with 'the api' are
- start a process
| - end a process
| - signal process to continue (either via default or supplied transition)
| - set a variable
| - read variable
| - get a tasklist
| - end a task
| - get basic properties of a task/node/.... in a process instance (e.g. task.hasEnded())
| - ...
|
|
| Although... working on tasks is already more complex. In jpdl you can have variables with a task scope, or on the process level. It has to be clear how to do that and should be possible via an api. In howfar this is possible in all process languages I'm not sure, so should this be generic? Or put in a more process language specific api, e.g. on that extends the basic api?
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | The well known list of 'basic concepts', which Thomas suggested, is merely a collection of core elements that will lead to both a meaningful set of API that can represent of large number of use cases to begin with, but at the same time covers critical areas of the engine implementation. At least that's the idea.
| |
|
| You mean language implementation instead of engine implementation right? To me an 'engine' is the implementation of a language on the pvm. Regarding the number of use cases I wonder if this is from a theoretical of practical view. As Bernd points out the flexibility of jBPM/JPDL and the way you can use the current api is one of its usp`s
|
| "heiko.braun(a)jboss.com" wrote :
| | If the list is incomplete or the terminology is somehow misleading then make suggestions how it could be changed.
| |
|
| Terminology is imo certainly not misleading, but the collection of concepts is, well not misleading, but maybe to theoretical, or as mentioned earlier something that belongs in a process language
|
| "heiko.braun(a)jboss.com" wrote :
| | Again this doesn't necessarily mean we ditch the existing jBPM4 code base, it's merely a process of verification.
| |
| | That is what, to a great extend, has been done the last years, hence we are now where we are with the api and language constructs. Verification against real live usecases and not just theoretical usecases (workflow patterns) or a non-excutable, visual definition (bpmn)
|
| That BPMN is eventually becoming more popular, the alignment of BPMN 2.0 with XPDL and a usable (free) editor, the time is now indeed right to leverage it more, but *without* losing the flexibility.
|
| "heiko.braun(a)jboss.com" wrote :
| | If the current code base would already have a precise and 'to the point' API, then we wouldn't need to do it.
| |
|
| The 'current, 3.x' api has grown, and once you know it (it is not hard to learn if you use it) is not to bad. It's not as to the point as it could be but that is something Tom was/is working on for jBPM4 (afaik) before this common api discussion started.
|
| "heiko.braun(a)jboss.com" wrote :
| | Here's how I can picture the meeting:
| | We go through the list of core elements and for each of those we'll first discuss correctness and importance of that element in a BPM world and then secondly match it with jBPM4 elements. Either the BPMN expression is wrong to begin with or unnecessary for jBPM4 (no use case) then we can ditch it right away. But if it turns out to be important then it will either have a representation in jBPM4, just differently named or it requires changes to the code base.
| |
|
| Now I'm kind of lost... you start with saying it is about the api and not the process language, and now it is mostly the language (elements are for me language constructs)
|
| What I think is more important is what we want to do with the (basic) api. Three things (quickly from my head, not complete maybe)
| - work on individual process instances
| | - signalling
| | | - setting properties
| | | - reading properties (
| | | - working on (a set) tasks
| | - getting a tasklist
| | | - ending a task
| | | - setting variables/propperties/...
| | | - advanced things
| | - get a tasknode in a process-definition and create a task on it
| | | - ending specific tasks on other nodes if something happens
| | | - ...
| | |
| |
|
| Why these advanced things? Because up to now you could not do everything in the jpdl language (but also were not limited to it!!!!) but had to write some small (often reusable) javacode to achieve something (see my milestones blog).
|
| Agreeing on a basic api for the first two items will not be hard at all with using BPMN terminology. Extending the language or providing additional node implementations via javacode so more bpmn elements are provided out of the box is also something we can agree on
|
| The third item has a lot to do with the process language. In my milestone example I explicitly create a task from another node. In another upcomming example, I send the other node an event/signal/trigger (yes, we should standardize here ;-)) so it can create the task itself. Probably fits better in BPMN, but are these kinds of events supported? Currently looking into that.
|
| Maybe we should have two api's per 'language', one basic that is common across process/workflow languages and an advanced one specifically for a language. For jpdl, the advanced api can be the jbpm api that is currently there. I'm just not sure though how pageflow, threadcontrol will fit in thebasic api (terminology wise) if that is a goal at all.
|
| "heiko.braun(a)jboss.com" wrote :
| |
| | But we'll start with a small set, and then gradually increase to the API until it is feature complete. In the beginning, the API would not allow you todo everything jBPM4 is currently capable of, but sooner or later it will.
| |
| Two things:
| - Feature complete by the GA release? That is sooner than later.
| - jBPM4 currently is not capable of 'anything' (ok exaggerated a little). The (new(er)!!) api`s are (were?) under development, JPDL4 is under development (maybe new language constructs like support for different gateways out of the box)
|
| Two things I cannot stress enough:
| - backwards compatibility needs to be there....
| - do not underestimate the current flexibility of jBPM (jpdl) and how it is used in other products
|
| Good discussion btw... lets keep it going, maybe the november meeting will be short then and we'll have lots of time to get used to kasteelbier ;-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180991#4180991
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180991
16 years, 4 months