1 / 75

Advanced Web Service Transactions Management

Advanced Web Service Transactions Management. Peter Dolog dolog@cs.aau.dk CS Department Intelligent Web Information Systems http://www.cs.aau.dk , http://iwis.cs.aau.dk. Outline. Compensations Design General problem Business transactions Middleware for advanced compensations

gwyn
Download Presentation

Advanced Web Service Transactions Management

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. Advanced Web Service Transactions Management Peter Dolog dolog@cs.aau.dk CS Department Intelligent Web Information Systems http://www.cs.aau.dk, http://iwis.cs.aau.dk

  2. Outline • Compensations Design • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges • Distributed Transactions and Waiting Cycles • Motivation • Related Work • Transaction Dependencies Management • Protocol • Cycle Detection • Experiments • Conclusions and Further Work Web Engineering, Lecture 14, Advanced Transactions Management

  3. Outline • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  4. Open Web Service Environment • Service Providers • A number of autonomous service providers exist • They can provide similar functionality • They can dis-/appear any time • Each wants to maximize its profit for executing provided services by external consumers • Service Consumers • Number of consumers with similar requirements exist • They want to achieve high value for their expense • To maximize their service • By composing matched available services from different providers Web Engineering, Lecture 14, Advanced Transactions Management

  5. Software Product Lines • Software Providers • Number of reusable software assets exist • They may vary in its functionality • They want to maximize its profit by providing the assets in an application in a family mostly from one company • Software Consumers • Number of consumers with similar requirements • They want to achieve high value for their expense • To maximize their service • By composing a final application from the reusable assets Web Engineering, Lecture 14, Advanced Transactions Management

  6. Feature Modelling as a Technique in Software Product Lines Web Engineering, Lecture 14, Advanced Transactions Management

  7. Outline • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  8. Payroll Scenario Company Employee Print and mail payslip Wait for payment Transfer monthly instalment for the new car Print and send payslip Transfer salary Transfer tax Transfer tax Transfer car instalment Transfer salary Bank Web Engineering, Lecture 14, Advanced Transactions Management

  9. Service Oriented Payroll Scenario Company Employee Print and mail payslip Transfer tax Transfer car instalment Transfer salary Bank To reach mutually-agreed outcome (commit/cancel) In environment with concurrent access Web Engineering, Lecture 14, Advanced Transactions Management

  10. Transactions • Control the execution of the required operations on the external services. • Consist of a set of operations (e.g. database operations) that are performed by multiple participants. • Control the collective outcome of the operations. • Distributed transactions control the execution of operations on multiple providers. • Participant • Coordinator Web Engineering, Lecture 14, Advanced Transactions Management

  11. Error Compensation Different transaction specifications exist for different purposes • Backward recoveryNormally, predefined rollback operations are executed in order to restore the state before the transaction. • Time and money is lost • Dependent transactions also have to roll back (domino effect) • Forward recoveryAims at changing pro-actively the state of the participant or transaction to enable a successful execution after a failure. • Complex • Can normally only be performed semi-automatically Web Engineering, Lecture 14, Advanced Transactions Management

  12. Traditional WS-Transaction Coordin. Structure 1. Create new transaction Normal request processing Request failure handling 2. Return coordination context 3. Invoke service, send coordination context 7. Send request result 8. Abort transaction 4. Register with coordination context 7. Send failure notification 5. Confirm registration 6. Process request → Failure Web Engineering, Lecture 14, Advanced Transactions Management

  13. T1 WS1 WS4 WS2 WS3 WS – Tx / Business Activity Coordination Type C abstract state diagram Web Engineering, Lecture 14, Advanced Transactions Management

  14. Payroll Processing Transfer instalment to the car dealer‘s account 3. Specify the salary details, print and send the payslip 1. Transfer of the salary to the employee‘s account 2. Transfer of the tax to the tax authority‘s account … Transaction Web Engineering, Lecture 14, Advanced Transactions Management

  15. Motivating Scenario – Problem … Transaction • A service fails due to an internal error. • The error can only be compensated by aborting the complete transaction. Why should the transaction be aborted, if a different service exists that can perform the same operations? Web Engineering, Lecture 14, Advanced Transactions Management

  16. Outline • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  17. Extended Transaction Coordination Structure 1. Create new transaction 2. Return coordination context 13. Send request result 3. Invoke abstract service, send coordination context 5. Register with coordination context 4. Request adapter context 7. Return adapter context 6. Confirm registration 8. Invoke concrete service, send adapter context 12. Send request result 10. Confirm registration 9. Register with adapter context 11. Process request Web Engineering, Lecture 14, Advanced Transactions Management

  18. New Components - Abstract Service • Does not directly implement functionalities. • Manages a list of concrete services. • Is a mediator between the client and the concrete service. • Manages and performs compensation actions. • Interfaces: • Service • Event (internal compensation handling) • Compensation (external compensation handling) • Contract exchange Web Engineering, Lecture 14, Advanced Transactions Management

  19. Compensation Activities and Types Web Engineering, Lecture 14, Advanced Transactions Management

  20. Example: Internal Compensation Rule • <cmp:InternalCompensationRule identifier="internalFailureLastRequestResending"> • <cmp:CompensationCondition> • <cmp:ParticipantEvent eventCode= "http://sourceforge.net/projects/frogs/AdapterInteraction/ParticipantFault"/> • <cmp:ParticipantState • stateType='http://schemas.xmlsoap.org/ws/2004/10/wsba/Faulting' /> • <cmp:ReplacementService exists="true" isDirectReplacement="true" /> • <cmp:RequestSequence> • <cmp:Request identifier="transferSalaryMethod" /> • </cmp:RequestSequence> • </cmp:CompensationCondition> • <cmp:CompensationPlan> • <cmp:Compensation> • <cmp:ServiceReplacement/> • </cmp:Compensation> • <cmp:Compensation> • <cmp:RequestResending lastN="1" /> • </cmp:Compensation> • </cmp:CompensationPlan> • </cmp:InternalCompensationRule> The condition of the compensation rule Condition 1: The internal event must have been a failure of the concrete service Condition 2: The state in which the concrete service has to be Condition 3: A direct replacement concrete service has to exist Condition 4: The last request must have called this method The execution plan of the compensation rule Step 1: Replace the current concrete service Step 2: Resend the last request Web Engineering, Lecture 14, Advanced Transactions Management

  21. New Components - Adapter • Encapsulates coordinator-specific functionality. • Functions as a coordinator for the concrete service. • Manages messaging: • Forwards normal messages between the real coordinator and the concrete service. • Intercepts failure messages and informs the abstract service. • Creates additional notifications as part of a compensation process. Web Engineering, Lecture 14, Advanced Transactions Management

  22. Internal Compensation Handling – No Action 15. Forward failure notification 14. Fail 16. Abort transaction 13. Report event • Concrete service fails. • Abstract service checks its compensation rules and contract. • Compensation is not possible. Normal transaction abort. 12. Signal failure 11. Process request Web Engineering, Lecture 14, Advanced Transactions Management

  23. Internal Compensation Handling – Replacement 21. Send request result 14. Forget participant 13. Report event • Concrete service fails. • Abstract service checks its compensation rules and contract. • Concrete service is replaced. Coordinator was not notified! 16. Resend request 20. Send request result 17. Register with adapter context 12. Signal failure 15. Confirm failure 18. Confirm registration 11. Process request 19. Process request Web Engineering, Lecture 14, Advanced Transactions Management

  24. Evaluation • Multiple scenarios for internal and external compensation handling have been implemented and tested. • An evaluation model has been created, which calculates net values for the standard environment and the abstract service environment. • Allows an assessment whether the utilization of the new design is economical and beneficial. Experiment performed on a simalated environment More in ACM TWEB paper Web Engineering, Lecture 14, Advanced Transactions Management

  25. Outline • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  26. Compensation Types Web Engineering, Lecture 14, Advanced Transactions Management

  27. Compensation Features Web Engineering, Lecture 14, Advanced Transactions Management

  28. Capability Feature Model • Consists of: • functionality feature model • compensation feature model • The compensation feature model can contain custom features. Web Engineering, Lecture 14, Advanced Transactions Management

  29. Service Capabilities Web Engineering, Lecture 14, Advanced Transactions Management

  30. Consumer Requirements Web Engineering, Lecture 14, Advanced Transactions Management

  31. Outline • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  32. Matchmaking between service and consumer feature models • Compatibility score calculation • Iteratively compares feature models • Features must appear at the same place in the graph • Mandatory features must all match but do not contribute to the compatibility score • If a mismatch is found in a mandatory feature, algorithm stops and a negative score is returned • Optional features add to the compatibility score when a match is found (in our case +1) • Additional features may contribute with different scores Web Engineering, Lecture 14, Advanced Transactions Management

  33. Restriction Feature Model Web Engineering, Lecture 14, Advanced Transactions Management

  34. Example: Internal Compensation Rule • <cmp:InternalCompensationRule identifier="internalFailureLastRequestResending"> • <cmp:CompensationCondition> • <cmp:ParticipantEvent eventCode= "http://sourceforge.net/projects/frogs/AdapterInteraction/ParticipantFault"/> • <cmp:ParticipantState • stateType='http://schemas.xmlsoap.org/ws/2004/10/wsba/Faulting' /> • <cmp:ReplacementService exists="true" isDirectReplacement="true" /> • <cmp:RequestSequence> • <cmp:Request identifier="transferSalaryMethod" /> • </cmp:RequestSequence> • </cmp:CompensationCondition> • <cmp:CompensationPlan> • <cmp:Compensation> • <cmp:ServiceReplacement/> • </cmp:Compensation> • <cmp:Compensation> • <cmp:RequestResending lastN="1" /> • </cmp:Compensation> • </cmp:CompensationPlan> • </cmp:InternalCompensationRule> Web Engineering, Lecture 14, Advanced Transactions Management

  35. Feature Model • <feature name="Compensation" type="NONE" id="compensation"> • <feature name="InternalCompensationHandling" type="NONE” id="internalCompensationHandling"> • … • <feature name="PartialRequestRepetition" type="NONE" id="reference3IXIpartialRequestRepetition"> • <feature name="ResultResending" type="NONE" id="reference3IXIreferenceIXIresultResending"> • </feature> • </feature> • </feature> • <feature name="Replacement" type="NONE" id="replacement"> • <feature name="LastRequestRepetition" type="NONE" id="reference4IXIlastRequestRepetition"> • </feature> • <feature name="PartialRequestRepetition" type="NONE" id="reference5IXIpartialRequestRepetition"> • <feature name="ResultResending" type="NONE" id="reference5IXIreferenceIXIresultResending"> • </feature> • </feature> • <feature name="AllRequestRepetition" type="NONE" id="reference6IXIallRequestRepetition"> • <feature name="ResultResending" type="NONE" id="reference6IXIreferenceIXIresultResending"> • </feature> • </feature> • </feature> • </feature> • … • </feature> Web Engineering, Lecture 14, Advanced Transactions Management

  36. Layers of Abstraction Navigation and Interaction Restriction Profiles Capability and Compensation Features and Configurations Capability and Compensation Concepts Physical Services and Workflow Variants xor and xor Web Engineering, Lecture 14, Advanced Transactions Management

  37. Outline • IWIS group and background • General problem • Business transactions • Middleware for advanced compensations • Service provider and client feature modelling • Matchmaking and restriction model • Further Challenges Web Engineering, Lecture 14, Advanced Transactions Management

  38. Workflows vs. Middleware • Compensations and adaptations can be specified at the design level in workflows • Copensations and adaptations can be encoded in an intelligent middleware • How to combine them • How to compose them • How to ensure consistency • … Web Engineering, Lecture 14, Advanced Transactions Management

  39. References • M. Schäfer and P. Dolog: Feature-Based Engineering of Compensations in Web Service Environment. ICWE 2009: 197-204 • M. Schäfer, P. Dolog, W. Nejdl: An Environment for Flexible Advanced Compensations of Web Service Transactions. ACM TWEB, 2(2), 2008 • P. Dolog, W. Nejdl: Using UML-based feature models and UML collaboration diagrams to information modelling for web-based applications. UML 2004. Web Engineering, Lecture 14, Advanced Transactions Management

  40. Distributed coordination of concurrent transactions Web Engineering, Lecture 14, Advanced Transactions Management

  41. Outline • Motivation • Related Work • Transaction Dependencies Management • Protocol • Cycle Detection • Experiments • Conclusions and Further Work Web Engineering, Lecture 14, Advanced Transactions Management

  42. Loosly coupled Long-running With user interaction Business Activity WS2 WS3 WS1 WS4 • WS1: Conference • WS1: Flight Ticket • WS3: Hotel Room • WS4: Car rental Web Engineering, Lecture 14, Advanced Transactions Management

  43. WS1: Conference WS1: Flight Ticket WS3: Hotel Room WS4: Car rental To reach mutually-agreed outcome (commit/cancel) Transactional Business Activity T1 Transactionas Business Activity WS2 WS3 WS1 WS4 Web Engineering, Lecture 14, Advanced Transactions Management

  44. WS1: Conference WS1: Flight Ticket WS3: Hotel Room WS4: Car rental To reach mutually-agreed outcome (commit/cancel) In environemnt with concurrent acces Transactional Business Activity T2 WS2T2 WS3T2 T1 Transactional Business Activity WS3T2 WS2 WS3 WS1 WS4T2 WS4 Web Engineering, Lecture 14, Advanced Transactions Management

  45. ACID Properties Relaxation • Current Standards and Open Specifications: • Atomicity Relaxation • Allow partial sets of participants to commit or abort (e.g. without having some services complete succesfully) • Isolation Relaxation • Allow concurrent users to observe partial results (e.g. after having some services executed, temporal results comming from their execution may be shown) Web Engineering, Lecture 14, Advanced Transactions Management

  46. Existing Open Specifications • WS-Coordination/WS-Transaction (IBM, Microsoft, and BEA …) • OASIS Business Transaction Protocol (HP, Oracle) • … • All support coordination activation, participant registration, transaction context • Protocols with limited abilities for concurrency under relaxed ACID properties Web Engineering, Lecture 14, Advanced Transactions Management

  47. T1 WS1 WS4 WS2 WS3 WS – Tx / Business Activity Coordination Type C abstract state diagram Web Engineering, Lecture 14, Advanced Transactions Management

  48. T1 WS1 WS4 WS2 WS3 WS – Tx / Business Activity Coordination Type C • Standards do not prescribe how to handle conflicts in concurent access • It is all a matter of compensation which is considered part of a business logic • We propose an approach where concurency control is part of the protocol based on completion dependency graph and cycle detection as a new coordination type abstract state diagram Web Engineering, Lecture 14, Advanced Transactions Management

  49. Completion Dependency Graphs • Within a transaction: two operations in conflict • Between transactions: • Assuming that T1 and T2 are two different transactions, a Completion Dependency T1 T2 occurs if there are two Web Service operations O1 and O2 (possibly from different Web Services) where O1 belongs to T1 and O2 belongs to T2 and: • O1 reads data updated by O2 • O2 still may compensate (roll-back is a special case of compensation) • T1 is called: dependent transaction • T2 is called: dominant transaction Web Engineering, Lecture 14, Advanced Transactions Management

  50. T2 T1 Concurrency Control for WS T1 T2 WS4 WS2 WS4 • Maintain an operation conflict matrix • Keep track of invocations • Recognize completion dependencies • Do not commit before dominant and cycle is resolved WS3 WS2 WS1 WS6 WS3 WS1 WS6 WS3 WS4 WS2 P1 P2 Web Engineering, Lecture 14, Advanced Transactions Management

More Related