The designer's job

Let's start to implement the first component using the CCM Tools. We'll define an IDL file named Hello.idl (Example 3.2.1) that describes the component's structure. In this example, our IDL source file is stored in a hello directory on our development machine.

The IDL file defines a Console interface that contains a println method. The Hello component provides the console interface as a facet. This means the Hello component will appear to external component users as if it possess a method called println that is only available at certain times. In this case, the println method will be available to external components when some sort of receptacle speaking the Console interface is connected to the console facet.

Keep in mind that the IDL file contains no specification of what exact action this println method will perform! The component developer bears the responsibility of filling in the method functionality after the component code has been generated. So although this method could theoretically perform any task, most component developers would expect it to print out its string argument and return something like the number of printed characters.

This component also has an attribute called prompt. Just like the method, the component's attribute could store any string; the IDL file contains no information about the attribute other than its data type! Most likely, though, it will store the command prompt for some user input. Finally, the HelloHome is defined to manage the Hello component.

Thus, we have created the following file structure:

        hello/
        |-- Hello.idl

Well done! We have designed an example component and created the corresponding IDL definitions. Note that the component designer normally defines the external view of a component as a part of the whole application structure, so in a real application there would be more components that would be capable of performing other distinct actions in the application.