avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: avalon newbie: Innocent question, please don't hurt me -- services strategy with Avalon framework
Date Fri, 15 Nov 2002 19:08:57 GMT
Okay so you've hooked me.  Show me a set of code that you regard as WELL 
designed and UNDERSTANDABLE (which means maintainable over time as 
well).  My biggest problem with the approach you suggest is the only 
examples I have of code that was done in that way I seriously seriously 
seriously dislike.  I also have a gripe against excessive "is a" 
relationships but putting that aside.  Point me to something that was 
done well that uses the framework in the manner you suggest.

-andy

Stephen McConnell wrote:

>
>
> Andrew C. Oliver wrote:
>
> > Some time ago someone sent me some ideas on how to use avalon in a
> > service based strategy such that it would be more containment based
> > than inheritance based (and bare will me that I regard interface
> > implementation as inheritance because its "is a" not "has a").
> > Basically, I don't want everything to implement 10 different
> > interfaces.  i'd rather null operations...  So I lost the message
> > (long story short, fired, lost laptop, rehired by same company in
> > different group, new laptop...stupid mozilla default settings had
> > deleted mail of my server against my will).. But I'm ready to do it
> > now ;-)
> >
> > What I basically want is:
> >
> > public class AbstractService implements x, y, z, ... {
> >
> > ??
> >
> > public SomeType someLifecycleMethodImNotUsing() {
> >   return null;
> > }
> >
> > }
> >
> > What are the x, y, and zs that I should most likely use?
>
>
> Probably:
>
>   LogEnabled,
>   Initializable,
>   Disposable
>
> But if you wanted to do the grand abstract approach, you could do
> something like:
>
>   LogEnabled,
>   Serviceable,
>   Contextualizable,
>   Configurable,
>   Initializable,
>   Startable,
>   Disposable
>
> But I also think it is bad approach.  I'll explain why.
> Creation of abstract class is something that makes sence when the
> underlying functionality is "rich".  That isn't the case with any of the
> above - as you will have seen from Leo's email you just end up with an
> object holding a bunch of state members.  What's missing is the
> relationship between that object and its container.  All of the above
> interface provide the formal points of inteaction between a container
> and a component.
>
>   LogEnabled
>
>      assignment of the logging channel that
>      the component will use (component does
>      not see any particular logging implemetation)
>
>   Serviceable
>
>      assignment of the services that the compoent
>      needs to function to do its job (component
>      should never need to go hunting for the service
>      it neeeds) - service that the component needs
>      would typically be declared as depedencies in
>      a meta declaration and the container will take
>      care of service provisioning
>
>   Contextualizable
>
>      supply of the runtime context - again, the
>      context information that the component needs
>      (key + type) can be declared in meta info so
>      a container can make sure the component gets
>      all of the context information it needs
>
>   Configurable
>
>      supply of the component configuration by the
>      to the component.
>
>   Initialiable
>
>       request from the container to the component
>       to initialize itself, typically the
>       component implemetation will validate internal
>       state at this point
>
>   Startable
>
>       only applicable in the case of a component that
>       needss to start up its own thread of execution
>       (i.e. a component acting as a server for example)
>       - called by the container to instruct the component
>       to start or stop doing its stuff
>
>   Disposable
>
>       Used by a container to tell the compoent to clean
>       up state
>
> Problem with the "AbstractService" approach is the abstract work should
> be in the container, not in the component.  It the container that has to
> take care of doing all of the leg work to make sure the component gets
> everything it needs.  It does this based on a combination of (a)
> lifecycle interfaces as described above, and (b) supplimentary meta
> information describing the component deployment criteria.
>
> By pushing all of the overhead onto the container, you end up with much
> better code in you component implemetation, and much less code.
>
>
> > And what else do I need?
>
>
>
> 1. a container
> 2. a component / service model (design)
>
> >
> > In short my application is a reporting service which lets me pull from
> > a number of data sources, execute various transformations and get out
> > a report via various delivery methods.  So I have DataProviderService
> > which has for instance a JDBCService which can process QueryDefs to
> > get stuff from a database (I don't ermember the names I have thus
> > far).  So far I've stubbed most things out and I'm fairly happy with
> > it, but I'd rather not re-invent the wheel, hence my interest in using
> > Avalon in place of the little "Service" and "ServiceManager" classes I
> > used as placeholders..
> >
> > Thoughts?
>
>
>
> Doing cause-grained component oriented development is an approach that
> lets you break apart systems more formally, and from that, the overall
> system (a set of assembled components) becomes much, much simpler to
> build.  In fact, combining the Avalon component model with meta
> information enables the automation of system assembly and deployment.
>
> Cheers, Steve.
>
> >
> > thanks,
> >
> > Andy
> >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> >
> > For additional commands, e-mail:
> >
> >
> >
> >
>




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message