1 / 15

The MAIS approach to web service design

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

vondra
Télécharger la présentation

The MAIS approach to web service design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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

  2. 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

  3. 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

  4. 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

  5. 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

  6. Framework

  7. 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

  8. 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

  9. 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

  10. 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

  11. 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).

  12. 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

  13. 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

  14. 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

  15. 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

More Related