Aaron,
Your response was more than I've expected and provided a lot of great
details. However, I still have a couple of questions:
1) I was able to gather from Avalon's web documentation that: a)
Components have roles and use "conf" files for their roles' mappings b)
Blocks have services and use "xinfo" to expose their services and to
specify their dependencies on other services c) This means that Components
should not implement Services but just roles! You've put, sort of, an equation sign
between Components and Services.
2) I still don't understand why did Avalon people introduced another
concept such as a Block. Since a Component can also be a Container, it
could represent a larger (block-like) application concept. Just by
implementing some sort of Serviceable marker interface it would let others
to know its intensions of being a Service. Was someone trying to confuse
us with the concept of a Block?
3) Who, do your think, would be best to review an Avalon PP presentation?
I don't want to send it to the whole list for comments.
Thanks,
Pawel
From: "J Aaron Farr" <[EMAIL PROTECTED]> on 12/09/2003 01:49 PM GMT
Please respond to "Avalon framework users" <[EMAIL PROTECTED]>
To: "Avalon framework users" <[EMAIL PROTECTED]>
cc:
Subject: Re: Avalon containers and good development practices (2)
On Tue, 2003-12-09 at 17:23, Pawel X Karendys wrote:
> 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.
Here's the way I explain it:
The smallest unit is the Service. The Service has at least two parts:
1. The interface (or ROLE)
2. The implementation (one or more)
The words Service and Component can be used interchangeably. I often
use Service to describe the interface and Component to describe an
interface and implementation, but the semantics are not fixed here.
You can then add meta-data or meta-info (depending on who you talk to)
to a Service:
Service + Meta-Data = Appliance
The term appliance is only used in Merlin. An appliance has all the
information necessary to tell a container how to deploy, use and remove
the service.
The term "block" has been used in a number of ways. Generally, a block
is a collection of one or more services (so it can be just one) which
performs some relatively complete application function. So a webserver
could be a block. It might be composed of one or more services. Some
services may be internal to the block. Some may be exported for other
blocks to use. A Cache or PersistentStore might also be called a block
and may consist of only one component.
So when speaking of a block, we need to consider scope. Additionally,
Phoenix and Merlin used the term block differently. In phoenix, an
application (single SAR deployable) might be composed of one or more
blocks. More than one application could be deployed simultaneously.
In Merlin, there was one root block which could have sub-blocks, so a
Merlin block was not completely analogous to a Phoenix Block. However,
this terminology has changed slightly and now Merlin uses the term
'container' interchangeably with block.
In summary, it can be a little confusing to figure out what means what
because to a degree it depends on if you're talking about Phoenix,
Merlin, Fortress or just abstract concepts. Hopefully this didn't
further confuse you. :)
> Consequently, since Component interface has been deprecated, is the same
> going to happen to the "ComponentManager" and the "ComponentSelector"? ?
> how about the "RoleManager"?
ComponentManager and ComponentSelector have been replaced with
ServiceManager and ServiceSelector. Although there are some problems
with the Selector interface, so it's a good rule of thumb to avoid it if
possible.
RoleManager is supported in Fortress, but also discouraged. Instead, we
are moving to a single meta-data model. In Fortress there is a
MetaManager (I think that's what it is called) and eventually we'll move
Fortress to support the same meta model as Merlin. However, you can
still use the RoleManager in Fortress. It's there mostly for legacy
support.
> 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.
You're free to use ECM or create your own lightweight container, but
you'll often find yourself adding this and that until you end up with
Fortress. Fortress is a very nice simple Avalon 4 container that
provides just about everything you need. Yet if Fortress is still too
much and you don't want to use something depricated like ECM, you can
actually create a _very_ simplistic Avalon container out of something
like PicoContainer.
The choice of Containers is all about need. In some cases you need the
crazy features of Merlin. In other cases, those features can just get
in the way. At least, that's my $0.02 on the subject.
> And finally, if "ServiceManager" is not managing services, why do we
call
> it a manager?
ServiceManager has two functions:
1. Supply service dependencies to other services
2. Allow simple service lookup and discovery
So in some sense, it's more a ServiceLookup service than a Manager. And
there has been some discussion about how to seperate out these two
semantics and still provide legacy support. For example, Merlin only
uses the ServiceManager for dependency resolution, NOT for service
discovery.
> Thanks one more time for your help,
No problem. These are good questions and remind me that I really need
to put together more documentation. :)
--
jaaron <http://jadetower.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
American Express made the following
annotations on 12/10/2003 10:07:39 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."
******************************************************************************
==============================================================================
