Charisma Interface Model

Converse provides a common language runtime that allows efficient coexistence of software components within an application. However, software components in an application interact with each other by exchanging data and transferring control. An interface model defines the way these components interact with each other in an application. The ideal interface model for a parallel component architecture should have the following characteristics:

1. It should allow easy assembly of complete applications from reusable components. An interface description of the component along with the implicit understanding of the component's functionality should be all that is needed to use the component in an application. Thus an interface model should be able to separate the component definition from component execution.

2. It should allow individual components to be built completely independently, i.e. without the knowledge of each other's implementation or execution environment or the names of entities in other components.

3. Components should make little or no assumptions about the environment where it is used. For example, a component should not assume exclusive ownership of processors where it executes.

4. It should be possible to construct parallel components by flexibly grouping together sequential components.

5. Hierarchically composed parallel components should be able to interact with each other without being aware of each others' internal parallel structures.

6. It should not impose bottlenecks such as sequential creation, serialization etc on parallel components. In particular, it should allow parallel data exchange and control transfer among parallel components.

7. It should enable the underlying runtime system to efficiently execute the components with effective resource utilization.

8. It should be language independent and cross-platform.

In this chapter, we discuss these objectives in the context of Charm++, a message-driven object-based parallel language described in the next section. The Charm++ interface model satisfies some of the objectives listed above. In particular, Charm++ components do not assume exclusive ownership of the processor(s) where it executes, and hides the details of component construction by providing proxy interfaces. However, the Charm++ interface model, which is similar to traditional component architectures, uses a functional representation of component interfaces. Charm++ extends the object model by presenting the component functionality as methods of an object. Thus, a component interface description in Charm++ is similar to declaration of a C++ object. Components interact by explicit method calls using the interface description of each other. Extending the object model to specify component functionality has various limitations. In section 3.2, we describe these limitations. In section 3.3, we propose an interface model for Charisma that eliminates these limitations. We then describe our prototype implementation of this model.