Use cases for a MPIService implementation as a component

A component-based implementation of MPIService could be used in several ways by a framework implementor or application designer.

Case 1: Component acting as a Service in a dynamically assembled application

In this scenario, the component is loaded in the frame and registers itself with the ServiceRegistry to provide MPIService ports to requesters in the frame. The component has no special information, so it must be given a communicator or assume MPI_COMM_WORLD and check MPI_Initialized to determine if it needs to call MPI_Init. The component class appears in the list of instantiable classes the framework may provide to the user. The component is registered as a singleton service.

Case 2: Component acting as a normal component without auto-connection

In this scenario, the component provides communicators only to those clients specifically connected by the application designer. The component class appears in the list of instantiable classes the framework may provide to the user. ServiceRegistry is not used. This scenario supports most easily MCMD.

Case 3: Component acting as a service port instance in a statically linked application

In this scenario, the component class does not appear in the list of instantiable classes the framework may provide to the user. Instead, a non-component driver creates and manages an instance of the component via the getServices() method in the gov.cca.AbstractFramework interface.