High-Level Service Connectors forComponent-Based High Performance Computing

Francisco Heron de Carvalho-JuniorRicardo Cordeiro CorreaGisele Azevedo AraujoJefferson Carvalho Silva

Departamento de ComputacaoUniversidade Federal do Ceara

Fortaleza, Brazil{heron, correa, gisele,jefferson}@lia.ufc.br

Rafael Dueire Lins

Departamento de Eletronica e SistemasUniversidade Federal de Pernambuco

Recife, Brazilrdl@ufpe.br

Abstract

Component-based programming has been applied to ad-dress the requirements of applications in high performancecomputing (HPC). The usual service connectors of com-mercial component models do not fit some requirements ofHPC, mainly regarding the support of parallelism, however.This paper looks at extensions to the usual notion of serviceconnector to meet such requirements, using the # compo-nent model as a substratum, evidencing its expressiveness.

1. Introduction

The increasing relevance of applications that demand forhigh performance computing (HPC) has made parallel com-puting a mainstream technology, attracting the attention ofthe software industry. Such importance has been enforcedby the increasing dissemination of off-the-shelf architec-tures for parallel computing, such as clusters and grids,and the consolidation of multicore processors in the hard-ware industry. Now, the knowledge on HPC techniques forparallel and distributed programming has become the keyfor reaching peak performance of contemporary computerarchitectures. Unfortunately, parallel programming is stillhard to be incorporated into widespread platforms for soft-ware development [9, 33].

In the recent years, component technology has been ap-plied to meet the requirements of HPC applications, yield-ing the rise of component models and frameworks inspiredby their success in the commercial arena [36], such as CCA

and its compliant frameworks [6], Fractal/ProActive [10],and P-COM [27]. However, current component modelshave limitations to express some of the requirements ofHPC applications. Indeed, they do not support neither asuitable notion of parallel component nor adequate connec-tors for parallel synchronization. For this reason, aiming atbetter support for parallelism ad hoc orthogonal extensionsto HPC component models have been proposed.

This paper looks at service connectors for components-based distributed and parallel programming for HPC appli-cations. Advanced concepts from type systems theory areapplied to provide a higher-level of abstraction from theunderlying computation platforms. The connectors are de-scribed in terms of the # component model, whose com-pliant programming systems support user-defined primi-tive and composite connectors, being independent from theevolution of the application requirements and technologi-cal contexts. Thus, this paper also serves both to evidencethe expressive power of the # component model to describeconnectors and to enumerate the set of service connectorsthat will be supported by a programming environment basedon #-components that has been developed [13].

In Section 2, the # component model is introduced. Sec-tion 3 concerns about client/server bindings, commonlyused in distributed parallel applications. Section 4 presentspeer-to-peer bindings, suitable for parallel synchronization.Section 5 shows how higher-order facilities for client/serverand peer-to-peer bindings can give support for skeletal pro-gramming. Section 6 introduces generic and abstract bind-ings, for supporting high level of abstraction in the use ofbindings. Section 7 concludes the paper, outlining furtherdevelopments of this work.

Figure 1. Example of Parallel Program

2. The # Component Model

The # component model moves parallel programmingfrom a process-based perspective to a concern-oriented onethat is closer to software engineering, abstracting away thecomputation infrastructure. A first intuitive notion of #-components can be obtained from a simple parallel pro-gram that perform a linear algebra operation described inFigure 1. For that, its processes are sliced using concernsaddressed by #-components as a slicing criterion, like inFigure 2. Certain concerns are parallel, involving slices ofmany processes, such as the four slices that define alloca-tion of processes to processors, the two slices of processes0 and 1 that perform the matrix-vector product U = B × Yin parallel, and that ones defining communication channels(send and recv pairs between processes). #-components al-low to encapsulate such kind of cooperative slices, repre-sented by units, as highlighted by dashed ellipses in Figure2. A unit defines the role of a process with respect to theconcern addressed by the #-component. One should noticethat #-components can also deal with non-functional con-cerns, such as the allocation of processes. Figure 3(b) illus-trates the main operations involved in the overlapping com-position of a set of #-components B1, B2, . . . , Bn to form anew #-component A. The description in the caption of theillustration provides elements for its understanding.

