Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jwt-dev] [jwt-users] and the road goes on...

Hi Fabrice

First thanks for your "straight from the trenches" insights !

I really like what you say about doing both top-down and bottom-up approaches. For though top-down is the classical one in the workflow field, it has shown that alone it is not enough ; whereas the bottom-up has now the SOA wind blewing in its sail - as a close contributor to the Petals ESB I am well aware of that. I am actually convinced that by partnering with the SOA / SCA targeted friend project SCOrWare and aiming to provide for its BPM tooling needs we've already set similar goals.

On a related note I've recently been at the SOA / BPM show in Paris and I'll write more about it later.

About process views and UI : now I agree tabs would be the way to go to display the different views on a same process. I'm not sure it'll be as simple as actually having a "same process" between them, but that as well as how business-specific views are linked with a technical implementation of the process may be solved later, by refining our use cases.

Best regards
Marc Dutoo
Open Wide

Fabrice Dewasmes a écrit :
Hi all,

I've been very busy during the last months but it's still interesting to give some more inputs to the guys designing and developping all the great stuffs ! ;)

I'm very pleased to say that JWT has great days coming. I'm working together with some people in a great european institution and it's getting more and more evident that a flexible tool as JWT plans to be is definitely awaited by the market. The need for a BPMN notation seems to be important for a few people. In fact what is important I think is to have the ability to use JWT as top-down tool as so as a bottom-up tool. What I mean by this is that when going towards SOA, the two different approachs are most of time considered. The top-down approachs considers going from BPM representation to a more technical view whereas the bottom-up approach is focusing on the technical aspects, eventually mutualising the services achieved and exposing them to a more high level view (typically the process view, the analyst view). Having the ability to use JWT as a simple technical tool for modeling a process and deploy it on a runtime is great but what is also interesting is to be able to start from a more business modeling view (typically BPMN) and then switch from this view to a more technical view. How this could be implemented is maybe to have different tabs on the editor exposing the same process in different views. Then comes the difficulty of mapping the different views as the representations may not perfectly suits from one another.

let me know of what you think about this.


On 2/27/07, *Fabrice Dewasmes* < fabrice.dewasmes@xxxxxxxxx <mailto:fabrice.dewasmes@xxxxxxxxx>> wrote:


    Thanks Marc for the introduction. Users workgroup starts as of now ! ;)
    I strongly invite every people involved in this group not to
    hesitate to comment anything I say and participate actively.


    First of all, we shall clearly define the goal of this workgroup. In
    one of his previous emails, Marc spotted it as this : Gathers all
    user-oriented point of views and desideratas.

    To my point of view the users workgroup should gather requirements
    from the community and committers and package this to be presented
    to the architecture workgroup so that they can evaluate feasibility
    and integrate the requirement in the roadmap. Our role is important
    as it will help JWT project go in the right direction and gain great
    community adoption.


    We may use the wiki to expose the requirements that are gathered.
    But to capture community requirements maybe we should find a
    communication channel. I think we will definitely need a jwt-user
    mailing list.

    Some starting ideas

    - what could be interesting for the wam part is to be able to define
    a server model the same way WTP does and then define instances of
    that model. Then a dedicated view will show the servers declared and
    enable the user to start/stop them.
    - Again for WAM, we should be able to deploy a process definition to
    a server model. Special deployment checks should occur to see if the
    process grammar matches the server capabilities. Then I think we
    should have a dedicated perspective where we could navigate in the
    servers, deployed packages, deployed processes. A right click on a
    process could enable to start one process either in run mode or
    debug mode. For both we shall be able to enter process variables
    values. The process graphical view shall enable to see the process
    instance state(for example by highlighting current state).
    - For WE we should provide a simple user way to expose business
    services. I mean that most of the time there are existing services
    in the companies that they certainly wat to leverage and use in a
    process orchestration. A user shall be able to rapidly import
    services made available by the company so that the can be part of a
    process. The import shall be possible from several sources : UDDI,
    WSDL (file or URL), or more specific services that may depend on the
    infrastructure but that are generic (for example mail service). The
    imported services should be available in a front panel and could be
    dragged and dropped on the process graphical view

    Those use cases shall be discussed and then refined. Your turn now !



jwt-dev mailing list

Back to the top