5:24 a.m.
"heiko.braun(a)jboss.com" wrote : 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".
|
BPMN is not a proven concept. Look at the discussions around BPMN 2.0 and you'll see
that the future if far from clear or stable. Second, it is a analysis modelling notation
with focus on the business analyst. For the terminology part, that is not a good basis
for an executable process language.
I agree with Ed's comment later on that BPMN terminology is not a good basis for the
API.
"heiko.braun(a)jboss.com" wrote :
| 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.
|
Adding a runtime interpretation to BPMN modelling constructs is possible. But by doing
that, you would limit the use of BPMN for its original purpose: analysis modelling.
Because when all BPMN constructs have a runtime interpretation, that means that an analyst
can not model freely any more. When he/she draws a certain box, he/she has to be aware of
the implications when this process is being executed on a computer system. Which
eventually will limit BPMN to graphical programming.
It is impossible to create an executable process language so that non tech analylsts can
model in all freedom and which aftwards turns out to produce exactly the right software.
There must be a mapping between analysis and executable process language. The easiest and
most practical way to do this is by introducing a one-way translation between BPMN and
jPDL. That way BPMN can keep its focus on being a modelling notation for non tech
business analysts. And jPDL can keep its focus on being an executable process language
that developers can use to produce the same diagram as the analysis model.
"heiko.braun(a)jboss.com" wrote :
| 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.
The market doesn't have proven concepts that we can just follow and implement. Two
years ago, BPEL was the well accepted standard for BPMN. One year ago, BPMN came into the
picture. So everyone focussed on the impossible BPMN to BPEL mapping. Now, as people
realize BPEL is best suited for service orchestration, BPEL is starting to fade away as a
solution for BPM. Now, the battle for BPMN 2.0 shows that BPMN itself is not a proven
concept.
There is only 1 product in the BPM area that I have great respect for. IDS Scheer's
ARIS. They take the inverse perspective of us. We start from an executable process
language jPDL, and we try to bind it to the analysis world without compromise on the
technical and executable side. IDS Scheer has by far the most advanced modelling
environment, and they only go as far to bind it to implementation details as they can
without compromise on the analysis side.
All initiatives that try to combine both have been proven to be good only in a niche area.
There is no technology that binds the 2 automagically and is able to be more then a niche
product.
@camunda: IDS Scheer has one of the best round tripping support out there. E.g. they can
create graphical diffs of analysis models and calculate the impacted parts in the related
executable process. But I think it does not fit our target. As it takes a huge
development effort. And it also takes a great effort from to user to bind the analysis
and implementation models and keep all of that in sync. I think the latter is only
suitable in the very top range of use cases. I think that with a one-way translation from
analylsis to implementation model, we can serve more then 90% of the use cases.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4166788#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...