A # programmer views parallel programs from the hor-izontal perspective of Figure 2, by concerns, while a tra-ditional programmer views them from the vertical perspec-tive, by processes. The latter ones tend either to encapsulateindividual slices in modules, separated from their cooperat-ing slices, or to encapsulate cooperating slices in a singlemodule, calling the appropriate slice according to the pro-cess identification like in SPMD programming. Both al-ternatives break modularization principles. The mixing ofprocesses and concerns in the same dimension of softwaredecomposition has made hard to meet software engineeringand parallel programming.

Since #-components are concrete software entities, a no-tion of type for #-components has been developed to work

Figure 2. From Processes to #-Components

abstractly with them, where units are typed by interfacesand #-components by component types [16]. A subtypingrelation has also been introduced for characterizing special-ization relations. In the further sections, component typeswill be informally represented as diagrams as shown in Fig-ure 3 for depicting the structure of #-components belongingto it.

The idea to move the focus of software architecturesfrom components to exogenous connectors is not new[35, 2, 28], giving rise to algebras of connectors [23, 5].The #-components capture a generalized notion of first-class connector, treating uniformly connectors and com-ponents as #-components, an approach that has been criti-cized in [28]. However, in # programming systems, connec-tors are conceptually separated from usual components bymeans of component kinds, introduced in the next section.For instance, an architectural connector, specified by a setof roles and a glue [2], may be viewed as a #-component,whose units correspond to its roles and configuration to itsglue. The overlapping composition of #-component is an al-gebra for composing new connectors from more basic ones.Moreover, the ability to develop new primitive connectorsfrom scratch is another important feature of # programming.

2.1 # Programming Systems

A programming system comply to the # componentmodel if it materializes the notion of #-component. Sincethe nature of #-components is abstract, making possible tocover functional and non-functional concerns, # program-ming systems define a set of component kinds, which groups#-components of the same nature. For the #-componentsthat belong to it, a component kind defines the semantics

In (a), a visual notation for a #-components, represented by ellipses and their unitsby rectangles. From (b) to (e), some configuration scenarios. In (b), it is shown howa unit of a #-component A is defined by unifying units of a set of inner componentsB1, B2, . . . , Bn, which become slices of the enclosing unit. Arrows mean thatunits are, in fact, moved from the source to the target position. In (c), a unit ofan inner #-component B is lifted to be a unit of the enclosing component A. Ifall units of an inner #-component B is lifted in a #-component A, we say that Aspecializes B and the type of A is a subtype of the type of A. In (d), unified units ofB1, B2, . . . , Bn are injected in a unit lifted from C. In (e), it is shown how, in theconfiguration of A, two inner #-components C1 and C2 of B1 and B2, respectively,are fused in A. For instance, if B1 and B2 are matrix transformations and C1 andC2 represent the matrices they operate, respectively, then the fusion of C1 and C2means that B1 and B2 operate over the same data structure (data sharing, like inFractal [10]). If C1 is a specialization of C2, C1 supersedes C2.

Figure 3. Configuration of #-Components

of their units, the semantics of the unification of such units,their deployment models, the rules and restrictions for com-bining them to #-components of other component kinds,and so on. The usual component models define only onecomponent kind as a particular notion of software module.A #-programming system also provide a library of primitive#-components and/or facilities to build them from scratchaccording to component kind definitions.

The first # programming system was Haskell# [14], forcoarse-grained parallel functional computations on clustersof multiprocessors. Recently, an architecture for # frame-works for developing # programming systems has beenproposed [13], originating the HPE framework (Hash Pro-gramming Environment), a # framework as a plugin of theEclipse Platform. A # framework can be extended withcomponent kinds for defining complete programming sys-tems. The HPE programming system, implemented on topof CLI/Mono [1], was developed by instantiating the HPEframework with seven component kinds, targeting at clus-

Figure 4. 1-1 Binding - Before Fusion

Figure 5. 1-1 Binding - After Fusion

ters of multiprocessors: computation, data structure, syn-chronization, architecture, environment, application, andqualifier. There are also plans to incorporate componentkinds for distributed parallel computations using Forro, aCCA framework. The service connectors proposed in thispaper will be incorporated to HPE/Forro.

In the rest of this paper, it will be used the terms compo-nents environment, for the set of components deployed ina given computation platform, and components infrastruc-ture, for those artifacts that control deployment and launch-ing of components in the environment.

3. Client/Server Bindings

