Service Oriented Architecture for Adaptive Evolutionary Algorithms

Service Oriented Architecture for Adaptive
Evolutionary Algorithms: Implementation and
Applications
PhD Dissertation by
Pablo García Sánchez
University of Granada
Advisors
Jesús González Peñalver
Juan Julián Merelo Guervós
Alberto Prieto Espinosa
16/06/2014
domingo 15 de junio de 2014

Heterogeneous and dynamic environments
SOA
SOA-EA
OSGiLiath
Objective 4
Objective 2
Objective 1
Objective 3
Real
problem
Real
infrastucture
SOA
SOA-EA
OSGiLiath
Real
infrastructure
Objective 4
Objective 2
Objective 1
Objective 3
Real
problem

Classic distribution approaches in EAs
3

New trends
4
CC Photo by @draxus
Pool
Client
Client

Examples of adaptation in algorithms
• Adaptive Memetic Algorithms:
• Hyper-heuristics.
• Multimemes.
• Co-Evolving MAs.
• Adaptation to hardware.
5
GA SA
SA
LS
TS
Individual
...
?

Challenges in EA software (Parejo et al. 2012)
• Standardization.
• Interoperability.
• Dynamic and reﬂexive capabilities.
• High cost on switching from a framework to other.
• Open Science.
6
Algorithm::Evolutionary
MALLBA
jMetal
ECJ
DR-E-AMParadiseEO
HeuristicLab
METCO
jCLEC
gridUFO

SOA
SOA-EA
OSGiLiath
Real
infrastucture
Objective 4
Objective 2
Objective 1
Objective 3
Real
problem

Service Oriented Architecture
8

Service characteristics
• Differences with Object-Oriented paradigm.
• Discoverable and dynamically bound.
• Self-contained.
• Modular.
• Interoperable (different programming languages).
• Loosely coupled.
• Location transparent.
9

Technologies and methodologies for SOA
10
BCM
Specific Ontology
Navigation
Content Rendering
Transaction Handling
Business Processes
Collaboration
Agreements, MOA
Codelist subsetting Services;
Transaction Processing
Communities of Interests
- CoI
44
55
66
7788
99
1010
1111
!
Copyright (C) OASIS Open 2003-2006. All Rights Reserved.
UMM SOMA
Ali Arsanjani
https://www.ibm.com/developerworks/library/ws-soa-design1/
REST Web Services

SOA as a solution
• Development
• Integration
• Standardization
• Dynamism
11
SOA (abstract) GRID (infrastructure)
Web Services
Frameworks for
EAs
Evolutionary
Robotics
Cloud Computing
Globus

25
SOA
SOA-EA
OSGiLiath
Objective 4
Objective 2
Objective 1
Objective 3
Real
problem
Real
infrastucture

SOEAs
13
BitFlip
Mutation
Binary
Initialization
Fitness Distributor
Evaluation
TPX
Recombination
Roulette
Selection
UPX
N Worst Rep.
Replacement
MMDP calculator
Evaluation
MMDP calculator
Evaluation

Design issues for SOEAs
• Genericity in EA design (Gagné & Parizeau):
• Representation.
• Fitness.
• Operations.
• Evolutionary model.
• Parameter management.
• Conﬁgurable output.
• Restrictions in SOA design (Valipour):
• Dynamic binding.
• Self-contained.
• Location transparency.
14

SOA-EA
15

Step 1: Identiﬁcation
• Problems to solve.
• Elements needed.
• Re-utilization.
• Operators.
• Extension points.
• Parameterization.
16

Step 2: Speciﬁcation
• Inputs/Outputs.
• Operations of each services.
• Individual representation.
• Services usage.
• Order of execution.
• Multiple instances.
• Adaptation to machines.
17

Speciﬁcation: Operators
• Flexibility: Recombination can receive more than two
individuals.
• Receive interfaces (generic representation).
18
Recombination
List of individuals
List of individuals
Crossover
mother, father son1, son2

Speciﬁcation: Population, Parameters and Fitness
19
Population
- add Individuals
- get N Best Individual
- get N Worst Individuals
- get Size
...
Parameters
- get Parameter
- update Parameter
- get Parameter Labels
...
Fitness
Calculator
List of individuals
List of ﬁtnesses

Specification of the flow
• Reduce the impact of future changes.
• Example of flow: Evolutionary Algorithm implementation
(generic evolutionary model).
• Automatic adaptation and binding of the elements.
• Services for hardware adaptation.
20
BitFlip
Mutation
Binary
Initialization
TPX
Recombination
Roulette
Selection
N Worst Rep.
Replacement

Steps 3 and 4: Implementation and deployment
• Local or remote services.
• Interfaces publication.
• Public or private services.
• Dynamism control.
• Overload of messages.
• Technology selection.
• Security, persistence, benchmarking and
monitoring.
21

SOA
SOA-EA
OSGiLiath
Objective 4
Objective 2
Objective 1
Objective 3
Real
problem
Real
infrastucture

• Framework to develop SOEAs.
• Includes well-deﬁned interfaces and implementations.
• Paradigm independent.
• Multiple technologies for distribution and discovery.
• Plug-in based.
• Automatic binding.
• Component-oriented.
OSGiLiath
23

Example: Basic GA
24

Example: NSGA-2
25

Example: Master-slave model
26

Example: Island model
27
Island BIsland A

Example: Adaptation of operators
28

Implementation: Why OSGi?
29
OSGi Web Services
Primary environment Local* Internet
Language Java* Any
Interfaces Java Interface* WSDL
Communication protocol Variable SOAP
Dynamism White-Board Explicit
Client creation Previously known Automatic
Extras Plug-in based WS-Extensions
* (by default)

SOA validation experiments
• Experiment 1: OSGi comparison.
• Experiment 2: Adaptive service binding.
• Experiment 3: Distribution and language independence.
• Experiment 4: Development time between frameworks
for EAs.
• Algorithm: canonical GA with same parameters.
• Problems: MMDP and OneMax.
• 30 times for conﬁguration.
30

OSGi does not add overload
• Experiment 1: Performance using OSGi.
• Comparing the same EA.
• Solving OneMax problem with the same parameters.
• Stop criterion: ﬁxed number of generations.
31
Average solution Average time (s)
OSGiLiath 612.26 ± 6.05 0.19 ± 0.02
OSGiLiath
(without OSGi)
613.36 ± 4.50 0.19 ± 0.02

Service adaptation improves the results
• Experiment 2: Adaptive service binding.
• Solve the MMDP problem.
• Static version vs. adaptive version.
• Stop criterion: optimum found.
32
Evolutionary Algorithm
Algorithm
List Population
Population
Selector Gatherer
Parent Selector
Asynchronous
Enabler Impl
Asynchronous Enabler
N Tournament
Parent Selector
Roulette
Parent Selector

Service adaptation improves the results (II)
33
Non−adaptive Adaptive
0e+001e+072e+073e+074e+07
Configuration
Evaluations
Number of evaluations to solve MMDP problem

OSGiLiath is independent of the programming language
• Experiment 3: Integration with other systems.
• Language independence: PHP and Java.
• Comparing different communication mechanisms: SOAP
and OSGi ECF generic.
• Different number of individuals: 250, 500, 1000, 2000.
34

OSGi ECF does not add overhead communication
35
500 1000 1500 2000
0.00.10.20.30.40.50.6
Number of individuals
Seconds SOAP
OSGi

SOA saves development time
• Experiment 4: Comparison with other frameworks.
• The same algorithm and parameter conﬁguration in
different frameworks (solving OneMax).
36
Name Avg. Solution Avg. Time (s) Lines of Code
OSGiLiath 612.26 ± 6.05 0.19 ± 0.02 10
OSGiLiath
(without OSGi)
613.36 ± 4.50 0.19 ± 0.02 103
MALLBA 578.76 ± 7.48 0.16 ± 0.01 2073
ECJ 602.76 ± 6.08 1.40 ± 0.03 5
Algorithm::Evo-
lutionary
617.60 ± 12.92 7.78 ± 0.29 41

Study on parameter adaptation
• There is not a central control node.
• The number of nodes participating is not limited.
• All nodes automatically bind the available distribution
services.
• The nodes must stop when the optimum is found.
• Services must be executed in heterogeneous machines
with different operating systems and architectures.
38

Automatic binding of nodes
39
Replacer
Basic
Replacer
Migrator
Migrator Ring
Buffer
Remote nodesLocal Node
Migrator
Migrator
...

Conﬁgurations
• Homogeneous Hardware (HoHa).
• Heterogeneous Hardware (HeHa).
• Homogeneous Size (HoSi): 256 individuals.
• Heterogeneous Size (HeSi): proportional to generations.
• Adaptive Size (AdSi):
40

Experimental setting
• Problems to solve: MMDP and OneMax.
• Stop criterion: optimum found.
• Topology: ring.
• Benchmark: number of generations.
• Algorithm: canonical steady-state genetic algorithm.
• The same parameter conﬁguration in all nodes.
• 40 times per conﬁguration.
41

Automatic adaptation improves results (MMDP)
42
HoHa
(Homogeneous Hardware)
HeHa
(Heterogeneous Hardware)
HoSi HeSi AdSi
5e+022e+031e+045e+042e+05
Configuration
Time(HeterogeneousHardware)
HoSi HeSi
5e+022e+031e+045e+04
Configuration
Time(HomogeneousHardware)

Average population sizes in AdSi solving MMDP
43
HeN1 HeN2 HeN3 HeN4
02004006008001000
Node
PopulationSize

