1 / 18

Coordination in Service Oriented Architectures Using Transaction Processing Concepts

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

mae
Download Presentation

Coordination in Service Oriented Architectures Using Transaction Processing Concepts

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. Coordination in Service Oriented Architectures UsingTransaction Processing Concepts 18th International Workshop on Database and Expert Systems Applications(2007)Peter Hrastnik 報告人:69721057 李玠峰

  2. Outline • Introduction • Related Work • Fundamental Requirements for an SOA Transaction Processing System • Approach • Prototype • Conclusion

  3. ACID characteristics • Atomicity • Consistency • Isolation • Durability

  4. 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.

  5. 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.

  6. Advanced Transaction Logic • Two aspects of ACID transaction logics are problematic in SOAs. Atomicity Isolation • An SOA transaction processing system must support ATMs.

  7. 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.

  8. 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.

  9. 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.

  10. 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.

  11. Architecture of an SOA transactionprocessing system

  12. 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.

  13. 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.

  14. 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.

  15. 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.

  16. 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.

  17. 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.

  18. 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.

More Related