making sense of software architecture

71
1 Making Sense of Software Architecture Research and Development Experience Yan Liu 12/29/2008

Upload: rossa

Post on 19-Jan-2016

21 views

Category:

Documents


0 download

DESCRIPTION

Making Sense of Software Architecture. Research and Development Experience Yan Liu 12/29/2008. Outline. About Me Research Overview Research Experience Developing Adaptive Software Systems Related Research Position Alignment Position Expectation. About Me. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Making Sense of Software Architecture

1

Making Sense of Software Architecture

Research and Development Experience

Yan Liu12/29/2008

Page 2: Making Sense of Software Architecture

2

Outline About Me Research Overview Research Experience

Developing Adaptive Software Systems Related Research

Position Alignment Position Expectation

Page 3: Making Sense of Software Architecture

3

About MeSenior Research @ NICTA, July 2007 – presentConjoint Senior Lecturer @ CSE, UNSW, July

2007 – present

Researcher @ NICTA, March 2004 – June 2007 Lecturer @ School of Computer Science and

Engineering, University of New South Wales (CSE, UNSW), March 2004 – June 2007

PhD, 2001-2004. University of SydneyIntl. Postgraduate Research Scholarship,

Department of Education, AustraliaSupervisors: Prof. Alan Fekete and Prof. Ian GordonThesis:

A framework of performance prediction of component-based applications

Page 4: Making Sense of Software Architecture

4

Research StatsResearch funding – $1.2MResearch projects:

Adaptive Middleware Platforms - AMPComponent Architecture for microkernel-based

Embedded Systems – CAmkES

Collaborative projectsPerformance Assessment of e-Government Service

Architecture – e-PASA (Medicare/ATO)Trade-off Analysis Method for Mission Critical

Middleware Systems on DSTO Hybrid Test Bed (DSTO)

Architecture Evaluation for Middleware-based Airborne Mission Systems (DSTO)

Page 5: Making Sense of Software Architecture

5

Research MissionDevising analysis models, architectures and frameworks to improve the performance and dependability of large distributed software systems.

Page 6: Making Sense of Software Architecture

6

Research Capability

SoftwareArchitecture

Performance modeling

Architecture design & evaluation

Adaptive self-managing systems

Queuing theoryStatistic

analysisStochastic process

Model driven developmentArch.

evaluation Component-based engineering

Zero-configuration policy

Performance control

Non-stopping replacement

Page 7: Making Sense of Software Architecture

7

Application Domains

SoftwareArchitecture

Middleware Applications

Embedded Systems

Integrated Service Systems

Architecture evaluation

Performance modeling

Component-based development

Architecture evaluation

Resource allocation

Self-managing and adaptation

Model driven development

Capacity planning

Page 8: Making Sense of Software Architecture

8

Research Outcomes

SoftwareArchitecture

Middleware Applications

Embedded Systems

Integrated Service Systems

Patent application filedSoftware

prototypes

NICTA research fund

Open source software released

Government International Science Linkages – Europe Fund, 2009 – 2010.

Zero-configuration policy

Collaborative projectsNon-stopping

replacement

NICTA research fund

Page 9: Making Sense of Software Architecture

9

Research Capability

SoftwareArchitecture

Performance modeling

Architecture design & evaluation

Adaptive self-managing systems

Queuing theoryStatistic

analysisStochastic process

Model driven developmentArch.

evaluation Component-based engineering

Zero-configuration policy

Performance control

Non-stopping replacement

Page 10: Making Sense of Software Architecture

10

Research ExperienceDeveloping Middleware-based Adaptive

Systems

SoftwareArchitecture

Middleware Applications

Embedded Systems

Integrated Service Systems

Architecture evaluation

Performance modeling

Component-based development

Architecture evaluation

Resource allocation

Self-managing and adaptation

Model driven development

Capacity planning

Page 11: Making Sense of Software Architecture

11

Adaptive Middleware Platform

RespondSense

AnalysePlanAggregate stimuli frommultiple sources

Make optimal plans of actions

Detect stimuli in real-time

Invoke actions in real-time

Page 12: Making Sense of Software Architecture

12

Open Problems

Extensible software architectures

Mechanisms to enable dynamic monitoring and

adaptation

Accurate and reliable

predictive models

Mapping high level business goals to

low level QoS management

Sense and Respond

Asynchrony

Global situational awareness

Accuracy and efficiency

Lower cost and higher quality than human

administration

Architecture frameworks

