Service Composition and Selection in Service Oriented Network Architecture (SONATE)

University of KaiserslauternDepartment of Computer ScienceIntegrated Communication Systems ICSYhttp://www.icsy.de

Service Composition and Selection in Service Oriented Network Architecture

(SONATE)

26th October 2010

M. Rahamatullah Khondoker

2M. Rahamatullah Khondoker, University of Kaiserslautern

Outline

Motivation for SONATE Overview of SONATE Concepts and Terminologies

- Building Blocks- Workflows- Framework- Service Composition

Service Selection Conclusions and Outlook Discussion


Problem Statement

It is hard to integrate new mechanismsinto the current Internet

Because: Many implicit dependencies

(i.e. tight coupling)between existing mechanisms

The problem is not limitedto specific protocols ormechanisms

It is an architectural issue!


Motivation for SONATE

A Future Network architecture should be flexible:

- Long term flexibility: Support evolution of networks

- Short term flexibilityDynamically adapt to requirements and constraints


Long Term Flexibility

Enable: stepwise introduction of new functionality Easy introduction of new functionality without depending

on agreements with vendors / providersReasons:

- Enable utilization of highly specific or experimental functionality- Reduce time to market- Opportunity for small companies to provide (network-) services

Of course standardization is still required

Solution: Loose Coupling


Short Term Flexibility

Requirements of current application, e.g. - Different behaviour for regular and emergency phone calls

Current network constraints, e.g. - Mobile or wired network access- A Network may require authentication when prioritization is

requested Capabilities of currently involved nodes

- Adapt to supported functionality. This is important to utilize new functionality.

Solution: Dynamic Adaptation

SONATE Concepts


Building Blocks

Functionality is provided by self-contained building blocks (BB)- Micro-protocols (e.g. flow-control, retransmission or a video

codec)- Other functionality (e.g. monitoring or lookup services)

BB have generic and well-defined interfaces

Description (XML)

BB Code

Effects,Ports,etc.

Effects,Ports,etc.

Effects,Ports,etc.

Effects,Ports,etc.


Services

A Service- Can be seen as a set of visible effects of the underlying

implementation of a protocol or mechanism - Hides implementation mechanisms

Examples of effects• Reliable transmission, Addressing, Security, Routing, Loss Detection,

Loss Reduction, Loop Avoidance, Connection Management, etc.


Workflow

Interaction of Services is defined by a workflow description- Order of Services- Possible data exchange

Descriptions can be changed easier than code Placement of a functionality is not fixed


Workflow

Interaction of Services is defined by a workflow description- Order of Services- Possible data exchange

Descriptions can be changed easier than code Placement of a functionality is not fixed

Loose coupling achieved by:

Building blocks & Workflow-Descriptions

Foster long term flexibility


SONATE Framework

Workflow processing Management of services

Repository of building blocks

Msg1 Msg2 Msg3

Timer, Events,debugging support, …

From previous node To successor node

Shared Data Structures

Physical orvirtual link

Physical orvirtual link

WorkflowEngine

ToApplication

receive send

FromApplication

Msg1’ Msg3’Msg2’


Service Composition

Create workflow descriptions- Select services to be used- Compose (connect)

services

Adapt to (current) requirements andconstraints

ServiceComposition

Application: Requirements

Network: Constraints

…


Signal Workflows

Be independent of Service Composition algorithms Intermediate nodes may

- alter workflows, i.e. act as gateways- provide feedback, i.e. request different behavior

Initiator Next Node

Msgs

FunctionalComposition

Framework FrameworkMsgs

Gateway Node


FrameworkMsgsMsgs


Signal Workflows

Be independent of Service Composition algorithms Intermediate nodes may

- alter workflows, i.e. act as gateways- provide feedback, i.e. request different behavior

Initiator Next Node

Msgs


Framework FrameworkMsgs

Gateway Node


FrameworkMsgsMsgs

Dynamic adaption achieved by:

Service Composition& Processing of Workflow-Descriptions

Foster short term flexibility

Service Selection


Service Selection

Service Composition Approaches- Manually (supported by tools)- Templates (predefined structure, delayed completion)- Genetic algorithms (automatic but time consuming process)- Compose few coarse grain modules / partial workflows- Compose fine grained building blocks


