Software Defined Service Networking (SDSN) - by Dr. Indika Kumara

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
Services
Service 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

What is a PhD?
5
PhD
O/L
A/L
MSc
BSc
PhD
Human Knowledge

What is a PhD?
6
Knowledge Tree
Contributions

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

Cloud Services
11
Infrastructure as a Service (IaaS)
Platform as a Service (PaaS)
Software as a Service (SaaS)
End-users
Web
Focus

Multi-Tenancy
• An architectural principle, whereby multiple application
variants can be derived from the same application to
support the requirements of individual tenants
12
UoM
WWW
UoM
WWW
UoP
WWW
UoP
WWW SaaS
WWW
Conventional 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 SIMT
Operational cost
Scalability
Engineering Cost
Tenant-specific
Variations and Changes
Economies of Scales

Multi-Tenancy in Composite SaaS
Applications
15
Services
Tenants
Composite
App.

16
My PhD Work
How 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 evolution
3. 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
AutoRepair
JackParts
TomTow
24by724by7
Mac
Repair
Swift
Tow
Repairing Using External PartsRepairing Using Internal Parts
6 days
due to
External
Parts
3 days

Sharing and Different Use of Services
22
Happy
Tours
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-through 26
Assessing
Repair
AutoRepair
JackParts
Cheap
Parts
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

• 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
AutoRepair
JackParts
TomTow
24by724by7
Mac
Repair
Swift
Tow

• 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
Trigger
Towing
and
Repairing

Illustration : Multi-tenant SN Design
30
Service
Network
Collaboration
Units
Virtual
Service
Networks
Role
Contract
Sharing
Differe
nt Use
HappyToursEuroCars

Meta-model: Configuration Design
Process
ServiceNetwork
CollaborationUnit
VirtualServiceNetwork
Event
InteractionTerm Role
Contract
Service
Task
Represents
Pre/post conditions
Generates
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
Refersto
Regulates

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";
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
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;
}
1
2
3
4
5
6
7
8
9
Contracts and their interaction terms
rule "rAdmissionCheckV1"
when
$msg : RoleServiceInteraction(opName== "assist",
state=="Admittable")
then
AdmissionControl("assist","123,1d",$msg);
end
rule "rProcessSelectionV1"
when
$msg : RoleServiceInteraction(opName== "assist",
state=="Routable")
then
LoadBalance("assist","AnyTrucksP1:2,AnyTrucksP2:1",$msg);
end
1
2
3
4
5
6
7
8
9
10
11
12
13
14
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;
}
}
}
1
2
3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
Collaboration Units
Configuration
Design
Regulation
Design

VirtualServiceNetwork AnyTrucks {
Process AnyTrucksP1 {
CollaborationUnitRef CaseHandling;
CollaborationUnitRef RepairingByAutoRepair;
CollaborationUnitRef TowingBySwiftTow;
CollaborationUnitRef RentingRoom;
InterCollaborationRegulationUnitRef AutoRepairAndSwiftTow;
}
Process AnyTrucksP2 {
CollaborationUnitRef CaseHandling;
CollaborationUnitRef RepairingByAutoRepair;
CollaborationUnitRef TowingByTomTow;
CollaborationUnitRef RentingRoom;
InterCollaborationRegulationUnitRef AutoRepairAndTomTow;
}
InterProcessRegulationUnitRef AdmissionAndProcessSelection;
}
1
2
3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
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
Service
Coordination
Infrastructure
Management
Platform

Illustration: Runtime Model of an SN
39

General Design of a REP
40
Regulation Table
Key Rule Identifiers
ECA Rules
State Manager Event Manager
Trigger
Produce/
Update
Regulation Knowledgebase
Messages
Trigger
e1 en Events
Admission Control SynthesizeQueue PublishEvent
Regulation Mechanisms
Model Manager
S1 Sm States
Mapping
Function

41
Process
Enactment
Termination
of Process
Instance
Progress of Instance of
Local Collaboration 1
Local Collaboration n
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 changes
2. Interaction and
obligation changes
1. 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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

51
Reg. Evol. Management Policy: Example
rule "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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

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
1
2
3
4
5
6
7
8
9
10
11
12
13
14
Conf. Management Policy: Example

53
rule "rAnalyseResponseV6"
when
$msg : RoleServiceInteraction(opName== "analyseResponse")
then
Forward("SC-TX.iOrderTaxi.Req",Synthesise("OrderTaxReq.xsl",$msg));
end
1
2
3
4
5
6
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
1
2
3
4
5
6
1
2
3
4
5
6
7
8
(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 VSN
Updated 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
Throughput(RequestsperSample)
3 Sharing Schemes
GFS : Global Fixed
Scheme
GMS : Global
Minimum Scheme
GOMS : Global
Minimum With
Overbooking Scheme

• VSN(Virtual Service Network) enactment
overhead
65
EnactmentOverhead(Milliseconds)
LoC (Lines of Codes)
Mean of
116.47 ms for
1288.4 LOC

• Relative performance overhead with BPEL in
Apache ODE
66
ResponseTime(Milliseconds)
Number of Concurrent Users

• Runtime change enactment time (RCET) for
11 types of functional change scenarios
67
Change Scenario (CS)
Milliseconds
RCET(RuntimeChangeEnactmentTime)
Add Rollback
533.45 ms 14 msMean

• Runtime change enactment time (RCET) for
11 types of performance change scenarios
68Change Scenario (CS)
MillisecondsRCET(RuntimeChange
EnactmentTime)
Add Rollback
395 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.
“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
“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
Gaps
How 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

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

Software Defined Service Networking (SDSN) - by Dr. Indika Kumara

More Related Content

Viewers also liked (13)

Similar to Software Defined Service Networking (SDSN) - by Dr. Indika Kumara (20)

Recently uploaded (20)

Software Defined Service Networking (SDSN) - by Dr. Indika Kumara

Editor's Notes