Andrew C. Oliver wrote:
Some time ago someone sent me some ideas on how to use avalon in aProbably:
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?
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: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
