150 likes | 274 Views
The MAIS approach to web service design. 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. Porto 13 June 2005. Andrea Maurino
E N D
The MAIS approach to web service design 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 Porto 13 June 2005 Andrea Maurino Università di Milano Bicocca maurino@disco.unimib.it
Outline • 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 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 focus • 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 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
Service 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 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 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 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 Management 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 Management 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 Architecture • 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 Architecture • 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
Conclusion • 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