Software-Defined Service Networking (SDSN) :

Indika Kumara

Jun Han

Alan Colman

Malinda Kapuruge

Future of Software Services and Applications over the Cloud and the Internet

2

Things Data People Cloud Classical ServicesService Ecosystem

App1 App2 App3

Tenants and End-users

??? SDSN

Outline• What is a PhD?• SaaS (Software-as-a-Service) and multi-tenancy• Three key issues in composite SaaS applications

– Runtime sharing with tenant-specific variations– Runtime evolution– Tenant-oriented configuration and reconfiguration

• Our approach: Software-Defined Service Networking (SDSN)

• Some future directions for multi-tenant cloud applications

3

4

What is a PhD?

What is a PhD?

5

PhD

Elementary

O/L

A/L

MSc

BSc

PhD

Human Knowledge

What is a PhD?

6

Knowledge TreeContributions

What is a PhD? …

7

“Broad and Shallow”

Vs. “Narrow and

Deep”

Why do a PhD?• Develop the skills required to conduct

(academic) research at a professional level (accepted by the peers)– Academic Career

– Industry Career• Startups, high-tech companies, top consulting firms, …

8

Why do a PhD/Research? …• Pleasure of finding things out

– Richard Feynman - The Pleasure of Finding Things Out (watch Video)

9

"Nobody ever figures out what life is all about, and it doesn't matter. Explore the world. Nearly everything is really interesting if you

go into it deeply enough." ― Richard Feynman

"You ask me if an ordinary person could ever get to be able to imagine these things like I imagine them. Of course! I was an ordinary person who studied hard. There are no miracle

people. It just happens they get interested in this thing and learn all this stuff, but they're just people." ― Richard Feynman

10

SaaS and Multi-

tenancy

Cloud Services

11

Infrastructure as a Service (IaaS)

Platform as a Service (PaaS)

Software as a Service (SaaS)

End-users

WebFocus

Multi-Tenancy• An architectural principle, whereby multiple application

variants can be derived from the same application to support the requirements of individual tenants

12

UoMWWW

UoMWWW

UoPWWW

UoPWWW SaaS

WWWConventional Multi-tenant

Variants

SaaS Maturity Model

13

MT-Efficient Configurable Scalable(workload)

1 1 12 2 23 33 444

Multi-tenancy Models• Multi-instance multi-tenancy (MIMT)

– SaaS maturity levels 1 and 2• Single-instance multi-tenancy (SIMT)

– SaaS maturity levels 3 and 4

14

MIMT SIMTOperational costScalability

Engineering CostTenant-specific Variations and Changes

Economies of Scales

Multi-Tenancy in Composite SaaS Applications

15

Services

Tenants

CompositeApp.

16

My PhD WorkHow to achieve the best of both

SIMT and MIMT models for composite SaaS applications?

Three key Issues in Multi-tenant SaaS Applications

1. Runtime sharing with tenant-specific variations– Share services and their aggregation

2. Runtime evolution3. Tenant-oriented configuration and

reconfiguration

17

Consider both functional and performance requirements

Issue 1

18

How to share services among multiple tenants/applications with

different functional and performance requirements?

Illustration : Roadside Assistance Composite Cloud Application

19

Heterogeneous Services

– Diverse capabilities– Diverse performance properties (response time and

throughput) of those capabilities– Diverse relationships between services

• Interaction relationships • Normative relationships

20

MacRepair

• Repairing (2d, 100/d)• Internal spare parts

• Repairing (3d,200/d)

AutoRepair

Heterogeneous Collaborations

• Configuration differences => performance differences

• Regulation differences => performance differences 21

AutoRepairJackParts

TomTow

24by724by7

MacRepair

SwiftTow

Repairing Using External PartsRepairing Using Internal Parts

6 days due to

External Parts

3 days

Sharing and Different Use of Services

22

HappyTours

EuroCars

Software-Defined Service Networking (SDSN)

23

Controller

Services

Virtual Service Networks

Service Network

Concepts and Design Support• A service network design has a configuration

design and a regulation design.• Configuration design

– Describe the topology of a service network (i.e., network nodes and connections) as a set of roles connected by contracts between them.

24

Concepts and Design Support …• Regulation design

