Guys,
Thanks for responding to my previous email regarding "Avalon containers
and good development practices".
I guess, my question regarding documenation has been the most
controversial. I definitely agree that writing code is more sexy than
producing documentation and, after all, software projects need to provide
their bottom line, which is functionality. On the other hand, a good
engineer should be able to express his/her ideas not only through code but
also using creative diagramming techniques, especially that it is less
expensive in case of making architectural mistakes and better suited for
group discussions. It also helps others to participate in a project(s)
without a need to burn more midnight oil. Also, some architectural
diagrams can help those that want to base their work on an open-source
project(s) in a timely fashion. Well, good understanding of Avalon can
make it as popular as Apache or Struts; however, Merlin's documentation is
fairly impressive for an open source project. As for my participation, I'm
planning to donate a PowerPoint presentation in the near future, for those
that want to quickly introduce their teams/managers to the Avalon
framework.
In the mean time, I'm still unclear about differences between a component
and a block. As far as I understand, a component is a low-level entity
implementing all Framework's lifecycle methods with the ".xconf"
description file attached to it. On the other hand, a block is a
component-like entity with a BlockInfo file describing dependencies and
implementing all component lifecycle methods except to "suspend" and
"resume". When does a component become a block? Is it only when we need
services? If so, a block is a component with services and without any
differences between the two in terms of business scope they are trying to
address.
Following the above, is there any clear-cut difference between their usage
except to the Services? Well, since Component's marker interface has been
already deprecated, what makes your code a Component? Is it the interfaces
and its contract (kind of logical boundary)?
Can a component implement a Service without being a block? Is it possible
to use just one concept, i.e. Component (forget the block), that can be
either serviceable or not. If this is the case, what do we do with
"suspend" and "resume" and which configuration file format do we support?
Consequently, since Component interface has been deprecated, is the same
going to happen to the "ComponentManager" and the "ComponentSelector"? ?
how about the "RoleManager"?
Regarding ECM vs. Fortress, can a solution with background threads and
half a dozen of managers be considered a light-wait replacement to the ECM
(even if its architecture is superior)? If I just want to create a simple,
vertical component architecture made out of components that are quick to
initialize, should I just stick to using a default manager? ? but it
doesn't use the "ComponentHandlers" (and pooling) that are nice.
And finally, if "ServiceManager" is not managing services, why do we call
it a manager?
Thanks one more time for your help,
Pawel
American Express made the following
annotations on 12/09/2003 10:23:36 AM
------------------------------------------------------------------------------
******************************************************************************
"This message and any attachments are solely for the intended recipient and may
contain confidential or privileged information. If you are not the intended recipient,
any disclosure, copying, use, or distribution of the information included in this
message and any attachments is prohibited. If you have received this communication in
error, please notify us by reply e-mail and immediately and permanently delete this
message and any attachments. Thank you."
******************************************************************************
==============================================================================
