Download - M. Adorni, F. Arcelli, D. Ardagna, L. Baresi, C. Batini, C. Cappiello, M. Comerio, M. Comuzzi, F. De Paoli, C. Francalanci, S.Grega, P. Losi, A.Maurino,

M. Adorni, F. Arcelli, D. Ardagna, L. Baresi, C. Batini, C. Cappiello, M. Comerio, M. Comuzzi, F. De Paoli, C. Francalanci, S.Grega, P. Losi, A.Maurino, S. Modafferi, B.

Pernici, C. Raibulet, F. Tisato

The MAIS approach to web service designThe MAIS approach to web service design

Porto 13 June 2005

Andrea MaurinoAndrea Maurino

Università di Milano BicoccaUniversità di Milano Bicocca

[email protected]@disco.unimib.it

2The MAIS approach to web service design

OutlineOutline

The MAIS Project

The MAIS Methodological Framework • General view

Service Specification and Compatibility Analysis Broker-Provider Negotiation and Dynamic Evaluation of

Management Costs Process Partitioning Optimal Service Selection and Quality Renegotiation Implementation Guidelines for a QoS-Oriented Reflective

Architecture

Conclusions and future work


The MAIS ProjectThe MAIS Project

Develop methods, models, and architectures for multichannel adaptive information systems

Multichannel• Service provisioning: web, e-mail, sms, client-server

• Mobile information systems

Heterogeneity, dynamic evolution of channels• Device characteristics

• Network connections

Adaptation to context• User model

• Service provisioning

• Channel of invocation, QoS


Research focResearch focusus

Adaptive orchestration of e-services Reflexive architecture for context-aware services Design of web Services with QoS

Adaptive networks Low power consumption processors

Methods and tools for multichannel interface design and integration

Application areas: e-learning, tourism, emergency teams


The MAIS methodological frameworkThe MAIS methodological framework

4 Methodological steps

Requirements Analysis

• elicit, validate and negotiate web service requirements

• Multichannel, QoS

Design

• model services with MAIS-UML

Deploy

• Network infrastructure

Run time

• adaptive and context-aware use of web services


FrameworkFramework

Analysis

Design

Deployment

Runtime

Service specification and compatibility analysis

Broker-provider negotiation and dynamic evaluation of management costs

Process Partitioning

Optimal service selection and quality renegotiation

Broker-provider negotiation and dynamic evaluation of management costs

Input/output

Interdependence

Domain Req.QoS Req.User Req.Actual ServicesArchitectural Req. UML Diagrams

QoS Req.User Req.PriceArchitectural Req.Budget

Architectural Configuration

Domain and QoS Req.Global/Local ConstraintsPriceMAIS-Registry

Process Description


Service Specification and compatibility analysisService Specification and compatibility analysis

Analysis, (re)-design of web service

• Use of MAIS QoS, Services and Channel Ontology

3 sub-phases:

functional service modelling,

• Model requirements thanks UML

• Logical and operational structure of Web Services

high-level redesign

• Augment existing schema with QoS dimension (from the MAIS QoS ontology)

• Modelled with MAIS-UML profile

• Metrics QoS dimensions have a (Bk)) quality level


Service Specification and compatibility analysisService Specification and compatibility analysis

Context adaptation

• Verification of quality values of QoS requirements and Quality thresholds

Comparison between Bk of each QoS and ideal level

request by user

QoS tree

Simple Additive Weighting technique

• Weights and composition rules to each node


Process PartitioningProcess Partitioning

New deployment strategies for MobIS Goals:

• improve the independency among actors

• Reduce interaction and knowledge sharing

Solution: decompose a unique process into a set of sub process• Automatic partitioning rules

• Based on graph transformation systems

Input: MAIS-UML (translated into MAIS-BPEL), network topology

Output: set of MAIS-BPEL Some formal and empirical result on the correct

behaviour of sub process


Optimal Service Selection and Quality RenegotiationOptimal Service Selection and Quality Renegotiation

Goal: select from registry a set of services • functional equivalent service

Optimization problem with two difference approach Select at run time the best candidate service which supports

the execution of a running high level activity. (local level)• Service can be selected if its price is lower than a given threshold

Identiy the set of candidate services which satisfy end-user preferences for an entire application (global level)• the total price has to be less than 2$.

Service composition with QoS modelled as a mixed integer linear programming problem • NP-hard !!! Multiple Choice Multiple Dimension Knapsack problem

• We use CPLEX, a state of the art commercial solver, which implements a branch and cut technique


Broker-Provider Negotiation and Dynamic Evaluation of Broker-Provider Negotiation and Dynamic Evaluation of Management CostsManagement Costs

Broker between provider and users Conflicting Goals

• Maximize the satisfaction of user requirements

• Achieve maximum possible returns from its brokering role

Broker is paid each time a service is supplied by user Broker can increase the QoS offered by provider Preliminary phase

• set the value of a triple <pij,percij,qij>

• pij :price paid by the user for the service,

• percij :is the percentage on the price due by the service

provider to the broker (0 and 1)

• qij is the aggregate value of QoS offered to user (0 ≤ qi j≤ 1).


Broker-Provider Negotiation and Dynamic Evaluation of Broker-Provider Negotiation and Dynamic Evaluation of Management CostsManagement Costs

Negotiation processes is realized by means of • Negotiation Protocol:

• bilateral bargaining protocol;

• Negotiation Objectives: • typical multiattribute problem: negotiation of a triple of attributes

• Decision Model: • trade-off based strategy

Utility function V • evaluate how much an offer is worth to a participant

Increase QoS level an extra cost c*(qij),

• provide the service to the customer at a higher price p*(qij)

Modify selection of web services in case of cooperative process

Even in the design phase


Implementation Guidelines for a QoS-Oriented Reflective Implementation Guidelines for a QoS-Oriented Reflective ArchitectureArchitecture

Architectural reflection introduces a reflective layer

• applications can observe and control at execution time non-functional features of the system components,

• supporting adaptability.

A reflective layer is causally connected to the physical layer.

Components and QoS cannot be defied in absolute way

• domain-dependent QoS like “low”, “medium”, “high”

Definition of QoS extension pattern


Implementation Guidelines for a QoS-Oriented Reflective Implementation Guidelines for a QoS-Oriented Reflective ArchitectureArchitecture

R_Object

getQoS()setQoS()

QoSQuantitativeQoSQualitative

QoS

name : StringunitOfMeasure : String

QoSValue

QoSValueSet

1

1

1

1

1

1..*

1

1..*

1

1

+actualValue

1

1R_ElementalR_Aggregate 1 0..*1 0..*

QoSStrategy

mapUp()mapDown()

1

1

1

1

R_Object expose measurable QoS values

• Controlled/observed

• Model high-level/domain-dependent abstraction

R_aggregate casually connected to QoSStrategy to set of QoS

QoSStrategy

• How QoS is obtained/mapped


ConclusionConclusion

Propose of a methodological framework

• From Analysis to run time execution

• Fusion of several contributions

Future works

Evolution of each component according to the specific research problem

Extension of our proposal to include MAIS results for the front-end

• Integration

• Validation

Download - M. Adorni, F. Arcelli, D. Ardagna, L. Baresi, C. Batini, C. Cappiello, M. Comerio, M. Comuzzi, F. De Paoli, C. Francalanci, S.Grega, P. Losi, A.Maurino,

Top Related