Interface Discovery

Intent

Allow programmatic access to the methods and properties of a component so that its structure and protocol can be determined at runtime.

Motivation

When you are building a component-based system, one of the fundamental questions that arises is "How do you tie the components together?" Graphical development tools, CASE tools, "Trader" services and the like all need to be able to determine the structure of components in order to connect them up properly. Consider the following two examples to illustrate why this is important:

In most Graphical development environments, components are represented by "nodes" while connections between components (method sends, property settings, event notifications, etc.) are represented by "arcs". When a user of such a tool points at a node and says "I want to see what is available for connection to other components" how does the tool discover that information?
A "Trader" Service allows an object to request a service from another object whose identity is not known at runtime. For instance, consider a highly-available stock-quoting system. If a user needs a stock quote they honestly do not care what system provides that information -- they only care that some system can provide that information to them when they ask for it, accurately, correctly, and in a timely manner. The role of the "Trader" is to put together requestors of services together with providers of services. But how does the "Trader" know what objects can provide which services?

The answer to both these questions is to allow some standard, programmatic way of discovering what services an object can offer. In that way our Graphical Development Environment can query the "node" as to what endpoints are available for connection to other objects. In the same way, our "Trader" service can ask the objects registered with it what services they provide so that it can match requests with providers.

Known Uses

In JavaBeans, introspection through the the java.beans.Introspector allows you to programmatically access a Bean's properties and methods. A client discovering a Bean's interface would ask for a BeanInfo? object with java.beans.Instrospector.getBeanInfo(Class beanClass). If one doesn't exist, it introspects the Bean, looking for methods starting with prefixes "get" and "set" and returns a BeanInfo? manufactured from this information.

In COM, ITypeInfo and IDispatch allow for programmatic discovery of an object's methods and properties. Development tools like VisualBasic discover methods, properties, and events for ActiveX controls. It displayes a graphical table that allows users to customize properties of controls inserted into forms, and uses it to discover the envents that can be dispatched from the control back to the form so the developer can implement EventHandlers (e.g., MyWidget_OnButtonClick would be an EventHandler shown in the form's drop-down list of functions and subroutines for a control named MyWidget?).

In most CORBA implementations there is an Interface respository that you can query for information about Modules, Interfaces, Methods and the like. This information can be used to construct Request objects using CORBA's Dynamic Invocation Interface to make CORBA calls whose structure was not known at runtime.

Related Patterns

In Java, one can FallBackOnReflection to support InterfaceDiscovery.

When using scripting languages, such as Tcl, to control components one can write a BootstrapScript that dynamically creates new commands based on the interfaces of a component found by InterfaceDiscovery.

The common way that systems implement InterfaceDiscovery is to SplitDesignTimeAndRunTime.

Sometimes it makes sense to externalize this interface location and signature information. Components can use ContainerManagedPersistence to archive its discovery of interfaces. For instance, CORBA Beans [http://www.trcinc.com/corbabeans] covers archiving method signature information so your code doesn't need to be recompiled if and when it changes.

I guess this is the best reason for having accessor names that begin with "get". (And a pretty weak reason at that.) -- DaveHarris

Actually, code performing InterfaceDiscovery of JavaBeans should use the bean APIs and not assume that accessors have names that begin with "get".

Alternatively, one can avoid explicit interfaces altogether and use a ComponentBus.

[Above the pattern as it evolved in the old format; it is currently being morphed into our standard format below. -ed]

Context

Applicability

Problem

Forces

Solution

Participants

Structure

Collaborations

Resulting Context

Consequences

Known Uses

In COM, ITypeInfo and IDispatch allow for programmatic discovery of an object's methods and properties. Development tools like VisualBasic discover methods, properties, and events for ActiveX controls. It displayes a graphical table that allows users to customize properties of controls inserted into forms, and uses it to discover the envents that can be dispatched from the control back to the form so the developer can implement EventHandlers? (e.g., MyWidget_OnButtonClick would be an event handler shown in the form's drop-down list of functions and subroutines for a control named MyWidget?).

Example

Implementation

Sample Code

Related Patterns

In Java, one can FallBackOnReflection to support InterfaceDiscovery.

The common way that systems implement InterfaceDiscovery is to SplitDesignTimeAndRunTime.

This material seems to be relevant to the subject matter of ServiceOrientedArchitecture, which has become a new buzzword. Perhaps some of this content could be moved to that page. Or are we looking at systems and environments from a different level of granualarity?

CategoryInterface ComponentDesignPatterns CategoryPattern CategoryDiscovery