A client/server binding enables a client component to ex-ecute a service offered by a server component, involvingtransfer of data and control. Client/server relationships arecommon in distributed applications [4], but the client andthe server components may also reside in the same mem-ory space. The client/server bindings approached by HPCprogramming artifacts can be classified in 1-1 (sequentialclient, sequential server), 1-N (sequential client, parallelserver), M-1 (parallel client, sequential server), and M-N(parallel client, parallel server).

Using the CCA terminology, a 1-1 binding links a usesport of the client to a provides port of the server [6]. Aport carries a service description specified by a signatureof methods that can be invoked by the client on the server.Invocations cause remote procedure calls only if client andserver reside in disjoint memory spaces. The invocation ofmethods may be synchronous or asynchronous. In the for-mer, the client waits for the server to finish the execution of

Figure 6. Port

the invoked method. In the latter, the client returns from thecall after invocation and continues execution, using specialconstructors to demand for the results of the method invo-cation and to synchronize with the server, such as futuresof Proactive/Fractal, iterators of Forro/CCA, and channels.Such feature allows to overlap computation and communi-cation, reducing the pause overheads of synchronization.

In Figure 4, BINDING depicts the component type for#-components that represent 1/1 bindings, with two unitsnamed uses and provides. They are configured by over-lapping two #-components of component types PORTSTUBand PORTSKELETON, whose units represent, respectively,the stub client’s slice and the skeleton server’s slice that mapthe remote procedure call performed by the client onto a lo-cal procedure call in the server side, taking care with mar-shalling and serialization of parameters and results, trans-mission of data across the network, and synchronization se-mantics. In #-components that will act as the client and theserver, the inner #-components of component types UPORTand PPORT must exist, respectively, such that PORTSTUB(PORTSKELETON) is a subtype of UPORT (PPORT). In aconfiguration where a client and a server are linked througha BINDING, such restriction makes possible to supersedethe inner #-component of component type UPORT (PPORT)with its concrete version of component type PORTSTUB(PORTSKELETON), fusing them as in Figure 5. Such op-eration binds the uses port to the provides port. The #-components of component type UPORT and PPORT are ab-stract versions that only knows the signature of methodsof the port, while that ones of component type PORTSTUBand PORTSKELETON are their concrete versions, enrichedwith the code that performs the call. Figure 6 (left) de-picts the configuration of a component type PORT, super-type of both UPORT and PPORT. Each method of its in-terface is described by an inner #-component of componenttype METHODi, for 1≤i≤N . The activation semantics ofunits of these slices corresponds to a method call.

In a # programming system, a BINDING #-componentmust exist for each kind of service. Moreover, several onesmay exist for the same service, covering different kinds ofexecution platforms, intended semantics, type of some datastructure to be passed as parameter, and so on. Section

Figure 7. M-N Binding

6.2 shows how a type system can enable some degree ofadaptability when programming with bindings. Since prim-itive binding connectors are programmable entities in the #programming systems, the set of supported bindings mayevolve according to the needs of the users and in responseto the advance of technologies. Other component models,like Fractal and CCA, normally require to be extended tosupport different kinds of primitive connectors.

1-1 bindings have been extended for distributed paral-lel applications, allowing efficient method invocations ofa parallel client onto a parallel server, running in distinctparallel computers, respectively. Such scenario is typicalin large-scale HPC simulations where several phenomenonmodels are coupled, each one running in a disjoint com-puting sites (clusters, supercomputers, or grids) connectedto the Internet. The efficient support for distributed par-allel applications has been approached by several works[25, 34, 20, 30, 37, 8]. In general, they separate the cases1-N, M-1, and M-N, listed before. Fractal has been re-cently extended with collective interfaces of kinds multi-cast (1-N) and gathercast (M-1); There is a promise of in-troducing M-N interfaces in the near future [7]. The ef-ficient approaches for collective-method-calls improve thefirst practices of hard-coded solutions employed by users ofCORBA, with centralized control at the client and serversides for distributing and aggregating parameters and re-sults, with a high overhead and poor scalability. A betterand scalable solution is to let parallel processes at the clientand server sides to synchronize directly, without intermedi-ation.

It is possible to design primitive #-components for col-lective bindings by a simple extension of the previous ap-proach of 1/1 bindings. In Figure 7, a #-component ofcomponent type UPORT (PPORT) is now composed by aset of homogenous units, each one becoming a slice of a