Separation of concerns

Non-instrument probes

Process orchestration

Model-based analysis

Empirical evaluation

Research ChallengesBusiness DemandsSoftware Engineering Solutions

Page 13: Making Sense of Software Architecture

13

Basic

Manual analysis and problem solving

Managed

Predictive

Adaptive

Autonomic

Centralized tools and manual actions

Cross-resource correlation and

guidance

System monitors, correlates and takes

actions

Dynamic business policy-driven management

Level 1 Level 2 Level 3 Level 4 Level 5

Technology Roadmap

Analytical modeling theory for quality

attributes

Experience gained through collaborative

projects

Software architectureand middleware

technologies

Adaptive integrated service architecture

Automatic tuning of mission critical system

Increased autonomic functionality

AMP

Page 14: Making Sense of Software Architecture

14

Start with a framework …

?

Page 15: Making Sense of Software Architecture

15

Aims for Adaptive Server Framework

Factor out common elements into infrastructure

Reduce effort to build adaptive components

Transparently enhance adaptive components with advanced features

Make it easier to build stable and dependable adaptation capability

Page 16: Making Sense of Software Architecture

16

Architecture

Page 17: Making Sense of Software Architecture

17

Architecture

Page 18: Making Sense of Software Architecture

18

Sample Implementationp u b lic v o id r e lo ad I n f o ( ) ;p u b lic v o id en ab le( ) ;p u b lic v o id d is ab le( ) ;p u b lic b o o lean is E n ab led ( ) ;

< < AS F I n te r f ac e> >L if ec y c le

p u b lic S tr in g g e tT y p e( ) ;p u b lic S tr in g g e tN am e( ) ;p u b lic E lem en tI n f o g e tI n f o ( ) ;p u b lic v o id s e tI n f o ( E lem en tI n f o in f o ) ;

< < AS F I n te r f ac e> >S ta te m an ag em en t

p u b lic v o id h an d leM es s ag e( M es s ag e m s g ) ;

< < AS F I n te r f ac e> >M es s ag e C o n s u m er

< < AS F I n te r f ac e> >M es s ag e P r o d u c er

p u b lic v o id ad d M es s ag eC o n s u m er ( S tr in g m es s ag eN am e, M es s ag eC o n s u m er c o n s u m er ) ;p u b lic v o id ad d M es s ag eC o n s u m er s ( S tr in g m es s ag eN am e, Ar r ay L is t c o n s u m er s ) ;p u b lic v o id r em o v eM es s ag eC o n s u m er ( S tr in g m es s ag eN am e,

M es s ag eC o n s u m er c o n s u m er ) ;p u b lic Ar r ay L is t g e tAllM es s ag eC o n s u m er s ( ) ;p u b lic v o id r em o v eAllM es s ag eC o n s u m er s ( ) ;p u b lic Ar r ay L is t g e tM es s ag eC o n s u m er By M es s ag eT y p e ( S tr in g m es s ag eN am e) ;p u b lic Ar r ay L is t g e tAllM es s ag eT y p es ( ) ;

p u b lic v o id d is p a tc h M es s ag e( M es s ag e m es s ag e , M es s ag eC o n s u m er c o n s u m er ) ;

< < AS F C o m p o n en t> >

S en s o r< < AS F C o m p o n en t> >

M o n ito r

< < Ad ap tiv e C o m p o n en t> >Ban d w id th S en s o r

< < Ad ap tiv e C o m p o n en t> >I m ag eP r o c es s in g M o in to r

p u b lic F u tu r e s u b m it( R u n n ab le ta s k ) ;p u b lic F u tu r e s u b m it( C a llab le tas k ) ;p u b lic v o id ex ec u te( R u n n ab le tas k ) ;

< < AS F I n te r f ac e> >C o n c u r r en c y

< < AS F S er v ic e> >

T h r ead Q u eu ed E x ec u to r

p u b lic v o id b in d T o E x ec u to r ( E x ec u to r e ) ;p u b lic v o id u n b in d T o E x ec u to r ( E x ec u to r e ) ;

< < AS F I n te r f ac e> >E x ec u to r C lien t

p u b lic v o id h an d leN o tif ic a tio n ( N o tif ic a tio n n o tif ic a tio n ) ;

< < AS F I n te r f ac e> >Bo o tS tr ap< < AS F C o m p o n en t> >

E n g in e< < AS F C o m p o n en t> >

I m ag eP r o c es s in g E n g in e

d is p a tc h tas k to

init

iali

ze a

nd

en

able

in

stan

ce

d is p a tc h tas k to

init

iali

ze a

nd

en

able

in

stan

ce

< < AS F C o m p o n en t> >C o n f ig u r a tio n E f f ec to r

p u b lic v o id ad d P o lic y T o S c o p e ( P o lic y p ) ;p u b lic D ec is io n r eq u es tG u id an c e ( P o lic y p ) ;p u b lic P o lic y r es o lv eC o n f lic t io n ( P o lic y p ,

Ar r ay L is t en ab led P o lic y L is t ) ;

p r iv a te S tr in g p o lic y N am e;p r iv a te S tr in g p o lic y S c o p e ;p r iv a te S tr in g p o lic y D es c r ip tio n ;p r iv a te b o o lean p o lic y E n ab led ;p r iv a te Ar r ay L is t C o n d itio n s ;p r iv a te C o n d it io n p o lic y C o n d it io n ;p r iv a te D ec is io n p o lic y D ec is io n ;p r iv a te in t p o lic y P r io r ity ;

p u b lic Ar r ay L is t g e tE n ab led P o lic ies ( ) ;p u b lic Ar r ay L is t g e tD is ab led P o lic ies ( ) ;p u b lic Ar r ay L is t g e tAllP o lic ies ( ) ;p u b lic v o id a ttac h P o lic y ( P o lic y p ) ;p u b lic v o id d e ttac h P o lic y ( P o lic y p ) ;

< < AS F I n te r f ac e> >P o lic y Ac tu a to r

init

iali

ze a

nd

enab

le i

nst

an

ce

< < AS F S er v ic e> >P o lic y M an ag er

in it ia lize an den ab le in s tan c e

r eq u es t g u id an c e f r o m

< < AS F C o m p o n en t> >P o lic y

< < AS F C o m p o n en t> >

P o lic y Utility

< < Ad ap tiv e C o m p o en n t>M es s ag in g T as k < < AS F C o m p o n en t> >

T as k s

Page 19: Making Sense of Software Architecture

19

Techniques

Page 20: Making Sense of Software Architecture

20

Two Ways of Adaptation

Policy-based configurationTuning configurable parametersThreshold value setupIf-then-action rules

Zero-configuration No threshold values Balance at equilibrium

Targ

et

metr

ic

Threshold value

Uti

lity

fun

ctio

n

Parameter

Page 21: Making Sense of Software Architecture

21

Performance Modeling

1

2

m

CompressionEngine

Application Server

λcomp

1

2

n

λ

Page 22: Making Sense of Software Architecture

22

Performance Modeling Application specific vs. common

metricstionwithAdaptaptationwithoutAda

TTT

Adaptive compression of

message payload

Adaptive rendering of images on Internet

Page 23: Making Sense of Software Architecture

23

Construction of Adaptation

Performance

Target performance

metrics

Resourceconstraints

Server configurationparameters

Application specificcontrol parameters

Control logic

System model Control model

Adaptation

Image scaling time

Network delay

CPU usage Thread pool size Image sizeResolution

Quality

ThroughputResponse

Time

QueuingNetworkModel

Scaling images based on network speed and image scaling time

UtilityFunction

Page 24: Making Sense of Software Architecture

24

Construction of Adaptation

BandwidthSensor

ImageScaleMonitor

ImageScaleAnalyzer

RepositoryApplicationComponent

ImageScaleEffecotr

Invocation flow message flow

ImageScaleEngine

BandwidthSensor

CPUSensorConfiguration

Mointor

ApplicationComponent

ImageScaleEffecotr

Invocation flow message flow

ConfigurationEffector

PolicyManager

QueuedExecutor

CompressionEngine

Derived control loop for controlling CPU usage

embedded queueing network

modelAnalysis results

Image scaling action: image compression

ratio and quality

Utility function

Thread pool management component Derived control loop for scaling images

Reconfigure the thread pool size

Page 25: Making Sense of Software Architecture

25

Prototype on JBoss App Server

Page 26: Making Sense of Software Architecture

26

Prototype on JBoss App Server

Page 27: Making Sense of Software Architecture

27

Add-on Event Correlation Service

Page 28: Making Sense of Software Architecture

28

Add-on Event Correlation Service

Page 29: Making Sense of Software Architecture

29

Prototype on .Net WCF

Web Services

Management Layer

Adaptive Components

Page 30: Making Sense of Software Architecture

30

Reach to High Level Business Goals

??

Page 31: Making Sense of Software Architecture

31

A Process-Oriented Solution

Model

Control Layer

Component Layer

Middleware

Action/Handler

jBPM

Suitable for stage-based service integration Control and Coordination

ModelingModel HandlersControl ComponentsCoordination

Integration with middlewareBusiness Process EngineEnterprise Service Bus

(ESB)

OptimizationReduce the size of payload

using distributed cache

Page 32: Making Sense of Software Architecture

32

Control ModelingModel

Page 33: Making Sense of Software Architecture

33

Actions and Handlers

public abstract class AnalysisHandler implements ActionHandler {

public void execute(ExecutionContext executionContext) throws Exception { // the actual code to handle the state or transition return; }}

Handler Handler

Model

Handler

Page 34: Making Sense of Software Architecture

34

Actions and Handlers

Handler Handler

Handler

Model

Page 35: Making Sense of Software Architecture

35

Component and Model Execution

Handler Handler

Model

Handler

ComponentComponent

Descriptor

ESBInterfaceMiddleware

ControlCtrlFactory

CtrlDeployer

CtrlConfig

executionContext.leaveNode("switch")

Page 36: Making Sense of Software Architecture

36

Coordination Controls

Handler Handler

Model

Handler

ControlCtrlFactory

CtrlDeployer

CtrlConfig

ComponentComponent

Manager

Descriptor

ESBInterface MulticastInterface Workload

SensorThrottling

ComponentBusinessSystem

ThroughputSensor

Sensor Aggregator

Middleware

Coordination

Page 37: Making Sense of Software Architecture

37

Coordination Controls

Handler Handler

Model

Handler

ControlCtrlFactory

CtrlDeployer

CtrlConfig

ComponentComponent

Manager

Descriptor

ESBInterface MulticastInterface Workload

SensorThrottling

ComponentBusinessSystem

ThroughputSensor

Sensor Aggregator

Control Model

(Process Engine)

EffectingMulticast

Middleware

Coordination

Page 38: Making Sense of Software Architecture

38

Coordination Controls

Handler Handler

Model

Handler

ControlCtrlFactory

CtrlDeployer

CtrlConfig

ComponentComponent

Manager

Descriptor

ESBInterface MulticastInterface

Middleware

Page 39: Making Sense of Software Architecture

39

Loan Brokering on ESB

Page 40: Making Sense of Software Architecture

40

Adaptive Services on ESB

Page 41: Making Sense of Software Architecture

41

Architecture Evaluation Method

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8Maintainability

ProgrammabilityRiskSelf-managing

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8Maintainability

ProgrammabilityRiskSelf-managing

Maintainability

Page 42: Making Sense of Software Architecture

42

Adaptation with Zero Configuration

Traditional systems have absolute control over components

Distributed systems may not: dishonest usersKaZaa free ridingGrid computingKeyword advertising

The economic solution: Auctions

Page 43: Making Sense of Software Architecture

43

Evaluation – Sponsored Search

Dual Problems:Maximise search engine (provider) profitMaximise advertiser profit

Simulation allows quick validation of methods

Page 44: Making Sense of Software Architecture

44

Research Outcomes1 best award summer scholarship project 1 nomination of NICTA research award

1 software prototype ready for trial (NICTA Evaluation License)

1 patent application filed

9 publications Journal papers: Software Practice and Experience, Journal of Software and Systems; Conference/workshop papers: ICWS, ICSOC, COMPSAC, QoSA, ICSE workshop - SDSOA, ICSE workshop SEAMS, Invited paper to LNCS

Page 45: Making Sense of Software Architecture

45

Position AlignmentLinkage to MeDICi projects

Service selectionsMonitoring SLAsDefining the selection policy

Integration with MeDICiCompliant to Mule ESBTransferring process-based model to MeDICi job scheduling

Dealing with massive dataPicture from http://medici.pnl.gov/index.html

Page 46: Making Sense of Software Architecture

46

Position ExpectationHave direct contribution to the through

the position role

Synergize my capability with the rest of the team

Continue to consolidate my research strength

Expect fun and challenges

Page 47: Making Sense of Software Architecture

47

Position Expectation

Research leadershipSteer research directionSecure research fundsManage R&D activities

Research expertiseResearch publicationsProfessional services

Professional skillsSoftware design and development

Opportunity for funding application and industry collaboration

Continue research connections and collaboration

Page 48: Making Sense of Software Architecture

48

Thank You!

Page 49: Making Sense of Software Architecture

49

Backup Slides

Research Outcomes and Impact

Page 50: Making Sense of Software Architecture

50

Software architecture evaluation

stochasticprocess

statistics

Modelsqueuingtheory

middleware

softarch.

webtech.

Middleware Architecture Evaluation MethodS

How to evaluate the COTS software framework acquired?

How to evaluate the COTS software framework acquired?

Defence applications

Page 51: Making Sense of Software Architecture

51

Application in mission critical systems

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9Perforamnce

Scalability

LivenessConfigurability

Modifiability

System Under Test

Page 52: Making Sense of Software Architecture

52

Research outcomes Two projects funded by Defence Science

and Technology Organization (DSTO), Department of Defence, Australia, in 2007 and 2008.

Research reports published by DSTO Full papers published at QoSA conference Research collaboration with Dr. Len Bass,

SEI/CMU A TSE submission in writing A new project with DSTO is under

discussion

Page 53: Making Sense of Software Architecture

53

Performance assessment of SOAs

stochasticprocess

statistics

Modelsqueuingtheory

middleware

softarch.

webtech.

Integrated SOAs

Internet

Net medical expenses over

$1500?

Retrieve Medicare Financial Tax

Statement

Proceed to the next section

Medicare Financial Tax

Statement Tax Office Medical Tax Statement Retrieval Web Service

Yes

No

egovernment Performance Assessment for Service Architecture (ePASA)

Can the system scale up to handle peak load at the deadline?

Can the system scale up to handle peak load at the deadline?

Page 54: Making Sense of Software Architecture

54

Application in SOAsRequest Distribution in Hour (01/07/2006-19/07/2006)

020406080

100120140160180200220240260280300320340360380

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Day

Req

ues

ts

01234567891011121314151617181920212223

S e s s io n s f ro mA TO e -Ta x

de dica te dn e two rk

A pplica t io n S e rv e r C lu s te r

D B s e rv e rs

m

Pro x y

M a in fra m e tra n s a ct io npro ce s s in g

m

Scenarios (i.e. 5 classes of workload)

Scenarios (i.e. 5 classes of workload)

Component(QNM equivalent

server)

Component(QNM equivalent

server)

Container(software hosting the

computing)

Container(software hosting the

computing) Host(physical deployment)

Host(physical deployment) Service demand

(e.g. CPU, Disk, network demand)

Service demand(e.g. CPU, Disk, network

demand)

Workload mixWorkload mix

Page 55: Making Sense of Software Architecture

55

Research outcomes Corner stone project for a new research

group setup at NICTA Canberra Lab Public breakfast seminar with 30+

attendees from IT companies and government agencies

Media coverage Nominated for NICTA research impact

awards Full paper at published at CBSE, Boston,

2007

Page 56: Making Sense of Software Architecture

56

Adaptive middleware

Respond Sense

AnalysePlan

stochasticprocess

statistics

Modelsqueuingtheory

middleware

softarch.

webtech.

Adaptive Middleware Platform

(AMP)

Can models drive the adaptation? And how?

Can models drive the adaptation? And how?

Page 57: Making Sense of Software Architecture

57

PhD Thesis : Performance Prediction Method

client broker account stockitem stockholding stocktx Transaction Manager

BuyStock (visits=7%)

check account credit (ratio=1) get stock price (ratio=1)

update (ratio=1)

start transaction

transaction rollback if there is not enough credit (ratio=1)

commit transaction

insert transaction record (ratio=1)

client broker account stockitem stockholding stocktx Transaction Manager

BuyStock (visits=7%)

check account credit (ratio=1) get stock price (ratio=1)

update (ratio=1)

start transaction

transaction rollback if there is not enough credit (ratio=1)

commit transaction

insert transaction record (ratio=1)

R/W

FindByPK

CS

LC A/P

Y [hr] N [1-hr]

R [p] W [1-p]

Cached

LC A/P

Y [h] N [1-h]

Cached

LD

R or W

SD

W [1-p]R [p]

R/W

FindByPK

CS

LC A/P

Y [hr] N [1-hr]

R [p] W [1-p]

Cached

LC A/P

Y [h] N [1-h]

Cached

LD

R or W

SD

W [1-p]R [p]

0200400600800

100012001400

50 100 200 300 400 500Res

po

nse

tim

e (R

) in

m

s, r

ead

-on

ly in

ten

sive

CMP Predicted

CMP Measured

RM Predicted

RM Measured

OCC Predicted

OCC Measured0

200400600800

100012001400

50 100 200 300 400 500Res

po

nse

tim

e (R

) in

m

s, r

ead

-on

ly in

ten

sive

CMP Predicted

CMP Measured

RM Predicted

RM Measured

OCC Predicted

OCC Measured

... ...

...

C lien ts

R eq u es t q u eu e C o n ta in er q u eu e J M S S er v er

m 1 m '

M D B q u eu e

m 2

D ataS o u r c e q u eu e

C losed Q u eu e O pen Q u eu e

... ...

...

C lien ts

R eq u es t q u eu e C o n ta in er q u eu e J M S S er v er

m 1 m '

M D B q u eu e

m 2

D ataS o u r c e q u eu e

C losed Q u eu e O pen Q u eu e

Performance Prediction

Client SessionBean EntityHome EntityBean

setValuefindByPrimaryKey

getValue

setValue

getValueSet findByNonPrimaryKey

getAllValues

* [ f o r e a c h e n t i t y ]

Architecture model(calibrating)

Application design model

Performance model(populating)

Performance profile(benchmarking)

Performance model

Page 58: Making Sense of Software Architecture

58

stochasticprocess

statistics

Microkernel-based embedded systems

Modelsqueuingtheory

middleware

softarch.

webtech.

http://www.ok-labs.com/

Can low level OS libraries be modules and components?

Can low level OS libraries be modules and components?

Page 59: Making Sense of Software Architecture

59

Application in embedded OS

1

3

2

4

5

6

Page 60: Making Sense of Software Architecture

60

Application in embedded OS

Verifying CAmkES components and connectors

Client Server

uses providesIguanaRPC

“add” “add”CAmkES

PnP

send interface

receive interface send interface

receive interface

ports

Page 61: Making Sense of Software Architecture

61

Research outcomes A software for open source (getting

internal paper work) Published conference and journal

papers (CBSE, QoSA, ASWEC, and JSS) Research collaboration with Prof. Lori

Clarke at University of Massachusetts Amherst

Page 62: Making Sense of Software Architecture

62

Research Vision

Page 63: Making Sense of Software Architecture

63

stochasticprocess

statistics

Modelsqueuingtheory

middleware

softarch.

webtech.

MarketModels

Resource allocation, valuation in Ultra Large Scale Systems (ULSS)

Page 64: Making Sense of Software Architecture

64

Applying market-based approach to ULSS

Page 65: Making Sense of Software Architecture

65

Student supervision Spin-off student projects from research

activities

Introduce ‘taste-of-research’ project to 4th year undergraduate students

Students always give you a surprise if you really work with them as a team

Totally 39 students (2004 – now)

Page 66: Making Sense of Software Architecture

66

Example student projects

Page 67: Making Sense of Software Architecture

67

Other Stuff

Page 68: Making Sense of Software Architecture

68

Adaptive Server Framework Architecture

ASF Supported Adaptive Application Servers

Middleware (.Net Framework/JAVA EE/ Enterprise Service Bus)Middleware (.Net Framework/JAVA EE/ Enterprise Service Bus)

Standard-based Management LayerStandard-based Management LayerStandard-based Management LayerStandard-based Management Layer

Operating SystemOperating System

EngineEngine

ExecutorExecutorEffectorEffector

SensorSensor

EffectorEffector

SensorSensor

MonitorMonitor

AnalyzerAnalyzer Repository

Repository

PolicyManagerPolicy

Manager

Event Correlation

Security Manager

Web Services Wrapper

ASF service ASF service layerlayer

Page 69: Making Sense of Software Architecture

69

Adaptive Services on ESB What to be

composed is driven by application specific scenarios

Architecture-based approach helps with how to compose them

Rest of System

1

Token Bucket1

Smart proxy

m

n

Deployment boudnary

Bank 1

Bank 2

Bank 3

Bank 4

J2EE Server

Web Service Container

Enterprise Service Bus

SmartProxy

MonitorTester

Planer

Manager

Esper

Complex event processing

Quartz

Job scheduling

Auction Algorithm

OS Monitors

jBPM

Business process engine

General SOA ArchitecturesWith Services Connected Through

Endpoints

Page 70: Making Sense of Software Architecture

70

Evaluation – Failover without Coordination

Page 71: Making Sense of Software Architecture

71

Evaluation – Failover with Coordination