Transactional Service Pattern

by Dragan Ivanovic — last modified Apr 26, 2012 08:57

— filed under: KnowledgeModel

Definitions

Term: Transactional Service Pattern		Domain: Cross-cutting issues
Term: Transactional Service Pattern		Engineering and Design (KM-ED)	Adaptation and Monitoring (KM-AM)	Quality Definition, Negotiation and Assurance (KM-QA)	Generic (domain independent)
D o m a i n : L a y e r s	Business Process Management (KM-BPM)
	Service Composition and Coordination (KM-SC)				Describes how interaction between services should be realized to guarantee transactional properties. Implementing a Transactional Service can be easy if the message transport is transaction aware. Examples for transaction-aware infrastructure can be found in most ESBs such as Sonic ESB and Iona Artix, and also in messaging middleware like MSMQ, any JMS implementation, or SQL Server Service Broker. If you are using a transactional message transport, you can implement the Transactional Service Pattern by just creating a transaction on that resource. You may need to make the transaction distributed if, for example, you also perform database updates within the same unit of work. Then you just read a message from the ESB or messaging middleware, process it, send reactions or other messages generated by the process to outgoing or destination queues, and commit the transaction, if everything was successful [Rotem-Gal-Oz, 2008].
	Service Infrastructure (KM-SI)
	Generic (domain independent)