1 / 25

CPXe: a SLAng case study

Davide Lamanna, James Skene, Wolfgang Emmerich Computer Science Dept. (UCL) Software Engineering Group {d.lamanna | j.skene | w.emmerich}@cs.ucl.ac.uk. CPXe: a SLAng case study. Agenda. e-Business: setting the scene SLAng concepts review XML: why? CPXe Three scenarios Evaluation

nishan
Download Presentation

CPXe: a SLAng case study

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. Davide Lamanna, James Skene, Wolfgang Emmerich Computer Science Dept. (UCL) Software Engineering Group {d.lamanna | j.skene | w.emmerich}@cs.ucl.ac.uk CPXe: a SLAng case study

  2. Agenda • e-Business: setting the scene • SLAng concepts review • XML: why? • CPXe • Three scenarios • Evaluation • Future work

  3. e-Business • Execution of transactions of commercial significance in a distributed computing context • Involving an organisation, its clients and its partners (public collaborative process) • Internal to an organisation, integrating separate computational assets (private process) • Technical-integration support • Component-based middleware • Communication protocols • Application Service Provision (ASP) and Web-service provision • Infrastructure provision (ISP, SSP, application hosting) • Non-functional (quality) requirements • Need for description and negotiation of QoS properties

  4. Web services: Setting the scene

  5. SLAng reference model

  6. SLAng contribution • Support for inter-organisational service provision (storage, network, middleware, application level) • Captures provider and client responsibilities with respect to non-functional properties • Format for the negotiation of QoS properties • Unambiguous inclusion in contractual agreements • Language appropriate as input for automated reasoning systems or QoS adaptive middleware

  7. SLAng features • End-point description of contractors: • info on customer/provider location and facilities • Contractual statements: • start date, duration, charging clauses, rebates on SLA violation • Service Level Specification (SLS)s: • Technical QoS description and the associated metrics

  8. XML: Why? (1/3) • Integration with existing service description languages • (e.g., WSDL+BPEL+SLAng) • Tools & parsers • Go beyond firewalls

  9. XML: why? (2/3) • Parameterisation: tier- and actors-specific parameters. • Quantitative and qualitative description of services • Compositionality: cascading of responsabilities (easy to track) • Validation: syntax, consistency (as a result of a composition)

  10. XML: why? (3/3) • Monitoring: basis for derivation/installation of automated monitors • Enforcement: trigger for extension of services • by, e.g., caching, replication, clustering, farming, routers configuration • Deployment descriptors: make components hosting QoS-aware • by simply inserting SLAng istances • UML tools for software performance engineering

  11. SLAng structure

  12. Component parts of an SLA

  13. An example of QoS parameters

  14. Common Picture eXchange environment • I3A architecture to develop Internet-based digital photo services • It links digital services, Internet storage and retail photo finishing together • Web Services technologies (SOAP, WSDL and UDDI): define, develop, publish • Imaging applications distribuited across a number of parties (in-home, on-line, in-store) • Images can be pushed from the requester, pulled from an on-line service or referenced in a CPXe-compliant storage service

  15. CPXe Architecture

  16. Aggregation of services • Appear to clients as having more capabilities than autonomously provided • SLA negotiation support so that QoS can be delivered together with the service • Collaboration regulated by SLAs, whenever organisational boundaries are crossed • CPXe entities can hold different roles and possibly change them with respect to their partners • CPXe directory replicated at multiple locations (fail over)

  17. Scenario 1: Print service from home

  18. Scenario 2: Picture access

  19. Scenario 3: Update/order from a kiosk

  20. A natural language SLA (1/2) This Deed of Agreement is entered into as of the Effective Date identified below. BETWEEN WebApp2Go.com of London (To be known as the Server in this Agreement) AND: CPXe-Dir of Los Angeles (To be known as the Client in this agreement). WHEREASServer desires to enter into an agreement to supply Client with Replication of software components (To be known as Hosting in this Agreement). NOW IT IS HEREBY AGREED that Server and Client shall enter into an agreement subject to the following terms and conditions: 1. Definitions and Interpretations 1.1 All information (order, payment, notifications, etc.) is to be sent electronically. 1.2 This agreement is governed by British law and the parties hereby agree to submit to the jurisdiction of the Courts of the Britain with respect to this agreement. 2. Commencement and Completion 2.1 The commencement date is scheduled as the 11th of February 2003. 2.2 The completion date is scheduled as the 10th of February 2004. 2.3 The schedule may be modified by agreement as defined in Section 9. 3. Service use 3.1 Client will allow a mean number of active service clients equal to 24,000, with a maximum peak of 40,000. 3.2 Client will guaranteed an arrival rate of service requests not greater than 113.2 per second. 4. Provision 4.1 500 Mbytes of disk space will be provided. 4.2 High availability will be enabled, with 99.6% as the percentage of availability over a year and 2 hours as mean recovery time. 4.3 20 hours of scheduled outages and 12 hours of routine maintanance are planned. 5. Performance 5.1 Server guarantees a mean response time equal to 2.6 seconds, with peak time latency of 4.7 seconds. 5.2 Server guarantees a successful transaction ratio equal to 98% over a year. 5.3 The cluster throughput, based on 9 containers, with 310 active clients, will guarantees a method invocation rate of 53.141.

  21. A natural language SLA (2/2) 6. Security 6.1 Data protection will be enabled using RSA as the encryption method. 6.2 Certification, authentication and virus scanning will be guaranteed at any time. 6.3 User configuration data will be archived using Rar, and backed up using REOBack. 6.4 A complete backup wil be executed every 24 hours, with an incremental backup interval of 6 hours. 6.5 Users will be given the possibility to access individually their backup data. 7. Monitoring 7.1 Server will use IDX as a tracking system for monitoring performance levels. 7.2 Server will report every 48 hours the state of the system, using a properly formatted XML document. 8. Termination 8.1 If Client or Server fail to carry out any of its obligations and duties under this agreement the offender is to be considered in breach of the e-contract. 9. Disputes and compensation clauses 9.1 Server and Client shall attempt to settle all disputes, claims or controversies arising under or in connection with the agreement through consultation and negotiations in good faith and a spirit of mutual cooperation. 9.2 Server and Client shall provide electronic evidences about breaches of the e-contract. 9.3 Unless it is proved that Client has caused outages, Server shall provide for a compensation equal to 4 times as much the difference between the promised availability and the delivered one. 9.4 This method of determination of any dispute is without prejudice to the right of any party to have the matter judicially determined by a British Court of competent jurisdiction. 10. Amendment 10.1 This agreement may only be amended in writing signed by or on behalf of both parties. E-SIGNATURES In witness whereof Server and Client have caused this agreement to be entered into by their duly authorized representatives as of the effective date written below. Effective date of this agreement: 7th of February 2003 [E-signature] [E-signature] [Person] [Person] [Role] [Role] E-address for Notices: [E-address] [E-address]

  22. SLA in SLAng <?xml version="1.0" encoding="UTF-8"?> <SLAng xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="dave/TAPAS/SLAng0_5/SLAng0_5.xsd"> <Vertical> <Hosting> <Id sls_id="49258" service_id="Replication"/> <Client> <Name>CPXe-Dir</Name> <Place>Los Angeles</Place> <Clients mean_number="24000" maximum_number="40000" arrival_rate="113.2"/> <Availability>95%</Availability> </Client> <Server> <Name>WebApp2Go.com</Name> <Place>London</Place> <Provision disk_space="500" memory_usage="512"/> <High_availability>99.6%</High_availability> <Maintenance recovery_time="2" scheduled_outages="20" routine_maintenances="12"/> <Performance response_time="2.6" peak_time_latency="4.7" successful_transactions="98%" processing_speed="843"/> <Cluster_throughput containers="9" active_clients="310" method_invocation="53.141"/> <Security data_protection="true" encryption_method="RSA" certificate="true" user_authentication="true" intrusion_detection="false" virus_scanning="true" eavesdrop_prevention="false"/> <Backup solution="REOBack" complete_backup_interval="24"incremental_backup_interval="6" data_types="User configuration data" archiving_form="rar" client_access="true" backup_encryption="false" individual_client_backup="true"/> <Monitoring tracking_system="IDX System" report_method="XML" report_frequency="48" reporting_on_demand="false" security_violations="false"/> </Server> <Mutual> <Service_schedule start="2003-02-11" end="2004-02-10"/> <Failure_clauses compensation="(100%-availability)*4" exclusion_clauses="Client caused outages"/> </Mutual> </Hosting> </Vertical> </SLAng>

  23. Evaluation • SLAs transformed into a more suitable format for inclusion in a service contract • SLAng is expressive enough to represent the QoS parameters for the complete definition of interfaces in multi-party deployments • Precise and fairly concise SLA specifications • no SLA > 2 Kbytes • SLAs can be transformed using XSLT style sheets into deployment descriptors for web servers or application servers

  24. Research agenda • Model and reason about SLA composition • UML tools for SPE design • SLAng instances into deployment descriptors, to make components hosting QoS-aware • Test the effectiveness of SLAng for monitoring compliance to SLAs • Toolkit for service composition and analysis (assist ASPs in determining what SLAs they can offer) • Model checking

  25. Questions ?

More Related