Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

A Distributed Transaction Model for Read-Write Linked Data Applications

62 vues

Publié le

Mihindukulasooriya, Nandana, Raúl García-Castro, and Asunción Gómez-Pérez. "A Distributed Transaction Model for Read-Write Linked Data Applications." In International Conference on Web Engineering, pp. 631-634. Springer International Publishing, 2015.

Publié dans : Technologie
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

A Distributed Transaction Model for Read-Write Linked Data Applications

  1. 1. A Distributed Transaction Model for Read-Write Linked Data Applications Nandana Mihindukulasooriya Supervised by: Raúl García Castro and Asunción Gómez-Pérez Ontology Engineering Group, Universidad Politécnica de Madrid, Spain {nmihindu, rgarcia, asun}@fi.upm.es Read-write Linked Data applications provide a novel alternative to application integration that helps breaking data silos by combining the Semantic Web technologies with the REST design principles. One drawback that hinders the adoption of this approach in enterprise systems is the lack of transactions support. Objective: Define a REST-compliant distributed transaction model for data-intensive read-write Linked Data applications • Linked Data / Semantic Web technologies bring several benefits to EAI by breaking data silos * Global identifiers and typed links (Linked Data) * Ease of merging data from sources (RDF) * Explicit semantics of data (OWL/RDFS) • Lack of support for quality-of-services hinders their adoption in enterprise systems • Common transaction scenarios • Composite Linked Data applications • Business workflows Our approach The key features of the proposed transaction model are: * Transactions as Linked Data resources * Transaction ontology and media types * Hypermedia-driven * Multi-version concurrency control * aligned with W3C LDP * Distributed transactions support Motivation Presenter Nandana Mihindukulasooriya @nandanamihindu / nmihindu@fi.upm.es State-of-the-art • RESTful transaction models * 8+ models in the literature * optimistic, pessimistic, and reservation models * few use cases are well-covered (TCC) • Challenges for the current models * Providing the strong consistency guarantees while adhering to the REST constraints (e.g., isolation vs statelessness) * Distributed transactions on the web * Create and delete operations * Fault handling References: [1] N. Mihindukulasooriya, M. Esteban-Gutierrez, and R. García-Castro. Seven challenges for RESTful transaction models. In Proceedings of the companion publication of the 23rd international conference on World wide web, pages 949–952, Seoul, South Korea, Apr 2014. [2] N. Mihindukulasooriya, R. García-Castro, and A. Gómez-Pérez. A Distributed Transaction Model for Read-Write Linked Data Applications. Engineering the Web in the Big Data Era. Springer International Publishing, 2015. 631-634. [3] N. Mihindukulasooriya, M. Esteban-Gutierrez, R. García-Castro, and A. Gómez-Pérez. A Survey of RESTful Transaction Models: One Model Does not Fit All. Accepted for the Journal of Web Engineering. Transaction ontology Transaction lifecycle dependsOn {transitive} Transaction ActiveTransaction status=Active Finished Transaction Lock SharedLock access=Shared Transactional Resource Transactional Container Persistent Provisional Resource state=Persistent Transient Provisional Resource state=Transient Transaction Manager Transaction Status Transaction Composition InFlightTransaction status={Committing, Aborting, Rollingback} Ongoing Transaction AccessType hasWorkingCopy {owl:InverseFunctionalProperty} ExclusiveLock access=Exclusive Provisional Resource access {owl:cardinality 1} exhaustive {owl:unionOf} disjoint {owl:disjointWith} disjoint {owl:disjointWith} exhaustive {owl:unionOf} disjoint {owl:disjointWith} exhaustive {owl:unionOf} disjoint {owl:disjointWith} status {owl:cardinality 1} exhaustive {owl:unionOf} hasParticipant {owl:InverseFunctionalProperty, owl:minQualifiedCardinality 1} participatesIn {owl:maxQualifiedCardinality 1} disjoint {owl:disjointWith} exhaustive {owl:unionOf} controlledBy {owl:cardinality 1} involves hasLock {owl:InverseFunctionalProperty} isWorkingCopyOf {copyFor ○ locks} locks {owl:InverseFunctionalProperty, owl:cardinality 1} contains {owl:InverseFunctionalProperty} manages {owl:InverseFunctionalProperty} Persistency State state {owl:cardinality 1} hasPersistentCopy {owl:cardinality1} hasTransientCopy hasNestedTransientCopy {hasWorkingCopy○hasDependant} RollbackFailed Transaction status=RollbackFailed Completed Transaction Committed Transaction status=Committed Rolledback Transaction status=Rolledback Aborted Transaction status=Aborted AbortFailed Transaction status=AbortFailed Failed Transaction exhaustive {owl:unionOf} disjoint {owl:disjointWith} disjoint {owl:disjointWith} exhaustive {owl:unionOf} On-going In-Flight Active Committing Aborting Rolling Back Committed Aborted Rolledback «new» «commit» «abort» «rollback» «complete» «complete» «complete» Completed «dispose» «dispose» «dispose» «enroll» POST TransactionManager POST Transaction/E DELETE Transaction DELETE Transaction DELETE Transaction POST Transaction/A POST Transaction/C Failed Rollback Failed Abort Failed «fail» «fail» Finished Protocol Overview