"Craig R. McClanahan"

[Warren Janssens <wh...@yahoo.ca>]

That's probably for the best that it is more
procedural than declaritive -- I know that I don't
really want to relearn prolog-style programming.

Anyways, I guess my interest in a workflow engine
would be for things like approval chains (you know --
first this person or group approves, then the next
person, etc...) since this thing tends to crop up in a
lot of business applications.  Had you envisioned the
non-web part of the framework being able to handle
something like this.  If so then I think I wouldn't
mind contributing since I know I'll have to write many
more applications that need that during my career.

--- "Craig R. McClanahan" <cr...@apache.org> wrote:
> 
> 
> On Fri, 16 Nov 2001, Warren Janssens wrote:
> 
> > Date: Fri, 16 Nov 2001 17:32:57 -0500 (EST)
> > From: Warren Janssens <wh...@yahoo.ca>
> > Reply-To: Jakarta Commons Developers List
> <co...@jakarta.apache.org>
> > To: commons-dev@jakarta.apache.org
> > Subject: workflow
> >
> > I was just curious how the workflow in sandbox
> relates
> > (if at all) to jsr 94 and/or ruleml?
> >
> 
> I don't know much of the detail behind JSR 94, but
> from the description it
> looks like this is focused on a "declarative" style
> of locating rules that
> match a particular business situation.  In a similar
> vein, RuleML seems to
> be more focused on the inference engine space.
> 
> The Commons Workflow package is more "procedural" in
> nature, defining the
> actual steps that should take place and not worrying
> so much about how you
> decide which Activity is relevant at this point in
> time.  My initial
> primary use case was relatively low level
> (automating the navigation of
> wizard-style dialogs in web applications), and the
> generic workflow design
> grew out of those needs -- such as generalizing the
> concept of Scopes
> instead of hard-wiring it to the Servlet concepts of
> request, session, and
> applicaiton scope.
> 
> Finally, it's worth noting that the Commons Workflow
> package provides an
> XML syntax for defining the Steps of an Activity,
> but using it is not
> required -- you can use any mechanism you wish to
> construct the in-memory
> object trees for each Activity.  If you use the XML
> syntax, the concept of
> using a namespace for rule sets is somewhat similar
> to what RuleML does.
> 
> Craig
> 
> 


_______________________________________________________
Build your own website in minutes and for free at http://ca.geocities.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: "Craig R. McClanahan"

["Craig R. McClanahan" <cr...@apache.org>]

On Tue, 20 Nov 2001, Warren Janssens wrote:

> Date: Tue, 20 Nov 2001 21:21:27 -0500 (EST)
> From: Warren Janssens <wh...@yahoo.ca>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Subject: "Craig R. McClanahan" <cr...@apache.org>
>
> That's probably for the best that it is more
> procedural than declaritive -- I know that I don't
> really want to relearn prolog-style programming.
>
> Anyways, I guess my interest in a workflow engine
> would be for things like approval chains (you know --
> first this person or group approves, then the next
> person, etc...) since this thing tends to crop up in a
> lot of business applications.  Had you envisioned the
> non-web part of the framework being able to handle
> something like this.  If so then I think I wouldn't
> mind contributing since I know I'll have to write many
> more applications that need that during my career.
>

Although the use case you describe is very interesting, the current
Workflow implementation does not really address it yet (other than
reserving the interface name org.apache.commons.workflow.Process :-).  The
current stuff around "Activity" is mostly related to things that are
basicially synchronous, done in a short time frame, by a single individual
-- the "Process" notion is mostly a TODO.

That being said, I'd be very interested in collaborations to make the
Process notion come to life ..

Craig


> --- "Craig R. McClanahan" <cr...@apache.org> wrote:
> >
> >
> > On Fri, 16 Nov 2001, Warren Janssens wrote:
> >
> > > Date: Fri, 16 Nov 2001 17:32:57 -0500 (EST)
> > > From: Warren Janssens <wh...@yahoo.ca>
> > > Reply-To: Jakarta Commons Developers List
> > <co...@jakarta.apache.org>
> > > To: commons-dev@jakarta.apache.org
> > > Subject: workflow
> > >
> > > I was just curious how the workflow in sandbox
> > relates
> > > (if at all) to jsr 94 and/or ruleml?
> > >
> >
> > I don't know much of the detail behind JSR 94, but
> > from the description it
> > looks like this is focused on a "declarative" style
> > of locating rules that
> > match a particular business situation.  In a similar
> > vein, RuleML seems to
> > be more focused on the inference engine space.
> >
> > The Commons Workflow package is more "procedural" in
> > nature, defining the
> > actual steps that should take place and not worrying
> > so much about how you
> > decide which Activity is relevant at this point in
> > time.  My initial
> > primary use case was relatively low level
> > (automating the navigation of
> > wizard-style dialogs in web applications), and the
> > generic workflow design
> > grew out of those needs -- such as generalizing the
> > concept of Scopes
> > instead of hard-wiring it to the Servlet concepts of
> > request, session, and
> > applicaiton scope.
> >
> > Finally, it's worth noting that the Commons Workflow
> > package provides an
> > XML syntax for defining the Steps of an Activity,
> > but using it is not
> > required -- you can use any mechanism you wish to
> > construct the in-memory
> > object trees for each Activity.  If you use the XML
> > syntax, the concept of
> > using a namespace for rule sets is somewhat similar
> > to what RuleML does.
> >
> > Craig
> >
> >
>
>
> _______________________________________________________
> Build your own website in minutes and for free at http://ca.geocities.com
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>