Re: Componentizing Werkflow

On Fri, 2003-04-25 at 14:23, Vinay Chandran wrote:
> Kevin,
> 
> > It wouldn't unzip for me :'(
> My current eclipse snapshot is at 
> http://www.xspiral.com/werkflow/WERKFLOW.ZIP
> Hopefully this should zip fine.(if at all 
> you need to see it:-)) 
> 
> > I believe that the plan was to add Avalonization
> > around the engine
> > rather than integrate it with the engine. 
> > 
> I was planning to avalonize the engine.
> 
> > When I first started doing the persistence stuff I
> > thought that I would
> > require Avalon life cycles and such (in fact the
> > initial version of the
> > Prevayler persistence manager was Avalonized). It
> > turns out that It's
> > not as required as I thought (some prodding from Bob
> > to get me looking
> > from different angles helped). Removing Avalon from
> > the core of werkflow
> > defers some of the configuration issues to the
> > hosting environment (for
> > example an Avalon or MBean container) and the system
> > itself easier to
> > embed in other systems that don't need/support an
> > Avalon style life
> > cycle.
> >
> One can always write Avalon ComponentWrapper  to
> bootstrap the components within non-avalonic
> containers
> as well as in a standalone mode.
> (Fortress@Avalon)
> The intent of Afvalon, as you very well know, is to
> use IoC and Separation of Concerns design paradigms,
> thats whats make Avalon powerful.Everything other
> is the spice around it (spice adds value to
> the food though :-) )
> Avalon forces you to think rightly and 
> thus help separate you interfaces and implementations,
> leading to better componentized/flexible entity.

I'm a long term user of Avalon (and a fan), but you can create
components without the avalon framework. At it's core avalon is a set of
patterns.

> > It may be simpler/lighter to handle the
> > componentization aspects of
> > Avalon using Sun's service provider interfaces
> >
> (http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider)
> > or commons discovery
> > http://jakarta.apache.org/commons/discovery/
> > 
> Umm!!!
> I wonder how issues like dependencies between 
> components,lifestyle,lifecycle features of containers
> can be realized by using this api.

Dependencies between components are handled via factories and interfaces
(the jaxp factory for example). The difference to avalon is that the
component manager plays the part of the factory.

> > These are specific implementation classes based on
> > interfaces found in
> > persistence etc. In my opinion the have a class name
> > the same as the
> > interface name but in a seperate package can lead to
> > confusion 
> Interface: ChangeSet
> Implementation : DefaultChangeSet or ChangeSetImpl
> 
> This conventions enables one to visualize as well as 
> make them co-exist amicably within the same package,
> with no loss of meaning.
> 
> >for
> > example if int eh body of the code I see
> > 
> > foo = new ChangeSet();
> > 
> > I have to scroll back up to the top of the file and
> > find the package
> > declaration to see the type of changeset being
> > initiated. 
> 
> Firstly,Are there different types of changesets????
> ChangeSets contain sets of changed process-cases.
> Why would you need another of its kind.

Yes, changesets are passed to and from the persistence manager. The
internal representation of the change set from a given persistence
manager may be totally different (eg to support lazy loading from a
database).

> If so then they can be prefixed rightly in their
> Implementations(eg: xxxxChangeSet)

Yup, for example PrevalyerChangeSet.

> > The other problem with making the concrete name the
> > same as the abstract
> > name is that you end up with method declarations
> > like:
> > 
> > ProcessCase implements
> > com.werken.werkflow.ProcessCase
> > 
> DefaultProcessCase implements or
> ProcessCaseImpl implements ...

The CoreChangeSet is a specific implementation to the core package. This
doesn't mean that it's the default implementation.

Bob is the naming convention man. I just follow. It makes sense though.

> > Always, Bob has been a little busy over the last
> > couple of weeks but
> > we've been working through different models there
> > are a number of
> > changes on the board with regard to how case
> > persistence is handled.

Mostly it has been to do with changing the way correlations are loaded
and unloaded from the persistence manager.

-k.

-- 
If you don't test then your code is only a collection of bugs which 
apparently behave like a working program. 

Website: http://www.rocketred.com.au/blogs/kevin/