client (server) process participating in the collective call.The same idea is applied to #-components of componenttypes PORTSTUB and PORTSKELETON. The processes ofthe collective stub and the collective skeleton must performdistributed synchronization to complete the service, as em-phasized in Figure 7. No centralized control is needed.

Implementors of collective interfaces must define how aset of remote collective calls performed by M client pro-cesses are mapped onto a set of local collective calls per-formed by N server processes, where M and N may dif-fer. This problem is relatively easy to resolve when there iseither one client (1-N) or one server (M-1), but it is chal-lenging in the general case. CCA community works hard topropose solutions for the “M×N problem”.

For now, each collective binding in a # programming sys-tem implements its own reduction and distribution strate-gies. This is flexible but poorly abstract for use in practice.Section 5 will show how to parameterize collective bindingswith specific strategies. In the M-N case, strategies must befor redistribution of argument data from the M client pro-cesses to the N server processes and of result data from theN server processes to the M client processes. Such redis-tribution strategies may be very irregular, but only a matterof how synchronization among process slices representingstubs and skeletons is performed.

Figure 8. Peer-To-Peer Binding

4. Peer-to-Peer Bindings

Asymmetric connectors, such as client/server bindings,are not suitable for most of common process synchroniza-tion patterns that occur in parallel computations [17]. Infact, channel-based message passing, and not remote proce-dure calls, is the fundamental synchronization mechanismof parallel programming for cluster and capability comput-ing architectures [4], involving the exchange of messagesbetween processes using send and receive primitives. Thedistinct roles of senders an receivers suggest asymmetry inparallel processes interaction. However, in most of cases,processes act as peers, performing symmetric patterns ofinteraction implemented on top of low level send and re-ceive primitives. This is the reason why the designers of

message-passing libraries, such as MPI, enrich them witha set of collective synchronization primitives for commonpatterns of data movement involving several processes.

Peer-to-peer bindings capture symmetric patterns of in-teraction between components. Peer components act asclients and servers of a service distributed among them-selves. They start a call of a method in a collective port,acting as clients, which is performed in parallel by them-selves, acting as a servers. The symmetric call could alsohave synchronous or asynchronous semantics.

A generic #-component for peer-to-peer bindings com-prises a set of homogenous units, one for each peer process.Figure 8 shows its set of inner #-components of compo-nent type CPORTIMPL, with simultaneous role of stub andskeleton, each one intended to supersede a #-component ofcomponent type CPORT of a peer #-component. Examplesof peer-to-peer bindings can be obtained from the symmet-ric collective operations of MPI, like the variants of all-to-all, all-gather, all-reduce, and scan, which involves onlydata movement. However, one could think about completepeer-to-peer services, involving also control transfer. Forexample, peer #-components could execute a service lin-ear system solve in a peer-to-peer port, where parametersare distributed across them, with all data redistribution andsynchronization managed by the #-component that imple-ments the peer-to-peer service binding. Such approach re-sembles the use of parallelized scientific libraries, such asthat ones of BLAS family and that makes part of the ACTSCollection [22]. In fact, it is planned to use this approach toincorporate ACTS as primitive #-components of HPE.

5. High-Order Bindings

The formal development of the idea of reusable patternsof parallelism interaction, or skeletons, that can be particu-larized to perform specific parallel computations was intro-duced by Murray Cole [18]. Skeletons have been widely in-vestigated by the academic community in the last decades,but had little impact in industry [19]. Some papers orga-nized taxonomies of skeletons [11, 24]. The authors ofthis paper have proposed the notion of partial topologi-cal skeletons for Haskell# [15], with a library includingCole’s skeletons and collective synchronization skeletonsimitating MPI collective subroutines. Topological skeletonscan be combined by overlapped composition to form newskeletons, and not only by nested composition supported byother combination frameworks for skeletons [24]. More-over, topological skeletons are said to be partial becausethey can carry pre-defined pieces of computation. The workof Cole with eSkel [19] has also proposed skeletons for col-lective communication operations of MPI. More recently,the fundamental principles behind skeletons have inspiredthe notion of high-order components (HOCs) for grid pro-

