[Design of JBoss jBPM] - Re: Defining the API Mission
by estaub
In case it wasn't clear...
My note about the mismatch between BPMN and JPDL was in no way meant to discourage mapping from B to J. I'm going through the same process as Jeff. I was only saying that introducing use of BPMN terms into the execution domain, e.g., as the basis for names in an API, would be a really bad idea.
Re use of GPD... I'm pretty unhappy with GPD. The code base is not very extensible, and is highly dependent on the XML editor codebase.
I went to the talk by the Eclipse BPMN editor guys at EclipseCon, and was very sold on GMF. The BPMN editor is really slick, and easily extensible. People kept complimenting them on this or that feature, and they kept saying things like "well, it wasn't really a requirement, but all we had to do to implement it was write these 5 lines of code, so we just threw it in." High praise for the framework!
After spending some time with the code, I am even more sold. I would very strongly suggest that Koen look at GMF et al again - it's probably grown up a lot since he checked it out the first time.
-Ed
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166729#4166729
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166729
18 years, 1 month
[Design of JBoss jBPM] - Re: Defining the API Mission
by heiko.braun＠jboss.com
anonymous wrote :
| The mismatch in naming of workflow elements is nearly as bad as it can get...
|
I totally agree with this. This was the reason for looking at BPMN in the first place. We wanted to get to "proven concepts" with "established terminology".
And to be honest, following the discussions around BPMN and executable dialects, I still don't see arguments why it can't be done. Please show me examples of BPMN elements that conflict with execution.
IMO it's not necessary to have full BPMN support. We just need those parts that we actually can make executable. If I remember correctly BPMN even defines profiles with different scopes. But I think a 60% BPMN support is still better 100% jPDL, which is, by the way, something we cannot even easily compare at the moment, because jBPM doesn't use common BPM patterns and established terminology to express it's features/capabilities.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166725#4166725
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166725
18 years, 1 month
[Design of JBoss jBPM] - Re: Defining the API Mission
by camunda
Hi guys,
wow, a lot of content (an me beeing to busy to really joing that interesting discussion :-/)...
anonymous wrote : Thats why I don't think we should pursue of making BPMN executable. It creates the false illusion that analysis models automagically can be made executable. That is a false promise that many BPM vendors promote and that gives BPM its bad reputation. We get our recognition from being more modest but honest.
I agree with it. Basically I think making BPMN executable or supporting Round-Tripping and all that is in the state of research. Interesting to keep up, but to early to really go for it. Would be very interesting for a Master Thesis or the like (camunda would volunteer for funding and supervise such a thesis ;-)). But I think, executing BPMN is not really the best try, better generate a execution language out of it.
And for now I would definitely keep the GTD (okay, get rid of some bugs ;-)), the people like jBPM because it is relatively easy.
anonymous wrote : I see no advantage in centering our execution design on BPMN: it imposes extraneous requirements and shreds no light on our particular challenges. I believe we should center it on our experiences with jBPM 3, and take BPMN compatibility as a secondary criterion.
|
Agreed. It should be obvious to center on our experiences with jBPM up to 4...
anonymous wrote :
| I think we should have a (one-way) BPMN to jPDL export functionality in the STP BPMN designer.
|
| That fits right into our vision and strategy. Analysts can then model freely in BPMN. When they're done, they can give that BPMN analysis model as part of the requirements input to the development team. Then the development team can do an export to jPDL and further make the process executable.
|
Agreed. This would be also a very interesting move forward! Very, very interesting!
anonymous wrote : After that, further iterations all happen on the jPDL executable process. The analysts will now still recognize the jPDL diagram. They still can discuss it. But further iterations will not be synchronized back to the original BPMN analysis model. (just like no one would keep their analysis UML class diagrams in sync with the implementation UML diagrams.) Once the tranlation is done to an executable process language, it becomes software is it comes under the control of the development team.
|
anonymous wrote : In fact, in case of UML class diagrams, no-one even thought of automagically synchronizing the analysis class model with the executable classes.
I do not really agree on this. I think, there could be more support than just one way generation. Even with UML there are tools that can at least keep traces between analysis and execution model. You can even set traces between use cases and classes. This can be very helpful if used (there you are right, not used very often).
With BPM I see tools today which can link process landscapes to analysis models, which can link to implementation models. This has a real value.
Supporting a roundtrip or maybe even share a same model (and have analysis and execution as different "views") is a interesting vision. I have the feeling it can be reached somehow, but it is still a stony path. So I wouldn't concentrate on this goal too early or at least with a clear focus on research. Shouldn't hinder the further development of jBPM itself! Again: I (or say we as camunda) would be interested in joining research activity in that field. We are very active in the field of BPMN and currently involved in some activities around it.
Workflow-Patterns: I wouldn't do too much effort in this, I see it a lot in universities, thesis and that stuff, but rarely in real life projects or evaluations.
Another thought: I get the feeling that currently a lot of experiences and thoughts of jBPM are not taken completely into account for some definitions.
Cheers
Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166690#4166690
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166690
18 years, 1 month
[Design of JBoss jBPM] - Re: iCalendar wrapper
by aapthorp
Thought I'd just post a quick update on this...I got a bit side tracked with limitations of various user agents and also seeing what the potential was...
In addition to the basic capabilities to provide task entries (as a .ics) via http and handling task invitations via e-mail I've been playing with CalDav...having written a rather crude CaldDav server on top of jBPM. This allows me to update tasks directly via a calendar agent (e.g. Lightning). So I can mark a task as complete and jBPM fires the transition. This could easily be extended to create standalone tasks in jBPM if I added handling for externally created UIDs.
Having discovered Mozilla Lightning invite attendees window for tasks I've been trying to figure out how to support this...so manual task delegation can be done via the user agent.
The main issue I've had is the different capabilities of various user agents. My main test agents are Lightning, Kontact and Evolution. Lightning has Caldav support but, doesn't handle attachments or task/todo invitations. Kontact doesn't handle Caldav, but does handle attachment and task/todo invitations. Just checking out the latest version of Evolution.
I now to do some refactoring...before I can post something stable.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166560#4166560
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4166560
18 years, 1 month