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]
