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 | ||||
---|---|---|---|---|---|
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) |
Competencies
References
- [Rotem-Gal-Oz, 2008] Arnon Rotem-Gal-Oz, SOA Patterns: Basic Structural Patterns – Part 2: The Transactional Service Pattern, 2008. Last accessed 25.Aril 2012.