[
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.
Fabrice
On 2/27/07, *Fabrice Dewasmes* < fabrice.dewasmes@xxxxxxxxx
<mailto:fabrice.dewasmes@xxxxxxxxx>> wrote:
Hi,
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.
Goal
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.
HowTo
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 !
Fabrice
------------------------------------------------------------------------
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev