service oriented architecture for adaptive evolutionary algorithms

Service Oriented Architecture for Adaptive Evolutionary Algorithms: Implementation and Applications

PhD Dissertation by Pablo García SánchezUniversity of Granada

AdvisorsJesús González PeñalverJuan Julián Merelo GuervósAlberto Prieto Espinosa

16/06/2014

domingo 15 de junio de 2014

Heterogeneous and dynamic environments

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture

SOA-EA

OSGiLiath

Real infrastructure

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Classic distribution approaches in EAs

New trends

CC Photo by @draxus

ClientClient

Examples of adaptation in algorithms

• Adaptive Memetic Algorithms:

• Hyper-heuristics.

• Multimemes.

• Co-Evolving MAs.

• Adaptation to hardware.

Individual...

Challenges in EA software (Parejo et al. 2012)

• Standardization.

• Interoperability.

• Dynamic and reflexive capabilities.

• High cost on switching from a framework to other.

• Open Science.

Algorithm::Evolutionary

MALLBA jMetal

DR-E-AMParadiseEOHeuristicLab

METCOjCLEC

gridUFO

SOA-EA

OSGiLiath

Real infrastucture

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Service Oriented Architecture

Service characteristics

• Differences with Object-Oriented paradigm.

• Discoverable and dynamically bound.

• Self-contained.

• Modular.

• Interoperable (different programming languages).

• Loosely coupled.

• Location transparent.

Technologies and methodologies for SOA

Specific Ontology Navigation

Content Rendering

Transaction Handling

Business Processes

Collaboration Agreements, MOA

Codelist subsetting Services; Transaction Processing

Communities of Interests- CoI

778899

UMM SOMA

Ali Arsanjani https://www.ibm.com/developerworks/library/ws-soa-design1/

REST Web Services

SOA as a solution

• Development

• Integration

• Standardization

• Dynamism

SOA (abstract) GRID (infrastructure)

Web Services

Frameworks for EAs

Evolutionary Robotics

Cloud Computing

Globus

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture

BitFlip

Mutation

Binary

Initialization

Fitness Distributor

Evaluation

Recombination

Roulette

Selection

UPXN 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.

• Configurable output.

• Restrictions in SOA design (Valipour):

• Dynamic binding.

• Self-contained.

• Location transparency.

SOA-EA

Step 1: Identification

• Problems to solve.

• Elements needed.

• Re-utilization.

• Operators.

• Extension points.

• Parameterization.

Step 2: Specification

• Inputs/Outputs.

• Operations of each services.

• Individual representation.

• Services usage.

• Order of execution.

• Multiple instances.

• Adaptation to machines.

Specification: Operators

• Flexibility: Recombination can receive more than two individuals.

• Receive interfaces (generic representation).

RecombinationList of individuals

List of individuals

Crossover

mother, father son1, son2

Specification: Population, Parameters and Fitness

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 individualsList of fitnesses

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.

BitFlip

Mutation

Binary

Initialization

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.

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture

• Framework to develop SOEAs.

• Includes well-defined interfaces and implementations.

• Paradigm independent.

• Multiple technologies for distribution and discovery.

• Plug-in based.

• Automatic binding.

• Component-oriented.

OSGiLiath

Example: Basic GA

Example: NSGA-2

Example: Master-slave model

Example: Island model

Island BIsland A

Example: Adaptation of operators

Implementation: Why OSGi?

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 configuration.

OSGi does not add overload

• Experiment 1: Performance using OSGi.

• Comparing the same EA.

• Solving OneMax problem with the same parameters.

• Stop criterion: fixed number of generations.

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.

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)

Non!adaptive Adaptive0e

Configuration

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.

OSGi ECF does not add overhead communication

500 1000 1500 2000

Number of individuals

Seconds

SOA saves development time

• Experiment 4: Comparison with other frameworks.

• The same algorithm and parameter configuration in different frameworks (solving OneMax).

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

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture

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.

Automatic binding of nodes

Replacer

Basic Replacer

Migrator

Migrator Ring Buffer

Remote nodesLocal Node

Migrator

Configurations

• Homogeneous Hardware (HoHa).

• Heterogeneous Hardware (HeHa).

• Homogeneous Size (HoSi): 256 individuals.

• Heterogeneous Size (HeSi): proportional to generations.

• Adaptive Size (AdSi):

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 configuration in all nodes.

• 40 times per configuration.

Automatic adaptation improves results (MMDP)

HoHa (Homogeneous Hardware)

HeHa (Heterogeneous Hardware)

HoSi HeSi AdSi

Configuration

rogeneous

HoSi HeSi

Configuration

Average population sizes in AdSi solving MMDP

HeN1 HeN2 HeN3 HeN4

Popula

tion S

Automatic adaptation improves results (OneMax)

HoHa (Homogeneous Hardware)

HeHa (Heterogeneous Hardware)

HoSi HeSi

0120000

140000

Configuration

HoSi HeSi AdSi

100000

120000

140000

180000

Configuration

rogeneous

Average population sizes in AdSi solving OneMax

HeN1 HeN2 HeN3 HeN4

Adapting parameters affect all services (MMDP)

Adapting parameters affect all services (OneMax)

Adaption improves the results in time

• Adapting online or offline the sub-population size to the computational power of each node yields significantly 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.

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture

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.

Planet Wars

Agent generation

• For each planet execute tree.• Based in decisions and actions.• Dynamic fitness: 5 combats vs

Genebot and ExpGenebot.• Crossover/mutation of

branches/tags and rates.

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

Configuration

3G 7G UG 3E 7E UE

Configuration

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.

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.

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 identified.

• 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.

Contributions (and II)

• The methodology has been validated using a specific SOA technology: OSGi.

• A SOA-based implementation (OSGiLiath) of distributed, dynamic, standards-based evolutionary algorithms has been able to solve efficiently 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.

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 fields.

• New modules and services to address new problems will be added to OSGiLiath.

Publications related with this thesis

Total First author

Journals 5 2

LNCS 5 5

Other peer-reviewed conferences

Open Science

• OSGiLiath: https://github.com/fergunet/osgiliath

• Thesis development: https://github.com/fergunet/tesis

• Web page: http://www.osgiliath.org

Thank you very much!

Questions?

service oriented architecture for adaptive evolutionary algorithms

Technology

evolutionary body building: adaptive physical designs for...

sensorless adaptive ﬁeld oriented control of brushless...

adaptive algorithms and parallel computing -...

evolutionary authoring tool for adaptive hypermedia with -...

adaptive object-oriented software development

adaptive memory: the evolutionary significance of survival

generic programming using adaptive and aspect-oriented...

adaptive selection in evolutionary algorithm thesis

an adaptive supg method for evolutionary convection-di ......

adaptive evolutionary genetics - 東京大学€¦ ·...

adaptive evolutionary genetics - university of · pdf...

evolutionary adaptive discovery of phased array sensor...

a goal-oriented adaptive finite element method with

operation of a layer-oriented multiconjugate adaptive

evolutionary problems in aspect oriented software...

improving adaptive game ai with evolutionary learning

towards aspect oriented adaptive case management

object-oriented analysis and design evolutionary...

distributed adaptive networks: a graphical evolutionary

the adaptive market hypothesis: market efficiency from an...