– Describe the regulation of the conversational behaviors in the service network by routing the interaction messages between services, and by conditioning or restricting such interaction flows.

– A set of regulation enforcement points applying regulation policies, which share a common set of regulation mechanisms.

25

Illustration : Regulation Types

• Four logical points of interaction regulation– Synchronization, Routing, Pass-through, and

Coordinated Pass-through26

Assessing Repair

AutoRepair

JackParts

CheapParts

EuroParts

24by7

TomTow

Example Regulation Mechanisms• Routing

– Classify, AdmissionControl, Loadbalance, Synthesise, Forward, Schedule /Queue, Drop, …

• Synchronization– Pull, Synthesise, ExecuteTask, …

• Pass-through– Push, MonitorResponseTime, MonitorThroughput,

PublishEvent, SendToManager, Block, …– Deontic concepts (permission, obligation, privilege,…)

• Coordinated Pass-through– Create/Activate/Passivate/Terminate VSN instances

27

Concepts and Design Support …• Collaborations as building blocks of processes

– Services in collaborate support requirements or features, making the collaboration suitable abstraction for reuse and composition.

– Decompose configuration and regulation designs into modular units.

28

AutoRepairJackParts

TomTow

24by724by7

MacRepair

SwiftTow

Concepts and Design Support …• Processes in virtual service networks as

composition of collaboration units

– Wiring collaboration units => inter-collaboration regulation units

– Regulations across processes => inter-process regulation units

29

Towing Repairing

TriggerTowing

and Repairing

Illustration : Multi-tenant SN Design

30

Service Network

Collaboration Units

Virtual Service Networks

Role

Contract

Sharing

Different Use

HappyToursEuroCars

Meta-model: Configuration Design

Process

ServiceNetwork

CollaborationUnit

VirtualServiceNetwork

Event

InteractionTerm Role

Contract

Service

Task

Represents

Pre/post conditionsGenerates Refers to

Refers to Connects

31

Meta-model :Regulation Design

32

RoutingREP

RegulationRule

Role RegulationEnforcementPoint

SynchronizationREP InteractionMessage

RegulationMechanism

PassthroughREPContract

Coordinated-PassthroughREP

REP - Regulation Enforcement Point

CollaborationUnit

ProcessVirtualServiceNetwork

Refers toRegulates

Programing Support• A DSL and an XML based executable language

33

Role TC1 { Task tDeliver { Inputs GC1_TC1.iSendLocation.Req, GC2_TC1.iSendLocation.Req; Outputs SC_TC1.iPayTow.Req, GC1_TC1.iNotifyDelivery.Req, GC2_TC1.iNotifyDelivery.Req; QoS responseTime "2h" throughput "162/d"; } Task tPickUp {...} ServiceBinding "http://swifttow.com/services/towservice";}...Role GC1 { Task tDoRepair { Inputs GC1_TC1.iNotifyDelivery.Req; Outputs SC_GC1.iPayRepair.Req; QoS responseTime "2d" throughput "200/d"; } Task tOrderRepair {... } ServiceBinding "http://macrepair.com/services/repairservice";}

1234567891011121314151617181920

Roles and their tasks

Programing Support ….

34

