Setting the scene “Deutsche Bank AG has agreed to outsource two internal business processes to Accenture Ltd. as part of Dependability of its ambitious program to cut costs and Web Service Architectures increase efficiency by moving non-core operations to external service providers. Under the service agreement announced Thursday, Deutsche Bank James Skene, Franco Raimondi and will outsource its worldwide corporate purchasing and accounts payable Wolfgang Emmerich services to Accenture. The global London Software Systems consultancy and software development Dept. of Computer Science group, located in Hamilton, Bermuda, will provide IT systems and tools to University College London manage the bank's entire procurement- http://sse.cs.ucl.ac.uk to-payment process.” [Source: IDG, 30 Jan 2004] 2 Setting the scene Web Service Dependability • Current WS standards mainly Tracking focus on functionality • But organizations depend on quality of services provided by 3 rd parties Purchase Purchase Accounts Funds Request Request • Their service needs to be Payable Transfer Client Server delivered with agreed quality – Availability / Timeliness Accounts – Reliability Receivable – Confidentiality Order – Integrity, … 3 4 1
Dependability Management Achieving dependability in WS Architectures • Testing web services alone SLA insufficient because service dependability determined by – Resource provision available in the Purchase Purchase Server Client run-time environment Request Request Monitor Monitor Client Server – Service usage profile • For web services, we need to – have quality norms and standards SLA – know how to measure quality violations – have continuous quality monitoring – use quality criteria for service selection Component Message passing • These need to be reified at run-time Generation Feedback Loop 5 6 Service Level Agreements Service Level Agreements • Associate penalties to aberrant • Determine required and service behaviour provided service quality • Are often part of service delivery • Written in terms of contracts – Non-functional requirements • Mitigate risk – Usage constraints • Previously mostly written in natural • Often annexed to a service language provision contract – Ambiguous – Incomplete • Bi-lateral – Inconsistent • Bi-directional • We focus on SLAs in formal languages 7 8 2
SLA content SLA Language Engineering SLA Abstract Syntax SLAs determine conditions, e.g. • Aim: defining precise and unambiguous SLAs language • Reliability • Use OMG’s Meta Object • Timeliness Facility (MOF) to define • Availability Behavioural – Abstract syntax of SLA language • Throughput constraints – Service observation domain • Backup model May include terms determining • Define semantics of SLA langu- • Monitorability age in model denotational style Service Observation • Penalties Domain Model – Behavioural constraints between • Administration syntax and domain model • Schedules of applicability See: J. Skene, D.D. Lamanna and W. Emmerich: Precise Service Level Agreements. Proc. ICSE 04 9 10 Syntax definition for web service SLAs in MOF SLA in OMG Human readable Textual Notation services SLA ServiceTerms ServiceDefinition 1..* terms SLA() { sLA operations 1..* operations terms = ServiceTerms[terms]() { OperationDefinition 1..* penalties = { FailureModeDefinition ::slang::PenaltyDefinition[p1]("Pay client 100 dollars.") failureModes } +kind 1..* services = ServiceDefinition[service](Notification port") +maximumLatency penalties operations = { penalty PenaltyDefinition OperationDefinition[o1]("notify") { } 1..* OperationDefinition[o2](”subscribe") { } conditions } ServiceConditions ReliabilityClause failureModes = { conditions +maximumLatency reliability FailureModeDefinition[f1]() { +reliability kind = OPERATION; 1..* +window operations = {OperationDefinition[o1]} maximumLatency = ::types::Duration(5, S) InputThroughputClause } } inputThroughput +inputWindow } 1..* +concurrency See: http://www.sourceforge.net/slang 11 12 3
SLA in HUTN (cont’d) Further SLA syntax: Administration conditions = ServiceConditions[conditions]() { inputThroughput = { InputThroughputClause[iTC1]() { inputWindow = ::types::Duration(1, min) sLA 1..* admin 1..* SLA Administration Reconciliation Account inputConcurrency = 10 admin reconciliation agreed operation = {OperationDefinition[o1]} sLA admin } Evidence owner } reliability = { +date Party ReliabilityClause[rC1]() { evidence party party failureModes = {FailureModeDefinition[f1]} // When > 5 secs reliability = ::types::Percentage(0.9) ViolationCalculation Violation violation window = ::types::Duration(1, min) calculation penalties = { violator UnreliabilityPenaltyClause() { terms clientDefinition ServiceTerms ClientDefinition penalty = ::slang::PenaltyDefinition[p1] } serverDefinition ServerDefinition } } } } 13 14 Service observation domain model Semantics of input-throughput clause owner Party class InputThroughputClause { evidence 1..* invariant { ReportRecord Evidence conditions.sLA.admin->forAll( +sent 1..* report a : ::services::Administration | +date Report +received violationFirstUsage(a.reconciliation.agreed)->forAll( records first : ::services::es::ServiceUsageRecord | a.calculation.violation->one( report v : ::services::Violation | defectEvidence ServiceUsageRecord DefectReport v.violator = conditions.sLA.terms.clientDefinition.party +duration +defectKind operation and v.violatedClause = self OperationDefinition +outcome:Outcome measurement and v.penalty = penalty and v.evidence = DefectKind violationEvidence(a.reconciliation.agreed, first) Outcome +PARAMETER:int=1 ) +SUCEEDED:int=1 +OPERATION:int=2 ) +FAILED:int=2 +SERVICE:int=3 ) +NO_RESPONSE:int=3 +DATA:int=4 } +DATA_AGED:int=4 15 16 4
Reminder Generating SLA Monitors • SLAs machine readable SLA • MOF gives standard representation • Idea: Generate monitoring Purchase Purchase Server Client Request Request component from SLA Monitor Monitor Client Server • Given service observation data monitor decides whether actual service SLA level complies with SLA violations • Generator written using – Java Metadata Interface (Sun) – Eclipse Platform 17 18 Key idea Timed Automata • SLAs concern many timeliness constraints: • A time sequence is a sequence of real numbers � = � 1 � 2 … � n such that � i > � i-1 . – Latency • A timed word is a pair (w, � ) where w is a word of – Input and Output Throughput length n and t is a time sequence of length n – Reliability • Timed automata extend finite automata in the – Availability following way: • Events can be intercepted and time stamped without – They introduce a set of clocks changing web service requester and provider – They allow definition of time constraints over transitions • Monitors can be expressed using timed automata – They allow to reset clocks. • Detection of SLA violations reduces to acceptance of • Timed automata accept timed words and recognize timed languages. timed words that consist of timed events See: Alur & Dill, 1994: A Theory of Timed Automata. Theoretical Computer Science 126(2):183-253 19 20 5
Expressing Web Service Reliability Constraints On-line monitoring Architecture Timed SLA • Negate constraint (i.e. timed automaton accepts Automata timed word that indicates non-reliability) • In this example, no more than one failure occurrence (fm) per minute. SLA SLA Violation Monitor Evidence • Online monitoring per transition is efficient (constant interceptor in number of outgoing transitions per state). Client Provider See: F. Raimondi, J. Skene, W. Emmerich & B. Wozna: A Methodology for On-line Monitoring Non-Functional Requirements Specifications of Web Services. Proc. PROVECS Workshop at Tools Europe. Zurich. 2007. 21 22 Performance Summary SLA Purchase Purchase Server Client Request Request Monitor Monitor Client Server SLA violations 23 24 6
Ongoing Work • Integration of SLAs with Service Orchestrations: • Given: – SLAs with service providers – A BPEL orchestration • What SLA can be offered for the composite service? 25 7
Recommend
More recommend
