Computer Science

System Software

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 [4] composition using plans (see [5]). However, CoPL and CoML are not tuned toward a special component technology like JavaBeans, or Microsoft's .NET [6] components.

CoML - Component Markup Language

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:

• a component is strongly typed
• a component is accessed via interface(s)
• a component interface offers methods and/or properties
• a component uses an event-mechanism as its primary ``wiring'' technique for plugging components together
• the component life-cycle is split into design-time and run-time and thus between wiring components versus creating instances

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:

• defining the component itself
• setting and getting properties
• defining event-bindings and thus wireing differnt components
• placing method-calls
• building up a containment hierarchy

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>

Related Work

Sun and IBM have developed their own composition language based on the meta syntax XML. However both, Sun's JavaBean Persistence [8] and IBM's Bean Markup Language (BML) [9], 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.

CoML is influenced by BML. The main differences are that CoML is not focused on JavaBean composition, that CoML supports interfaces where BML allows explicit type conversions, that CoML does not allow embedding of foreign scripting code - like JavaScript [10] - in order to remain platform independent.

Conclusions

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.

Plans along with the generator are used at a different point in time than scripting languages, which are typically interpreted or executed (like e.g. Piccola [7], JavaScript or IBM's Bean Markup Language). These languages are interpreted at run-time, i.e. at the end user's computer during actual execution of the application.

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.

Bibliography