Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] Open source Eclipse plug-in based on JaWE&Shark 
Hi,
I fully agree that JWT should get integrated with other Eclipse projects (Birt, STP, Mylyn). This is not currently a priority, but this is something that we keep in mind (as any Eclipse committer must do). It will probably come with time and growing community... 

I also agree that JaWE or YAPROC are better tools for Shark than JWT.
JWT tries to be useful and efficient for non-developer business analyst and for several process engines (it resolves the "Babel Tower" issue of the BPM [1]). Thus, we cannot introduce into JWT capabilities that are too technical or specific to one workflow engine. The leitmotiv is to give to business analyst and workflow developer a powerful and easy tool, that would help encourage them to make a good use of BPM without constraint about the engine they can use.
By definition of JWT (see the original proposal [2]), using JWT for Shark would have the same benefit as using JWT for any engine: make process design easier and more agile, leverage SOA in processes, and a lot of things that will come with age... 

More technically:
The Project entity is actually the Package in XPDL vocabulary. JWT and XPDL metamodels have a lot of similarity, but they do not use the same vacabulary, the WorkflowService uses JWT vocabulary. The wiki page is not up to date, if you want to see the current status of wam api, you can see sources at [3] 


I hope my answers help you to better understand the aim of JWT.

Regards,
Mickael


[1] http://www.eclipsecon.org/summiteurope2007/presentations/ESE2007_JWT.pdf
[2] http://www.eclipse.org/proposals/jwt/
[3] http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.jwt/wam/jwt-wam-runtime-api/src/org/eclipse/jwt/wam/api/WorkflowService.java?revision=1.2&root=Technology_Project&view=markup 

Pablo Beltran a écrit :

Hi,
License issues make all the code unuseful for you. I could change my license type, but it would not resolve the full problem because the projects used by YAPROC are LGPL and some of them should be required by you.
On the other hand, at this point, your draft is in a very early state. I would put the frontier of your extesion points before the communication issues to concentrate in what JWT-wam will do (a draft of your extension points capabilities) because the communication layer can be solved by vendors easyly and it has not too much impact from a Eclipse point of view.
Would be nice if JWT-wam (or other JWT subproject) would resolve some dificulties related with other Eclipse technologies. For example: BIRT for reporting, Mylyn to filter processes used by Eclipse projects and include only the relevant for each context, and so on.
I want to apologise if I'm changing the JWT (JWT-wam) scope:) but I think on JWT as a bridge between workflows and the entire Eclipse platform making easier adopt the Eclipse provided techonolgies for workflow vendors.
Now I'm asking to myself why are (or would be) the benefits of ussing JWT for Shark. And I can't find a good answer to that question since Shark has resolved in a gracefuly way the main communication issues thus it don't get a clear benefit from using JWT. Maybe things are different for Bonita since JWT is a good exercise to create a new communication API. 

Finally I've a question about your current data model for JWT-wam:
* What does mean the Project entity? It seems like projects belong to processes. 

Best regards,
Pablo.
2009/1/26 Mickael Istria <mickael.istria@xxxxxxxxxxx <mailto:mickael.istria@xxxxxxxxxxx>> 

    Hello Pablo,

    Thanks for your interest to JWT and for your advices.
    I'll try to spend some time today to take a look at YAPROC to see
    which interesting features it contains and give you some feedback.

    Here are a few comments about JWT that may be interesting for you
    to know:
    * Since JWT is an Eclipse.org project, we are not allowed to
    include into JWT some code or libraries that are under the LGPL or
    GPL. Only EPL code is allowed on Eclipse.org code base, and we can
    use some code/libs under the BSD, Apache, MIT-like licenses, but
    it requires the approval by the Eclipse PMC (if you are interested
    in Eclipse Intellectual Property policy, take a look at this page
    => http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf).
    <http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf%29.>..
    * JWT-wam (workflow administration and monitoring) is currently
    only a draft. You can find a few details on the page
    http://wiki.eclipse.org/JWT_Monitoring. As you can see, we have a
    kind of "abstraction layer" that contains some beans to describe
    the workflow state, and a WorkflowService interface that contains
    a set of operations to query the workflow engine about runtime
    data. This API is not definitive since it is often refactored, any
    comments are welcome ;)
    * To link a workflow engine to JWT, the only thing to do is to
    implement this WorkflowService interface. We currently have an
    implementation for Bonita v3 with webservices (on SCorWare's
    private SVN, since we cannot commit it to Eclipse because of
    license), one with an "embedded" Bonita v4, but we could also
    think about an implementation directly on databases, thanks to
    VirtualDB.

    Feel free to criticize it if you want to, it is still in progress
    and any other opinion will help us!

    Regards,
    Mickael


    Pablo Beltran a écrit :

        YAPROC is a new Eclipse (one moth old) plugin that embeds JaWE
        & Shark with many nice features like reporting, process viewer
        at runtime, activity management, graphical history,... and
        compatible with the XPDL 1.0 specification.
         Now, YAPROC becomes an open source project under the LGPL v3
        license terms. Maybe you can re-use some parts in your project.

        The plugin, documentation, sources and online demos are
        available from www.upversion.com <http://www.upversion.com>
        <http://www.upversion.com/>


        Likely a very interesting feature for you is the VirtualDB
        that allows you to integrate differents java technologies into
        a jdbc driver. It's not a technology from me but I adapted it
        to be successfully used  to integrate Shark into a new complex UI.

        Based in my experience with Shark (which has a quite complex
        API) and YAPROC (which has a quite complex UI) I would
        separate UI issues from communication workflow  issues. Mybe
        you have done this exercise but If not I would like alert to
        you about potential design limits to build a complex and
        usable UI based on a workflow communication layer when
        required functionality grows and grows.

        I think now is too soon to implement this kind of solutions in
        JWT because your actual UI is quite basic but maybe in the
        near future if you develop new plugin views and you need to
        relate many of them and many complex filters would be required
         to show a lot of information in the Eclipse Workbench in a
        coherent manner, so maybe this problem arises and you need to
        resolve it. In this case, VirtualDB is a very suitable
        technology to solve this kind of problems.
         Best regards,
        Pablo.
        ------------------------------------------------------------------------

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


    _______________________________________________
    jwt-dev mailing list
    jwt-dev@xxxxxxxxxxx <mailto: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

Back to the top