Home » Eclipse Projects » Java WorkFlow Tooling (JWT) » Re: AW: JWT project proposal
|Re: AW: JWT project proposal [message #22845]
||Wed, 02 August 2006 09:34
| Marc Dutoo
Registered: July 2009
Thanks for this insightful feedback, I'll use it to update the draft.
See remarks in text.
Oh, we might need some more targeted writing on your part as well ;)
First the wiki thing. I've asked objectweb, but since jwt is not an
objectweb project... Eclipse gives wikies, but only to approved ones. So
I 'm ok with your editme.com pointer, since there are other proposals
there (however it doesn't seem to be much used anymore ?). Is that ok
with you ? Or would it be easier to have one at your's ?
Finally, please create our account on the project page
https://forge.openwide.fr/projects/jwt/ and tell me your login so I can
add you as project member.
Florian Lautenbacher wrote:
> Hi Marc,
> attached you find a few additions/ideas to the current proposal. A
> wiki where, we could work together on the document, really would be a
> good idea. If ObjectWeb can't provide one, then I might create a new
> group in our CSCW-system where we can work with a wiki, if you like.
> Proposed thematics
> Put the emphasis on the Workflow Editor.
> Lay the stress on the specificities of the JWT approach (see text
> below) vs the market of existing BPM tooling projects.
> Add use cases examples showing the advantages in decoupling BP
> representation and implementation (grammar...), in order to
> demonstrate how it allows easier building of customized workflows for
> business specific solutions on one side, and how it allows a broader
> choice on the technical platform and the way it integrates with the
> entreprise information system on the other side.
> Maybe a simpler technical take on JBI would be better. In this same
> field add the SOA & SCA problematic (see article on the SOA point of
> view on BPM below, cite research project if validated).
> Add how it integrates with integration tooling projects such as STP
> (see description of STP below).
> Try to get some more examples beside ObjectWeb, otherwise it looks
> like this is only an ObjectWeb project. Remove the link to the JSR 268
> (Java SmartCards?) and change it to the JSR 208 (JBI). Put further
> emphasis on the advantages of having a project like JWT (it is not
> just another tool for modeling the processes, it is a framework!)
OK with JSR 208 ;)
Perfectly OK with the integrated framework & tooling solution philosophy
> Description of the products
> WE : seems fine to me. Florian : do you have any interesting addition ?
> At the beginning it sounds like WE would be one editor with only one
> XML file and one format as an output. But this is not the case! The WE
> will have multiple views for the same workflow definition (not only
> XPDL and BPEL, but one could also argue that we have a business view
> and a technical view). And maybe there could be much more views added.
> For example for specifying ISO-certification processes, considering
> ITIL, etc. And on the other hand there should be not only one output
> XML format, but it should be possible to generate several formats to
> stay independent in the workflow engine. We could transform the model
> to XPDL as well to BPEL code (this would be an advantage over the STP
> Of course in the end we will start only with the BPMN representation
> and an XPDL grammar, but the vision should be specified more in detail.
Good idea, giving examples of business-specific representations & views
would help understand the scope.
We should underline XPDL's advantages over BPEL in order to better
explain our choice as well.
Finally how the business view might affect the technical implementation
view, and how this last one may be configured and the power these
features harnesses should be detailed as well in my mind (see Miguel's
> WAM : explicit prioritized features. Remove the reference to Shark and
> explicit the problematic of the choice of BPM server.
> A better outline of how both may work together would be valuable in my
> I agree completely.
> Description of the architecture
> Clearer emphasis on the workflow model API.
> I'd put the use of EMF / GEF and the great context of the Callisto
> release in the light here as our architecture of choice.
> Please add EMF to the architecture overview diagram. It should
> be visible which parts are included into WE and which one in WAM
> (currently only WAM can be found in the diagram). Where is the
> difference between the Workflow model and the Workflow Engine model?
OK for EMF.
The workflow model is our wf edition pivot model.
The wf engine model is an extension of the basic start / stop / deploy
API over BPM engines used in the Wf Admin & Monitoring tool (WAM) toward
a meta-model for easy adaptation of new server types allowing more
extensive server management features. See the philosophy for it in the
"Server model" section of the JST page
> WE Extension points : these are an architectural decoupling of the
> WE, so let's say so :)
> Why only a decoupling of WE? It is also a decoupling between WAM and
> WE and therefore we need to define the interfaces between both
> in great detail.
Yes. How much we will be able to do before submitting for approval
should however not be a stopping point (Guennadi was speaking of a
"waterfall-like" specification process).
> Leveraging and integrating with existing technologies and projects
> Integration with other Eclipse projects : a simple list will do.
> Other projects : Objectweb projects (STP, JoNES...), TODO BPM projects
> What is meant with WST: sse components in the current proposal? JDT or
> What kind of validation framework will we use? Is there one available
> in the Eclipse project? I only know the one in the
> openArchitectureWare project (www.eclipse.org/gmt/oaw/doc/index.php
> A few words about XPDL:
> -perhaps we should mention the Workflow Reference Model from the WfMC
> first and then describe which parts are already available (examples
> for Open-Source Process Definition Tools, Workflow Engines, etc.) and
> then explain how XPDL fits into it and how JWT can be used in increase
> the flexibility therein.
> * sponsoring organisations : objectweb, Open Wide (potential new
> Objectweb project to be added).
> Did you get the reply/information from ObjectWeb you were hoping
> for? Which ObjectWeb project is this going to be?
I'll have it before asking for submission and you'll have the info by
then ! The idea would be that the BPM tooling part of the project is not
in the objectweb "middleware" philosophy and so would be contributed to
JWT. Obviously it will follow JWT's philosophy.
> Additions are open.
> * proposed project lead and initial committers : to be discussed,
> initial partners to be recontacted. New : Marc Dutoo (Open Wide),
> Florian Lautenbacher (Augsburg Universitat).
> Please change this to (University of Augsburg, Germany).
> * interested parties : initial partners to be recontacted. New : Maybe
> Miguel Valdez (Bull)
> * initial code contributions : Florian : yours to be added (if you're
> ready I'll open you up an account)
> You can download our code on XXXX (ask Florian or Marc for the URL or
> become a project partner).
> But I would prefer if it only visible for the project members of JWT
> and for the eclipse board. Our partner wants to make sure that their
> competitor in Germany won't get the code before they have finally
> implemented their adapters for their own program. So the question is,
> can you restrict the access to the project members ? (it is already a
> https-link, but it doesn't seem to make use of it).
I understand (I hope you competition isn't already among the JWT
I've created a private section on the JWT project page (
https://forge.openwide.fr/projects/jwt/ ) for that.
> Below are a few resources, not to be integrated "as is", some to be
> translated in english.
> That would be good, because unfortunately I don't speak French. :-(
No problem ;)
> That's it from the moment from my side, all the best,
Current Time: Sat Aug 19 01:56:30 GMT 2017
Powered by FUDForum
. Page generated in 0.17247 seconds