cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hunsberger, Peter" <Peter.Hunsber...@stjude.org>
Subject RE: Experience with workflow at Hippo Webworks
Date Mon, 08 Mar 2004 21:49:31 GMT
Guido Casper <gcasper@s-und-n.de> writes:

> 
> Hunsberger, Peter wrote:
> 
> > Guido Casper <gcasper@s-und-n.de> writes:
> > 
> >>Hunsberger, Peter wrote:
> >>
> >>>For the end user I believe you always have to have modeling
> >>
> >>tools for
> >>
> >>>building work flow, the internal implementation should be
> >>
> >>completely
> >>
> >>>transparent; the first time I wrote GUI modeling tools for
> >>
> >>work flow
> >>
> >>>was 13 years ago (as a subcontractor for one of the major work flow
> >>>vendors) I don't believe the end user expectations have 
> >>
> >>declined since
> >>
> >>>then!
> >>
> >>I'm slowly starting to see an unsolvable conflict :-)
> >>
> >>Some are looking for a tool for developers and some are 
> looking for a
> >>tool for users. And I guess we'll be having a hard time 
> >>finding a single 
> >>tool being both.
> > 
> > 
> > I probably should have written "For the end user I believe 
> you always 
> > have to have the option of having modeling tools for building work 
> > flow...".  However, even as written originally I don't see 
> a conflict? 
> > I think it's not unreasonable to assume that the modeling 
> tools will 
> > be independent of Cocoon.
> > 
> > What is needed is a way to take the models, where ever they may 
> > originate, and implement them in Cocoon.  I think the only 
> way that's 
> > going to be generally possible is if Cocoon has some form 
> of template 
> > based model (even if it is internally used to generate a 
> script based 
> > implementation via some XSLT).
> 
> As I see it, a user tool can only work within a limited context. The 
> more you try to widen that context, the more the user tool starts 
> resembling my development tool (with a UI still intended for 
> end users) 
> and things get messy.

Hmm, maybe, but I don't think so; work flow modeling has been around for
a pretty long time now.  The modeling tool I worked on 12-13 years ago
is still being sold although I think that package was sold off and the
company we did the work for now sells something based on a different
code base.  The concepts, even then, where well defined, and there
wasn't much in the way of work flows you couldn't model.

> If my state objects and my action objects both are Avalon 
> components I 
> can easily build really complex conditions and state transferring 
> activities. I hardly see how these may be modelled in a user tool.
> 
> IMO modeling tools are great tools for communicating using 
> models being 
> reduced representations of the reality (isn't that what models are 
> about?) but are usually hard to use to generate the reality 
> out of the 
> model.

I believe model based engineering is going to be more and more common.
You may have heard of Model Driven Architecture?  Really, I think this
is Integrated CASE becoming a reality for all code... I do know that for
what we want to do we can't do it without tools that the business
analysts can use to build the work flows; there is no way that we can
involve developers for each of the 1000's of work flows that we will
building over the next couple of years.

> I think it would be a good idea to talk about these two
> -a user-oriented workflow tool with a modeling UI and a well defined 
> limited context
> -and a more flexible development tool
> 
> as separate implementations sharing the same interface.
> 

I don't see any reason to limit the user oriented tool?  Start from a
flexible underlying model, be aware that it should be possible to
generate the model form some GUI....

 


Mime
View raw message