Nicolas, Your response was very helpful. It looks like different Avalon products and pieces of documentation take a little different spin on the Avalon's terminology, so precise clarification puts everyone on the same page. People that had a chance to grow with the system don't see this as a big problem but, unfortunately, it makes a newcomer's life much harder.
Thanks, Pawel From: "Niclas Hedhman" <[EMAIL PROTECTED]> on 12/12/2003 09:18 AM ZE8 Please respond to "Avalon framework users" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: RE: Avalon containers and good development practices (2) I think Pawel was more onto "semantics" than actual features. "Component" (capital C) deprecated concept and should be avoided at all times. "component" (lowercase C) a generic, layman term, used to casually describe something that is encapsulated. "Service" (capital S) explicit and official concept of exposure of a limited set of functionality thorugh the ServiceManager. "service" (lowercase S) a generic, layman term, user to casually describe that a functionality is somehow provided. "Block" (capital B) = Merlin's name for a component (lowercase C) exposing 1->N Services (capital S), all declared in a system of block.xml file(s). "block" (lowercase b) = aq very generic term for a part used to build something bigger. Avaloner are encouraged to be very specific, but we all break this promise from time to time. Niclas Farr, Aaron said: >> -----Original Message----- >> From: Pawel X Karendys [mailto:[EMAIL PROTECTED] >> >> 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 >> > <snip/> > > A component can implement more than one service. That's not a > problem. Of course, "client" code only ever sees the component as > one service or another. > > public class MyComponent > extends AbstractLogEnabled > implements Serviceable, Initializable, MyServiceOne, > MyServiceTwo > { > ... > } > > and then in some 'client' code: > > > MyServiceOne serviceOne = (MyServiceOne) > manager.lookup("serviceOne"); MyServiceTwo serviceTwo = > (MyServiceTwo) manager.lookup("serviceTwo"); > > serviceOne and serviceTwo may in fact be the same "component" (or > even instance) but client code will only be able to handle them > via the role interface by which they were retrieved. > > I know this is definitely possible in Merlin. I haven't tried it > with Fortress (Fortress may create two instances, one for each > service, I'm not sure). But the concept is definitely possible > and allowed. > > J. Aaron Farr > SONY ELECTRONICS > DDP-CIM > (724) 696-7653 > > > --------------------------------------------------------------------- > 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] American Express made the following annotations on 12/12/2003 07:56:07 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." ****************************************************************************** ==============================================================================
