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]
