coordination in service oriented architectures using transaction processing concepts n.
Download
Skip this Video
Download Presentation
Coordination in Service Oriented Architectures Using Transaction Processing Concepts

Loading in 2 Seconds...

play fullscreen
1 / 18

Coordination in Service Oriented Architectures Using Transaction Processing Concepts - PowerPoint PPT Presentation


  • 142 Views
  • Uploaded on

Coordination in Service Oriented Architectures Using Transaction Processing Concepts. 18th International Workshop on Database and Expert Systems Applications(2007) Peter Hrastnik. 報告人 : 69721057 李玠峰. Outline. Introduction Related Work

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Coordination in Service Oriented Architectures Using Transaction Processing Concepts' - mae


Download Now 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
coordination in service oriented architectures using transaction processing concepts

Coordination in Service Oriented Architectures UsingTransaction Processing Concepts

18th International Workshop on Database and Expert Systems Applications(2007)Peter Hrastnik

報告人:69721057 李玠峰

outline
Outline
  • Introduction
  • Related Work
  • Fundamental Requirements for an SOA Transaction Processing System
  • Approach
  • Prototype
  • Conclusion
acid characteristics
ACID characteristics
  • Atomicity
  • Consistency
  • Isolation
  • Durability
transaction processing systems
Transaction Processing Systems
  • Basic business systems that serve the operational level
  • A computerized system that performs and records the daily routine transactions necessary to the conduct of the business
  • The group of services achieves a coordinated common, consistent, and mutually agreed outcome.
related work
Related Work
  • Advanced transaction models (ATMs)

try to relax ACID style transactionlogic because its rigiddemandsarenotappropriate for severalapplication areas.

  • nested transaction, multilevel transactions, ACTC, TWSO (Transactional Web Service Orchestrations) …etc.
advanced transaction logic
Advanced Transaction Logic
  • Two aspects of ACID transaction logics are problematic in SOAs.

Atomicity

Isolation

  • An SOA transaction processing system must support ATMs.
arbitrary advanced transaction logic
Arbitrary Advanced Transaction Logic
  • Business Transaction Protocol :WS–TX family and WS–CAF.
  • Components have to be updated in order to be aware of such new communication protocols.
  • Service coordination using transaction processing concepts in SOAs would need the possibility to employ arbitrary transaction logic.
transaction primitives
transaction primitives
  • begin starts a transaction.
  • In case the outcome of the associated service–activities of a transaction is considered to be successful, the transaction is terminated with a commit.
  • When the outcome of the service–activities is considered to be erroneous,

abort cancels a transaction.

compensate transaction primitive
compensate transaction primitive
  • Compensation is used to perform some forward actions that neutralize the already persisted changes.
  • After compensation, it is visible that the original service–activities took place.
  • In business terms, compensation resembles the “cancellation” concept.
approach
Approach
  • To orchestrate transactions efficiently, transaction dependencies are used.
  • Such a transaction dependency consists

of a source state and an effect.

  • No system update is necessary to incorporate new transaction logic.
approach1
Approach
  • The service assembly combines a group of services using some process logic.
  • It sets up transaction dependencies and controls transactions by issuing transaction primitives on transactions.
  • All these transaction-related matters are carried out by the transaction monitor.
approach2
Approach
  • Not only the commit primitive but also others, like compensate, may be synchronized using the two phase commit protocol for achieving an atomic outcome.
  • Finally, the transaction monitor keeps track of transaction dependencies and executes dependency effects when a corresponding state emerges.
approach3
Approach
  • The transaction monitor receives transaction primitives and forwards

to affected services.

  • When a transaction involves more than one service–activity, the transaction monitor executes synchronization protocols in order to assure a consistent outcome.
approach4
Approach
  • According to these transaction-related matters, the transaction monitor sends appropriate transaction primitives to affected services.
  • These services have to fulfill certain requirements.
  • A service has to implement the transaction primitives and synchronization protocols that are stated in the service contract.
prototype
Prototype
  • Service assemblies are expressed using Java. Setting up transaction dependencies and issuing transaction primitives is a matter of using API calls.
  • The transaction monitor is implemented as

a SOAP Web service.

  • SOAP handles communication in the system, including transaction-related matters like transaction primitives or synchronization protocol commands.
prototype1
Prototype
  • Services are implemented as SOAP Web services and receive transaction

primitives and synchronization protocol commands through an extra SOAP interface.

  • Transaction-related capabilities of services are expressed using WSDL and may be obtained through an API by concerned components like the assembly or the transaction monitor.
conclusion
Conclusion
  • In contrast to prominent proposals for Web service transactions, the presented

approach inherently supports the use of arbitrary advanced transaction logic.

  • This working implementation can be used for experimenting with transaction processing in

SOAs.

  • Future work will focus mainly on the improvement of the prototype to achieve production quality in order to employ it in real life SOAs.