gramming [3], leading to HOC-SA (HOCs Service Archi-tecture), one of the Globus incubator projects. The serviceof a high-order binding is parameterized by a computation,encapsulated in a component supplied by the client. HOCsare services that encapsulate patterns of parallel interactionin the resources of a grid. The skeletons in # programmingsystems are partial topological skeletons.

A generic #-component for high-order bindings is ob-tained only by parameterizing bindings described in the pre-vious sections with other #-components addressing com-putations required by the service. For example, a 1-Nclient/server binding for bag-of-tasks computations couldbe provided, where the client passes a #-component thatimplements the computation performed by each server pro-cess. Another use of high-order bindings is to param-eterize 1-N, M-1, and M-N collective bindings by dis-tribution, reduction, and redistribution strategies, insteadof supporting several bindings for the service varying ac-cording to the strategy. This is exemplified in Figure 9,where BINDING〈t : REDISTRIBUTE, u : REDISTRIBUTE〉is a component type for M-N bindings parameterized by in-ner #-components t and u for redistribution strategies.

6. Polymorphic Bindings

A polymorphic type system for # programming systemshas been proposed, supporting generic and abstract com-ponent types with semantics in bounded quantification en-riched with type operators. The three main purposes of thistype system are safety, abstraction, and modularity. Safetyis ensured by forbidding stuck configurations where pro-gramming mistakes that are common in parallel program-ming with low-level message-passing approaches, like MPIand PVM, may occur, such as: non-matching send and re-ceive calls, conflicting messages arriving at the receiver,some kinds of deadlocks that can be avoided statically, andso on. This paper does not provide a formal specificationfor the type system of # programming systems. In the nexttwo sections, it shows, informally, how generic and abstractcomponent types can be achieve high level of abstractionand modularity in the specification of service bindings.

6.1 Generic Bindings

In the high-order M-N binding of Figure 9, a program-mer could pass any #-component of subtypes of REDISTRI-BUTION to parameters t and u. However, the # program-ming type system supports a polymorphism approach thatis more expressive than subtyping polymorphism, based onuniversal bounded quantification [12]. Using this approach,#-components of component type

∀D<:REDISTRIBUTE. BINDING〈t : D, u : D〉

Figure 9. A High-Order Collective Binding

become also parameterized by the type of redistribution#-component. This approach allows to fix a more spe-cific bound for the types of allowable redistribution #-components. Generic bindings could be introduced toHOCs for introducing polymorphic skeletal services.

6.2 Abstract Bindings

The implementation of a binding for a given service mayvary according to the kind of execution platform; the strat-egy employed for distribution, reduction, and/or redistribu-tion in collective bindings; the intended semantics; and soon. For such cases, the # programming type system intro-duces partial abstract components, with semantics in exis-tential bounded quantification. For instance, consider thegeneric M-N binding of Figure 9. Suppose that its imple-mentation may vary according to the execution platform andsome data type involved in the communication. The follow-ing notation is adopted to capture this scenario:

BINDINGOP[P<:PLATFORM, T<:DATA]

= ∀P<:P. ∀T<:T. ∀D<:REDISTRIBUTE. BINDING〈t:D, u:D〉

Figure 10. An Abstract Collective Binding

BINDINGOP is a partial abstract component, depictedin Figure 10. In fact, P and T are existentially quantifiedtype variables 1, respectively bounded by componenttypes PLATFORM, for classifying execution platforms,and DATA, for classifying types of data structures. Infact, a partial abstract component is a bounded exis-tential type, analogous to partial abstract data types inusual programming languages, for which there is onedeployed #-component of exactly such type in the en-vironment. The terms abstract component and partialabstract component will be used interchangeably. Ex-amples of #-components that inhabits BINDINGOP are{∗RMI, ∗DATA; binding1}, {∗RMI, ∗ARRAYOFDOUBLE; binding2},{∗WEBSERVICE, ∗ARRAYOFINTEGER; binding3}, and{∗CORBA, ∗ARRAYOFINTEGER; binding4}.

