Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
AW: [jwt-dev] Problems in using the wf-codegen framework

Hi Miguel,

yes, okay, so let's focus on JDK 1.5 for the future for all plugins. Please
find attached an example process (StandardPalette.workflow, one of the
German example processes) as well as the generated BPEL code
(Standardpalette.bpel).

As you can see, the BPEL code contains several AgilPro-specific parts which
are adapted to the AgilPro integration framework. But, as already mentioned,
the templates can be changed easily to fit also for other process engines.

The block-based image in the paper that you've attached was created with the
Oracle BPEL viewer and is not part of the wf-codegen plugin I'm afraid.

Best regards,

Florian

-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Miguel Valdes Faura
Gesendet: 10 July 2008 11:35
An: 'Java Workflow Toolbox'
Betreff: RE: [jwt-dev] Problems in using the wf-codegen framework

Hi Florian,

>I guess we might change that, but as far as I know JWT WE is also 
>compiled with Java 6.0? Didn't you have some problems here?

I had no problems with JWT WE. I think the 0.4 release was compiled under
jdk 1.5.

I was discussing yesterday with Marc and he is agree to focus on jdk 1.5 in
next versions.

>-did you have specified the path to the implementation.jar?

Yes I did, I correctly configured the framework following the steps
described in the documentation, as you mentioned.

> -the second reason could be that your process is too simple. That's a 
>smallbug which we need to fix in the next version: if your process only 
>consists of one action, then the transformation does not start (because 
>there is actually nothing to transform), but this results then in a 
>file with the content "null".

That's what I though at first but I've tried with a more complex example and
got the same issue. Could you provide us a sample JWT definition that you
successfully managed to transform to BPEL ? that way we will check whether
it was a configuration/installation issues or a definition one.

Thanks in advance.

>The codegeneration does not create a visible output of the graph in 
>block-structure, but you can easily open the resulting bpel-file in a 
>bpel-viewer to see the block-structure.

Here attached the document were I found the information about graphical
transformation, I guess this should be an JWT editor extension right ?

>Concerning the BPEL import operation: in principle this should be 
>feasible, but probably the BPEL actions might be separated and only 
>some of them taken into the process model (one won't need all the 
>assign actions, but probably only invoke or receive's). Building the 
>BPEL-structure with the JWT constructs should not be a problem at all 
>for the main constructs (switch,flow, etc.), maybe only the links in 
>BPEL might make it a little bit difficult.

I see, this is something we would like to investigate. Thanks.

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é : jeudi 10 juillet 2008 09:32 À : 'Java
Workflow Toolbox'
Objet : AW: [jwt-dev] Problems in using the wf-codegen framework

Hi Miguel,

I don't think that we have a code dependency on Java 6 in this framework, it
was itself as well as the used libraries only compiled with Java 6. I guess
we might change that, but as far as I know JWT WE is also compiled with Java
6.0? Didn't you have some problems here?

Concerning the "null": this could have several reasons:
-did you have specified the path to the implementation.jar? In the
preferences under codegeneration there is a way to specify all details for
the codegeneration. You can simply check the "Use default Configuration"
(standard), but you also need to specify a path where this standard
configuration can be found. This would be the path to the
agilpro2bpel_impl_jwt.jar (or something like that). Then it should work.
-the second reason could be that your process is too simple. That's a small
bug which we need to fix in the next version: if your process only consists
of one action, then the transformation does not start (because there is
actually nothing to transform), but this results then in a file with the
content "null".
The codegeneration does not create a visible output of the graph in
block-structure, but you can easily open the resulting bpel-file in a
bpel-viewer to see the block-structure.

Concerning the BPEL import operation: in principle this should be feasible,
but probably the BPEL actions might be separated and only some of them taken
into the process model (one won't need all the assign actions, but probably
only invoke or receive's). Building the BPEL-structure with the JWT
constructs should not be a problem at all for the main constructs (switch,
flow, etc.), maybe only the links in BPEL might make it a little bit
difficult.

Best regards,

Florian


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Miguel Valdes Faura
Gesendet: 08 July 2008 17:09
An: 'Java Workflow Toolbox'
Betreff: RE: [jwt-dev] Problems in using the wf-codegen framework

Hi Florian

The preferences dialog is now working as expected with jdk 1.6, do you have
a code dependency on this jdk version or this binary version was just
compiled with jdk 1.6 ? 

IMO, do not provide support for jdk 1.5 could be a problem for a number of
users.

I've tried to generate a BPEL file from a simple JWT diagram (by leveraging
the Codegeneration menu -> StartGeneration operation) and the file was
created but with "null" as content... any idea ?

If I well remember in one of the white papers you sent me on this framework,
there is a graphical transformation out there allowing to visualize a JWT
process in block based structured when planning to export it as BPEL, I was
expecting to see this view/feature with this plugin... I'm missing something
?

Just my a last question, do you have an idea of the required effort to allow
BPEL import operations ? meaning from a BPEL file to visualize a JWT diagram
?

Thanks,

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 15:15 À : 'Java
Workflow Toolbox'
Objet : AW: [jwt-dev] Problems in using the wf-codegen framework

Hi Miguel,

jwt.we_0.4.0 is the newer version. We started with 1.3.0, but then realized
that Eclipse forces us to use version numbers smaller than zero, till we
graduate from the incubation phase. Therefore, jwt.we_0.4.0.jar is okay. But
this is not the source of your problem, I guess.

The error message probably comes from another Java version installed on your
PC: do you use Java 5 or older or at least define this in the project
settings in Eclipse? I believe we used Java 6.0, so when Java 5 searches for
the class file and it does only find something compiled in Java 6, then in
shows this exception "Bad version number in .class file".

Regards,

Florian

-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Miguel Valdes Faura
Gesendet: 08 July 2008 14:43
An: 'Java Workflow Toolbox'
Betreff: RE: [jwt-dev] Unstructered graphs

Florian,

I've tried to install the workflow-codegeneration framework (following the
instructions described in the document
"de.uniAugsburg.wf-codegen.userManual_1.1.0.pdf") but something went wrong.
When I tried to set up Eclipse preferences: "Window->Preferences->Code
Generation" I got the following error: 

"Unable to create the selected preference page.
Bad version number in .class file"

The only thing in my environment that differs from the installation
procedure is the version of the JWT plugin: I'm using
org.eclipse.jwt.we_0.4.0.jar (the only one I found) while in the
documentation the org.eclipse.jwt.we_1.3.0.jar is referenced.

thoughts?

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 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

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

Attachment: Standardpalette.bpel
Description: Binary data

Attachment: StandardPalette.workflow
Description: Binary data


Back to the top