Transactional workflow
Download as PPTX, PDF1 like1,505 views
This document discusses transactional workflows from both a conceptual and language perspective. Conceptually, transactional workflows can be modeled either as separate transaction and workflow models combined, or as a single integrated transactional workflow model. From a language perspective, transactional workflows can be specified using separate transaction definition and workflow definition languages, or an integrated transactional workflow definition language. The document outlines different approaches to relating these models and languages and the advantages of using transactional workflows.
Transactional workflow
- 1. Transactional Workflow By: Pranjal Bhumij
- 2. Contents: • Introduction. • The Conceptual Perspective. • The Language Perspective.
- 3. The Workflow • An orchestrated and repeated pattern of activities. Which enables a systematic organization of resources and performs these following actions with it: 1. Transform materials 2. Provide services 3. Process Information
- 4. The transaction management, already used for several decades in the database world, have been combined with workflow to satisfy these requirements(clear process semantics and robustness in process execution). The Transaction
- 5. • To support transactional workflows, there are two basic approaches: either transactional aspects and workflow aspects are treated as separate issues, or they are seen as one integrated issue.
- 6. • In the former case, separate transaction and workflow models exist that are combined to obtain transactional workflows. • In the latter case, one single transactional workflow model is used. • In the situation where we have separate workflow and transaction models, • we need to relate these two models. We have three possible basic relations, (PERSONAL)
- 7. • Workflows over transactions (WF/TR): workflows are more abstract than transactions, i.e., transaction models are used to provide semantics to workflow models. • Transactions over workflows (TR/WF): transactions are more abstract than workflows, i.e., workflow models are used to provide process structure to transaction models. • Transactions and workflows as peers (TR+WF): workflow and transaction models exist at the same abstraction level, i.e., workflow and transaction models can be seen as two sub-models of an implicit, loosely coupled process model.
- 8. • Three main variants with respect to the nature of the single model: • Hybrid transactional workflow model (TRWF): a single hybrid model is used that contains both transaction and workflow concepts. • Transactions in workflows (WF): A single workflow model is used, in which transactional aspects are mapped to workflow primitives. • Workflows in transactions (TR): A single transaction model is used, in which workflow aspects are mapped to transaction primitives.
- 10. The language perspective • In the conceptual point of view, we are interested in the conceptual specification of transactional workflows. For this specification, we use one or more specification languages. Given the two main classes in the taxonomy of Figure 1, we can have two situations: • There is a separate language for specifying workflow aspects, the workflow definition language (WFDL), and a separate language for specifying transaction aspects, the transaction definition language (TRDL). • There is an integrated language for specifying both workflow and transaction aspects, the transactional workflow definition language (TRWFDL).
- 11. • If we have two languages, the languages can have two relations: either one language is a refinement of the other, or the two languages are orthogonal with respect to another.
- 12. • If the TRDL is a refinement of the WFDL, the WFDL level contains workflow attributes and the intermediate states at the TRDL level are related to transaction states. If the WFDL is a refinement of the TRDL, the TRDL level contains transactional attributes and the intermediate states at the WFDL level are related to control flow states.
- 13. • In the integrated approach, all aspects are merged into a single language. This language covers a state space that is the cross product of the two state spaces discussed above
- 14. Advantages • Ensure failure handling. • Event Log. • Control Flow Mining.
- 15. Conclusion • Workflow • Transaction • Transaction Workflow • The Conceptual Perspective • The Language Perspective • Advantages.