bindingi, for i=1, . . ., 4, are #-components for the sameservice, with implementations tuned for a certain executionplatform and data structure. In usual programming lan-guages that support ADTs, like Ada, programmers are re-sponsible to pack and unpack modules as ADTs. In # pro-gramming, programmers are still responsible to pack prim-itive #-components as inhabitants of abstract components,explicitly, but they let to the components infrastructure thetask of unpacking at launch time. Programmers build com-posite #-components by overlapping abstract componentsviewed as parameterized abstract components [16], whichare type operators that, when applied to other abstract com-ponents supplied as parameters, return the #-componentof the abstract component. This is the justification forthe “parameterized-like” notation for abstract components.By supplying parameters E and T of BINDINGOP, a pro-grammer may control the choice of the system for an ap-propriate binding of the #-component. For example, if aconfiguration claims for an inhabitant of BINDINGOP bysupplying it as BINDINGOP[RMI, ARRAYOFDOUBLE], then the sys-tem returns, at launch time, the #-component C, such that{∗RMI, ∗ARRAYOFDOUBLE; C} exists in the environment. For in-stance, amongst the #-components listed before, binding2

is chosen for C. If BINDINGOP [RMI, ARRAYOFDOUBLE] is notdeployed in the environment, the system will search fora more generic #-component than binding2. Since RMIand ARRAYOFDOUBLE are bounds for universally quanti-fied type variables, by subtyping rules it can be found bylooking for an inhabitant of BINDINGOP [RMI, DATA], assumingthat DATA is the lowest supertype of ARRAYOFDOUBLE.In such case, the #-component binding1 could be chosen,which is a more generic implementation, probably less ef-ficient because it is suitable for any data structure. Fur-thermore, if there is no #-component {∗RMI, ∗DATA; C′}, thesystem will continue to generalize BINDINGOP until to

1One can read BINDINGOP using the notation for pack-ages of existential types used in [31], such as BINDINGOP ={∃P<:PLATFORM, ∃T<:DATA; . . . }

find a suitable #-component. Such approach is possible ifthe system keeps track of the subtyping hierarchy of ab-stract components deployed in the environment. In orderto avoid ambiguities, only one #-component can inhabitan abstract component in a given environment, but # pro-gramming systems could easily introduce some versioningmechanism for managing #-components. If no generaliza-tion of BINDINGOP[RMI, ARRAYOFDOUBLE] is found in the environ-ment at the deployment time of a configuration that refersto it, the user is warned. If such condition still happens atlaunch time, an unrecoverable error exception occurs. Theapproach of searching and combining components at launchtime, from specifications given by programmers at configu-ration time, has been used by P-COM [27].

After the system unpacks {∗RMI, ∗ARRAYOFDOUBLE; binding2}for BINDINGOP[RMI, ARRAYOFDOUBLE], binding2 must be appliedto the component type of the intended redistribution strategyand to two #-components of such component type. Since itis not desirable programmer intervention at launch time, it isnecessary to include configuration facilities that allow pro-grammers to set these parameters at configuration time. Infact, this is possible because the kind of the type of bindingi

is known at configuration time, but it is possible to resolvethis problem by using parameterized abstract components:

BINDINGOP[P<:PLATFORM, T<:DATA, D<:REDISTRIBUTE] =

∀P<:P. ∀T<:T. ∀D<:D. BINDING〈t:D, u:D〉

The configuration continues similarly to the sce-nario depicted in Figure 10. If a programmer usesBINDINGOP[RMI, ARRAYOFDOUBLE, TRANSPOSE] in a configuration,where TRANSPOSE is an abstract component for #-components that implements a particular redistributionstrategy, the system will look, in the client’s environment,for inhabitants of subtypes of TRANSPOSE for each refer-ence to D in the configuration body.

For a given choice of E, T , and D, and by forc-ing only abstract components with all parameters suppliedin the configuration body of BINDINGOP[E, T,D], thecomponent infrastructure can choose the actual inner #-components to be overlapped to form a #-component forBINDING[E, T, D] by looking at its corresponding abstractcomponents. One should remember that the inner abstractcomponent of BINDING[E, T, D] are E, T , PORTSTUB[D],and PORTSKEL[D] (Figure 10). Such approach frees pro-grammers of making assumptions about parameters of high-order #-components whenever building configurations, let-ting such responsibility to the component infrastructurewithout compromising the explicit control of programmers.In fact, the component infrastructure sees any composite#-component as a high-order one, parameterizing it by itsinner #-components by default. Thus, to build a compos-ite #-component, the infrastructure only supplies its pa-rameters (inner components) by providing the unpacked #-

component for its abstract component type. Thus, the com-posite #-component can be viewed as a combinator whosedefinition depends on its component kind.

