Aaron you clarified alot for me! > > From: J Aaron Farr <[EMAIL PROTECTED]> > Date: 2003/12/10 Wed AM 10:01:12 EST > To: Avalon framework users <[EMAIL PROTECTED]> > 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] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
