| AW: [jwt-dev] JWT/STP |
Hi, as already announced a while ago, we were working on transformation rules between JWT and STP-IM. The transformations have long been finished, but it took a while to translate the describing document from German in English. You can now find the source code with several examples, the German document describing it and an English summary on Bug #244825 in Eclipse Bugzilla. For those interested I also attached the English summary to this email. Any comments are welcome. Best regards, Florian -----Ursprüngliche Nachricht----- Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Andrea Zoppello Gesendet: 08 July 2008 13:44 An: Java Workflow Toolbox Betreff: Re: [jwt-dev] JWT/STP Sorry just get your response :-) Andrea Andrea Zoppello ha scritto: > Hi Miguel, > > Have you looked at my previous response. > > Hope this help... > > Andrea > Miguel Valdes Faura ha scritto: >> Florian, >> >> Ok, that's what I though, it seems more natural way to generate code >> from JWT. >> >> Adrian, if you have more info on the STP status would be great to >> exchange with you that topic ! >> >> 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é : mardi 8 juillet 2008 11:18 >> À : 'Java Workflow Toolbox' >> Objet : AW: [jwt-dev] JWT/STP >> >> Hi Miguel, >> >> >>>> Does it means that STP guys has already able to generate BPEL or >>>> this will >>>> >> be part of your contribution to STP ? >> >>>> Still in this subject, there is something which is not clear to me, >>>> are >>>> >> there anybody in STP working on the generation of any XML based >> languages for processes from their BPMN editor ? or the intent is >> always to use STP-IM first and the generate ? >> >> I'm not involved in the STP project, but I am following their >> dev-mailing list. To my knowledge they are aiming to use the STP-IM >> to have a pivotal model to generate code from BPMN to BPEL or from >> SCA to JBI or JAX-WS (at least that's also what they say on their >> website [1]). However, they are not aiming to generate XML code in >> e.g. XPDL from their STP-IM. I'm not sure how far they are in >> generating BPEL-code from the STP-IM (maybe Adrian could tell us more >> here?). Right now Juan Cadavid is working on a transformation from >> BPMN to SCA using the STP-IM (as part of the Google Summer of >> Code) as >> far as I know. >> We are only working on a transformation from JWT to STP-IM, but not >> further. >> >> >> Our intent in JWT is to generate code from any JWT model. This means >> normally a direct transformation from JWT to XPDL or to BPEL. >> However, in >> order to integrate better with STP we are also working on this >> transformation from JWT to STP-IM, but our main goal is normally to >> generate code directly. >> >> Best regards, >> >> Florian >> >> [1] http://wiki.eclipse.org/STP_Intermediate_Metamodel >> >> -----Ursprüngliche Nachricht----- >> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] >> Im Auftrag von Miguel Valdes Faura >> Gesendet: 08 July 2008 08:25 >> An: 'Java Workflow Toolbox' >> Betreff: RE: [jwt-dev] Unstructered graphs >> >> Florian >> >> >>> I'm glad to hear that. If you could contribute anything we would of >>> course be happy, or if you'd like us to change some parts we will >>> also try to assist you wherever possible. >>> >> >> Thanks, we have just started playing with JWT so I guess we will >> require some help at the beginning. We will start by getting the >> knowledge of >> JWT: >> views, metamodel, BPMN vs JWT notation, STP-IM, extensions points >> (views + meta-model), XPDL and BPEL generation... (I expect end of >> this month we will have a good knowledge of those points). >> >> As soon as my team has a better view of the whole thing I will set up >> a development plan that I will, for sure, share with JWT community. >> (this statement assumes that no major constraint came out, meaning I >> will play 100% JWT if I see how to support XPDL and BPEL in a unified >> way and using an extensible technology -> same than PVM but at >> designer level). >> >> I would like as well to understand the relationships between JWT and >> STP on the BPM part. >> >> >>> That will need some discussion with the developers, but should be >>> possible. >>> The wf-codegen framework itself includes another sourceforge project >>> (tokenanalysis) which itself is GPL, so both will need to be >>> changed. >> >> Ok, for the moment we will download it and start playing with it. >> Thanks. >> >>> Yes, the codegeneration framework is even a better way to generate >>> BPEL code than using STP-IM. However, we want to be able to >>> integrate more with the current STP projects which is why we develop >>> this transformation (not only to generate BPEL-code, but also >>> JBI-code, or whatever else is currently in development in the >>> STP-project). >>> >> >> Does it means that STP guys has already able to generate BPEL or this >> will be part of your contribution to STP ? >> >> Still in this subject, there is something which is not clear to me, >> are there anybody in STP working on the generation of any XML based >> languages for processes from their BPMN editor ? or the intent is >> always to use STP¨-IM first and the generate ? >> >> >>> Not exactly. The XPDL codegeneration is currently done directly from >>> the JWT model using XSLT transformation sheets and no intermediate >>> layer (such as the STP-IM) is used. >>> >> >> Ok. >> >> Thanks, >> Miguel >> >> 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 16:37 À : >> 'Java >> Workflow Toolbox' >> Objet : AW: [jwt-dev] Unstructered graphs >> >> Hi Miguel, >> >> >>>> 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) >> >> Yes, we don't restrict users to have complete block based structure, >> but to have more freedom in specifying their process models (on the >> other side having more problems during codegeneration, etc.). >> >> >>>> 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). >> >> I'm glad to hear that. If you could contribute anything we would of >> course be happy, or if you'd like us to change some parts we will >> also try to assist you wherever possible. >> >> >>>> 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... >> >> Probably Mickael or Marc can answer best on this. >> >> >>>> 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 ? >> That will need some discussion with the developers, but should be >> possible. >> The wf-codegen framework itself includes another sourceforge project >> (tokenanalysis) which itself is GPL, so both will need to be changed. >> >>>> 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 ? >> Yes, the codegeneration framework is even a better way to generate >> BPEL code than using STP-IM. However, we want to be able to integrate >> more with the current STP projects which is why we develop this >> transformation (not only to generate BPEL-code, but also JBI-code, or >> whatever else is currently in development in the STP-project). >> >> >>>> Shall we easily make a try of this framework on top of the current >>>> JWT >>>> >> editor ? >> >> Yes, there is a good documentation on the sourceforge site how to >> download and install it and how it is internally structured, so you >> should have no problem using this framework. If you have any >> problems, please don't hesitate to contact me. >> >> >>>> I guess the second approach will be similar that the one used for XPDL >>>> >> generation ? >> >> Not exactly. The XPDL codegeneration is currently done directly from >> the JWT >> model using XSLT transformation sheets and no intermediate layer >> (such as >> the STP-IM) is used. >> >> Best regards, >> >> Florian >> >> -----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 >> >> _______________________________________________ >> 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 >> >> _______________________________________________ >> 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 >> >> >> > > -- *Andrea Zoppello* ___________________________________________ <www.spagoworld.org> Spagic Architect ___________________________________________ Architect Research & Innovation Division *Engineering Ingegneria Informatica S.p.A. * Corso Stati Uniti, 23/C - 35127 Padova - Italy Phone: +39-049.8692511 Fax:+39-049.8692566 *www.eng.it www.spagoworld.org* _______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev
Attachment:
JWT2STPIM.pdf
Description: Adobe PDF document