Abstract Components enable a general notion of skeletonservice, as proposed originally by Cole, whose implementa-tion vary according to the underlying computation platform.It is more general than HOCs, because a service may haveseveral implementations in the same server, each one moreappropriate for certain combinations of parameters.

7. Conclusions and Lines for Further Works

The support for a suitable set of connectors is a key is-sue for the success of a component model for developinghigh performance computing (HPC) applications targetedat high-end distributed and parallel architectures. Serviceconnectors are a widespread artifact to plug components insuccessful component models of commercial applications,but they must be extended to address some peculiar require-ments of HPC applications, mainly regarding the expres-sion of parallel patterns of synchronization amongst com-ponents. For such purpose, this paper provides a set ofextensions to the usual service connectors that have beenapproached in the design of component models for HPC,showing how advanced concepts from type systems the-ory could be used to lift the level of abstraction in theiruse in programming. The expressiveness of the # compo-nent model, whose compliant programming systems sup-port user-defined primitive and composite connectors, isevidenced by mapping the proposed service connectors interms of #-components. Indeed, such connectors will be in-troduced in HPE/Forro, a # programming system that is aCCA framework for distributed parallel applications.

8. Acknowledgments

CNPq - Conselho Nacional de Pesquisas e Desenvolvi-mento Tecnologico, Brazilian Government, sponsors thisproject (grant 475826/2006-0).

References

[1] The Mono Project. http://www.mono-project.com, 2006.[2] R. Allen and A. Garlan. A Formal Basis for Architectural Connection. ACM

Transactions on Software Engineering and Methodology (TOSEM), 6(3):213–249, 1997.

[3] M. Alt, J. Dunnweber, J. Muller, and S. Gorlatch. HOCs: Higher-Order Com-ponents for Grids. In Workshop on Component Models and Systems for GridApplications (in ICS’2004). Kluwer Academics, July 2004.

[4] G. Andrews. Concurrent Programming: Principles and Practice. AddisonWesley, 1991.

[5] F. Arbab. Reo: A Channel-Based Coordination Model for Component Com-position. Math. Structures in Computer Science, 14(3):329–366, 2004.

[6] R. Armstrong, G. Kumfert, L. C. McInnes, S. Parker, B. Allan, M. Sottile,T. Epperly, and Dahlgreen Tamara. The CCA Component Model For High-Performance Scientific Computing. Concurrency and Computation: Practiceand Experience, 18(2):215–229, 2002.

[7] F. Baude, D. Caromel, L. Henrio, and M. Morel. Collective Interfaces for Dis-tributed Components. In 7th International Symposium on Cluster Computingand the Grid (CCGrid 07). IEEE Computer Society, 2007.

[8] F. Baude, D. Caromel, and M. Morel. From Distributed Objects to Hierar-chical Grid Components. In International Symposium on Distributed Objectsand Applications. Springer-Verlag, 2003.

[9] Bernholdt D. E., J. Nieplocha, and P. Sadayappan. Raising Level of Program-ming Abstraction in Scalable Programming Models. In Workshop on Pro-ductivity and Performance in High-End Computing (P-PHEC), pages 76–84.Madrid, Spain, IEEE Computer Society, 2004.

[10] E. Bruneton, T. Coupaye, and J. B. Stefani. Recursive and Dynamic SoftwareComposition with Sharing. In European Conference on Object Oriented Pro-gramming (ECOOP’2002). Springer, 2002.

[11] D. K. G. Campbell. Towards the Classification of Algorithmic Skeletons.Tech. Rep. YCS 276, Dep. of Computer Science, University of York, 1996.

[12] L. Cardelli and P. Wegner. On Understanding Types, Data Abstraction, andPolymorphism. Computer Surveys, 17(4):471–522, Dec. 1985.

[13] F. H. Carvalho Junior, R. Lins, R. C. Correa, and G. A. Araujo. Towards anArchitecture for Component-Oriented Parallel Programming. Concurrencyand Computation: Practice and Experience, 19(5):697–719, 2007.

[14] F. H. Carvalho Junior and R. D. Lins. Haskell#: Parallel Programming MadeSimple and Efficient. Journal of Universal Computer Science, 9(8):776–794,Aug. 2003.