Automatic adaptation improves results (OneMax)
44
HoHa
(Homogeneous Hardware)
HeHa
(Heterogeneous Hardware)
HoSi HeSi
80000100000120000140000
Configuration
Time(HomogeneousHardware)
HoSi HeSi AdSi
100000120000140000180000
Configuration
Time(HeterogeneousHardware)

Average population sizes in AdSi solving OneMax
45
HeN1 HeN2 HeN3 HeN4
02004006008001000
Node
PopulationSize

Adapting parameters affect all services (MMDP)
46

Adapting parameters affect all services (OneMax)
47

Adaption improves the results in time
• Adapting online or ofﬂine the sub-population size to the
computational power of each node yields signiﬁcantly
better results in time.
• The same heterogeneous parameter setting could not
improve the results in homogeneous environments.
• The generations in each node is a possible benchmark
for parameter setting.
• Changing a parameter can affect all services of the
SOEA.
48

Motivation
• RTS games (Planet Wars).
• Genetic Programming.
• Existing competitive (agents): GeneBot (G) and
ExpGenebot (E).
• Different node depth: 3,7, Unlimited.
• Validation of the bots in other maps.
50

Planet Wars
51

Agent generation
• For each planet execute tree.
• Based in decisions and actions.
• Dynamic ﬁtness: 5 combats vs
Genebot and ExpGenebot.
• Crossover/mutation of
branches/tags and rates.
52
actualMyShipsRatio>0.711
attackWeakestNeutralPlanet(0.3)
attackNearestEnemyPlanet(0.2)
attackEnemyBase(0.91)
myShipsLandedFlyingRatio>0.21

Obtained bots are competitive
• Each generated bot with different maximum depth (3, 7
and U) is tested vs. Genebot (G) and Exp-Genebot (E) in
100 maps.
53Percentage of victories Turns to be defeated
3G 7G UG 3E 7E UE
100200300400500
Configuration
Turnstobedefeated
3G 7G UG 3E 7E UE
10203040506070
Configuration
Percentageofvictories

A SOEA obtains competitive bots for RTS games
• A SOEA is used to generate agents for playing Planet
Wars RTS game without using human knowledge, using
Genetic Programming.
• EA and SOA requirements have been taken into
account.
• Obtained bots outperform the one generated by human
experts and optimized by a GA.
• Differences in maximum depth.
54

Conclusions and outlook

Conclusions
• EAs can be successfully migrated to SOA and take
advantage in dynamic and heterogeneous scenarios.
• The used SOA technology has a huge impact in several
issues.
• SOA not force to use distribution services.
• SOA paradigm can be applied successfully to EAs to
facilitate the integration, distribution, dynamism and
development in some scenarios.
56

Contributions (I)
• The Service Oriented Architecture paradigm has been proposed to
create distributed, heterogeneous, dynamic and standards-based
environments for Evolutionary Algorithms, as it provides
mechanisms for interoperability, integration and dynamic control.
• The requirements to develop EAs in the SOA paradigm have been
identiﬁed.
• These requirements have been taken into account to propose
SOA-EA, a methodology that is able to successfully adapt
evolutionary algorithms to distributed, heterogeneous, dynamic,
standards-based environments.
• Several steps to design all the elements in an EA have been
proposed inside this methodology.
57

Contributions (and II)
• The methodology has been validated using a speciﬁc
SOA technology: OSGi.
• A SOA-based implementation (OSGiLiath) of distributed,
dynamic, standards-based evolutionary algorithms has
been able to solve efﬁciently different problems.
• As an application of this methodology, two different
parameter adaptation schemes of island-based EAs to
heterogeneous hardware have been proposed, and an
algorithm to obtain competent bots for RTS games has
been obtained.
58

Future work
• New research line in automatic adaptation of parameters
and operators in dynamic and heterogeneous
environments under the SOA paradigm.
• More mechanisms to enable/disable services.
• Different benchmarking services.
• Comparison of communication mechanisms.
• Automatic service composition using other technologies.
• Extend the concept of SOEA to other ﬁelds.
• New modules and services to address new problems will
be added to OSGiLiath.
59

Publications related with this thesis
60
Total First author
Journals 5 2
LNCS 5 5
Other peer-reviewed
conferences
4 2

Open Science
• OSGiLiath: https://github.com/fergunet/osgiliath
• Thesis development: https://github.com/fergunet/tesis
• Web page: http://www.osgiliath.org
61

Thank you very much!
Questions?

Service Oriented Architecture for Adaptive Evolutionary Algorithms

More Related Content

Similar to Service Oriented Architecture for Adaptive Evolutionary Algorithms (20)

Recently uploaded (20)

Service Oriented Architecture for Adaptive Evolutionary Algorithms