"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#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...