Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[jwt-dev] Re: Components in JWT

Hi Florian

So what about using the JWT CVS on the Open Wide Forge to host temporarily things that have no fixed place yet ? Here at Open Wide we're already using it this way for JWT and BPMN samples.

Now what about this in the jwt eclipse repository :

jwt-compatibility / jwt-bpmn (may contain their own samples)
jwt-compatibility / jwt-xpdl (may contain their own samples)
jwt-compatibility / jwt-samples (a unified version of the previous subproject samples)

And why not :

jwt-wam / jwt-runtime-bonita-sca (bonita extension allowing to call sca services) jwt-wam / jwt-registry-scorware (workflow editor plugin allowing to browse the service semantic registry by the INT)

Arguably those last two could be put rather in the SCOrWare private project SVN, but I'd rather have the JWT community have a look at it.

jwt4soa would have been an umbrella for soa, sca and scorware minded extensions. For example, jwt-wam / jwt-runtime-bonita-sca makes sense, but if we also develop jwt-we / jwt-we-sca i.e. an we plugin allowing to drag and drop sca components from the Obeo sca editor on JWT actions in order to link them together, it might be better to pack both at the same place...I admit I'm not sure what is the right thing to do.


NB. The idea of "jwt-samples" was to have one set of

Florian Lautenbacher wrote:

Hi all,

sorry for the late response. The last days had been quite busy. The idea to
have some additional sub-projects/components where the other resources could
be committed is quite good, but I'm not sure whether we simply can add
components or whether we need to ask the PMC about that. Actually, we can
simply add components in Bugzilla ourselves (using MyFoundation) and of
course adding another directory in the CVS is not a problem either. Maybe we
should first start adding a directory for the components to CVS and at the
same time add the components to Bugzilla and in parallel to that we can ask
EMO about the normal progress about that.

So, which kind of "components" do we like to have:
- I would agree with something like JWT4SOA if that is necessary (what would
be the content of that?)
- There definitely needs to be something like JWT-transformations which
could include both jwt-bpmn as well as jwt-xpdl or jwt-bpel. In my opinion
those could easily be bundled in one component (however having different
source code of course).
- JWT-samples are surely necessary. However I'm not sure, whether this
should be an own component or whether we simply should have a part on our
web site called "documentation" where these example processes are given and
explained in detail.
- jwt-runtime-bonita seems to be part of the proposed WAM part of JWT, so I
don't see why we should have an own component for that. Better start filling
the WAM component (where jwt-runtime-bonita could again be a subcomponent).

The idea of using EAnnotations to support different runtime engines like
Bonita in JWT sounds good to me. However, since I missed the telco last
Friday, there is probably already an agreement on this!? Marc, Stéphane?

Best regards,


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Montag, 3. Dezember 2007 23:12
An: Java Workflow Toolbox; Florian Lautenbacher; Stéphane DRAPEAU;
Betreff: Re: AW: [jwt-dev] Re: Samples, BPMN-JWT transformation, new
committers, etc.


I agree with you. We all promise to do it right in the future :)

Actually Loic could have committed the samples, but there is no JWT project
for JWT4SOA or JWT2BPMN or ...

What about these subprojects :

jwt-bpmn for jwt to bpmn and vice versa transformations and their integration in jwt we, as well as a quick launch of STP BPMN ed

jwt-xpdl for jwt to xpdl (bonita version) transformation and their integration in jwt we

maybe a jwt-samples, to gather a common basic version of our interoperability & validation samples. Then these scripts could be copy and pasted by any interoperability project ex. jwt-bpmn and fine-tuned at will, but at the end the jwt-samples scripts would have to be updated in a consistent manner. This would ensure that a new interoperability feature won't break an existing one. Other ideas on samples and how to ensure format consistence, anyone ?

jwt-runtime-bonita for bonita integration as a jwt runtime. NB. this could also be put in the scorware private project, but I'd rather put it here so the whole JWT community can help and give inputs.

As for how JWT workflow model will have to be extended to support the bonita runtime there's nothing final yet, but why not add an EAnnotation mechanism just like BPMN so as to not require to change the model each time there is a new standard or engine supported ? Florian, Stéphane, your take on this ?


By the way, did you read the PMC's comments on the two new committers on
The PMC's comments were: I'm a little concerned by the +1 votes that
"as requested" - individual committers are required to be making up their
own minds on whether to vote someone in, not just following a party line.
will assume that that is what you all have done. Please make sure that
voting comments in the future correctly reflect your opinions of the
candidate. Thanks.

I agree with him, that normally new committers should have developed some
code, answered some bugs or did anything else, but I also see the problem
when there is nobody to submit the code and you need to do all the things
yourself... ;-)

Best regards,


-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] Gesendet: Mittwoch, 14. November 2007 19:30
An: Stéphane DRAPEAU; Florian Lautenbacher
Cc: Etienne Juliot
Betreff: JWT to BPMN translation - first spec and samples

Hello all

Here is my first take on JWT to BPMN translation detailed spec and samples.
You'll find in this mail (content or attachments) :
  * a first sample JWT process :
* its translated STP BPMN files : transformation_sample_3_approval_frompp (without annotations yet
* my analysis of JWT to BPMN translation, whose goal is to be the basis
of a translation algo. What about putting this on the wiki ?
  * Florian's answers to some questions of mine, that could be the
step towards a "How to build processes in JWT" FAQ. What about putting this
on the wiki ?

Next steps :
* MDU : adding annotations to the STP BPMN process (though how they are
obtained is already spec'd)
  * MDU : completing my second sample, writing a third one
* everyone : sort out the last indecisions in translation behaviour (see
below first, and in attachments)
  * SDR : work on the translation ^^
  * FLA : look at all that, help out whenever it is useful (thanks for
cleaning my process)


PS indecisions to be closed out (see details in attached SCOrWareJwtBpmn) :
  * JWT eventHandler
* JWT Data mapping : this I left out for now. Its meaning and use should
be made clearer.
  * at a lower level, about JWT events
  * I do not agree with the Augsburg proposed mapping for pool & lane,
rather "Pools represent participants, lane are for categorizing activities".
  * I do not agree with the Augsburg proposed mapping Application to
special BPMN DataObjects

jwt-dev mailing list

Back to the top