certain enhancements, which are encompassed in Glasgow, became necessary.
The current specification of Glasgow consists of three parts. The first is an extensible run-time containment-and-services protocol. The second is the JavaBeans activation framework. The third is a drag-and-drop subsystem.
Bean Containers
The extensible run-time containment-and-services protocol is a component that lets Beans learn about their environment and the services it provides. This protocol addresses two fundamental issues related to a component model. The first is the establishment of a hierarchy relationship among the Beans. In a Windows-based environment, a well-defined relationship exists among an application's windows.
A dialog box, for example, is a child of a main window object. The focus for receiving events doesn't return to the parent window until the dialog box is dismissed. These types of relationships can and do exist among Beans, but no standard hierarchical arrangement i
s defined for them.
The second issue is the ability of a container to provide services to its components. A container is referred to as the
embedding context
in the Glasgow specification, and it's expected that it will provide a variety of services to its components. For example, a parent window may not let its components exist outside its boundaries.
Going back to our Windows environment, each component (perhaps a dialog box) has a container. Once again, Beans and containers (which could be Beans) are capable of such interactions, but there is no standard mechanism for doing so. The figure
"Run-Time Arrangements"
shows these two disparate relationships.
When a window is opened, the respective windowing API usually returns a handle or a descriptor for the window. This lets subsequent operations be performed on that window. This handle -- called a BeanContext in Glasgow terminology -- can manage the relationship between a Bean and its containing environment, or
other Beans.
To accommodate the hierarchical structure required by BeanContexts, Glasgow defines other interfaces,
java.beans.BeanContextChild
and
java.util.Collection
, which provide the means to manipulate a Bean by adding children to it or to traverse through its hierarchy.
The interaction among Beans -- or, more appropriately, BeanContexts -- is based on a scheme similar to the new event model introduced in the Java Development Kit (JDK) 1.1. The model describes interactions in terms of listeners and sources. A BeanContext interested in another BeanContext first registers itself as a listener, and subsequently it's notified of changes by the source BeanContext.
In actual implementation, BeanContext is basically an interface. It defines not only hierarchical information, but also methods for service discovery and provider facility. A Bean uses the
hasService()
and
getService()
methods to ask a BeanContext about its services and uses them when appropriate
. These methods also let JavaBeans learn about the operating environment and take advantage of any services the environment already provides.
Handling Data
The second part of Glasgow is the JavaBeans activation framework. In principle, it is similar to how helper applications in a browser work. When a browser receives a piece of data, it looks at the Multipurpose Internet Mail Extensions (MIME) type to determine the data's type. The MIME type was transmitted as part of the HTTP header. Once a browser determines the data type, it searches a table to see what helper application must be invoked to decode and display the data.
The activation framework brings this flexible capability to JavaBeans. The services provided are categorized into the following groups: the determination of of an arbitrary data type, the encapsulation of access to the data, the discovery of available operations on the data, and the instantiation of an object (Bean) that performs the desired operation on data.
A
DataHandler
is an object that acts as the main interface between an arbitrary piece of data and a client wishing to use the activation framework. A
DataSource
is an object that contains both the data and the MIME type of the data. A
CommandMap
is a mapping between the operations available on a data type and a series of
CommandObjects
that implement the operations.
The figure
"Dealing with Data"
shows a typical usage scenario. A client object has a piece of data (the
DataSource
), and it uses the activation framework to determine what to do with that data.
Drag and Drop
The last part of Glasgow introduces a drag-and-drop (D&D) subsystem, something long desired by GUI developers. Enhancements to the Java Foundation Classes (JFC) provide a standard method for performing D&D in the Java environment. This lets Bean-based applications integrate nicely into environments where D&D operations are supported. For example, y
ou could drop an object from OpenLook into a Bean.
The D&D mechanism is an extension of the Uniform Data Transfer Mechanism introduced in JDK1.1. Its goals are twofold. The first is to keep the implementation platform-independent. This is possible because the mechanism uses the Abstract Window Toolkit (AWT) and JFC, which are already standardized among different Java implementations. The second goal is to provide integration with platform-dependent D&D facilities. For example, this means potentially you could drag and drop an OLE object onto a Bean as if it were a native OLE object.
All D&D operations can be managed based on a series of distinct states of the objects involved. A single Drag Source and one or more Drop Targets must exist, and all could be Beans. The usage of terminology such as Drag Source and Drop Target points to a familiar naming convention associated with the new event model in JDK1.1.
In fact, the D&D operation is very similar to what happens during an ev
ent. The
DragSource
class defines the responsibilities of the source (the object initiating the operation).
DropTarget
does the same for the recipient object of the operation. Both objects also have a listener piece (
DragSourceListener
and
DropTargetListener
) that listens to events fired by their counterpart object. Collectively, these components are able to complete the D&D operation in a standard platform-independent manner.
While Glasgow consists of only three enhancements to JavaBeans, they are very significant ones. The run-time extensions allow the construction of hierarchies of objects, which is crucial in forwarding application events. The activation framework provides an infrastructure where Beans -- and future applications -- can transparently handle diverse types of data. Last but not least, D&D lets users simply drag information around the screen, wherever they need it.
illustration_link (22 Kbytes)
Glasgow establishes a hierarchy among Beans, so that events and data progress to the appropriate component.
illustration_link (19 Kbytes)
The activation framework lets objects transparently recognize and process data.
Piroz Mohseni is coauthor ofJavaBeans Developer's Guide(M&T Books, 1997). You can reach him at mohseni@iname.com.
Glasgow Enhances JavaBeans
