Aaron,
Thanks again for tons of useful information. More things start to make
sense; however, component is a good, industry approved concept for
encapsulating higher level logic using internal implementation/classes.
In your email you've essentially stated: "Component = Service". So far so
good but what happens if I want my Component (well, Service) to implement
more than one service? In the "old days", when components used to be
"Components", one could say:
my Component provides/implements/exposes two Services
now, one has to say:
my Service provides/implements/exposes two Services :-)
or maybe:
my Block provides services to other block through Services :-)
In the real world, one provides a particular services through his
"contract" with a client, he himself is not a service. Components
providing Services would echo this. I guess, this is more of a
logical/naming problem, so it's not such a big issue, although it makes
technology harder to learn.
Thanks one more time,
Pawel
From: "J Aaron Farr" <[EMAIL PROTECTED]> on 12/10/2003 03:01 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 Wed, 2003-12-10 at 17:07, Pawel X Karendys wrote:
> 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.
Let's see if I can clear things up.
First the history:
In the beginning there were only components. The components had a role
defined by a java interface and an implementation defined by a concrete
java class. In ECM and Fortress roles and components could be described
in a set of XML configuration files, generally one for the roles and one
for the implementations. In Phoenix land, roles were still roles and
components were still components, but they were defined in xinfo files
scattered across the various jar archives that would make up an
application. This was done to allow developers to deploy a jar file
that contained not only the interfaces and implementations, but also the
basic meta-data. Thus, the xinfo files and the conf files had the same
purpose but were used by different containers.
At this time, all components were children of the one
org.apache.framework.component.Component interface. A brave developer
scaled Mt. Doom and tossed the Component interface and all the other
marker interfaces into the fiery pit, thus freeing all components from
bondage of the one Component.
Upon return from this quest, the developer said, "All Components shall
now be dubbed Services" and a new set of ServiceManagers and
ServiceSelectors appeared that could converse with any Object, not just
Components. These Service utilities performed the exact same functions
as their deprecated Component counterparts, but didn't require
everything be a Component. That is:
Component componentManager.lookup(String role);
became
Object serviceManager.lookup(String role);
So in this sense, Components ARE Services. But now the Avalon community
had two names for the same thing and this is generally were confusion
arises.
Secondly, each container (currently) uses its own meta-data format.
Phoenix = .xinfo file + block level assembly files
Merlin = .xinfo, .xtype + block level "block.xml" files
ECM = single XML file for all roles,
single XML file for all implementations
Fortress = can use ECM style configuration
also uses simple 'meta-data' format with a services list
that lives in the META-INF directory of a jar file
In each case, the same basic information is being stored: what are the
services, what are the implementations, what are their lifestyles, do
they have any specific configuration information. The dream is to
eventually have everything use just one meta-data format (probably the
Merlin version) but still have backwards compatibility for legacy apps.
If things still aren't clear, that's understandable. Let me know what
needs clarified.
> 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?
The concept of block is an assembly level concept. A block really
doesn't exists at the development level or component level. It's only
when you get a bunch of services together that they create a block.
Let's make a bad analogy: automobile
The components and services are the low level nuts and bolts, wires and
tubes, pipes and bars. These get put together to create blocks which
perform a complete function: the engine, the fuel system, the air
conditioning. When all of these get put together you get your
application -- a car.
So some meta-data is really only applicable at the block level -- how do
these nuts and bolts get put together to do something coherent.
Additionally, the block lets other blocks know how to use it. It is
possible that a block could be just one really big component. That's
mostly a design issue. But in general a block is a set of components
which have been wired together (via meta-data) to perform a single
function.
> 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.
As suggested, if you can, but it up on a website and send the URL to the
list or a couple developers. That would probably be easiest.
Hope I'm actually clarifying and not just causing more confusion! :)
--
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/11/2003 08:04:47 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."
******************************************************************************
==============================================================================
