Peter, This won't help, but when we obsoleted the name ComponentManager for the sake of ServiceManager (Composable for Serviceable) we compounded the issue. That the need was there I am not disputing :-)
- Paul >Hi, > >On friday I was working through some architecture designs and kept coming >across the same old issues with terminology. In Avalon we tend to mix terms >around quite a bit without any rigourous usage of one set of terms. We have >in the past also used generically named marker interfaces (Component+Service) >and differ in how we interpret our terminology (ie is Role the lookup key, >the contract, the physical contract, the intention to use contract, etc) > >Recently even Berin misunderstood something because we were using a generic >term (Service) to refer to specific ideas. I also had problems explaining >things recently because I was using the same term (Service) to mean 4-5 >different things depending on context (WebService, "service handlers", work >interface, implementor of work interface etc). > >So I guess I was wondering what the best strategy is for minimizing confusion. >My initial thoughts were to use very specific terms when dealing with very >specific things and to shy away from generic terms. > >Anyways the things we need to define terms for include the following ideas. >Consider the case where one implementation A wants to provide some feature F >via key K to implementation B. > >A = DefaultConnectionManager >B = FTPServerImpl >F = ConnectionManager (and associated metadata if any) >K = ConnectionManager.ROLE > >Phoenix refers to A and B as blocks, while ECM/Fortress refer to them as >Components. Other containers (ie Myrmidon) may refer to them as services. > >Phoenix may also refer to A as a "Provider" and B as a "Consumer". It may also >say that B is dependent on F that is provided/satisfied by A. Other >containers have used terminology such as "uses". > >In Phoenix F is named the Service and K is the role while in Fortress there is >no distinction and F+K == Role. > >Anyways I would like to see some more consistent terminology usage. We have >some terms that mean different/conflicting things in different container >contexts. > >So anyone got any good suggestions? Basically we have a diagram like > > > +---+ *---* +---+ > | A | ----------#> | F | <----------- | B | > +---+ *---* +---+ > >A and B are java classes >C is a java interface > >And we need to come up with a consistent terminology for A, B, F and the >relationships A->F, F->B. Also we may need to define the "B end" of B-F >relationship and the "A end" of A-F relationship > >Some options; > >A = Provider or ServiceProvider >B = Consumer, ServiceUser, ServiceClient >F = Role, Interface, Service, Work Interface, Facet (as in each component > has many facets) >A->F = Provides, Implements, Exports >F->B = Requires, depends, needs, uses >A end = (same terminology as A-F mainly) >B end = Dependency, Receptacle, Need > >Any other terminology ? Any preferences? > My preference FWIW, is to use terms from those already marketted and not to add any more. So +1 to choices from Role, Interface, Service, Implements, Provides & Requires (used in manifests) And -1 to Facets, Provider, ServiceProvider, Cunsumer, ServiceUser, ServiceClient, WorkInterface, Exports, Depends, needs, uses, receptacle. If we have to obsolete some from the currently used set, then so be it. We're now better at referring to Avalon as Avalon-Framework or Avalon-Phoenix etc, I think the best course of action is term reduction, a terminology page and some coaching on use. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