[15] F. H. Carvalho Junior and R. D. Lins. Topological Skeletons in Haskell#. InInternational Parallel and Distributed Processing Symposium (IPDPS). IEEEPress, Apr. 2003.

[16] F. H. Carvalho Junior, R. D. Lins, and A. T. C. Martins. An InstitutionalTheory for #-Components. In Proceedings of the Brazilian Symposium onFormal Methods (SBMF’2006), pages 137–152, 2006.

[17] K. Chiu. An Architecture for Concurrent, Peer-to-Peer Components. PhDthesis, Department of Computer Science, Indiana University, 2001.

[18] M. Cole. Algorithm Skeletons: Structured Management of Paralell Computa-tion. Pitman, 1989.

[19] M. Cole. Bringing Skeletons out of the Closet: A Pragmatic Manifesto forSkeletal Parallel Programming. 30:389–406, 2004.

[20] A. Dennis, C. Perez, and T. Priol. Portable Parallel CORBA Objects. In 7thEuropar Conference, pages 835–844. Springer, Aug. 2001.

[21] J. Dongarra, I. Foster, G. Fox, W. Gropp, K. Kennedy, L. Torczon, andA. White. Sourcebook of Parallel Computing. Morgan Kauffman Publish-ers, 2003.

[22] L. A. Drummond and O. A. Marques. An Overview of the Advanced Compu-Tational Software (ACTS) Collection. ACM Transactions on MathematicalSoftware, 31:282–301, 2005.

[23] J. L. Fiadeiro, A. Lopez, and M. Wermelinger. Categorical Semantics ofParallel Program Design. Lecture Notes in Computer Science, 2793:190–234,Springer, 2003.

[24] M. M. Hamdan. A Combinational Framework for Paralell Programming Us-ing Skeleton Functions. PhD thesis, Department of Computing and ElectricalEngineering, Hariot-Watt University, Jan. 2000.

[25] K. Koahey and D. Gannon. PARDIS: A Parallel Approach to CORBA. InProc. of the 6th IEEE Intl. Symposium on High Performance Distributed Com-puting (HPDC’97), pages 31–39. Springer, Aug. 1997.

[26] K. Lau, P. V. Elizondo, and Z. Wang. Exogenous Connectors for SoftwareComponents. Lecture Notes in Computer Science (Proceedings of 2005 Inter-national SIGSOFT Symposium on Component-Based Software Engineering -CBSE’2005), 3489:90–108, 2005.

[27] N. Mahmood, G. Deng, and J. C. Browne. Compositional development ofparallel programs. In L. Rauchwerger, editor, LCPC, volume 2958 of LectureNotes in Computer Science, pages 109–126. Springer, 2003.

[28] N. R. Mehta, N. Medvidovic, and S. Phadke. Towards a Taxonomy of Soft-ware Connectors. In Proceedings of 22nd International Conference on Soft-ware Engineering, pages 178–187. ACM Press, 2000.

[29] T. Murata. Petri Nets: Properties Analysis and Applications. Proceedings ofIEEE, 77(4):541–580, Apr. 1989.

[30] C. Perez, T. Priol, and A. Ribes. A Parallel Corba Component Model for Nu-merical Code Coupling. In Proc. of the 3rd Intl. Workshop on Grid Computing(published in LNCS 2536), pages 88–99. Springer, Nov. 2002.

[31] B. Pierce. Types and Programming Languages. The MIT Press, 2002.[32] F. Plasil and S. Visnovsky. Behavior Protocols for Software Components .

IEEE Transactions on Software Engineering, 28(11):1056–1076, 2002.[33] D. E. Post and L. G. Votta. Computational Science Demands a New

Paradigm. Physics Today, 58(1):35–41, 2005.[34] C. Rene and T. Priol. MPI Code Encapsulating Using Parallel CORBA Ob-

ject. Cluster Computing, 3:255–263, 2000.[35] M. Shaw. Procedure Calls are the Assembly Language of Software Intercon-

nection: Connectors Deserve First-Class Status. In International Workshopon Studies of Software Design, Lecture Notes in Computer Science. Springer-Verlag, 1994.

[36] A. J. van der Steen. Issues in Computational Frameworks. Concurrency andComputation: Practice and Experience, 18(2):141–150, 2006.

[37] O. Standard. Data Parallel CORBA, v1.0. Technical Report 2006-01-03,Object Management Group, Object Management Group, Jan. 2006.