Next: Related Work
Up: ContextBox: A BeanBox Environment Components
Previous: ContextBox: A BeanBox Environment Components
Glasgow [7], Sun's code-name for the new release of the JavaBeans [8] component model specification, lists the extensible runtime containment and services protocol [9] as one of three new capabilities added to the JavaBeans component model (the other two are [10] and [11]). This is manifested in Java 2 (JDK 1.2) in a new java.beans.beancontext package. Components implementing the BeanContextChild interface may interrogate their enclosing BeanContext environment to dynamically discover and employ services.
The precise details of application, however, remain nontrivial. Much of the complexity with the newly introduced context package rises from the possibility of the component to simultaneously belong to more than one of the three different logical hierarchies: a collection hierarchy, a visual hierarchy, and the new context hierarchy, each governed by a different, sometimes contradicting, set of constraints and rules. For example, a Container cannot implement a BeanContext directly, but may be associated with one by implementing the BeanContextProxy interface [9], all because of a method name collision.
Arguably, the BeanContext specification and API alone are insufficient for utilizing the new concepts quickly: the documentation is complicated to understand, and open to interpretation. The new java.beans.beancontext package is an API, not a set of guidelines, and the overall learning curve remains steep [12]. Unfortunately, the JavaBeans example was not followed.
Unlocking the JavaBean API and its underlying philosophy would have been hard without the availability of the Bean Development Kit (BDK) [13], also called BeanBox [14] after the name of its main class. The BeanBox permits running demos. It permits testing your own beans. It demonstrates the functionality expected from a visual builder. You can determine, for example, whether a reluctant bean is really not working properly, or whether the commercial environment is at fault, by also testing the bean in the BeanBox. It is not a development tool, but rather a testing and demo tool.
What is missing is a similar lightweight demo, assembly, design, and testing environment, like the BDK, but one that also supports context-nested beans. Such an environment would serve three purposes; it would provide: (1) a vehicle for demonstrating good examples of runtime discovering of services; (2) a third-party client for testing user-made runtime containment components; and (3) a prototype (but not necessarily a role model) for visual bean-builder environments to follow. As far as we know, none of the commercial JavaBean builders fully support the runtime containment and services protocol [9].
In this paper, we lay out the concerns and explain what is needed in order to provide a meaningful assembly and design environment for manipulating context components. We identify the lifetimes and visual-dimensions of components at assembly and design time, we map the assembly-design space, and we describe how to support nesting of context components.
We present an actual working implementation,
which we name ContextBox
,
of an environment
for demonstrating, testing, or prototyping a visual
context bean-builder. ContextBox is an extension
of JavaSoft's BeanBox. It adds to the BeanBox
several new features that are useful for the
developers and programmers working with
BeanContext objects. It was created as a
byproduct of our need to quickly test our own
beans that implement the BeanContext interface,
and now we wish to share it with everyone.
The ContextBox environment allows BeanContext developers to test and evaluate JavaBeans components implementing the extensible runtime containment and services protocol. We enhanced the BeanBox with new visual manipulation capabilities for nested beans, so that it is possible to drag and drop, serialize and de-serialize, group and ungroup nested beans. By means of these visual manipulations, beans can be put inside other beans.
We also expose the inner working of the BeanBox, thus promoting potential reuse, and simplify the implementation cost of others. We report lessons learned from our experience of reusing the BDK software.
Next: Related Work
Up: ContextBox: A BeanBox Environment Components
Previous: ContextBox: A BeanBox Environment Components