Demand for rapid prototyping and cross-project reuse of object libraries has stimulated growth of component architecture in industry. Individual companies (e.g. Microsoft, Sun) and consortia (e.g. OMG) have developed different component architectures to meet this demand in the distributed computing world. Component architectures in the distributed programming community (such as COM, JavaBeans, CORBA) do not address efficiency issues that are vital for coupling parallel software components. Though all of them support in-process components, they incur overheads unacceptable for the needs of parallel component integration. Microsoft COM has limited or no cross-platform support necessary for the emerging parallel computing platforms such as the Grid [23]. JavaBeans have no cross-language support, and needs components to be written only using Java, while FORTRAN dominates the parallel computing community. CORBA supports a wide variety of platforms and languages, but does not have any support for abstractions such as multi-dimensional arrays.
Parallel computing communities in academia and various U.S. national laboratories have recently formed a Common Component Architecture forum [22] (CCA-forum) to address these needs for parallel computing. Common Component Architecture (CCA) [5] is one of the efforts to unify different application frameworks. The CCA approach tries to efficiently connect different applications developed using various frameworks together by providing parallel pathways for data exchange between components. The CCA Forum has developed a Scientific Interface Description Language (SIDL [21]) to allow exchange of multi-dimensional arrays between components, and have proposed a coupling mechanism (CCA-ports) using provides/uses design pattern. For parallel communication between components, they have proposed collective ports that implement commonly used data transfer patterns such as broadcast, gather, and scatter. In-process components are connected with Direct-Connect ports, which is close in efficiency to a function call. However, these component method invocations assume blocking semantics. Also, CCA restricts itself to SPMD and threaded programming paradigms, and does not deal with coexistence of multiple non-threaded components in a single application. Hooking up components dynamically is listed among future plans, and it is not clear how the efficiency of coupling will be affected by that.
The most suitable way of combining multiple components using CCA is by developing wrappers around complete application processes to perform parallel data transfer, delegating scheduling of these components to the operating system. Heavyweight process scheduling by the operating system leads to coupling inefficiencies. If the communicating components belong to different operating system processes even on the same processor, invoking a component's services from another component requires an inefficient process context-switch. For example, on a 500 MHz Intel Pentium III processor running Linux, invocation of a ``reflector service'' (that returns the arguments passed to it) takes 330 microseconds when the service is resident in another process, while it takes 1.3 microseconds for service residing within the same process (Corresponding times on a 248 MHz Sun Ultra SPARC workstation running Solaris 5.7 are 688 and 3.2 microseconds respectively.)