[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: AW: [jwt-dev] Unstructered graphs
|
Hi Marc,
The use of subprocess blocks could be an option to add support for non
structured graphs, we will keep that in mind as we have not yet taken a
decision on that point... but definitely could be an option.
Thanks for the documents on JWT transformations, now we have a more clear
view on how it works, what is already achieved and what could be the next
steps... would be great to start playing with the XPDL transformation and,
from the pointers you gave us, there is no link where download this
extension ? is there any pointers on how to download and install the XPDL
plugin ?
We will start by evaluating this one as well as the codegenerator for BPEL.
Best 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 Marc Dutoo
Envoyé : lundi 7 juillet 2008 18:54
À : Java Workflow Toolbox
Objet : Re: AW: [jwt-dev] Unstructered graphs
Hello Miguel, Florian
Florian, thanks for your many and in depth answers. Right now I'm in
Toulouse showcasing some JWT4SCOrWare niceties to partners so I'm not
much available.
Miguel, nice to see so many thoughtful questions :)
About supporting unstructured graphs i.e. more than one input or output
on Actions,
Florian, Miguel, I think both of you are right when saying that JWT has
right now a good balance between flexibility for the user and support of
different BPM formats, and that it could be used for those by Bonita
users. I think unstructured graphs could still be supported on this
basis, thanks to jwt-views and metamodel extensions ; for example, in
jwt-views could be configured "newChildNode" commands allowing to create
"blocks" of nodes in a pattern-like manner, that would be modelized as
extended metamodel-annotated embedded subprocesses : this would allow to
create in a single click an embedded subprocess containing an Or node
followed by an Action followed by a Split node, while the subprocess
would be displayed using a BPMN XOR icon.
About JWT2XPDL transformation,
In short,
* supported features of the current version are : common node types,
decisions, embedded subprocesses, variables, Bonita hooks
* it has been validated by loading process samples in ProEd and
executing them in Bonita Engine
* it has been developed using XSL on top of the JWT transformation
framework by Guillaume Decarnin of Open Wide (who already did similar
work last summer). He'll be able to answer your more
implementation-related questions.
In depth & limitations,
* look up the detailed transformation spec on the jwt wiki at
http://wiki.eclipse.org/JWT2XPDL (wiki accessible from
http://wiki.eclipse.org/index.php/Java_Workflow_Toolbox_Project , and
from there the link is in the page dedicated to BPM formats
compatibility / jwt-transformations at
http://wiki.eclipse.org/JWT_Transformations). On limitations listed
there, this can be said :
* only project properties and no activity properties, because we're
not sure how they would semantically translate in JWT... an open subject
if there is any.
* full participant support should be able to be supported thanks to
JWT metamodel extensibility**
* full hook support will be easily supported thanks to JWT metamodel
extensibility (it is even a use case requirement, see
*http://wiki.eclipse.org/JWT_Metamodel )*
* supporting iterations and external suprocesses still need some
thinking and work among all of us
Coming next :
* web service calls in Bonita using the SCOrWare Frascati SCA
Framework is developed but not committed, as well as other JWT4SCOrWare
niceties
* taking advantage of JWT metamodel extensions ( to define hooks
properly etc.)
Regards,
Marc
Florian Lautenbacher a écrit :
> 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