Contract GC1_TC1 { A is GC1, B is TC1; // References to the roles GC1 and TC1 ITerm iSendLocation(String:location) from AtoB; ITerm iNotifyDelivery(String:ack) from BtoA;}Contract SC_TC1 { A is SC, B is TC1; // References to the roles TC1 and SC ITerm iPayTow(String:bill) withResponse (String:ack) from BtoA;}

123456789

Contracts and their interaction terms

rule "rAdmissionCheckV1" when $msg : RoleServiceInteraction(opName== "assist", state=="Admittable") then AdmissionControl("assist","123,1d",$msg);endrule "rProcessSelectionV1" when $msg : RoleServiceInteraction(opName== "assist", state=="Routable") then LoadBalance("assist","AnyTrucksP1:2,AnyTrucksP2:1",$msg);end

1234567891011121314

Regulation rules

35

CollaborationUnit TowingBySwiftTow { ConfigurationDesign { TaskRef TC1.tPickUp { InitOn "ePickUpReqd"; Triggers "ePickedUp"; } TaskRef TC1.tDeliver { InitOn " ePickedUp * ( eSentGC1LocToTC1 | eSentGC2LocToTC1 ) "; Triggers "ePayTowReqdByTC1 * ( eDeliveredVehicleToGC1ByTC1 | eDeliveredVehicleToGC2ByTC1 )"; } TaskRef SC.tPayTC { InitOn "ePayTowReqdByTC1"; Triggers "eTC1Paid"; } } RegulationDesign { Routing { RuleRef SC.rPayTCResponseV1; RuleRef TC1.rPickUpResponse; RuleRef TC1.rDeliverResponseV3; RuleRef MO.rRequestAssistV2; } Synchronization { RuleRef TC1.rPickUp; RuleRef SC.rPayTC1; } Passthrough { RuleRef MO_TC1.rPickUp; RuleRef SC_TC1.rNotifyPickUp; RuleRef SC_TC1.rPayTow; RuleRef SC_TC1.rPayTowResponse; } }}

12345678910121314151617181920212223242526272829303132333435363738

Collaboration Units

Configuration Design

RegulationDesign

VirtualServiceNetwork AnyTrucks { Process AnyTrucksP1 { CollaborationUnitRef CaseHandling; CollaborationUnitRef RepairingByAutoRepair; CollaborationUnitRef TowingBySwiftTow; CollaborationUnitRef RentingRoom; InterCollaborationRegulationUnitRef AutoRepairAndSwiftTow; QoS responseTime "6d" throughput "82/d"; } Process AnyTrucksP2 { CollaborationUnitRef CaseHandling; CollaborationUnitRef RepairingByAutoRepair; CollaborationUnitRef TowingByTomTow; CollaborationUnitRef RentingRoom; InterCollaborationRegulationUnitRef AutoRepairAndTomTow; QoS responseTime "6d" throughput "41/d"; } InterProcessRegulationUnitRef AdmissionAndProcessSelection;}

12345678910121314151617181920

36

Virtual Service Networks (VSNs)

Process 1

Process 2

SDSN Middleware

• Design Goals– Minimize the semantic gaps between the design-

time models and the runtime models of a multi-tenant service network

– Support the simultaneous enactment of multiple virtual service networks on the same service network

– Enable policy-based runtime management of a multi-tenant service network

37

38

Architecture of SDSN Middleware

Enactment Engine

Adaptation Engine Configuration Design Models

Regulation Design Models

Model Manager

Organizer Policy Manager

Operational Manager

Services

Serv

ice

Coor

dina

tion

Infra

stru

ctur

e

Man

agem

ent

Plat

form

Illustration: Runtime Model of an SN

39

General Design of a REP

40

Regulation Table

Key Rule Identifiers

ECA Rules

State Manager Event Manager

Trig

ger

Prod

uce

/U

pdat

e

Regulation Knowledgebase

Mes

sage

s

Trigger

e1 en Events

Admission Control SynthesizeQueue PublishEvent

Regulation Mechanisms

Model Manager

S1 Sm StatesMapping Function

41

Process Enactment

Termination of Process Instance

Progress of Instance of Local Collaboration 1

Progress of Instance of Local Collaboration n

Progress of Instance of Local Collaboration 2

Progress of Process Instance

Routing

Pass-through

Synchronization

Providing Service Capability

Process Selection

Process Instantiation

VSN Level

Process Level

Local Collaborations Level

Admittance of Instantiation Requests

Activation of Process Instance

VSN Enactment

Issue 2

42

How to make runtime changes to multi-tenant composite cloud

applications?

Business Example with Changes

43

Changes

Let us analyse the example

Runtime Evolution Scenarios• Different stakeholders request changes to the

SaaS application during runtime:– External service providers

• Service-level, e.g., replacing TomRepair garage with MelRepair for better performance

– SaaS provider• Feature-level, e.g., a new feature Legal Assistance• Architecture-level, e.g., extending a repairing

collaboration by incorporating an optional external vehicle assessor

– Tenants• Feature-level, e.g., a new feature TaxiHire

44

Requirements for Evolution Support• Support different classes of changes that can

potentially occur during the lifetime of the multi-tenant composite cloud application

• Identification of the potential impacts of a change on the application and its individual tenants

• Runtime realization and management of each change and its impacts without disturbing unaffected tenants

45

Our Evolution Support

46

• We have developed the support for change and impact management of multi-tenant service networks– Types of configuration and regulation design changes,

and types of their potential impacts• Functionality and performance perspectives

– A policy language to support the definition of the runtime changes as management policies, and a policy engine to enact such policies.

• Configuration management• Regulation management • Evolution management

Change Impact Graph: Configuration

47

+ - * Role-Contract Structure

+ - * Role

+ - * Contract + - * Task+ - * Interaction Term

+ - * ServiceBinding

+ - * / Service

+ - * Service Interface

+ - * Service Capability

+ - * Service Operation

+ - * Collaboration Based Decomposition + - * Behaviour Unit + - * Event

+ - * Process

+ : Add - : Remove * : Modify / : Replace : Potential Direct Impact Relation

+ - * Virtual Service Network

+ - * Capability Performance

+ - * Service Relationship + - * Service Interaction

Change Impact Graph: Regulation

48

+ - * Role-Contract Structure

+ - * Role

+ - * Contract

+ - * Task

+ - * Interaction Term

+ - * Service Capability

+ - * Regulation Unit Based Decomposition + - * Regulation Unit

+ - * Event

+ - * Process

+ : Add - : Remove * : Modify / : Replace : Potential Direct Impact Relation

+ - * Virtual Service Network

+ - * Capability Performance

+ - * Service Interaction

+ - * State

+ - * Synchronization REP

+ - * Routing REP

+ - * Passthrough REP

+ - * Global REP + - * Regulation Rule

+ - * Regulation Mechanism

+ - * Service Regulation Decision

Example: Adding TaxiHire Feature

49

7. VSN and process changes

6. Inter-collaboration and Inter-process unit changes

5. Collaboration unit changes

4. Regulation rule changes

3. Task changes2. Interaction and

obligation changes1. Topology and player

changes

RentingVehicles

HiringTaxi

RentingRooms

Towing

RepairingExParts

RepairingInParts

HappyTours VSN EuroCars VSN

iOrderTaxi,…tOrderTaxi,…

Conf. Evol. Management Policy : Example

50

rule "conf_evol_mgt" when ($mgp:ManagementPolicyState(id =="conf_evol_mgt",state=="incipient")) then // role-level changes addRole("TX","14Cabs","http://14cabs.com/services/TaxiHireService"); addTask("TX","tOrderTaxi"); addTask("TX","tProvideTaxiInvoice"); ... // Role SC addTask("SC","tPayTX"); ... // contract-level changes addContract("SC-TX","SC","TX"); addTerm("SC-TX","iOrderTaxi","AtoB"); ... addTerm("SC-TX","iSendTaxiInvoice","BtoA"); ... $mgp.setState("done");end

1234567891011121314151617181920

51

Reg. Evol. Management Policy: Examplerule "reg_evol_mgt" when ($mgp1:ManagementPolicyState(id =="conf_evol_mgt",state=="done")) and ($mgp2:ManagementPolicyState(id =="reg_evol_mgt",state=="incipient")) then //synchronization rule changes addSynchronizationRule("TX","TX_SYN.drl"); //all rules at the syn. REP addSynchronizationRule("SC","payTX.drl"); //routing rule changes addRoutingRule("TX","TX_Routing.drl"); //all rules at the routing REP addRoutingRule("SC","payTXResponse.drl"); addRoutingRule("SC","analyzeResponseV6.drl"); //passthrough rule changes addPassthroughRule("SC-TX","SC-TX.drl");//all rules at the passth. REP addSynchronizationTableEntries("Tenant2","orderTaxi:TX,payTX:SC"); addRoutingTableEntries("Tenant2","analyzeResponseV6, payTXResponse:SC,provideTaxiInvoice,orderTaxiResponse:TX"); addPassthroughRulesToRegulationUnit("Tenant2","orderTaxi, orderTaxiResponse,sendTaxiInvoice,sendTaxiInvoiceResponse:SC-TX"); ... $mgp2.setState("done");end

12345678910111213141516171819202122

52

rule "conf_mgt" when ($mgp1:ManagementPolicyState(id =="conf_evol_mgt",state=="done")) and ($mgp2:ManagementPolicyState(id =="conf_mgt",state=="incipient")) then link("SC","TX"); link("SC.tAnalyse.outputs","SC-TX.iOrderTaxi.Req"); link("TX.tOrderTaxi.inputs","SC-TX.iOrderTaxi.Req"); link("TX.tOrderTaxi.outputs","SC-TX.iOrderTaxi.Res"); ... link("SC.tPayTX.inputs”,"SC-TX.iSendTaxiInvoice.Req"); link("SC.tPayTX.outputs”,"SC-TX.iSendTaxiInvoice.Res""); ...end

1234567891011121314

Conf. Management Policy: Example

53

rule "rAnalyseResponseV6" when $msg : RoleServiceInteraction(opName== "analyseResponse") then Forward("SC-TX.iOrderTaxi.Req",Synthesise("OrderTaxReq.xsl",$msg));end

123456

rule "rOrderTaxi" when $msg : RoleRoleInteraction(opName == "orderTaxi") then PublishEvent("eOrderTaxiReqd",$msg);end

rule "rOrderTaxi" when $e1 : Event(id == "eOrderTaxiReqd") then RoleRoleInteraction [] inMsgs = Pull("SC-TX.iOrderTaxi.Req"); RoleServiceInteraction exMsg = Synthesise(inMsgs,"OrderTaxi.xsl"); ExecuteTask(exMsg,"tOrderTaxi");end

123456

12345678

(a)

(b)

(c)

Regulation Management Policies: Example

Issue 3

54

How to allow tenants to directly configure and reconfigure their

application variants at runtime to meet their initial and changing business

requirements?

Configuration and Reconfiguration Scenarios

• Functional

55

HappyTours

Repairing

Rental Vehicle

Towing

Accommodation

Configuration Reconfiguration

HappyTours

Repairing

Rental Vehicle

Towing

Accommodation

Configuration and Reconfiguration Scenarios …

• Performance

56

HappyTours

Repairing

Rental Vehicle

Towing

Accommodation

Configuration

ExternalParts

3 days

5 days

HappyTours

Repairing

Rental Vehicle

Towing

Accommodation

ExternalParts

3 days

5 days

Reconfiguration 56

Requirements for Configuration and Reconfiguration Support

• A high-level configuration abstraction that allows the tenants to perform the configuration and reconfiguration activities.

• Support natural mappings between (functional and performance) requirement options and realization options.

57

Requirements for Configuration and Reconfiguration Support Contd…

• Support the natural dependencies between functional options, between performance options, between functional and performance options, and between realization options

• Automated generation and enactment of application variants for tenants, without halting the shared application

58

Runtime VSN Configuration and Reconfiguration

59

Feature Model

Mapping Models

VSN Design Model Template

Commonality and Variability in

Requirements as Functional ad Performance

Features

Commonality and Variability in Feature

Implementations

Create/Update a Feature

Configuration by a Tenant

Automatically Generate a VSN Design based a

Feature Configuration

Automated VSN Design Generation

Variability Modelling

• A feature-based model-driven approach

VSN Configuration: Example

60

RentingVehicles RentingRooms

Towing RepairingExParts

RepairingInParts

HappyTours VSN Feature Configuration

VSN Reconfiguration: Example

61

RentingVehicles RentingRooms

Towing RepairingExParts

RepairingInParts

HappyTours VSNUpdated Feature

Configuration

Prototype Implementation• Middleware and tools

62

Code Completion Assistance

Routing Regulation Mechanisms

Feature Model

Feature Configuration

Context Menu for Creating a VSN

WSDL URL for Created VSN

Organizer Role API Operations

Designer

Regulation Policy Designer

VSN Creation

Management Policy Designer

Evaluation : Case Studies• Goal: To show the feasibility of the SDSN

approach and to validate its capabilities• Fully-fledged roadside assistance case study

– Sharing with variations, evolution, tenant-oriented configuration and reconfiguration

• Expressiveness assessment – Types of sharing and variation – 26 cases– Types of changes and impacts – 44 cases

• Estimation of engineering effort and evolution effort via software metrics

63

Some Evaluation Results …• Utilization of services via sharing

64

GFS :10.13%GMS : 14.25%GOMS:17.8%

Increase in Utilization in Comparison with Non-sharing (MIMT)

MIMT : Multi-Instance Multi-Tenancy (Baseline)Sample Number

Thro

ughp

ut (R

eque

sts

per S

ampl

e) 3 Sharing SchemesGFS : Global Fixed SchemeGMS : Global Minimum Scheme GOMS : Global Minimum With Overbooking Scheme

Some Evaluation Results …• VSN(Virtual Service Network) enactment

overhead

65

Ena

ctm

ent O

verh

ead

(Mill

isec

onds

)

LoC (Lines of Codes)

Mean of 116.47 ms for 1288.4 LOC

Some Evaluation Results …• Relative performance overhead with BPEL in

Apache ODE

66

Res

pons

e T

ime

(Mill

isec

onds

)

Number of Concurrent Users

Some Evaluation Results …• Runtime change enactment time (RCET) for

11 types of functional change scenarios

67

Change Scenario (CS)

Mill

isec

onds

R

CET

(Run

time

Cha

nge

Enac

tmen

t Tim

e ) Add Rollback

533.45 ms 14 msMean

Some Evaluation Results …• Runtime change enactment time (RCET) for

11 types of performance change scenarios

68Change Scenario (CS)

Mill

isec

onds

R

CET

(Run

time

Cha

nge

Enac

tmen

t Tim

e )

Add Rollback395 ms 34.36 msMean

Relating to Existing Literature• Relating to existing service composition approaches

– Structure-centric (architectural) and organization-based– Natural representation of multi-tenant service networks,

and separation of structure, behaviour, and management in the system architecture

• Relating to variability realization approaches– Compositional approach at runtime– Collaborations as unit of compositions– Runtime sharing with variations

69

Relating to Existing Literature Contd... • Relating to SDN (software-defined networks)

– Similarities in Goals/Motivations (better support for management tasks) and System Architecture (computing entities/end-hosts, data plane, south bound interface, control plane, north bound interface, control applications)

– Differences in the Abstractions and Capabilities in each layer in the system architecture

• Relating to performance differentiation in multi-tenant cloud applications– Services as primary resources– A design approach 70

Publications …• Peer-reviewed Journal articles

– I. Kumara, J. Han, A. Colman, and M. Kapuruge, “Software-Defined Service Net-working: Performance Differentiation in Shared Multi-Tenant Cloud Applications,” IEEE Transactions on Services Computing, 2016.

– I. Kumara, J. Han, A. Colman, and M. Kapuruge, “SDSN@RT: A Middleware Environment for Hosting Shared Multi-tenant SaaS Applications,” Software: Practice and Experience, 2016 (in preparation – the final stage).

– Tenant-oriented configuration and reconfiguration => IEEE Transactions on Services Computing

– Runtime evolution => TBD– Policy-based management => TBD

71

Publications …• Invited book chapters

– I. Kumara, J. Han, A. Colman, and M. Kapuruge, “Virtualisation and Management of Application Service Networks,” Network as a Service for Next Generation Internet, IET (Institution of Engineering and Technology) , UK, 2016 (accepted).

72

Publications …• Peer-reviewed conference papers

– I. Kumara, J. Han, A. Colman, and M. Kapuruge, “Software-Defined Service Net-working: Runtime Sharing with Performance Differentiation in Multi-Tenant SaaS Applications,” in Proc. of 12th International Conference on Services Computing (SCC 2015), 2015, pp. 210- 217.

– I. Kumara, J. Han, A. Colman, and M. Kapuruge, “Runtime Evolution of Service-based Multi-tenant SaaS Applications,” in Proc. of 11th International Conference on Service Oriented Computing (ICSOC 2013), 2013, pp. 192-206.

– I. Kumara, J. Han, A. Colman, T. Nguyen, and M. Kapuruge, “Sharing with a Difference: Realizing Service-based SaaS Applications with Runtime Sharing and Variation in Dynamic Software Product Lines,” in Proc. of 10th International Conference on Services Computing (SCC 2013), 2013, pp. 567- 574.

73

Publications …• Peer-reviewed conference papers - collaborations

– T. Patikirikorala, I. Kumara, A. Colman, J. Han, L. Wang, W. Ranasinghe, and D. Weerasiri, “Dynamic Performance Management in Multi-tenanted Business Process Servers using Nonlinear Control,” in Proc. of 10th international conference on Service-Oriented Computing (ICSOC 2012), 2012, pp. 206-221.

– M. Kapuruge, J. Han, A. Colman, and I. Kumara, ”Enabling Ad Hoc Business Process Adaptations through Event-driven Task Decoupling,” in Proc. of 25th International Conference on Advanced Information Systems Engineering (CAiSE 2013), 2013, pp. 384-399.

– M. Kapuruge, J. Han, A. Colman, and I. Kumara,”ROAD4SaaS: Scalable business service-based SaaS applications,” in Proc. of 25th International Conference on Advanced Information Systems Engineering (CAiSE 2013), 2013, pp. 338-352.

74

Publications …• Peer-reviewed journals papers - collaborations

– M. Pathirage, S. Perera, I. Kumara, D. Weerasiri, and S. Weerawarana, "A Scalable Multi-Tenant Architecture for Business Process Executions," International Journal of Web Services Research, vol. 9, pp. 21-41, 2012.

75

Conclusion• SDSN (software-defined service networking), is a

service composition model that represents multi-tenant composite applications as multi-tenant service networks whose structure, behaviour, and control are separated– Share services and their coordination while

differentiating tenants' functional and performance requirements

• Support the changes to enacted multi-tenant service networks at runtime

• Tenant can configure/reconfigure their virtual service networks via high-level abstractions 76

77

Some Potential Future Directions for Cloud Applications

Research Gaps/Contributions

78

Desired Situation/System

Current Situation/System Research

GapsHow to identify the research gaps?

• Daydreaming (Imagination)• Critically reading for issues and ideas (broad / narrow)• Experimentation – trial and error• …

“Study hard what interests you the most in the most undisciplined, irreverent and original manner possible” --

Richard Feynman

E.g., Website for Each Univ E.g., Multi-tenant Website

Potential Research Directions for Cloud Applications

• Divide into– Model-driven engineering– Software optimization– Software evolution– Compliance management

79

Model-Driven Engineering• Model-driven development and management

of multi-tenant cloud applications

80

Model transformation

High-level models Executable software artifacts

UML (scenarios), feature model Design artifacts and management policies• Runtime sharing and variability (multi-tenancy)• Consistency and correctness (formal support)• Context, QoS (Quality of Services), and management decisions• Pattern-orientation • ..

Model-Driven Engineering …• Interactive change and impact management for

multi-tenant cloud applications

81

Interactive ToolSoftware Engineer Cloud Application

• High-level abstractions (multi-tenant)• Tracing, analysis, and visualizations of change impacts • Recommendations on ranked alternative changes, future changes and

risks, etc., (recommender systems and applied machine learning) • Alternatives and trade-offs (requirement, design, and realization)• Pattern-orientation • …

Software Optimization• Optimal (re)design of multi-tenant cloud

applications

• Optimal enactment of an instance of a multi-tenant cloud application for a particular user of a tenant– Strategies for application variant enactment in a

dynamic environment to achieve optimal user experience and service/resource utilization under changing conditions

82

Tenants with different fun./QoS requirements

Services and cloud resources

Constraints and Knowledge Optimal Design

Software Optimization …• Optimal (re)deployment of a multi-tenant cloud

application in a data center– Data center resources vs. third party services– Design and management complexity vs. resource

efficiency– Dynamic redesign for resource and management

efficiency– …

• Optimal change to a multi-tenant cloud application or its instances

83

Software Evolution• Multi-layer evolution of a cloud application

– Coordinated evolution of the layers of multi-tenant cloud applications

• Services layer• Application layer• Management (policy) layer• High-level configuration layer

• Pattern-oriented evolution of multi-tenant cloud applications

• Incremental, localized analysis of change impacts in multi-tenant cloud applications

84

Compliance management • Compliance management in multi-tenant cloud

applications– Conflicts, commonality, and variability in

compliance requirements of different tenants– Sharing and variations in policies – Policy specification (tenant-oriented) and

enforcement– Pattern-oriented, model-driven techniques – Change and impact management– …

85

Q/A

86

Thank You!

References• http://matt.might.net/articles/phd-school-in-pictures/• https://msdn.microsoft.com/en-us/library/aa479069.aspx• http://phdcomics.com/comics.php• https://openclipart.org/

87