Service Selection

Composition approaches differ according to- Tradeoff: When to perform vs. Information availability

• Design time: General requirements and protocols are known• Deployment time: General application requirements and system

constraints are known• Run time: User requirements and available resources are known

- Flexibility- Effort for calculation

It is unlikely that one approach is always optimal


Service Selection Process

Application

Requirements

Conventional

TCP/IPUDP/IPSCTP/IP…

Compound Template S&C

…

ServiceBroker

Offerings

Network Abstraction API

SelectedService

Requirements

Access to Service Provider

Service Providers


Requirements: Service Selection

Service Description- For comparing application requirements and offered services

Service Selection Methodology- For getting suitable services - For getting the best service


Service Selection: Service Description

Used to determine for a requested service- Which offered services are suitable

(i.e. fulfills all compulsory requirements)- Which suitable service is optimal

(i.e. compare properties of service) Describe services using two types of properties

- Mandatory properties, attributes using absolute values• <PropID, lower-bound, upper-bound>• Examples: compare MTU size, average Bandwidth, Costs, …

- Optional properties, attributes using absolute values• <PropID, rating> rating [-9,9]• Examples: decide to increase security vs. reduce delay


Service Selection: Methodology

Service Selection Methodology- For getting an optimal service, optimization of optional properties

is required- For example, security and delay of similar services - We need Multiple Criteria Decision Analysis (MCDA)

• Several algorithms (MAUT, AHP, ELECTRE III, Evamix) exist for doing this

- Where as no other MCDA methods allow interdependence of different criteria, AHP does that

- We used Analytic Hierarchy Process (AHP)• Checking consistency of evaluation measures• Reduces biased behavior in decision making process

- AHP must be adapted for automatic service selection


Service Selection: AHP

Fig. Analytic Hierarchy Process (AHP)

Absolutely More

Absolutely Less

9753-1 or 1-3-5-7-9

Moderately Less

Moderately MoreEqual

Fig. Pairwise comparison scale


Service Selection: Usage of AHP

AHP in service description and selection- Input

• A set of effects- Requirements

• Pairwise priority assignment• Calculate one priority for each effect

- Offers• Pairwise priority assignment

- This requires a mapping mechanism which cannot be done by AHP• Calculate one priority for each effect

- Output• A service with the highest priority value


Service Selection

The priority assigned in requirements needs to be mapped to the offered services

Pairwise prioritization of services per effect- The mapping must be generic- The mapping should be monotonic- A linear mapping of measured values to prioritization is not

adequate- An approach for mapping is proposed to use monotonic

interpolation/extrapolation

+/- 1

9

-9

Hints Measured value

Measured value of offers

Prio

rity

Fig. Values in terms of hints


Example: AHP in Service Selection

Offerings

Application Requirements


Summary and Outlook

Summary- SONATE as a flexible network architecture- Service Description- Service Selection

• Analytic Hierarchy Process (AHP)

Outlook- Service Composition Challenges

Thanks for your attention

Any questions, comments or concerns?


Discussion Questions?

Assuming that more than one services provide the same functionality. In that case, we need mechanisms for rating those services to select the most appropriate one.

- How to do rating of composed services?

• Which time is suitable for rating a composed service Design time, deployment time or runtime?

• Do we have enough information to aggregate properties at that time? For example, delay and security of a service



Assuming that a service, Reliable transmission, can be offered as a coarse-grained service or it can also be offered by following services- Error detection- Order preservation- Error control- Data flow limiting

- Which grained of service is better? Coarse-grained or fine-grained. Why?



Services might be dependent on each other. These dependency information can be written statically or can be obtained dynamically by analysing their semantics.

- Which way of obtaining dependency is better? Why? What properties to be in the service description so that dependency information can be obtained automatically?



Where to place services? End-to-end, every node, or in the middle boxes?



How to deal with heterogeneous services?

Integrated Communication Systems ICSY

University of KaiserslauternDepartment of Computer ScienceP.O. Box 3049D-67653 Kaiserslautern

M. Rahamatullah Khondoker, M.Sc.

