From Components to
Compositions
(1) Omer F. Rana (O.F.Rana@cs.cardiff.ac.uk)
(2) Cecilia Gomes (Cecilia.Gomes@di.fct.unl.pt)
(2) José C. Cunha (jcc@di.fct.unl.pt)
(1)
(2)
School of Computer Science and Welsh eScience
Centre, Cardiff University, United Kingdom
CITI, Universidade Nova de Lisboa, Portugal
Programming
Abstractions
Programming Languages and other forms of
software systems “evolve” to higher levels
of abstractions
–
–
–
–
–
Hide details of hardware platform/interfaces
Reduce development time
Reduce maintenance costs
Increase portability
Leave commonly performed tasks to software
libraries (compilers, optimzers, automated load
balancing, etc)
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
What are Programming
Abstractions?
From Wikipedia:
– A way to remove detail so one can focus on a
few concepts at a time
Control vs Data Abstractions
– Control: manage order of execution within a
program
– Data: manage data items in some meaningful
manner (data types)
Design Abstractions vs. Programming
Abstractions
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Greenspun’s 10th Rule of
Programming
“Any sufficiently complicated C or
Fortran program contains an ad hoc,
informally-specified, bug-ridden, slow
implementation of half of Common
Lisp.”
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Programming Abstractions
and Middleware
Middleware is a set of programming
abstractions
– Need to understand the programming
model employed by middleware
– Programming model identifies:
limitations, general performance, and
applicability of a given middleware
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Workflow and Programming
Abstractions
Three aspects of workflow:
– Components/services within a workflow
– Workflow enactment process (may be
distributed)
– Types of enactment process: data flow
vs. control flow
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Data/Control-Flow Spectrum
“clean” data(=ctl)-flow
special tokens flow
message passing, control flow
Data (tokens) flow
– (almost) no other side effects
– WYSIWYG (usually)
References flow
– token reference type may be “http-get”, “ftp-get”
– generic handling still possible
Application specific tokens flow
–
–
–
e.g. current Nimrod job management in Resurgence
“invisible contract” between components
Director is unaware of what’s going on
Specific messages passing protocols (e.g., CSP, MPI)
– for systems of tightly coupled components
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Various types of abstractions
Visual Composition
Data Flow or Control Flow
Language based
Functional Languages
Abstraction based
Petri nets, Process (Composition) Algebras
IRIS Explorer, ADL, Gateway/WebFlow,
ARCADE, Mathematica, MatLab etc
Recently – use of Mashup and Google Gadgets
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Enactment Strategies … I
Centralised Enactor
– Single graph coordinated through a
centralised enactor
– The enactor manages execution of
components in some sequence
Distributed Enactors
– Graph divided into sub-graphs and
handed to different enactors
– Each enactor responsible for executing
local graph
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Enactment Strategies … II
Event-based
– Each component on completion generates an
event
– Use of publish-subscribe mechanism
– Each component also activated through the
generation of an event
– Can have multiple event types
Blackboard/Shared memory
–
–
–
Component/Enactor writes to a shared space
Monitored by components/enactor
Blocks on availability of particular data items in
DPA Theme
shared space NeSC,
NeSC, Edinburgh, May 2007
Enactment for Automated
Composition
Enactment engine enlists use of other components
– Discovery Service
– Planning Engine
Enactment is “goal-oriented”
– Define requirement, rather than components
– Conflict detection support
– Mechanisms to chose between alternatives (constraints)
Difficult to do in practice
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Workflow
Planning/Adaptation
Goal-oriented
Abstract Concrete workflow translation
– May utilise a number of different infrastructure
services (Pegasus)
Level of automation can vary
–
–
–
–
Find components
Find sub-workflows
Find infrastructure services
Publish output data at specific locations
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Planning as Model Checking
Planning under uncertainty
Support different degrees of “run-time
observability”
– domain state partially visible via sensing
“Temporally extended planning” goals
– conditions on states that arise when a
plan is executed
– “goal” specifies conditions/constraints on
intermediate states, and not just on the
final outcome
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Planning Domains
actions
Plan
Domain
observations
Domain Model of generic system
Plan monitors evolution of domain via
“observations”
– Controls evolution of domain via “actions”
Planning domain defined in terms of:
– States, Actions (it accepts), Observations (domain can
exhibit)
– Transition function: action execution changes domain
state
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
– Observation function: observations associated with each
state
Action Execution and Beliefs
Context: internal state of plan
– Account for knowledge gathered during previous steps
– Actions: depend on observation and on the context
Due to partial observability, a set of domain states
need to be considered (given initial knowledge and
current plan state)
– Executing an action “a” evolves BB’ (contains all
possible states that can be reached through “a” from “B”)
– If after executing “a” observation “o” still holds, then filter
out states for which “o” is not valid
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
From EU NextGRID
project
Semantic Approaches
Component/Services have “rich” annotations to aid discovery
Descriptions also contain support for composition of components
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Web Services Modelling
Ontology (WSMO)
Use of Semantic Web Services to aid automated
composition
Given a goal, identify how services could be
composed to achieve the goal
Specifies a complete set of infrastructure that is
necessary to achieve this
Provides three main components:
–
–
–
Web Services Modelling Ontology
Web Services Modelling Language
Execution Environment
DPA Theme
From: John Domingue, Open University
NeSC,
NeSC, Edinburgh, May 2007
WSMO Working Groups
A Conceptual Model
for SWS
A Formal Language for WSMO
A Rule-based Language for SWS
DPA Theme
From: John Domingue, Open University
NeSC,
NeSC, Edinburgh, May 2007
Execution Environment
for WSMO
WSMO Top Level Notions
Objectives that a client wants to
achieve by using Web Services
Provide the
formally specified
terminology
of the information
used by all other
components
Semantic description of
Web Services:
- Capability
(functional)
-
Connectors between components
with mediation facilities for
handling heterogeneities
DPA Theme
From: John Domingue, Open University
NeSC,
NeSC, Edinburgh, May 2007
Interfaces (usage)
WSMO Web Service
Description
- complete item description
- quality aspects
- Web Service Management
- Advertising of Web Service
- Support for WS Discovery
Non-functional Properties
Capability
DC + QoS + Version + financial
functional description
client-service
interaction interface
for consuming WS
- External Visible
Behavior
- Communication
Structure
- ‘Grounding’
Web Service
Implementation
WS
WS
(not of interest in Web
Service Description)
WS
realization of
functionality by
aggregating
other Web Services
- functional
decomposition
- WS composition
Choreography --- Service Interfaces --- Orchestration
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
From: John Domingue, Open University
WSMO Mediators Overview
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
From: John Domingue, Open University
Mediator Structure
WSMO Mediator
Source
Component
1 .. n
Source
Component
uses a Mediation Service via
1
Target
Component
- as a Goal
- directly
- optionally incl. Mediation
Mediation
Services
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
From: John Domingue, Open University
Workflow Lifecycle
From:
Aleksander Slominski
Design
– Typical workflow is graph oriented
– Language: how expressive is workflow
– GUI: Visual Service Composition Environment
Deployment
– Workflow Description is sent to Workflow Engine
– Possibly validated and compiled
Execution
– Workflow Engine enacts Workflow Description
Monitoring
– Events reflecting from workflow and services
execution
Refinement
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Use of Workflow Tools
Workflow
Composition
Enactment
One or more
scheduler
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Annotations to
support scheduling
and Reconfiguration
One Perspective …
Need some interaction
between these
two views
Dynamic Optimization/Runtime-based
– Viewed as an improved scheduling approach
– Consider aspects of computation and data
– Workflow re-ordering, parallelism exploitation
(task dependencies to support mapping)
Design time/Structure Optimization
– Reconfiguration of an existing workflow
– Modifications to structure or execution order
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Use of Workflow Tools
Workflow
Composition
Experience from myExperiment
and Triana use (data analysis)
Enactment
1. Not use as a single workflow
session – very much intended to
be a “trial and error” process
One or more
scheduler
2. Prototype-based – used for
experimenting with services and
data sets
3. Production scale work is generally
mapped to dedicated code development
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Annotations to
support scheduling
and Reconfiguration
Regular workflows
(like parameter sweeps)
Vs.
Irregular (few nodes)
Approach
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Approach
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Approach
Patterns are divided into two
categories:
– Co-ordination (Behavioural) patterns
Capture
systems
interactions between software sub-
– Structural patterns
Capture
connectivity between particular types
of Grid software/hardware components
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Approach
1.
2.
3.
4.
Deploy Structural Patterns,
Refine them through Structural
Operators,
Use Behavioural Patterns to define
control/data flow/interactions,
Use Behavioural Operators to
manage execution
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Structural Pattern
Templates
Encode component connectivity. Ex: Pipeline,
Ring, Star, Façade, Adapter, Proxy.
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Structural Operators
Manipulate structural patterns keeping
their structural constraints.
Examples:
–
–
–
–
–
Increase, Decrease,
Extend, Reduce,
Embed, Extract,
Group,
Rename/Reshape, …
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Increase Structural Operator
Pattern
Result Pattern
Increase(Pipeline,2)
Real Subject
Increase(Proxy,2)
Real
Subject
Proxy
Proxy
Proxy
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Proxy
Extend Structural Operator
Pattern
Result Pattern
Extend(Proxy,element)
Real
Subject
Real
Subject
Proxy
Proxy
Facade
Facade
Extend(Facade,element)
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Facade
Proxy
Embed Structural Operator
A star embedded in the first component placeholder of a pipeline template.
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Behavioural Pattern
Templates
Capture temporal or (data/control) flow
dependencies between components.
Examples:
–
–
–
–
–
–
Master/Slave,
Streaming,
Service Adapter,
Service Migration,
Broker Service
Service Aggregator/Decomposer, …
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Behavioural Operators
Act over the temporal or flow
dependencies for execution control
and reconfiguration.
Examples:
– Start, Terminate,
– Log,
– Stop, Resume,
– Restart, Limit,
– Repeat, …
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Supported Patterns/Operators
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Pattern Operators example
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
3- Implementation over
Triana
The Triana tool is a component-based
front-end for Grid Environments
(developed at Cardiff University).
Extending Triana:
– Structural patterns
– Structural operators
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
•Applications are built by connecting services
available in a toolbox
•The execution follows the dataflow model
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
The User´s View
1.
2.
3.
To configure and execute an
application using the patterns library:
Select a structural pattern (eg
pipeline)
Refine the chosen pattern with
structural operators
Select a behavioural pattern to
specify interactions (eg dataflow)
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
The User´s View
4. All place-holders must be instantiated
with units or group of units
5. Use a behavioural operator (eg start)
for controlling the execution
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
The System View
Patterns are available at the GUI to be
composed / manipulated through
operators
Behavioural patterns map to a Resource
Management System that coordinates the
execution
A ``pattern executor`` enforces the
selected behavioural pattern at each
element
Operator invocations are passed to the
RMS interface API
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Triana architecture
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Patterns and Operators in
Triana
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
The System View
The GUI sends the user´s requests
for execution to the local Triana
Service, as a taskgraph
Execution may be local or distributed
Each Triana service may delegate
execution to a local RMS
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
3- Implementation over Triana –
Galaxy simulation example
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Galaxy simulation example
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Galaxy simulation example
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Galaxy simulation example: a second
configuration
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Galaxy simulation example: a second
configuration
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
4- Mapping to the DRMAA
API Stop(Pattern)
Pattern Instance
drmaa_control(job_id, DRMAA_CONTROL_SUSPEND, … )
job1
Data and
Control flow
job2
Data and
Control flow
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
job3
Resume(Pattern)
Pattern Instance
drmaa_control(job_id, DRMAA_CONTROL_RESUME, … )
job1
Data and
Control flow
job2
Data and
Control flow
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
job3
Repeat(n,Pattern)
Pattern Instance
for(int count=0; count<n; count++) {
Start(Pipeline);
drmaa_synchronize(job_identifiers, … )
}
job1
Data and
Control flow
job2
Data and
Control flow
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
job3
Behavioural Operators and
Scheduling
Manipulate workflow scheduling via
behavioural operators
Behavioural operators use
performance data from Ganglia
monitoring tool
Start, Stop, Resume – utilize
performance data
Dynamic binding of “start” to load
average
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Related Approaches
Skeletons
– “A skeleton is a programming template which
is parameterised by the application programmer with
problem-specific customising functions and commonly
specified as a higher-order function […] which can perform
recursive computations”;
– represent common behaviour in parallel programming and are
used as components for building parallel programs. E.g.: map,
filter. [Herrmann and Lengauer] in “Patterns and Skeletons for
Parallel and Distributed Computing”
Service Design Patterns for Computational Grids –
identify how applications may be composed, shared, and
managed over a Computational Grid. E.g.: Broker Service
Pattern, Service Adapter Pattern. [Rana et al] in “Patterns and
Skeletons for Parallel and Distributed Computing”.
– The Enhance Project, for example, aims to enhance the
performance predictability of Grid applications with Patterns and
Process Algebras
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Related Approaches
Workflow Patterns
– common requirements and control flow schemas, e.g. . Basic
Control Flow Patterns: Sequence, Parallel Split; Branching and
synchronization Patterns: Multi-choice, Synchronizing Merge
[van der Aalst et al] http://www.workflowpatterns.com.
Patterns for Object-Oriented Middleware
– recurring structure and interaction schemas in middleware
like CORBA, Web Services and Peer-to-Peer systems. E.g.:
Service Access and Configuration Patterns: Wrapper
Façade, Component Configurator; Event Handling
Patterns: Reactor [Schmidt et al] – Pattern-Oriented
Software Architecture, Patterns for Concurrent and
Networked Objects.
– The ObjectAssembler visual development
environment provides a catalogue of patterns for
connecting JavaBean components.
[ObjectVenture]
http://objectventure.com/objectassembler.html
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Our
approach
Skeletons
Application
Abstractions
Service Design
Patterns for
Computational
Grids
Patterns for
OO
Middleware
√
Design
Abstractions
√
√
Software
Engineering
Abstractions
√
√
Programming
Abstractions
Workflow
Patterns
√
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
√
√
√
To Conclude
Understand common patterns in Grid
environments and applications
– Grid app. == composition of services
– Triana == tool to support workflow for
distributed components
Software Engineering support:
– Structural and Behavioural Patterns
– Structural and Behavioural Operators
Use this as a basis to support workflow
enactment
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007
Further Reading
Extending Grid-based Workflow Tools with Patterns and Operators,
Cecilia Gomes, Omer Rana, Jose Cunha, Int. Journal of High
Performance Computing Apps, 2007 (in press)
Pattern/Operator based Problem Solving Environments, Cecilia Gomes,
Omer F. Rana, and Jose Cunha, EuroPar 2004, Springer Verlag, Pisa,
Italy, August 2004.
Patterns and Operators for Grid Software Development, Omer F. Rana,
Maria Ceclia Gomes and Jose C. Cunha, IADIS International Conference
WWW/INTERNET 2003, Algarve, Portugal, November 5-8 2003.
Pattern Operators for Grid Environments, M. Cecilia Gomes, Omer F.
Rana, and Jose C. Cunha, Journal of Scientific Programming, IOS Press,
2003.
A Pattern based Software Engineering Tool for Grid Environments,
Cecilia Gomes, Jose C. Cunha, and Omer F. Rana, NATO Advanced
Research Workshop on Concurrent Information Processing and
Computing, Sinaia, Romania, July 2003.
DPA Theme
NeSC,
NeSC, Edinburgh, May 2007