Coordination in service oriented architectures using transaction processing concepts
Download
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


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.


ad