Phone: +49 (0)631 205-26 43Fax: +49 (0)631 205-30 56

Email: [email protected]: http://www.icsy.de


Analytic Hierarchy Process (AHP): step 1

Ref: This example is taken from the slides of Dr. S. Tom Foster, Jr. and Dr. Gerald LaCava

The Analytical Hierarchy Process by Thomas Saaty

A.Car A Car B Car C

Price 13100 11200 9500MPG 18 23 29

Interior Deluxe Above Average StandardBody 4-Door Mid-size 2-Door Sport 2-door compactRadio AM/FM, tape AM/FM AM

Engine 6-cylinder 4-cylinder turbo 4-cylinder




B. Hierarchy of Decisions

Select the best car

Price MPG Comfort Style

Car ACar BCar C

Car ACar BCar C

Car ACar BCar C

Car ACar BCar C




C. Establish Priorities

1. The priorities of the four criteria in terms of the overall goal.2. The priorities of the three cars in terms of the purchase-price criterion.3. The priorities of the three cars in terms of the MPG criterion.4. The priorities of the three cars in terms of the comfort criterion.5. The priorities of the three cars in terms of the style criterion.




D. Pairwise Comparison Scale

Verbal Judgement of Preference Numerical RatingExtremely Preferred 9

Very strong to extremely 8Very strongly preferred 7

Strongly to very strongly 6Strongly preferred 5

Moderately to strongly 4Moderately preferred 3

Equally to moderately 2Equally preferred 1




E. Pairwise comparison matrix showing preferences for the three cars in terms of comfort

Comfort Car A Car B Car CCar A 1 2 8Car B 0,5 1 6Car C 0,125 0,166666667 1




F. Synthesizing JudgmentsComfort Car A Car B Car CCar A 1 2 8Car B 0,5 1 6 Sum the columns in the pairwise comparison matrix.Car C 0,125 0,166666667 1

1,625 3,166666667 15

Comfort Car A Car B Car CCar A 0,615384615 0,631578947 0,533333Car B 0,307692308 0,315789474 0,4 Divide elements by the column totals.Car C 0,076923077 0,052631579 0,066667

1 1 1

Priority Vector for ComfortComfort Car A Car B Car CCar A 0,615384615 0,631578947 0,533333 0,593432Car B 0,307692308 0,315789474 0,4 0,341161 Sum the rows.Car C 0,076923077 0,052631579 0,066667 0,065407

Car A 0,593Car B 0,341 The priority vector for the cars with respect to comfort.Car C 0,065




G. Other Pairwise ComparisonsPrice Car A Car B Car C Priority VectorsCar A 1 0,33333333 0,25 0,123Car B 3 1 0,5 0,32Car C 4 2 1 0,557

MPG Car A Car B Car CCar A 1 0,25 0,166667 0,087Car B 4 1 0,333333 0,274Car C 6 3 1 0,639

Style Car A Car B Car CCar A 1 0,33333333 4 0,265Car B 3 1 7 0,655Car C 0,25 0,142857143 1 0,08




H. Pairwise comparison matrix for the four criteria in the car selection problem.Criterion Price MPG Comfort StylePrice 1 3 2 2MPG 0,333333333 1 0,25 0,25Comfort 0,5 4 1 0,5Style 0,5 4 2 1

I. Priorities for the overall goal.Price 0,398MPG 0,085Comfort 0,218Style 0,299




J. Developing an overall priority ranking.Criterion Price MPG Comfort Style

Car A 0,123 0,087 0,593 0,265 Alternative Car B 0,32 0,274 0,341 0,655

Car C 0,557 0,639 0,065 0,08

Overall car A priority = .398(0.123)+0.085(0.087)+).218(0.593)+0.299(0.265)=.265Overall car B priority = .398(0.320)+0.085(0.274)+).218(0.341)+0.299(0.655)=.421Overall car C priority = .398(0.557)+0.085(0.639)+).218(0.066)+0.299(0.080)=.314




K. Final AHP Ranking of Alternatives

Car B 0,421Car C 0,314Car A 0,265

1

Dr. LaCava's Mid-life Crisis Maserati!

Documents

Service Composition and Selection in Service Oriented Network Architecture (SONATE)