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?
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
