1 Introduction

  Now, more than ever, it is not enough for applications to fulfill only their functional requirements. Modern applications must be flexible, or ``open'' in a variety of ways.

The Concise Oxford Dictionary defines ``flexible'' as: ``that will bend without breaking, pliable, pliant; easily led, manageable; adaptable, versatile; supple, complaisant.'' Software that ``bends without breaking'' is portable (to different hardware and software platforms), interoperable (with other applications), extendible (to new functionality), configurable (to individual users' or clients' needs), and maintainable. These kinds of flexibility are currently best supported by component-oriented software technology: components, by means of abstraction, support portability, interoperability and maintainability. Extendibility and configurability are supported by different forms of binding technology, or ``glue'': application parts, or even whole applications can be created by composing software components; applications stay flexible by allowing components to be replaced or reconfigured, possibly at run-time.

Currently there is considerable experience in component technology and a lot of resources are spent in defining component models and components. However, much less effort is spent in investigating appropriate glue technology. Specialized scripting languages and 4GLs each provide different forms of glue. Glue can be either highly structured, reflecting a particular architectural style of application composition, or it may be largely unstructured. Structured glue constrains flexibility by limiting the ways in which components may be configured, but supports application maintainability and comprehension by making application architecture explicit [MDEK95]. Unstructured glue is ultimately more flexible, but at the cost of maintainability: Tcl [Ous94], for example, is a simple scripting language that is good for combining arbitrary C functions for simple configuration tasks, but it does not support programming in the large, and, if abused, can lead to large, unmaintainable scripts.

At present, there exists no general-purpose composition language that supports both application configuration through structured glue (AKA ``connectors'' [SG96]), as well as the specification of architectural styles by defining different kinds of connectors. In our view, a composition language would be a combination of an architectural description language and a scripting language and could also serve as the back end to a visual composition environment [NM95].

We are presently prototyping a composition language called PICCOLA (``Pi Calculus-based Composition Language''), whose formal semantics is specified in terms of the $\pi$-calculus [Mil89]. In our view, a general-purpose composition language must be formal to support reasoning about component configurations. In particular, a composition language should support the following features, each of which benefit from formal semantics:

• Active Objects: objects are computational entities that provide services based on an encapsulated state. Objects may be active (concurrent), distributed, mobile, and may live in different environments. A composition language must be able to instantiate and communicate with active objects.
• Components: components are abstractions over the object space [ND95]. Components may be fine-grained, when used to build individual objects, or coarse-grained, when used to build compositions of objects.
• Glue: glue mechanisms and operators (connectors) define how associated components interact with each other [SG96]. A composition language must support the specification of new kinds of connectors.
• Object Models: a composition language must be able to bridge the gap between different object models. Objects and components that cannot be separated from their individual run-time environments must still be able to communicate. Connectors must achieve the mappings between these object models.
• Reflection: glue is often realized by intercepting messages between objects and performing some (reflective) transformations on these messages [Ber94,DBFPD95]. Reflection is also important for exercising run-time control on configurations. Metaobjects are active objects that control the creation, instantiation, and composition of other objects [LSN96] and can be used to realize various forms of reflective behaviour.
• High-level syntax: the specification of an application as a composition of components must be highly readable and compact. It is, therefore, important to be able to assign a high-level syntax when defining components (as is possible in languages like Smalltalk).

So far we have been using the $\pi$-calculus both as a formal specification language for modeling objects, components, and connectors as processes and as metaobjects and as a prototyping language. The $\pi$-calculus is admittedly low-level, and working with it is like programming in a kind of ``concurrent assembler.'' On the other hand, it provides the possibility of developing higher-level abstractions which can then be used directly to model the features of interest.

In this paper, we show problems of existing component and glue models and discuss requirements for a general-purpose glue model. We also report on our initial experiences in modeling components and glue with the $\pi$-calculus and describe our first steps in developing a platform (called JPICT) for experimenting with the design of PICCOLA. We conclude with some remarks about future work and directions.