| RE: [jwt-dev] Unstructered graphs |
Hi Florian, Thanks for your input ! I agree with you that the support of non structured graphs could have a big impact on the engine (we know that quite well :-) and on the tooling as well... so I'm trying to figure it out what is the best way to go to allow on one hand to give freedom to users and to the other hand to have unified tools for both XPDL and BPEL standards... Looking more deeply into JWT I'm well surprised to know that joins and splits are not block based (meaning a join matches exactly with the previous split/fork node). This feature gives a lot of freedom to end users when defining a graph: in a lot of situations multiple splits/forks end up on the same join node (i.e picture in cc) This is a feature that we consider to be in non structured graphs so I'm happy to know that is natively supported. That say, I feel we could imagine to use JWT as it is (structured based with some native flexibility) and so to focus on generic features development and extensibility (contributions) + customization (Bonita and Orchestra). Open Wide folks have already developed an extension allowing to generate XPDL from JWT, could somebody sent us some tips on how to install it ? we would like to start playing with that... My first concern would be to check what are the limitations (if there are) when generating XPDL from a particular JWT definition... On the BPEL flag, key for us as well, I'm really interested on the codegeneration framework you pointed out. Do you feel feasible to change the licence of this framework to EPL ? Related to this, why are you working on a model transformation over STP-IM as another way to generate BPEL from JWT ? is not the codegeneration framework approach good enough ? Shall we easily make a try of this framework on top of the current JWT editor ? I guess the second approach will be similar that the one used for XPDL generation ? Regards, Miguel Valdes BPM Manager Bull, Architect of an Open World TM 1, rue de Provence 38130 Echirolles (France) Direct Line: +33-4-76-29-72-28 Fax: +33-4-76-29-75-18 *Orchestra*, The BPEL open source project: http://orchestra.objectweb.org *Bonita*, The XPDL open source project: http://bonita.objectweb.org This e-mail contains material that is confidential for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -----Message d'origine----- De : jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] De la part de Florian Lautenbacher Envoyé : lundi 7 juillet 2008 11:06 À : 'Java Workflow Toolbox' Objet : AW: [jwt-dev] Unstructered graphs Hi Miguel, thanks for this explanation. Aah, now I understand what non-structured graphs are. You are right, in JWT non-structured graphs are currently not allowed since an action is only allowed to have one ingoing and one outgoing edge. Only control nodes (such as decision node) are allowed to have more than one in- or outgoing edges. Figure 2 of [1] would be much more complicated in JWT (see attachment). You are right, structured graphs make it easier for the workflow modeller, but make it more difficult for workflow engines, code generators, etc. Coming back to the questions Pierre did ask: -a non structured graph is currently not supported. If there is the need, we might think of changing the metamodel, but then the current control nodes are unnecessary and the semantics of the edges must be cleary defined in another way (if two edges are outgoing from an action: are they XOR, OR or AND?). Therefore, I would like to stay with the current representation. But perhaps we can create an own view which allows the definition of unstructured graphs!? This view would allow to have more incoming and outgoing edges on an action and make the control nodes unvisible. But then the change from one view to another will be much more complicated or not possible at all... As you've maybe seen, there is currently a strong discussion about extension of metamodels (also with several views) and last Friday we had a telco where we discussed our ideas and refined them. Perhaps your questions of non-structured graphs might be one of the requirements for this extension/modification of the meta-model!? (@Marc, Chris: what do you think here?) -concerning BPEL: Yes, the use of non-structured graphs makes the generation of BPEL-code much more complicated. Currently, there are (to my knowledge) two approaches for generating BPEL-code from JWT. The first one is using a workflow-codegeneration framework (Sourceforge-project, GPL, [2]), the second one over STP-IM. The workflow-codegeneration framework allows to use any kind of modeling tool (and has already been adapted for JWT) and generates BPEL code using code-templates. These are currently customized to a framework on top of JBoss jBPM, but can easily be adapted. The second one (over STP-IM) uses existing work that generates BPEL-code from a model in the STP Intermediate Model. Hence, a transformation from JWT to STP-IM is needed first and is currently developed in our lab. Probably, we will be able to commit a first version to Eclipse in the following weeks. Hope that answers your questions for the beginning. Best regards, Florian [1] http://www.theserverside.com/tt/articles/article.tss?l=BonitaPart2 [2] http://sf.net/projects/wf-codegen -----Ursprüngliche Nachricht----- Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Miguel Valdes Faura Gesendet: 07 July 2008 09:43 An: 'Java Workflow Toolbox' Betreff: RE: [jwt-dev] Unstructered graphs Hi Florian, I will take this answer as Pierre is currently on vacations and with limited access to email... What we call non structured graphs are graphs in which for instance more than one transition leaves a node (without the need of a split node in between) or in which one node/activity inside a split/join block is connected to another activity which is out of the previous block. Basically non structured graphs give freedom to the graph definition (i.e the jpeg image attached) In the current JWT editor non structured graphs definition are not allowed as the editor checks this constraint. In the following article (focusing on cycles and iterations in Bonita) non structured graphs concept is also explained together with cycles/iterations (in fact in Bonita we call loops or iterations on non structured graphs arbitrary cycles). If we correctly understood, JWT will not allow those cycles/iterations: http://www.theserverside.com/tt/articles/article.tss?l=BonitaPart2 Structured graphs make life easier to editors and workflow engines but add additional complexity to end users IMO. Regards, Miguel Valdes BPM Manager Bull, Architect of an Open World TM 1, rue de Provence 38130 Echirolles (France) Direct Line: +33-4-76-29-72-28 Fax: +33-4-76-29-75-18 *Orchestra*, The BPEL open source project: http://orchestra.objectweb.org *Bonita*, The XPDL open source project: http://bonita.objectweb.org This e-mail contains material that is confidential for the sole use of the intended recipient. Any review, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -----Message d'origine----- De : jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] De la part de Florian Lautenbacher Envoyé : vendredi 4 juillet 2008 17:48 À : 'Java Workflow Toolbox' Objet : AW: [jwt-dev] Unstructered graphs Hi Pierre, in the document (which you provided a link for) I don't find a clear definition and description of the importance of non-structured graphs. In this document only some examples for structured workflows are given as far as I can see (I didn't read it completely, but only parts of it; sorry if I missed the part that you mean!). However, I assume that you mean the difference between block-based and graph-based models? E.g. a typical BPEL-viewer is block-based (contains all kinds of blocks which are nested by each other). On the other side, languages such as BPMN are normally graph-based, so they contain only nodes and edges. So graph-based are non-blocked graphs or non-structured graphs - am I right? Or do you mean something else here? If you mean this, then I don't completely understand your question, because in JWT you normally only model graph-based models (containing nodes and edges, without defining blocks)! I would be happy if you could refine your question, then I'll try to think about how much work needs to be done to support it. Best regards, Florian -----Ursprüngliche Nachricht----- Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Pierre Vigneras Gesendet: 04 July 2008 12:01 An: Java Workflow Toolbox Betreff: [jwt-dev] Unstructered graphs Hi, we are currently analysing JWT and we have the following questions: In XPDL (which is the standard supported by our BPM product called Bonita), graphs can be of different "conformance" class: Non-Blocked, Loop-Blocked and Full-Blocked. Basically, XPDL (and therefore Bonita) supports Non-Blocked graphs, meaning non-stuctured graphs. So questions are: can non-structured graph be designed with JWT? If no, do you plan to support it? How much work has to be done approximately to support it? On the importance of non-structured graph in BPM, please see: http://www.workflowpatterns.com/documentation/documents/Structured.pdf Regards. -- Pierre Vignéras Bull, Architect of an Open World TM *BPM Team*, Bull R&D 1, rue de Provence 38130 Echirolles (France) Direct Line: +33-4-76-29-74-06 *Orchestra*, The BPEL open source project: http://orchestra.objectweb.org *Bonita*, The XPDL open source project: http://bonita.objectweb.org _______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev _______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev
Attachment:
SplitJoin.png
Description: PNG image
