1 / 11

Isolation Support for Services-based Applications

Isolation Support for Services-based Applications. Paul Greenfield + Alan Fekete, Julian Jang, Dean Kuo & Surya Nepal. SOA & Isolation?. Applications composed from services Long duration multi-step activities Later steps depend on results of earlier ones

goodridge
Download Presentation

Isolation Support for Services-based Applications

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. Isolation Support for Services-based Applications Paul Greenfield +Alan Fekete, Julian Jang, Dean Kuo & Surya Nepal

  2. SOA & Isolation? • Applications composed from services • Long duration multi-step activities • Later steps depend on results of earlier ones • Concurrency & shared state can cause failures • ‘Isolation’ would simplify applications & improve robustness • Lock-based isolation not practical • Traditional locks assume timeliness and trust • Services are opaque and autonomous • Deadlocks, orphan locks, lock strength, …

  3. Promises Model • Promises are resource isolation agreements • Client application • Determines resources needed for completion • Sends promise requests to resource owners • Defined using predicates over abstract resources • Resource owner (promise manager) • Accepts or rejects promise requests • Checks resource availability • Promised resources must remain available to client • Concurrent activity cannot cause promise violations

  4. Promise Example • Client processing purchase order • Get promise(s) that stock is available • Get promise that funds are available • …. • Request delivery of goods, request payment • These steps ‘guaranteed’ to succeed… • Stock manager (promise granted) • Reserve requested goods for this client • Account manager (promise granted) • Set aside requested amount of money

  5. Promises • Abstraction of real-world techniques • Escrow, reservations, … • Accepted promises guarantee availability • Protected resources are ‘isolated’ • Multiple (non-conflicting) promises allowed • Promises valid for limited time only • Validity period agreed between participants • Promise requests are non-blocking • Clients can try alternatives, negotiate, …

  6. Predicates & Resources • Predicates are ‘Booleans’ over resources • From simple tuples to general queries • Defined by resource/promise manager/contract • Reflect client view of resources/requirements • Type of predicate depends on client needs • Resources are abstractions • Predicates refer to defined resource properties • Resources can be polymorphic over properties • Can defer mapping to concrete resources

  7. Examples • Predicates result in sets of resources • Some resources inherently anonymous • Ensure $500 available in account 123456 • Some predicates can (partially) specify keys • Reserve (room 505, Sydney Hilton, 6/1/2007) • Reserve (*, Sydney Hilton, 6/1/2006) • Flexibility through non-key properties • Reserve room with Sydney Harbour view on 31/12/07 • Conflicts between promises not allowed • Even though different views used in predicates

  8. Promises & Protocols • Promise requests sent to ‘promise manager’ • (Predicates, duration, previous promises) • Set of predicates for newly requested resources • Atomically get all requested resources or none • Can atomically return previous promises • SOAP integration via header elements • Promise request, response, environment • Piggyback requests/responses to app msgs • Attach promise environment to app requests • Atomically release promises with app request

  9. Implementations • Predicates & resources are abstractions • No architectural implementation implied • Promise manager role could be filled by… • Database, application or ‘promise manager’ • Many possible promise implementations • Resource pools, ‘allocated’ tags, satisfiability checks, tentative allocation, delegation, … • Just require that promises can always be met once they are granted…

  10. Proof-of-Concept Prototype • Stand-alone Promise Mgr • Intercepts all app requests • Simple predicates for named & anonymous resources • Using satisfiability model • Granted promises held entirely within PM table • Available state is PM + RM • Promises/RM consistency checked before granting & after app requests complete Promise+Action Response PM App Action Response RM

  11. Summary • Early allocation, non-blocking model • Clients can rely on earlier allocation steps • Abstract predicates & resources • Flexible formats & implementations • SOAP-based protocol possible • Simple proof-of-concept built & working • Much more work still to be done…

More Related