1k likes | 1.02k Views
Explore the slow industrial adoption of Web services and the importance of Quality of Service at the solution level for integrated control. Learn about QoS standards, current challenges, and managing QoS attributes effectively in SOA.
E N D
Services ComputingChapter 8: Solution-Level Quality of Service in SOA IEEE Body of Knowledge on Services Computing Sponsored by Technical Committee on Services Computing, IEEE Computer Society Your Name:____________________________
Quality of Service in SOA SOA-QoS Representation of QoS Model Association of the QoSRequirement QoS Management QoS Framework Component Relationships Data Architecture Layer Modeling of Resources Fragment of QualityController role Outline Focus
8.1 State-of-the-art of QoS on Web Services 8.2 SOA-QoS 8.2.1 Context-Aware QoS Model 8.2.2 Representation of QoS Model 8.2.3 QoS Data Management 8.2.4 Business Relationship Model Outline
8.3 QoS Framework in an SOA Solution 8.3.1 QoS Framework Descriptions 8.3.2 Relationships Between Constructs in QoS Framework 8.4 Data Architecture Framework 8.4.1 Data Architecture Framework Descriptions 8.4.2 Relationships Between Constructs in Data Architecture: Component Relationships Outline
8.5 Modeling the Key Elements in QoS Management 8.5.1 Modeling of Resources 8.5.2 Modeling the QoS Assurance Process 8.6 Discussions on QoS in SOA 8.7 Summary Outline
Reasons why the speed of actual industrial adoption of Web services is quite slow 1.Training of service providers and service buyer to be adept with the new innovation of web services. 2. It has to earn the trustworthiness of businesses. QOS is identified to accumulate standards and protocols that aim at enhancing the trustworthiness of Web services in various aspects. Quality of Service in SOA
8 Solution-Level Quality of Service in SOA 8.1 Quality of Service in SOA • The speed of actual industrial adoption of Web services is quite slow. • QoS (a.k.a. ‘ilities’) • Meets specified requirements • Reliability, security, safety, etc. • Challenges in WS • Dynamic substitution • Remote hosting • Erratic Internet behaviors • Current state-of-the art
Reasons why the speed of actual industrial adoption of Web services is quite slow 3. In order to convince enterprises to use to adopt Web services; web services quality needs to be assured at the solution level that it can provide integrated Qos control at various granularity levels. 8.1 Quality of Service in SOA
QoS (a.k.a. ‘ilities’) Meets specified requirements Reliability, security, safety, etc. FOUR PERSPECTIVES of Qos Layer: 1. Security 2.Transaction 3.Reliable Messaging 4.Resource lifetime Management 8.1 Quality of Service in SOA
The QoS Layer of the current services standard currently defines the set standards to help developers and services providers enhance the quality of WEB Services at the message level and the transaction level: Examples: Pop out questionnaires Error messaging – Microsoft An SOA solution may comprise multiple services each exhibiting component level QoS attributes. 8.1 Quality of Service in SOA
Requirements of Managing a QoS of the entire solution requires: a. QoS information of the individual levels b. QoS information at the solution level 8.1 Quality of Service in SOA
8.1 Quality of Service in SOA Current Focused Attributes of WEB Services QoS Standards a. Availability e. Reliability b. Accessibility f. Regulatory c. Integrity g. Security d. Performance 12
Researchers are currently investigating on the wealth of theories contributed by Software engineering to be able to exploit and apply these technologies and methodologies in the field of Web Services using the enumerated focused attributes. There is a necessity of the method that guides engineers to create a fine grained solution level QoS control and management framework for SOA. 8.1 Quality of Service in SOA
Details to be addressed by the QoS management: 1. Representation 2. Measurement 3. Monitoring 4.Management of Qos of the federated and aggregated Services Challenges in WS 1. Dynamic substitution 2. Remote hosting 3. Erratic Internet behaviors Current state-of-the art 8.1 Quality of Service in SOA
A method for creating a data-driven QoS management framework. The Technique Addresses QoS Data from Five Perspectives 1.How to represent contextware QoS Data in a unified form. 2. How to communicate QoS Data through high level message exchange under constraints. 3. How to propagate QoS event at run time. 4. How to handle QoS events 8 Solution-Level Quality of Service in SOA8.2 SOA-QoS
The framework addresses QoS management through a logical QoS layer associated with a logical Data Architecture layer each comprise of: A closure of configurable constructs Non configurable constructs Based on the best practices of SOA solution development. Association of Fine-Grained Constructs is between: Relationships Interaction Patterns * The relationships between them are extensible rules to enable adaptability to evolutionary changes. 8.2 SOA - QoS
A solution level QoS model is needed to qualitatively and quantitatively define the quality of an SOA solution. This concept is defined as a combination of a set of attributes: reliability (Re), security (Se), safety (SA), availability (Av), and so on… 8.2 Context Aware QoS Model
Surrounding Contexts for Quality SoA Solution: Business level requirements Ex. Delivery Time and Execution Cost 2. Delivery Environment 3. SOA relationships *This can be presented as a function of specified attributes. 8.2.1 Context Aware QoS Model
Context-Aware QoS Model QoS(s) = f(aRe, bSe, cSa, dAv, ...) | (KPIs, environment, relationships) where a, b, c, and d are quantitative or qualitative measures of particular attributes, which fact implies that each attribute may contribute differently to the quality of an SOA solution in a specific context, including KPIs, environment, and relationships. 8.2.1 Context Aware QoS Model
In order to enable the QoS model over the entire SoA solution, it is necessary to identify a uniform, flexible and extensible way to model a QoS data (i.e. requirement) Example: Web Services Resource Framework (WSRF) –a QoS data as universal resources. 8.2.2 Representation QoS Model
WSRF – is an XML based presentation method, it captures resources using Web Services. 8.2 SOA-QoS
REASONS WHY WSRF: 1. QoS information may need to be carried by system or system components 2. QoS should be able to persist across and evolve as a result of Web service interactions. 3. QoS evolve as a stateful resource using WSRF. 4. QoS requirement can be modeled using WS Resource properties specifications. 8.2.2 Representation of QoS Model
Relative segments of a sample resource properties document definitions for QoS Requirement. The WS-Resource properties specification document is defined using XML Schema 8.2.2 Representation QoS Model
<xs:schema targetNamespace="http://servicescomputing.org/scbook/qos/QoSRequirement" xmlns:tns="http://servicescomputing.org/scbook/qos/QoSRequirement" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="QosRequirementId" type="xs:string"/> <xs:element name="Description" type="xs:string"/> <xs:element name="attribute" type="xs:string"/> <xs:simpleType name="QosTypeEnumeration"> <xs:restriction base="xs:string"> <xs:enumeration value="Reliability"/> <xs:enumeration value="Security"/> <xs:enumeration value="Safety"/> <xs:enumeration value="Availability"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="OperatorEnumeration"> <xs:restriction base="xs:string"> <xs:enumeration value="GREATERTHAN"/> <xs:enumeration value="GREATERTHANOREQUALTO"/> <xs:enumeration value="EQUALTO"/> <xs:enumeration value="LESSTHAN"/> <xs:enumeration value="LESSTHANOREQUALTO"/> </xs:restriction> </xs:simpleType> <xs:element name="constraint"> <xs:complexType> <xs:sequence> <xs:element ref="attribute"/> <xs:element ref="operator" type="operatorEnumeration"/> <xs:element ref="attribute"/> </xs:sequence> </xs:complexType> </xs:element> Representation of QoS Model
<xs:element name="PreCondition"> <xs:complexType> <xs:sequence> <xs:element ref="constraint" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="PostCondition"> <xs:complexType> <xs:sequence> <xs:element ref="constraint" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="QoSRequirement"> <xs:complexType> <xs:sequence> <xs:element ref="QosRequirementId"/> <xs:element ref="Description"/> <xs:element name="QosType" type="QosTypeEnumeration"/> <xs:element ref="PreCondition"/> <xs:element ref="PostCondition"/> </xs:sequence> </xs:complexType> </xs:element> … </xs:schema> Representation of QoS Model (cont’d)
QoSRequirement contains five elements: QoS Requirement Description QoS Type PreCondition PostCondition * Each element is of XML Schema Definition (XSD type String (xsd: string). 8.2.2 Representation of QoS Model
DEFINITIONS: 1. QoS RequirementID denotes the unique identifier of the QoS requirement with an XSD type String (xsd:string). 2. Description denotes the verbose descriptions of the QoS requirement, with an XSD type string. 3. QoSType denotes to which one of the four soft ware attributes the requirement is related, with defined type, QosTypeEnumeration containing four predefined values (Reliability, Security, Safety, and Availability) 8.2.2 Representation of QoS Model
4.PreConditiondenotes the precondition of the requirement. 5.PostCondition denotes the postcondition of the requirement. * Both PreCondition and Post Condition contain one or multiple constraints, each being a triple <attribute, operator, attribute>. 8.2.2 Representation of QoS Model
An attributeis of an XSD type String (xsd: string). Operator denotes one of the five operators, with defined type operator Enumeration containing five predefined values(>,>==.<,<=) 8.2.2 Representation of QoS Model
<wsdl:definitions targetNamespace="http://servicescomputing.org/scbook/qos/QoSRequirement" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xs=http://www.w3.org/2001/XMLSchema xmlns:wsrp="http://www.servicescomputing.org/scbook/qos/web-services/ws-resourceProperties" xmlns:tns="http://www.servicescomputing.org/sccbook/qos/QoSRequirement"> … <wsdl:types> <xs:schema> <xs:import namespace="http://servicescomputing.org/scbook/qos/QoSRequirement" schemaLocation="…"/> </xs:schema> </wsdl:types> … <wsdl:portType name=" QoSRequirement PortType“ wsrp:resourceProperties="tns: QoSRequirement"> <operation name="getQoSRequirementId"/> <operation name="getDescription"/> <operation name="getQoSType"/> <operation name="getPreCondition"/> <operation name="getPostCondition"/> … </wsdl:portType> … </wsdl:definitions> Association of the QoSRequirement resource properties document toaportType
The portType, with the associated resource properties document, defines the type of the WS Resource. In order for a QoS Requirement user to know that the QoS Requirement defines the WS-Resource properties document declaration is associated with the WSDL portType definition in the WSDL definition of the Web service interface, through the use of a standard attribute resourceProperties. 8.2.2 Representation of QoS Model
Five Operations as defined by portType “QoSRequirement: QoSRequirement(getQoSRequirement) getDescription getQoSType getPreCondtion getPostCondition Representation of QoS Model
QoS requirement is represented as a universal Web Service resource, it can be communicated between various architectural components through high level message exchange as a common service resource. Details of Qos Data Management 1. Each component is equipped with corresponding QoS requirements as validators. For such component, its related components and propagated QoS requirements can be analyzed. 8.2.3 QoS Data Management
Example: Another component with a child-parent relationship with it its QoS requirement will be inherited by the child component. 2. The QoS data is communicated through message delivery of QoS metrics and carried by business protocols. 3. In order to decide whether a QoS requirement needs to be propagated to another component, the relationships between the two components need to be analyzed first. 8.2.3 QoS Data Management
4. At run time, if a Qos requirement cannot be satisfied at one architectural component, a QoS validation failure event will be generated and be propagated to all related components. 5. Each receiving component will then validate its corresponding QoS requirements. 6. If they cannot be satisfied, the component in turn propagate the QoS events to its related components. * Such a chained QoS event propagation will help to perform runtime variation impact analysis. 8.2.3 Qos Data Management
Business Relationship Model Layered model captures services-oriented relationships at different granularities. 4 Types of Business Relationship Model 1. Business entity 2. Business service 3. Web service 4. Operation 8.2.4 Business Relationship Model
BUSINESS ENTITY A business entity refers to a business organization. BUSINESS SERVICE Business Service realizes some business functions in an enterprise. 8.2.4 Business Relationship Model
Web Service A Web Service implements a business service. Operation Operation refers to a specific function provided by a service. 8.2.4 Business Relationship Model
9 DIFFERENT GRANULARITIES 1.Business-to-business relationship (B-B-R) 2. Business _service relationship to business _ service relationship (BS-BS-R) 3. Web_service-to-web_service relationship (WS- WS-R) 4.Operation-to-operation relationship (O-O-R); The layered model captures services – oriented relationships at 9 different granularities which define the hierarchical relationships between SOA related elements. 8.2.4Business Relationship Model
9 DIFFERENT GRANULARITIES 5. Business-to-business service relationship (B- BS-R); 6. Business-to-web_services relationship (B-WS-R) 7. Business-to-operation relationship (B-O-R); 8. Business_service-to-web_service relationship(BS-WS-R); 9. web_service-to operation relationship (WS-O-R). 8.2.4 Business Relationship Model
8.3 QoS Framework in an SOA Solution • A logical QoS framework intends to control and manage the quality of an SOA solution.
14 Fundamental Constructs in the Internal Structure of the QoS framework Solution-level QoS manager Representation Manager Capability Manager Solution level QoS context (s-Qos context) manager Solution level instance manager (s-level instance manager) 6. Lifecycle manager 8.3 QoS Framework in an SOA Solution
7. Delivery time manager 8. Execution Cost Manager 9. Delivery Environment Manager 10. Relationship Manager 11. Reliability Manager 12. Availability Manager 13. Security Manager 14. Safety Manager 8.3 QoS Framework in an SOA Solution
S-QoS Manager An S-Qos manager construct is the center of the SOA-QoS framework. It coordinates all other constructs. It is called an S-Qos manager instead of a QoS Manager to emphasize that it refers to solution level QoS management, the s-QoS manager construct is a six tuple<represenation manager, s level instance manager, lifecycle manager, s-Qos enabler, capability manager, s-Qos context manager>. 8.3 Qos Framework Descriptions
S-QoS Manager An s-QoS manager construct is the center of the SOA-QoS framework. It coordinates all other constructs. It refers to the solution level QoS management. 8.3.1 QoS Framework Description
Representation Manager A representation manager construct is responsible for providing a unified description interface for QoS requirements. The purpose is to hide proprietary presentation details on specific QoS requirements. Web Services Resource Framework (WSRF) and WS-Policy are two possible candidates because they help to define requirements in a uniform manner. 8.3.1 QoS Framework Descriptions
Capability Manager A capability manager construct is responsible for handling how to represent, measure, monitor, and manage the detailed solution level QoS requirements in terms of traditional software-related attributes. As shown, for QoS capabilities are captured as default sub-contracts: reliability manager, security manager and safety manager. It should be noted that more software-related attributes can be plugged into the QoS framework as sub constructs for the capability manager construct. 8.3.1 QoS Framework Descriptions
S-QoS Context Manager An s-Qos context manager maintains contextual information for solution-level QoS management. It contains four categories of information, delivery time, execution cost, delivery environment and relationship. This construct implies that the solution level QoS measurement and assessment are based on surrounding contexts. 8.3.1 QoS Framework Descriptions
S-QoS Enabler An s-QoS enabler construct is responsible for adapting solution level QoS requirements into solution specific QoS requirements. For example, a solution level QoS requirement may imply different QoS requirements to other components in a specific solution. 8.3.1 QoS Framework Descriptions