[Design of JBoss jBPM] - Re: meeting context
by heiko.braun＠jboss.com
anonymous wrote :
| These 3 aspects
| * node pluggability
| * pluggable aspects
| * embeddability
| lead to the design goals of the PVM based approach to jBPM 4.
|
Good point. Let's talk about design goals, but in the context of the upcoming meeting. AFAIK the meeting is about the API and CTS, right?
Then we should put the focus on questions related to that domain. Thomas came up with a list of basic concepts that he would like to see addressed in the API:
- ProcessEngine, Process, ProcessDefinition
- StartEvent (None, Signal, Message)
- Task (None, Send, Receive)
- EndEvent (None, Signal, Message)
- Gateway (Inclusive, Exclusive, Parallel)
- Process, Activity Properties
- Process, Activity Assignments
- Signal, Message
- SequenceFlow
This however is not married to BPMN it merely borrows terminology. Why?
Becasue BPMN terminology is very precise and avoids redundancy.
All of these items do have associated semantics and it should be our first task to make sure everyone has same understanding of what this actually means. This will predict the implementation that follows.
Starting off with the jbpm4 code base and API doesn't work because a successful discussion with all participants requires a certain level of abstraction. We need to talk about what should be there instead of what is possible with the current implementation.
Once we agree on how these basic concepts relate to each other
(and I hardly believe that we manage to so in 3 days) then we could move on to topics that build upon that:
Process dialects
- handling multiple process dialects
- extending process dialect elements
- extending the core engine capabilities
Embeddability
- transactions
- persistence
- security
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180773#4180773
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180773
17 years
[Design of JBoss jBPM] - meeting context
by tom.baeyens＠jboss.com
"heiko.braun(a)jboss.com" wrote :
| Agree, it's API stuff. But I was referring to this
| anonymous wrote :
| | Questions were more about declaring vars, typing them, giving default values etc
| |
| My concern was more about granularity of the discussion. I.e. Thomas reply is more likely what I consider an appropriate level to have a discussion at the team meeting.
| Does that make sense?
In the first couple of years as we build jBPM, we had a lot of "can you do this process construct?" type of questions. We realized that by overwriting the Node's execute method, we could just implement any behaviour we want in plain Java. The focus then quickly shifted to the runtime data structure (the tree of executions). As only that becomes the limiting factor of what kind of process constructs the engine can handle.We also realized that this way, we can implement any process language as it is just a set of process construct implementations.
Next came pluggable aspects. Swimlanes in jPDL don't make sense in BPEL. Even other process languages that include task management (like bonita) have other interpretations of process roles. Correlation sets only make sense in BPEL. So it must be possible to plug these kinds of aspects on top of the core execution data.
And the last factor was the different environments: BPEL runs in an ESB-like environment (based on WSDL services). jPDL runs in any kind of Java environment and wants to bind to different transaction demarcation technology. Pageflow executions must be able to persist themselves in the http session, and so on.
These 3 aspects
* node pluggability
* pluggable aspects
* embeddability
lead to the design goals of the PVM based approach to jBPM 4.
So IMO it makes sense to see if the BPMN constructs can be build on top of the PVM. But I'm pretty confident that is going to be possible. That is not where the challenge is IMO.
We'll be pursuing following process languages:
* jPDL
* BPEL (Bull)
* XPDL (Bull)
* Pageflow (SEAM)
* Thread Control Language (TODO)
* Executing BPMN directly from the STP-BPMN file format could be another potential candidate.
In the context of those target languages, I don't think that a dogmatic adoption of BPMN has the answers. We should look at the executable process parts of BPMN and see to what extend it makes sense to align jPDL with BPMN. Then we should use the BPMN figures in the designer where appropriate.
The real challenge with BPM and the process languages that we target is to identify the common parts and define how we're going to add the process language specific parts. The PVM is focussed on the common parts, but with a clear strategy on how all of those specific process language features can be build on top. In terms of the API, we are currently far enough advanced to see that a common API is possible that is shared between all these process languages.
This means one API for all kinds of workflow.
Another challenge is the impact of persistence. The more you try to hide that aspect, the more it pops up in unexpected places. Over the last years, we found out that the clue has been to align jBPM's persistence with the user's domain model persistence. That is why embeddability is such a crucial part of what we do. By making the embeddability of jBPM easy into a Java project, we make our own market. A real discussion point in this sense could be JPA. As more projects start with non-hibernate based JPA persistence, we loose a big part of our embeddability.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180766#4180766
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180766
17 years
SVN commit error
by Bernd Rücker (camunda)
Hi Tom, hi list.
I just wanted to commit a fix for the context class laoder but get this error:
svn: Commit failed (details follow):
svn: CHECKOUT of '/repos/jbpm/!svn/ver/2136/jbpm3/trunk/modules/core/src/main/java/org/jbpm/graph/def/Action.java': 403 Forbidden (https://svn.jboss.org)
Anybody has an idea what to do? Am I missing any rights?
I am not sure if I already committed something in SVN, in CVS everything worked fine. Username is "camunda".
Thanks
Bernd
17 years
[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by kukeltje
"jbarrez" wrote : (Hijacking the thread again :p)
|
Accepted
"jbarrez" wrote :
| Ronald, is it possible to make a blog post about it or was it for a customer? I'm interested in seeing your approach ... perhaps we can exchange our ideas?
|
working on it, escalating tasks was part of it... not all will be in there since it would become to complex, but it is another nice example that you can do lots of things with jBPM with small amounts of additional code
"jbarrez" wrote :
| eg. we had to create a special actorId 'parser' by using a 'role:assigned_to' string: if the assigned_to it meant that no-one was working on it, else the task is visible to anyone of the role.
Hmm.... we could just use pooled actors (which were group/role names). If you want to discuss this more easily, contact me on aol/msn/skype, is all in my profile
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180746#4180746
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180746
17 years
[Design of JBoss jBPM] - Re: Cancelling a task fires task-end event
by thomas.diesler＠jboss.com
Actually, cancelling needs to be addresses in a much broader and general sense.
The loose term of cancel applies to many scenarios. From what I can see few of which are well defined
* cancelling a process definition
- cascading to process instance or not
- allowing running instances to terminate gracefully or not
* cancelling a process instance
- implicit cancelling through RuntimeException
- explicit cancelling through user exception
- model defined error flow
- model defined compensation flow
* cancelling of single task instance
- general support for multiple task instance
Also, how does an error during signal and message processing affect the process instance i.e. should the process be cancelled or not.
The above is merely a loose collection of related topics without the claim for completeness. The scope of cancel support can be defined for 1-Jan. However, please beware that there are much more basic and urgent topics to be covered.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4180745#4180745
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4180745
17 years
