Component Lookup

Intent

To provide an interface into the component framework by which a component can lookup the signature of another component to see if it is currently plugged into the framework and available for communication.

Motivation

Consequences

In using ComponentLookup we reduce the overhead that would be generated if each component announced itself to all components currently plugged into the framework.

Writing this has raised a few questions in my mind, what happens if the lookup fails? If there is a dependency on another component, does the component executing the lookup instantiate the required one, or should the framework? Come to think of it, is the dependency a good thing, should it have existed in the first place? Obviously, these are all implementation issues and the mumblings of a mad man! -- StuartBarker

Not at all; these are very good points. Is this a pattern or an antipattern? This pattern describes "first-party binding". Discussions on ComponentDesignPatternsContext seem to have settled on ThirdPartyBinding being one of the distinguishing features of a component based system. How this pattern is applicable will depend on the "Context" and "Problem" of the pattern... could someone fill them in?

On a purely format-related note, the "Intent" seems to be more of a solution: there is some problem that is solved by allowing components to find other components. Also, the "Consequences" seem to be unrelated. Finding what components are already instantiated is orthogonal to being notified when new components are introduced, or at least both approaches can be traded off against each other. Or are these the mumblings of a madman? :-)

-- NatPryce

Thanks Nat, as a beginner I could do with all the help I can get. I imagine this panning out into something like RMI, a registry that components associate themselves with and then interested parties do a lookup to establish communication. I've rephrased the "Consequences", hopefully I've made it a bit clearer. -- StuartBarker

Bugger. Having read ThirdPartyBinding, what I'm essentially intending to describe here is the way in which a component will use the third party to achieve communication with another component. Is it worth going on? I don't think so. -- StuartBarker

The point of ThirdPartyBinding is that a third party, unknown to the components that need to interact, connects the components interfaces so that they can communicate. Components provide interfaces to the third party that allows it to perform binding actions, but do not call operations on the third party themselves. This gives components ContextIndependence - they do not have knowledge of the context in which they are used and so can easily be reused in a different context, or the context can easily be modified around them.

ComponentLookup hides context dependencies within a component, which reduces one's ability to reuse the component and makes the system harder to maintain. On the other hand, in an "open" distributed system - one in which new servers and clients can be introduced during the lifetime of the system - name-servers are needed to "bootstrap" initial connections and traders are needed to find servers that meet particular service requirements. But, IMHO, these naming and trading support object-oriented, rather than component-oriented, systems. For further discussions about what a component-based system is, see ComponentDesignPatternsContext.

-- NatPryce