-- mchinosi
Posts
NULL Values in JSON
4 months ago
June 28, 2007
June 27, 2007
Read the comment on Bruce Silver's blog
I posted a comment on Bruce Silver's blog, BPMS Watch.
The article is Diagrams, Models, and Metamodels... Oh My!
Please, read it here
-- mchinosi
The article is Diagrams, Models, and Metamodels... Oh My!
Please, read it here
-- mchinosi
Orange + Apples
Keith Swenson has recently published an interesting question in his blog: Are Apples more useful than Oranges? where he argues that it is not possible to compare BPEL and XPDL because they are two different things (like Apples and Oranges). Besides, it is possible to guess how he leans a bit towards XPDL.
Bruce Silver replied on his blog (quoting and paraphrasing also original Keith's post) with an article (The Real Issues with XPDL, BPEL, and BPMN) in which he says:
In other words, XPDL captures the diagram, while BPEL captures the process semantics. Keith dismisses the latter as just the information an "execution engine" would need to know. Technically that's true of BPEL, I suppose. But which of these best represents the process model? The part that Keith glosses over is a process diagram is not the same as a process model. The argument over whether BPEL or XPDL is more "portable" is based on different interpretations of what portable means. If you mean the same process semantics can be executed on two different engines, then BPEL is more portable. If you mean that the same diagram can be created in two different tools, then XPDL — especially if you allow the target tool to ignore the graphical details that don't carry over.
and
BPMN is a modeling notation — more than just a diagram, since each element has defined process semantics, abstracted from implementation details — but BPMN has no official XML schema, i.e. no interchange format. XPDL 2.0 was explicitly created to capture all the elements of BPMN 1.0 for interchange, but — here's the part that Keith omits — from a diagram portability perspective, not a model portability perspective. That's because OMG (actually this dates back to BPMI) never defined which BPMN elements and attributes, and their associated process semantics, have to be supported by a "compliant" tool.
Finally, in the last two paragraph, he says that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models [...] that is independent of implementation architecture. At this end he underlines the lack of an XML-Schema for BPMN (If OMG does not publish a BPMN schema, I see more consternation in BPM-Land and a second chance for XPDL to get it right).
Keith replied again and then Bruce and, again, Keith and Bruce together through comments (The Diagram IS the Meaning, Diagrams, Models, and Metamodels... Oh My!).
I wish to thank either Keith and Bruce for their discussion because it is very interesting!
Moreover, I'm very happy because their words sound very well for my research! The main goal we would like to achieve is to build an XML-Schema for BPMN! An XML-Schema that should be complete as XPDL and 'executable' as BPEL. It should have a hierarchical structure to reflect a precise data model (which is compliant to the BPMN specifications). From our model it is possible to derive an XPDL (is this an 'Apple'?) file or a BPEL (is this the 'Orange'?) tree. In these cases we will have that either BPEL and XPDL will be subsets of our BPeX. We will have all data provided by the two notations. Apples + Oranges. A stub of our work is available on our project page.
Refresh your summer with a 'fruit salad'!
-- mchinosi
Bruce Silver replied on his blog (quoting and paraphrasing also original Keith's post) with an article (The Real Issues with XPDL, BPEL, and BPMN) in which he says:
In other words, XPDL captures the diagram, while BPEL captures the process semantics. Keith dismisses the latter as just the information an "execution engine" would need to know. Technically that's true of BPEL, I suppose. But which of these best represents the process model? The part that Keith glosses over is a process diagram is not the same as a process model. The argument over whether BPEL or XPDL is more "portable" is based on different interpretations of what portable means. If you mean the same process semantics can be executed on two different engines, then BPEL is more portable. If you mean that the same diagram can be created in two different tools, then XPDL — especially if you allow the target tool to ignore the graphical details that don't carry over.
and
BPMN is a modeling notation — more than just a diagram, since each element has defined process semantics, abstracted from implementation details — but BPMN has no official XML schema, i.e. no interchange format. XPDL 2.0 was explicitly created to capture all the elements of BPMN 1.0 for interchange, but — here's the part that Keith omits — from a diagram portability perspective, not a model portability perspective. That's because OMG (actually this dates back to BPMI) never defined which BPMN elements and attributes, and their associated process semantics, have to be supported by a "compliant" tool.
Finally, in the last two paragraph, he says that neither XPDL nor BPEL today meets the real need of the BPM community, which is a portable serialization of process models [...] that is independent of implementation architecture. At this end he underlines the lack of an XML-Schema for BPMN (If OMG does not publish a BPMN schema, I see more consternation in BPM-Land and a second chance for XPDL to get it right).
Keith replied again and then Bruce and, again, Keith and Bruce together through comments (The Diagram IS the Meaning, Diagrams, Models, and Metamodels... Oh My!).
I wish to thank either Keith and Bruce for their discussion because it is very interesting!
Moreover, I'm very happy because their words sound very well for my research! The main goal we would like to achieve is to build an XML-Schema for BPMN! An XML-Schema that should be complete as XPDL and 'executable' as BPEL. It should have a hierarchical structure to reflect a precise data model (which is compliant to the BPMN specifications). From our model it is possible to derive an XPDL (is this an 'Apple'?) file or a BPEL (is this the 'Orange'?) tree. In these cases we will have that either BPEL and XPDL will be subsets of our BPeX. We will have all data provided by the two notations. Apples + Oranges. A stub of our work is available on our project page.
Refresh your summer with a 'fruit salad'!
-- mchinosi
My new blog
Since all my personal research gurus have a blog, I decided to open my new blog!
Here I aim to publish the results and the steps of my PhD research about BPMN, BPEL, XPDL, and so on.
I and my collegues are developing an Eclipse-based editor to design BPMN diagrams using a structured hierarchical data model as core. It's name is BPeXEd, stands for BPeX Editor.
BPeX is the name we give to our research, as for Business Process eXtensions. We aim to extend formats and specifications adding some solid (should be 'formal'?) backend. This will permit us to provide some useful feature like the validation of the Business Process Diagrams, the serialization in XML formats, the security and privacy support, some metrics, the conjugation of data objects towards a more real format (like DB or XML trees), and so on.
Please, feel free to post your comments about my/our work!
It would be appreciated!
To see more in details our projects and to read some papers about that, please visit our project page on SourceForge.
-- mchinosi
Here I aim to publish the results and the steps of my PhD research about BPMN, BPEL, XPDL, and so on.
I and my collegues are developing an Eclipse-based editor to design BPMN diagrams using a structured hierarchical data model as core. It's name is BPeXEd, stands for BPeX Editor.
BPeX is the name we give to our research, as for Business Process eXtensions. We aim to extend formats and specifications adding some solid (should be 'formal'?) backend. This will permit us to provide some useful feature like the validation of the Business Process Diagrams, the serialization in XML formats, the security and privacy support, some metrics, the conjugation of data objects towards a more real format (like DB or XML trees), and so on.
Please, feel free to post your comments about my/our work!
It would be appreciated!
To see more in details our projects and to read some papers about that, please visit our project page on SourceForge.
-- mchinosi
Subscribe to:
Posts (Atom)
