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

SOA-EA

OSGiLiath

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem

Real infrastucture


SOA

SOA-EA

OSGiLiath

Real infrastructure

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem


Classic distribution approaches in EAs

3


New trends

4

CC Photo by @draxus

Pool

ClientClient


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 reflexive capabilities.

• High cost on switching from a framework to other.

• Open Science.

6

Algorithm::Evolutionary

MALLBA jMetal

ECJ

DR-E-AMParadiseEOHeuristicLab

METCOjCLEC

gridUFO



SOA

SOA-EA

OSGiLiath

Real infrastucture

Objective 4

Objective 2

Objective 1

Objective 3

Realproblem


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

778899

10 10

11 11

!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


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

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

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

Realproblem

Real infrastucture


SOEAs

13

BitFlip

Mutation

Binary

Initialization

Fitness Distributor

Evaluation

TPX

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.

14


SOA-EA

15


Step 1: Identification

• Problems to solve.

• Elements needed.

• Re-utilization.

• Operators.

• Extension points.

• Parameterization.

16


Step 2: Specification

• Inputs/Outputs.

• Operations of each services.

• Individual representation.

• Services usage.

• Order of execution.

• Multiple instances.

• Adaptation to machines.

17


Specification: Operators

• Flexibility: Recombination can receive more than two individuals.

• Receive interfaces (generic representation).

18

RecombinationList of individuals

List of individuals

Crossover

mother, father son1, son2


Specification: 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 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.

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

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

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

30


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.

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 Adaptive0e

+0

01

e+

07

2e

+0

73

e+

07

4e

+0

7

Configuration

Eva

lua

tion

s

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

0.1

0.2

0.3

0.4

0.5

0.6

Number of individuals

Seconds

SOAP

OSGi


SOA saves development time

• Experiment 4: Comparison with other frameworks.

• The same algorithm and parameter configuration 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



SOA

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.

38


Automatic binding of nodes

39

Replacer

Basic Replacer

Migrator

Migrator Ring Buffer

Remote nodesLocal Node

Migrator

Migrator

...


Configurations

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

• 40 times per configuration.

41


Automatic adaptation improves results (MMDP)

42

HoHa (Homogeneous Hardware)

HeHa (Heterogeneous Hardware)

HoSi HeSi AdSi

5e+

02

2e+

03

1e+

04

5e+

04

2e+

05

Configuration

Tim

e (

Hete

rogeneous

Hard

ware

)

HoSi HeSi

5e

+02

2e+

03

1e+

04

5e+

04

Configuration

Tim

e (

Hom

ogen

eous

Hard

ware

)


Average population sizes in AdSi solving MMDP

43

HeN1 HeN2 HeN3 HeN4

0200

400

600

800

1000

Node

Popula

tion S

ize


Automatic adaptation improves results (OneMax)

44

HoHa (Homogeneous Hardware)

HeHa (Heterogeneous Hardware)

HoSi HeSi

80000

10000

0120000

140000

Configuration

Tim

e (

Hom

ogen

eous

Hard

ware

)

HoSi HeSi AdSi

100000

120000

140000

180000

Configuration

Tim

e (

Hete

rogeneous

Hard

wa

re)


Average population sizes in AdSi solving OneMax

45

HeN1 HeN2 HeN3 HeN4

02

00

40

06

00

80

01

00

0

Node

Po

pu

latio

n S

ize


Adapting parameters affect all services (MMDP)

46


Adapting parameters affect all services (OneMax)

47


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.

48



SOA

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.

50


Planet Wars

51


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.

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

100

200

300

400

500

Configuration

Turn

s to

be

defe

ate

d

3G 7G UG 3E 7E UE

10

20

30

40

50

60

70

Configuration

Perc

enta

ge o

f vi

ctori

es


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

57


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.

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

• 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


https://github.com/fergunet/tesis




http://www.osgiliath.org

http://www.osgiliath.org

Thank you very much!

Questions?
