An Aspect Oriented Framework for Scientific Component Development
Manuel D´ıaz, Sergio Romero, Bartolom´e Rubio, Enrique Soler and Jos´e M. Troya
Dpto. Lenguajes y Ciencias de la Computaci´on.
M´alaga University
29071 M´alaga, SPAIN
mdr,sromero,tolo,esc,troya
@lcc.uma.es
Abstract
Aspect-Oriented Programming enables develop-
ers to capture in separated aspect modules concerns that
are spread over different components in a system. This pa-
per is an attempt to apply this paradigm to High Perfor-
mance Computing. Besides achieving the usual advantages
of improved modularity, more reusable code that is eas-
ier to develop and maintain, we pursue to improve effi-
ciency by means of dynamic changes of aspects at runtime.
We present an Aspect-Oriented Framework where Scien-
tific Components and Aspects are first-order entities (com-
ponents) which interaction is established by means of what
we have called Aspect Connectors. As an example, we fo-
cus on the communication aspect, which encapsulates
the communication scheme among the set of compo-
nents that set up a system. The expressiveness and suitabil-
ity of the approach are shown by means of an application
example.
1. Introduction
Component-Oriented Programming, initially applied to
the business world, is coming to the high-performance par-
allel and distributed computing scene. Component stan-
dards and implementations, such as OMG CCM [11], Mi-
crosoft DCOM [6], Sun Java Beans and Enterprise Java
Beans [5] [10], share serious shortcomings for parallel and
distributed scientific applications, due to the lack of the ab-
straction needed by parallel and distributed programming
and poor performance. They also have trouble with the
mechanism for encapsulating an existing scientific appli-
cation (which might itself be a parallel-distributed applica-
tion) into a component.
This work was supported by the Spanish project MICYT TIC 2002-
04309-C02-02
Recently, some efforts are being carried out in order
to incorporate component technologies to develop paral-
lel and distributed Programming Environments (PEs) in
the high-performance computing area. In this sense, AS-
SIST [17] is focused on high-level programmability and
software productivity for complex multidisciplinary appli-
cations, including data-intensive and interactive software.
SBASCO [4] is a PE oriented to the efficient developmentof
parallel and distributed numerical applications. A large ef-
fort is currently devoted to define a standard component ar-
chitecture for high-performancecomputingin the contextof
the Common Component Architecture (CCA) Forum [16].
This component-oriented approach results in more
reusable, extensible and adaptable software. How-
ever, achieving these features requires an appropriate
separation of the system concerns in independent mod-
ules. When designing and building systems, it is often
difficult to achieve a design that modularises all re-
quired system features. Commonly, there are certain
concerns that will not fit well into any component struc-
ture we choose. This is particularly true for certain kinds
of functionality, such as logging, debugging, communi-
cation, synchronization, distribution, security, etc. Design
compromises often lead to code where the same con-
cern happens to be spread over different components in a
system. These concerns are usually called crosscutting con-
cerns.
Aspect-Oriented Programming (AOP) [7] is a paradigm
that enables developers to capture crosscutting structure.
This makes it possible to program crosscutting concerns
in a modular way, and achieve the usual benefits of im-
proved modularity: simpler code that is easier to develop
and maintain, and that has a greater potential for reuse. A
well-modularised crosscutting concern is called an aspect.
Current AOP technologies offer different alternatives to
tackle the separation of concerns, that differ mainly in three
factors: the aspect definition language, the weaving process,
and the kind of concerns modeled as aspects. AO languages
can be aspect specific [9] or extensions of general purpose
languages providing special constructions used to imple-
ment any kind of aspects [8]. One common drawback of AO
languages is that the weaving process is static, mixing com-
ponent and aspect code at compile-time. One alternative to
AO languagesare AO frameworks [13]. Usually, AO frame-
works model components and aspects as separated entities
which are implemented in the same general purpose lan-
guage and composed in a more o less dynamical way at run-
time.
This paper presents an Aspect-Oriented Framework as an
attempt to apply the AOP paradigmto the high-performance
computing area. Our application domain is the parallel and
distributed solution of numerical problems, especially those
with an irregular surface that can be decomposed into regu-
lar, block structured domains, and other kinds of problems
that take advantage of integrating task and data parallelism
and have a communication pattern based on (sub)array in-
terchange. Usually, their execution times are large.
In this framework there are two kinds of component: Sci-
entific Components (SCs), which are in charge of computa-
tional tasks, and Aspect Components (ACs) used to encap-
sulate crosscutting concerns. This way, we pursuetwo bene-
fits. On the one hand, those usual of AOP, simpler and more
reusable code that is easier to develop and maintain. On the
other hand, to improve application execution time by means
of establishing changes at the aspect level (a better commu-
nication scheme, distribution, etc) dynamically at runtime.
SCs interact each other following a ”data flow” style by
means of a typical put
data/get data scheme based on the
SBASCO approach. The interaction among SCs and ACs
follows a ”procedural” style and is governed by means of
what we have called Aspect Connectors (ACNs). The code
of an ACN is statically (at compile-time) woven to a SC,
while, as stated above, an AC can dynamically change its
characteristics. In addition, a different AC can be composed
at runtime.
Our approach provides the basis to separate specific as-
pects that appear in the application domain, such as com-
munication, synchronization, distribution, convergence cri-
teria, etc. As an example, we focus in this paper on the com-
munication aspect, which encapsulates the communication
scheme among the set of SCs that build a system.
The rest of the paper is structured as follows. Next sec-
tion outlines the main characteristics of SBASCO taken into
consideration in our approach. Section 3 explains the SCs
implementing the computational task of a system and the
ACs encapsulating the communication aspect among SCs.
The way the ACNs are used to connect SCs and ACs is
shown in section 4. Finally, some conclusions and future
work are sketched in section 5.
2. An Overview of SBASCO
The inter-connection among SCs considered in our
framework is based on SBASCO, a programming environ-
ment oriented to the efficient development of parallel and
distributed numerical applications. This environment in-
tegrates two technologies: skeletons and components. A
software skeleton is a known reusable parallelism ex-
ploitation pattern [1]. A structured parallel programming
methodology is achieved by means of the establish-
ment of a fixed set of software skeletons or parallelism
constructors, which are the only way to express the paral-
lel structure of the programs [12].
In SBASCO, the internal structure of a component can
be established by means of the utilization of the three dif-
ferent skeletons previously defined in DIP [3]:
The multi-block skeleton is focused on the solution
of multi-block and domain decomposition-based prob-
lems, which constitute an important class of problems
in the high-performance computing area.
The farm skeleton improves a task throughput as dif-
ferent data sets can be computed in parallel on differ-
ent sets of processors.
Problem solutions that have a communication pattern
based on array interchange and may take advantage
of integrating task and data parallelism, can be de-
fined and solved in an easy and clear way by using the
pipeline skeleton, which pipelines sequences of tasks
in a primitive way.
A skeleton definition is based on the concept of do-
main [2]. Basically, a domain consists of the Cartesian
points establishing a region.
The following code shows the general scheme of the
MULTIBLOCK skeleton. Tasks solve the different domains
the problem has been decomposed in (Figure 1).
MULTIBLOCK skeleton_name
task1(arguments) processor layout
task2(arguments) processor layout
.....
taskm(arguments) processor layout
WITH BORDERS
border definitions
END
In the FARM skeleton, the stream of input data for the
task is accepted by a special process called emitter which
schedules them to each replica. On the other hand, a collec-
tor process collects the results from each replica and merges
them into the stream of output data from the task (Figure 2).
This skeleton is specified as follows:
FARM skeleton_name (R) task(arguments)
processor layout
domain1
domain2
task1
task2
borders
Figure 1. A problem decomposed in two do-
mains
replica1
e
replica2
replicaR
......
c
Figure 2. Structure of a farm with R replicas
where R establishes the number of replicas and proces-
sor layout indicates the number of processors where
each replica is going to be executed.
The PIPE skeleton pipelines sequences of tasks. Fig-
ure 3 depicts the structure of the general n-stage pipeline
corresponding to the PIPE skeleton shown in the follow-
ing code:
PIPE skeleton_name
stage1
stage2
.....
stagen
END
Each stage in the pipeline consumes and produces a data
stream, except the first and the last stages that may only
produce and consume, respectively. The communicationbe-
tween two pipe stages is specified by using the same do-
main as argument in both stages, unlike in the MULTI-
BLOCK skeleton, where border definitions are used.
In SBASCO, there are two views of a component inter-
face. The application view contains information related to
data types of component input/output. This view is used by
the programmer in order to develop his/her applications by
means of a composition language. The configuration view
stage
1
stage
2
...
stage
n
Figure 3. Structure of the n-stage pipeline
extends the application view with information about input
and output data distribution, processor layout and compo-
nent internal structure (in terms of skeleton composition
scheme).
A configuration tool uses the latter view, together with
an skeleton-associated cost model, to obtain an efficient im-
plementation of the application on parallel/distributed plat-
forms. The knowledge at the component interface level of
data distribution and processor layout allows the system to
obtain an efficient implementation of the communication
scheme among components, which follows a ”data flow”
style by means of a typical put
data/get data scheme. A
more detailed explanation of the two different views and
the way they are used can be found in [4].
3. Scientific and Communication Aspect
Components
The previously mentioned SBASCO configuration tool
tries to establish the most appropriate system configuration.
In order to achieve this, the analytical cost model associated
to each software skeleton is enhanced by a runtime analy-
sis focused on the establishment of some parameters, such
as the numberof processors used for each task and the num-
ber of replicas in a farm, which are of capital importance to
obtain an efficient system implementation.
Due to the fast evolution of hardware of both processors
and inter-processorcommunication systems, an accurate es-
timation is quite difficult. In addition, the system evolution
during execution may require a readjustment of that kind of
parameters in order to maintain the efficiency. This way, the
communication scheme among the different components,
which depends on this information,should be modified. But
in the SBASCO system, the communication scheme is a
crosscutting concern, that is, it is spread over the compo-
nents.
The main goal of our framework is to improve efficiency
by means of establishing changes on this kind of concerns
dynamically at runtime. In order to achieve that, we capture
them in separated (aspect) components. Besides efficiency,
we obtain more reusable code that is easier to develop and
maintain.
In our approach, Communication Aspect Components
(CACs) encapsulate the communication scheme among a
0
Y
X
left right
center
NxlNxcNxr
Nyl
Nyc2
Nyc1
Figure 4. A domain decomposition of an ir-
regular geometry
set of SCs of a system. This scheme is captured by the cor-
responding skeleton, where data distribution, processor lay-
out and, possibly, number of replicas of each SC are speci-
fied.
In order to show the way both kinds of components are
used, we introduce an example that solves a system of two
non-linear reaction-diffusion equations in an irregular ge-
ometry. A detailed explanation for this problem and the em-
ployed numerical method can be found in [14].
Figure 4 depicts the irregular geometry of the problem
that has been decomposed in three domains (left, cen-
ter, right). Each domain is solved by a SC. Figure 5
shows their definitions together with the description of the
CAC that captures their communication scheme. We use
a syntax based on CCM [11], enriched by constructors
and data types characterizing the programming model of
SBASCO.
The definition of the CAC, besides specifying the pro-
vided and used interfaces, establishes the Multiblock
skeleton that describes the interaction scheme among the
SCs. The predefined type Domain2D is used to capture the
Cartesian points that establish the region of a domain. For
example the expression
Domain2D left =
0,0,Nxl,Nyl
;
declares a two-dimensional domain left for the region of
the plane that extends from the point (0,0) to the point
(Nxl,Nyl).
On the other hand, the type CommScheme will contain
the required information, which is declared in the skeleton,
in order to carry out an efficient inter-component commu-
nication: data distribution, interaction among domains and
mapping of processors.
The data distribution types are HPF-like. For example,
the expression center:(*,BLOCK) declares a distribu-
interfaceScConfigure{
voidgo(inDomain2Dd,
inCommSchemescheme,inunsignednumProcs);
voidsetCacGet(inCaccacGet);
voidsetCacPut(inCaccacPut);
};
interfaceScChangeConf{
voidchangeCommScheme(inCommSchemescheme);
voidchangeNumProcs(inunsignednumProcs);
};
interfaceCacProvided{
voidinitGet(inScsc);
voidfinishGet(inScsc);
};
componentSc{
providesScConfigureconf;
providesScChangeConfchange;
usesCacProvidedsetStateInf;
};
componentSolveL:Sc{};
componentSolveC:Sc{};
componentSolveR:Sc{};
componentCac{
skeletonReactionDiffusion{
Domain2Dleft={0,0,Nxl,Nyl},
center={Nxl-1,Nyc1,Nxc+1,Nyc2},
right={Nxc,0,Nxr,Nyl};
Multiblock{
SolveL(left:(BLOCK,BLOCK))ONPROCS(2,2);
SolveC(center:(*,BLOCK))ONPROCS(2);
SolveR(right:(BLOCK,BLOCK))ONPROCS(2,2);
WithBorders
left(Nxl,Nyc1,Nxl,Nyc2)<-center(_);
center(Nxl-1,Nyc1,Nxl-1,Nyc2)<-left(_);
center(Nxc+1,Nyc1,Nxc+1,Nyc2)<-right(_);
right(Nxc,Nyc1,Nxc,Nyc2)<-center(_);
};
};
providesCacProvidedsetStateInf;
usesScChangeConfchange;
};
Figure 5. Definition of SCs and CAC for the
reaction-diffusion example
tion by columns for the domain center. This declaration
indicates the data distribution inside the SC that is bound
to the specified domain. In Figure 4, dotted lines represent
data distributions.
Another information related to domains is the interaction
information among domains (borders). In general, the prob-
lem is solved iteratively, so that for each iteration a commu-
nication of the different borders is needed. This communi-
cation is carried out by means of the predefined data flow
primitives get
data and put data, which obtain data
from and send data to a SC, respectively. Borders are de-
fined among the specified domains. For example, the ex-
pression
left(Nxl,Nyc1,Nxl,Nyc2) <-
center(Nxl,Nyc1,Nxl,Nyc2);
indicates that the zone of left delimited by points
(Nxl,Nyc1) and (Nxl,Nyc2) will be updated by
Cac
SolveL
SolveC SolveR
setStateInf
change
change
change
conf
conf conf
FrameWork
Figure 6. Interaction scheme for the reaction-
diffusion example
the values belonging to the zone of center delim-
ited by the same points. In our example, the domains
have been defined taking into account their distribu-
tion in the plane. Thus, in the definition of the bor-
ders, the regions at both sides of the operator <- are the
same. In these cases, our approach provides the nota-
tion
to be used at the right hand side.
In addition to data distribution and borders, the relation-
ship between domains and the processor layout where the
SCs are going to be executed are also indicated. Each SC is
solved by a disjoint set of processors. For example, the ex-
pression:
... ON PROCS(2,2);
indicates a square arrangement of 4 processors.
Figure 6 depicts the interaction scheme among the differ-
ent components. The sequence of application execution be-
gins with the creation of the three SCs and the correspond-
ing CAC. The framework calls the methods setCacGet
and setCacPut for each SC, so that these obtain a refer-
ence to the CAC for further communication. Our approach
provides two different methods to set a CAC for a given
SC because certain applications may require distinct CACs
for both get
data and put data data flow primitives.
In this example, however, the communication scheme is the
same for both get
data and put data primitives, and
so, the providedCAC is also the same. Then, the go method
is invoked, so that the domain, the initial communication
scheme and the number of processors of each SC are estab-
lished. After that, each SC begins its computational task.
During the application execution it is possible that
the CAC decides to change some parameters that af-
fect the communication scheme, such as the number of pro-
cessors of a SC. In this case, the CAC will call the
changeNumProcs method for the target SC, and the
changeCommScheme method for the SCs which commu-
nication scheme is affected by this change. For example, if
the number of processors of SolveL changes, this will im-
ply a change in the communication scheme for SolveL
and SolveC, but not for SolveR (see Figure 4). In
our application domain, where we usually face to prob-
lems with large execution times, the time spent on this
kind of changes is clearly recovered by the efficiency ob-
tained applying them. On the other hand, a different
CAC could be composed at runtime. This way, the meth-
ods setCacGet and setCacPut would be invoked
again.
The way a CAC obtains the necessary information in or-
der to decide whether a parameter is changed or not is ex-
plained in next section.
4. Interconnecting SCs and CACs
In AOP it is needed a tool called aspect weaver in or-
der to insert code fragments (advice) that are derived from
the aspect code to wherever they are needed. These inser-
tion points are called join points and must be established
by the programmer. A join point refers to a method, an at-
tribute, a class, an object, etc. The join points, and the way
they are grouped, are the key language elements to deal with
the crosscutting nature of aspects. They can describe points
in the static structure or the dynamic control flow of a pro-
gram in a very flexible way. The joint points and the advice
that should be run when they are reached constitute the way
an aspect is associated to a code.
General purpose AO languages, such as AspectJ [8] and
AspectC++ [15], are expressive enough to implement any
kind of aspect. They offer expressions and algebraic op-
erators in order to map, filter and combine different joint
points. Moreover, different kinds of advice can be declared,
including ”after” advice that runs after the joint point, ”be-
fore” advice that is executed before the join point and
”around” advice, which is executed in place of the join
point.
In our framework, components and aspects are sepa-
rated entities that are associated by using the methods set-
CacGet and setCacPut in the way described in previous
section. However, after association, SCs and CACs must in-
teract each other during computation. In order to be flexible
and expressive enough, our approach allows the program-
mer to establish this interaction control by means of what
we have called Aspect Connectors (ACNs). These ACNs
are based on the joint points and advice mechanism of AOP.