This section describes what we mean by components and how we use components in NetPebbles. The NetPebbles component model is based on well-known concepts of interfaces, components, attributes, and globally unique identifiers. To encourage reuse of existing component software, we borrowed ideas freely from the Java Beans and ActiveX technologies. At a high level, NetPebbles components are self-contained Java Beans. However, like the ActiveX components, certain aspects of components are immutable and all aspects of components have globally unique identifiers.
In NetPebbles, an interface is a group of semantically related
methods or functions, while a component is an
implementation of the interface. A component can implement one or
more interfaces. Each interface and component is identified by a
globally unique identifier (GUID)
.
An interface's GUID is
called an InterfaceID, while a component's GUID is called a
ComponentID. Interfaces and components may have attributes
associated with them. Attributes provide either informative description
(such as its semantics and suggested use) or parameters to assist
the NetPebbles runtime (such as a preferred execution site
and usage cost). Attributes are also identified by GUIDs, called
AttributeIDs.
NetPebbles InterfaceIDs are immutable, i.e. once an interface
has been defined, both the syntax and semantics associated with the
interface cannot change. The InterfaceIDs are required
to be registered in a component catalog. The NetPebbles interface browser
allows an application developer to browse through these interfaces in
the catalog. The NetPebbles runtime uses the catalog to locate and bind
to components that implement the interfaces. NetPebbles
ComponentIDs and AttributeIDs are also immutable. Immutability of
ComponentIDs ensures that newer versions of a component do not cause
runtime exceptions because they no longer support published
InterfaceIDs. Immutability of AttributeIDs guarantees that semantics associated with
an attribute will not change from the point a NetPebbles program is
built to when it executes. Components provide necessary read-only accessor methods to
examine the ComponentIDs and AttributeIDs associated with a component.
In the Java Beans model, package names are used as a means to identify interfaces and components, however, this mechanism does not assure immutability of interfaces. The Beans model does not have a registry or a way to look up method signatures or properties without using introspection. NetPebbles addresses these shortcomings by using mechanisms from the ActiveX model.
Even though, ActiveX interfaces are immutable and a local component registry exists, the ActiveX programming model is component-centered. Typically an ActiveX programmer is expected to find a component (in the registry), instantiate it, and then ``discover'' interfaces supported by the component. NetPebbles view is that interfaces are the starting point for a developer. A developer specifies the needed interface and lets the NetPebbles runtime find a ``suitable'' component that implements the interface.
The NetPebbles interface browsing requirements have two related technologies: The CORBA trader service and the Light-weight Directory Access Protocol (LDAP). In the CORBA trader service [2], interfaces can be hierarchically organized and can have attributes that capture non-computational aspects. The hierarchical relationship can be used to capture both interface inheritance as well as attribute aggregation. However, to locate a component, a programmer still has to know the interfaces and attributes that the component supports. An integrated (perhaps, a visual) browser/search-engine that understands the relationships among interfaces, components, and attributes is needed for NetPebbles. We are investigating suitable enhancements to the CORBA trader service, and prototyping it using the LDAP [3] distributed directory technology.