1. E-Business Service Components with Multiple Classes of Service and Dynamic Adaptability Mechanisms Vladimir Tosic, Kruti Patel, Bernard Pagurek Network Management & Artificial Intelligence Lab Department of Systems & Computer Engineering Carleton University, Ottawa, Canada vladimir@sce.carleton.ca http://www.sce.carleton.ca/netmanage/

2. Outline zResearch goals zDefinition of service components zService offerings - multiple classes of service for service components zWSOL - Web Service Offerings Language zDynamic adaptation mechanisms zExample - an m-commerce system zDAMSC (Dynamically Adaptable and Manageable Service Compositions) infrastructure zConclusions and future work

3. Research Goals zDevelop additional support within service components (e.g., Web Services) for adaptation of a service composition by dynamically adapting the constituent service components and their relationships, without breaking these relationships zComplement mechanisms for dynamic composition of service components and adaptation by rebinding of service components zApplication area: e- and m-business systems ytrust and customer retention are important issues yadditional agility, flexibility, and adaptability needed

4. Definition of a Service Component zA composable, reusable, and replaceable self- contained unit of service provisioning and management that encapsulates some service functionality and appropriate data zMain usage is composition with other service components into different services (but also can be used in isolation from other service components) zCan be software-based (a.k.a., algorithmic) and/or hardware-based (e.g., memory, printing, network bandwidth, etc.) zSpecial case: e- and m-business Web Services

5. Multiple Classes of Service zRepresent variations of service and QoS (Quality of Service) - differentiate provided services and QoS zRelate to the same functionality, but differ in constraints and cost zIncrease chances to succeed in the market by broadening the market segment yAllow a wider range of possible consumers, with different capabilities, rights and needs yAllow usage in different circumstances zEnable balancing of limited underlying resources and the price/performance ratio, and thus help to maximize the monetary gain

6. Types of Constraints in Classes of Service zFunctional: preconditions, postconditions, invariants zNonfunctional (a.k.a., QoS): QoS guaranteed to consumers and QoS required from suppliers yExamples: service priorities, guaranteed response times, verbosity of response information, required security, etc. zAuthorization policies (i.e., usage privileges) zDependencies from other service components and infrastructure zCost zOther relevant information: related components, alternative components, potential incompatibilities, synchronization and sequencing constraints, etc.

7. A Service Offering zA formal specification of a class of service for a service component or an interface ySpecified separately from the specification of functionality yContains specification of various types of constraints yDifferent types of constraints are separated into distinct layers to achieve greater flexibility and reusability yAllowed combinations of interface-level service offerings determine component-level service offerings zFormal specification supports precise selection of service components and minimizes unexpected feature interactions in service compositions

8. Service Offerings vs. Potential Alternatives zSome potential alternatives: yseparation of service and QoS dimensions, parameterization, multiple service components, multiple interfaces, service personalization techniques (e.g., user profiles) zService offerings are an additional mechanism for differentiation of service and QoS zAlthough they are not a complete replacement for the above alternatives, service offerings have advantages like additional flexibility, relatively low overhead, limited complexity of required management, support for dynamic adaptation mechanisms, etc. yCan be eventually combined with alternative mechanisms

9. WSOL - Web Service Offerings Language zFormal specification of service offerings for Web Services in XML (Extensible Markup Language) zExtends WSDL (Web Services Description Language) zWe are working on prototypes for: ya WSOL parser (with syntax and some semantic checks) yautomatic generation of WSOL files using Java yJava code generation from WSOL and WSDL specifications zWe reuse and extend existing tools: IBM WSTK Toolkit v2.4 and Apache Xerces XML parser yIf necessary, we will also develop additional tools zStill work in progress…

10. Motivation for Dynamic Adaptation Mechanisms zGoal: to accommodate changes that cannot be accommodated on lower system levels, without breaking relationships between service components yRobustness of relationships is important in e- and m- business due to the issues of trust and customer retention zBased on dynamic (i.e., run-time) manipulation of service offerings yThe service component has control and can restrict usage zRelatively limited power, but advantages are speed, simplicity, and low overhead yProvide additional agility, flexibility, and adaptability

11. Three Dynamic Adaptation Mechanisms 1.Switching between service offerings zInitiated by the service component or its consumers 2.Deactivation/reactivation of service offerings zConsumers using the deactivated service offering are automatically switched to an appropriate replacement zAfter the reactivation, these consumers are automatically switched back 3.Creation of new appropriate service offerings yNot creation of new functionality, but creation of new sets of constraints for the existing functionality yUseful after: dynamic upgrades, changes in related service components, a request by a “premium” consumer

12. Example - Part I (out of II) zAn m-commerce system built from third-party pay- per-use service components UserManager ProductInfoRepository ProductStockManager OrderManager Server (includes ShoppingCart states) ClientInteraction CreditCardVerification

13. Example - Part II (out of II) zService offerings accommodate the variety of users, user devices, communication mechanisms, security mechanisms, … zDynamic switching of service offerings accommodates temporary disturbances in QoS; changes of user devices; changes in trust, security, and rights; etc. zDynamic deactivation/reactivation of service offerings when QoS cannot be supported in new circumstances zDynamic creation of new service offerings to accommodate new security mechanisms, user devices, classes of consumer with special deals, etc.

14. DAMSC Infrastructure zDAMSC (Dynamically Adaptable and Manageable Service Compositions) is an infrastructure supporting adaptation and management of service compositions with manipulation of service offerings zWe are working on a number of open issues, like: yHow to relate service offerings for easier specification and easier automatic switching yHow to reduce the overhead of dynamic adaptation yWhere and how constraints are checked (e.g., QoS is measured) and enforced yThe concept of session objects zStill work in progress…

15. Some Related Work zIndustrial Web Service initiatives (e.g., Microsoft.NET and Sun ONE - Open Net Environment) yWe add multiple classes of service and dynamic adaptation zDifferentiated services and classes of service in telecommunications and TINA (Telecommunications Information Networking Architecture) yWe extrapolate and modify existing telecom concepts for computing service components (e.g., Web Services) yWe add new dynamic adaptation mechanisms zReconfiguration by rebinding of service components yWe complement this adaptation mechanism for situations where it is not appropriate or incurs too big overhead

16. Conclusions and Future Work zAdvantages of service offerings include additional flexibility, relatively low overhead, limited complexity of required management, and support for dynamic adaptation mechanisms zAdvantages of suggested dynamic adaptation mechanisms include speed, simplicity, low overhead, and enhanced robustness of relationships between service components zWSOL - a prototype parser is under development zDAMSC - there are still a number of open issues; a prototype implementation will extend existing Web service technologies and use WSOL