4 Conclusions and future work

When we talk about components we tend to ignore fact that components are more or less useless without an appropriate framework and gluing mechanisms. Furthermore, we argue that a single component is a contradiction in terms. When we talk about components we have to be aware that a specific component always belongs to a specific component framework.

It is the component framework which defines the software architecture of the components and the possible gluing mechanisms. The framework defines the kinds of interfaces that components may have and the rules governing their composition.

What all component models have in common is that they define components more or less as black box entities. Unfortunately, each component model also defines its own composition mechanisms, which usually cannot be applied to components of other component frameworks. Therefore, it is necessary to find basic mechanisms that allow to compose arbitrary components even if they belong to different component frameworks.

Our work addresses exactly this issue. We are trying to combine modern scripting mechanisms with component technology. The use of the $\pi$-calculus as the formal semantics seems to be the right direction. A composition language must provide means for configuration and execution of programs. Configuration is described by setting up components as parallel processes. The execution of this configuration takes place with the help of communication and process reduction. The application programmer does not have to use the primitive $\pi$-calculus constructs; our composition language provides all necessary higher level abstractions. Furthermore, we intend to add support for metalevel programming. With this metalevel we hope to get a system which is easy extendible in order to add new (possibly not yet known) component models.

We have learned from our modelling of various object-oriented abstractions in the $\pi$-calculus and the design of PICCOLA that the $\pi$-calculus serves as a good formal basis for our work. But as we have already mentioned, working with the $\pi$-calculus (PICT) is like programming in a concurrent assembler. We intend to develop an extented $\pi$-calculus which we call a composition-calculus. This composition-calculus will constitute the formal basis of our composition language. The definition of this calculus is driven by two directions: i) the application of the $\pi$-calculus to find suitable higher level abstractions and ii) the formalization of language constructs which constitute the core set of the composition language.

An important aspect of our next work is the evaluation of different type systems. Currently we use dynamic typing in our system. But dynamic typing also means that only a predefined set of types is allowed to be used for components. This works well in most cases, but when we add a new component model with a richer type system, it will break the existing type system. It is not acceptable to reduce the supported types only to some basic types like Integer and String. We need greater flexibility here. We hope that the metalevel of the composition language will help us to integrate also new types and type representations.

Beside the language design we also experiment with different compilation techniques. As already mentioned, we think that real object-oriented compiler construction is the right way for language prototyping. Unfortunately, Java does not support a rich set of metalevel programming. We have tested other platforms (e.g., Delphi, C++) that have a better support for modelling metaclasses. With these systems we got first results which are promising. We have implemented the lexical and syntactical analysis only by using metaclasses. These metaclasses represent the building blocks of the language. When the compilation starts, all metaclasses are registered in the system. This allows us to change the language and the compiler quite easily simply by adding or removing metaclasses. Each metaclass is fully responsible for the language construct it is implementing. Therefore, a metaclass does not change anything within the compiler. This approach is still in an experimental state and will be presented in future work.

Our prototype language compiler does not address efficiency, but flexibility. Furthermore, we have two systems in one: an interpreter as well as a compiler. We only need to change the mode of our system in order to switch between interpretation and compilation.

When do we call a software development environment a composition environment? A composition environment must be built of three parts: i) a reusable component library, ii) a component framework determining the software architecture, and iii) an open and flexible composition language. Most of the effort in component technology was spent on the first two parts. Now it is crucial to find an appropriate model to glue existing components together. In our opinion, the $\pi$-calculus is a powerful system in order to fill the missing gap in an elegant and natural way.