Re: avalon newbie: Innocent question, please don't hurt me -- services strategy with Avalon framework

["Andrew C. Oliver" <ac...@apache.org>]

I'm not buying it until you point me to a real project that is a good 
example of this done right and that hasn't suffered from excess 
complexity.  Then I'll buy it ;-)

-Andy

Stephen McConnell wrote:

>
>
> Andrew C. Oliver wrote:
>
> > 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.
>
>
>
> All of the containers in Avalon (Merlin, Fortress, Phoenix) have been
> built the patterns I've described.  But I don't think that's a good
> solution in terms of pointing you to something because it will be really
> easy to get mixed up about things because you will be looking at
> component based systems proving component management.
> There are examples of Phoneix components that follow this pattern in the
> cornerstone package, and the james is an example of a system based on
> the composition of components - but you should probably post an email to
> the Phoenix list to get suggestions on which of these components you
> should be looking at.
>
> I have a lot of stuff I'm working on that's internal that meets your
> criteria.  But to get to this position I've had to build the container
> API to provide the proper seperation of container-side verus component
> concerns.  I'm not saying there isn't well designed and understandable
> systems out there based on Avalon, but I do think that these examples
> will be of limited complexity.  Without these sort of container-side
> service abstractions the code in a complex system starts to get
> complicated with component management artifacts - in other words -
> things get cluttered and unnecessarily complicated.  Based on the work
> with excalibur/assembly, meta, container, configuration, I've managed to
> substantially simplify my code base and get a big application under
> control and readily understandable.
>
> Cheers, Steve.
>
> >
> >
> > -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:
> >
> > For additional commands, e-mail:
> >
> >
> >
> >
>




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