STCM: A spatio-temporal Component Model

Hinde Lilia BouzianeChristian Perez

PARIS Project-TeamINRIA Rennes/IRISA

Toulouse, France, December 7th 2007

Outline of the talk

• Context– Software component models and workflow languages

• Limitations of existing approaches for combining spatial and temporal compositions

• Objectives• A proposal for a spatio-temporal composition model• Conclusions and perspectives

Context

• Programming complex scientific applications for gird infrastructures

• Challenges– Simplifying application programming– Abstraction from underlying resources– Efficient usage of resources

• Programming by composition• Today approaches

– Software component models– Workflow models

u

PrecipitationSorption

Relargage

ConvectionDispersionAqueous Reactions

Gaz-liquid exchange Dissolution

Biology

Hydrologie

Spatial and temporal compositions

• Software component models– Description approach

• Workflow models– Programmable approach

A BC

DSpatial

composition

t1 t2

end

t3

start

temporal composition

time

y n

Software component models

• Ports– Method invocations, events/messages/streams

• Several component models– Common Component Architecture/CCA Forum (CCA)– CORBA Component Model/OMG (CCM)– Fractal/ObjectWeb – Service Component Architecture/OSOA group (SCA) – Etc.

Softwarecomponent

PROVIDEDPORTS

REQUIRED PORTS

(client interfaces)

Softwarecomponent

(server interfaces)

Workflow languages

• Ports– Input/output data

• Temporal composition– Control flow and/or data flow

• Several languages– Askalon-Abstract Grid Wrokflow Language/

Univ. Innsbruck, Austria (AGWL)– Triana/ Univ. Cardiff, UK– Grid Concurrent Language/ HLRS Stuttgart,

Germany (GriCoL)– Kepler/ SEEK, SDM, GEON, etc.– etc.

task task

task

task

task

y n

d_out

d_in

Data flow

Control flow

Limitations of existing approachesfor combining spatial and temporal

compositions

Why combining spatial and temporal dimensions

• Spatial composition– Strong coupled applications– Resources usage

• Temporal composition – No appropriate for strong coupled applications – Resources usage

Limitation of existing approaches

• Software component models– Adding meta-data about component’s behavior (exp: ICENI)– Objective: compute an optimal placement of components– Require code knowledge– Complicate application design

• Workflow models– Encapsulate spatial composition within tasks implementations– Objective: offer a level of composition for coupled codes– Limits the hierarchy to two levels– Limits re-usability

• Limitations because of– spatial and temporal compositions are not at the same level

Objectives

• Specifying a programming model allowing both temporal and spatial composition at the same level

• Expressing an application behavior by the assembly• Ability to deduce efficient resource usage directly from

the assembly• Take advantages from existing models

– No need to start from scratch

A proposal for a spatio-temporalcomposition model

Global Approach

• Extending a software component– Input an output data ports– Task concept

• Extending a workflow language – Spatial composition to obtain an assembly language

Temporal port model (1/3)

Component A {

input double inA; output double outA;}

output port

input port

outA

A

inA

Temporal port model: internal view (2/3)

Component A {

input double inA; output double outA;}

output port

input port

outA

A_implementation

Container

inA

…void setIn_inA(double val){…}double getOut_outA(){…}

Temporal port model: external view (3/3)set_double(…)

outA

Container Port_inA : implements Tmp_double{void set_double (double val){…}

void connect_outA (Tmp_double p){…}

inA

interface Tmp_double { void set_double(double d); void set_void();}

connect_outA(..)

…void setIn_inA(...){…}double getOut_outA(){…}

Task concept

outA

Container

inA 1

impl.task()

2

4

outA.set_double()

void setIn_inA(...) { d_inA = ..} void task() {d_outA = d_inA + 10}; double getOut_outA() { return d_outA}

set_double(25)

impl.setIn_inA(25)

3

impl.getOut_outA(..)

5

during configurationInput reception

connections

Component life cycle

• Component states– Created– Active– Running– Inactive– Removed/no-existent

created

inactive

active

runningno-existentremoved

task and request executions

Assembly model

<sequence name="name"> <dataIn name="name" type="..."

(set=..)?/>* <dataOut name="name" type="..."/>* <clientPort name="name" type="..."

(set=..)?/>* <serverPort name="name" type="..."/>* <!-- other spatial ports --> <component>+</sequence>

<if name="name"> <!-- like in sequence--> <component>* <condition> condition </condition> <then> <component>+ </then> <else> <component>+ </else>?</if>

Sequence Condition

Example<assembly name ="example"> ... <parallel name="ParallelCtrl"> <section> <component name="B"> <dataIn name="inB" ... set="init.out1"/> <serverPort name="pB" type=“Foo"/> </component> </section> <section> <component name="A"> <dataIn name="inA" ... set="init.out2"/> <clientPort name="pA" type=“Foo" set="B.pB"/> </component> </section> </parallel> ... </assembly>

Conclusions and perspectives• Combination of spatial and temporal composition

in a same programming model • Extension of component model (GCM/CoreGRID)

– Temporal port and task concepts• Extension of workflow language (AGWL)

– Spatial ports and composition

• Perspectives– Feasibility through an implementation

• Rely on a workflow engine/ dynamic deployment– Formal semantic for validation

Questions ?