A Software Composition Language and Its Implementation
Binary software components offer solutions to various software engineering problems, e.g. how to build and maintain complex software systems in a changing environment. The idea is to acquire prefabricated, well-tested and platform independent binary software components on the market and to compose them to new applications by plugging them together in builder tools without the need for coding. There are already markets  for components as well as some common understanding about the term software component .
The composition of binary software components divides the development process into two parts. First, component developers write new component libraries and second, application programmers use them to compose their applications. Often different individuals assume these roles. This leads to a knowledge gap, as the application programmer has to determine how and in which context he can apply the different components. Of course, a component provider has to state the component's context dependencies clearly in a proper documentation.
The full paper introduces the idea of component plans and their description in Component Plan Language (CoPL) that tries to bridge this gap and the idea of a component technology independent composition language as an XML  application, called Component Markup Language (CoML). Whereas in the paper we focus on the description of CoML.
A component plan describes how an application programmer typically glues components of a given library together. A plan is a description of a composition with Decision Spots. Typically a plan is written in CoPL and captures domain knowledge and typical usage scenarios or composition patterns by providing a typical pre-wiring of the used components. The application programmer processes these CoPL plans with a generator. The generator produces CoML code which can be used by different IDEs for different component technologies. Figure 1 shows a typical usage scenario for CoPL and CoML.
The generator uses the plan as input and - if stated in the plan - asks the application programmer to substitute place-holders by concrete components from a list of matching component implementations. We call these place-holders Decision Spots. Currently the matching algorithm is based on type substitutability.
On the one hand writing glue code manually gives the application assembler great flexibility, where on the other hand tools (e.g. wizards) automate routine and clearly predefined composition tasks, like generating a code snippet for a new GUI dialog. A possible way for combining the advantages of these composition techniques is to introduce a "script-able generator". In fact, a CoPL plan is used for scripting the generator. The interpreted plan guides application programmers semi-automatically (similarly to a wizard) through the assembly process for example by displaying a dialog for choosing the desired implementation (e.g. ArrayListImpl) for a given interface (e.g. for an "IList" interface). In contrast to a wizard, a plan is not fixed but can be modified. It is like a composition template with some degrees of freedom. A plan may contain Decision Spots that offer choices to the application programmer.
Considering a library with many components, it is a tedious task to find the right components and to instantiate and glue them together according to the desired composition pattern. Our component plans along with the generator automate this process by supplying the programmer with knowledge about how the component developer intended to wire the components.
CoPL is based on previous work on JavaBeans  composition using plans (see ). However, CoPL and CoML are not tuned toward a special component technology like JavaBeans, or Microsoft's .NET  components.
The Component Markup Language (CoML) is an XML application for composing software components. The main goal for CoML is to have a platform independent description of component composition which is process-able by various software tools like development tools. CoML can be interpreted like other scripting languages. In our intention CoML should primarily be created and used by software tools rather than require human beings to manually write (and execute) CoML scripts. However, in the spirit of XML, we still tried to make CoML human readable as well and developed an interpreter for the Java and the .NET platform.
In order to keep CoML component model independent we had to define minimum requirements for component models script-able by CoML:
Based on this assumptions about component models, CoML offers first class abstractions (i.e. XML tags) for describing a component composition. CoML tags can be used for:
Example 1: This CoML snippet shows a simple composition of two GUI components - a slider and a progress bar. When the slider is moved, the slider's current value is displayed in the progress bar. Slider and progress bar are connected via the change event. The slider is the event source and the method setValue of the progress bar is the event sink. The target component platform is JavaBeans from Sun.
<component id="progBar1" class="javax.swing.JProgressBar" > <property name="value" access="set"> <int>50</int> </property> </component> <!-- progress bar reacts upon the sliders change event --> <component id="slider" interface="ISlider" class="ssw.webui.Slider"> <on-event name="change" filter="stateChanged"> <method-call name="setValue" idRef="progBar1"> <property idRef="slider" name="value" access="get"/> </method-call> </on-event> </component>
Sun and IBM have developed their own composition language based on the meta syntax XML. However both, Sun's JavaBean Persistence  and IBM's Bean Markup Language (BML) , are tailored for JavaBeans.
The main goal of Sun's approach is to have a proprietary standardized format for exchanging mainly GUI JavaBeans compositions between different Java IDEs. At the beginning of the project we tried to use Bean Persistence as the primary output of the Generator. Unfortunately Bean Persistence expressiveness for composing components via events is too limited for our purposes.
An application programmer uses component plans at design-time, i.e. when he assemblies the components to a new application. The benefits are to have a script-able wizard, that produces a platform independent description of a concrete component composition.
The output of the generator is a composition description in CoML. CoML is component technology and platform independent. Different tools like development tools, documentation tools or software architecture visualizing tools can use CoML for e.g. exchanging component compositions or displaying them in different manners. Of course, CoML can be interpreted as well and currently we have interpreters for Java and Microsoft's .NET component platform. We have a research prototype for composing JavaBeans which uses CoML as its persistence format.