http://www.cs.wpi.edu/~heineman

Abstract

1 Introduction

Our focus is on supporting both component designers and application builders: the designers will be aided in creating components that can easily be adapted (thus increasing reuse), and for the first time, application builders will have mechanisms for adapting software components. By design, black box components often only allow minimal customization and are reusable if they exactly match a particular need in an application. However, the use of the component is also heavily dependent on the ability for application builders to adapt the component for use in different applications.

We make a distinction between software evolution, where the software component is modified by the component designer, and adaptation, where an application builder adapts the component for a different use. We also differentiate adaption from customization; an end-user customizes a software component by choosing from a fixed set of options (such as OIA/D [Kicz97]). An end-user adapts a software component by writing new code to alter existing functionality.

1.1 ADAPT

• A Component specification language for specifying the interface of a component and how it is adapted.
• Active interfaces

1.1.1 Component Specification Language

component Spreadsheet {
  implements Serializable,
             SpreadsheetListener;

  // one-dimensional property.
  indexedProperty Function function(String)

  // one-dimensional property.
  indexedProperty String Value(String);

  // Basic state properties of this component
  property boolean debug;

  // Methods
  float  getNumericValue(String);
  void   installFunctions();

  float  evaluateConstant(String);
  void   evaluate(Node);
  float  calculateFunction(Expression);

  // expects add/remove
  void addSpreadsheetListener(SpreadsheetListener);
  void removeSpreadsheetListener(SpreadsheetListener);

  // SpreadsheetListener Interface 
  void handleSpreadsheetEvent(SpreadsheetEventObject);
}

The ADAPT (Architectural Description of adAPTable components) language is used to describe the interface for a component and its adaptations. If the component is written in a reflective language, such as Java, then the specification for a component can initially be generated directly from the component. The above figure describes one such specification generated for a Spreadsheet Bean. This Bean supports a set of spreadsheet services, allowing clients to set individual cell values (through the Value property), and allows external client Beans to become listeners for refresh requests as new values are added and computed. An ADAPT description provides a convenient place to specify adaptations to the component, as we now describe.

1.1.2 Active Interfaces

Suppose that the application builder wishes to modify the Spreadsheet Bean in Figure 1 so that it generates an event whenever the particular value of a cell changes (for example, because the cell contains a calculated formula), not just when the contents change; for example, changing a cell from "(+ 2 3)" to "(* 5 1)" changes the contents, but not the value. The application builder could modify the component directly (which we are trying to avoid) or filter out messages from the Spreadsheet (but this would require the client to store duplicate values to detect differences, and is space/time inefficient). We use an active interface to insert a before-evaluate function that has the Spreadsheet component record the value of the cell before its update and an after-evaluate function that compares the new value against the old; if the values are different, the after-evaluate function generates the appropriate notification. These functions would then be incorporated into the object ss, the instantiation of the Spreadsheet component. With this scheme, different component objects from the same class can be adapted in different ways, offering even more flexibility to the application builder.

component ss adapts Spreadsheet {
  code      code.jar;
  action    storeValue (in Node);
  action    compareValue (in Node);

  void evaluate (Node node) {
    before   storeValue(node);
    after    compareValue(node);
  };
};

Active interfaces are different from the pre-packaged implementation strategies of OIA/D [Kicz97]. OIA/D sketches a solution showing how the client can provide their own implementation strategy, but typically an entire method for a component is replaced. Our approach is more fine-grained, allowing adaptation to occur when needed. We do not violate the encapsulation of the component, since the methods invoked within the active interface do not directly access private information in the component. Thus the component designer has great flexibility, and can place the responsibility for correctness on the application builders that adapt the component.

1.2 Context

We are interested in extending the JavaBean component model to distributed applications. In particular, we are designing a message framework called SOWER on which a distributed application composed of beans can be built. SOWER is based on the Event-Based Software Integration (EBI) described in [Barr96]. The key features of SOWER are:

• It is integrated with the BDK.
• JavaBean components can be used as is without modification.
• Connector code is automatically generated as needed to deliver JavaBean events between remote components.
• The registration of the communication between Beans is separate from the actual delivery of Bean events.

2 Requirements

2.1 Core Requirements

1. Separation of physical composition from logical composition. JavaBeans provides a convenient abstraction for communication between two components, and the distribution mechanism must maintain this separation.
2. Using JavaBeans without design modification. The JavaBeans standard is gathering support in industry, so any approach to building distributed applications must be compatible with the basic Bean model.
3. Support for dynamic configuration. The framework enabling communication between distributed Beans must allow the application builder to deploy and move Beans between each site. The virtual communication between Beans should be flexible enough to be reconfigured when Beans move.

2.2 Advanced Requirements

1. In Situ Adaptation. When adapting the behavior of a class C, object-oriented design methodologies suggest that a new subclass SC be created that extends C to create the new, desired functionality. This approach does not work when we wish to adapt the behavior of a component. First, even though a component may syntactically be equivalent to a class (as in JavaBeans), inheritance is ill-suited for such adaptation. Consider a component constructed using the Facade design pattern [Gamm95]; creating a subclass of the Facade class complicates the design. Second, once a component is deployed, the application builder should be able to adapt the component by supplying new code to be integrated into the component; inheritance is strictly a compile-time mechanism.

3. Conclusions

References

1. [Abow95] Formalizing Style to Understand Descriptions of Software Architecture. ACM Transactions on Software Engineering and Methodology, 4(4):319-364, October 1995.
2. [Barr96] A Framework for Event-Based Software Integration. Daniel Barrett, Lori Clarke, Peri Tarr, Alexander Wise. ACM Transactions on Software Engineering and Methodology, 5(4):378-421, October 1996.
3. [Gamm95] Design Patterns: Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison-Wesley, 1995.
4. [Hein97] A Model for Designing Adaptable Software Components. George Heineman. Submitted for Publication.
5. [Kicz97] Open Implementation Design Guidelines. Gregor Kiczales, et al. 19th International Conference on Software Engineering, pages 481-490, May 1997.
6. [Rama97] A Emacspeak: A Speech-Enabling Interface. Dr. Dobb's Journal, 22(1):18-23, September 1997.
7. [SUN97] JavaBeans 1.0 API Specification. Sun Microsystems, Inc. December 4, 1996.
8. [Yell97] Protocol Specification and Component Adaptors. Daniel Yellin and Robert Strom. ACM Transactions on Programming Languages and Systems, 19(2):292-333, March 1997.