Abstract: A transaction management engine, such as a business process management (BPM) engine, can allow an application to define transaction demarcations in order to ensure that portions of a workflow are processed atomically. In one such system, a JMS message is queued to the workflow as part of an existing transaction. If that transaction commits, the queued JMS message ensures that the workflow will be invoked in a new transaction that allows the workflow to perform the next unit of work in the newly initiated transaction. When the unit of work is completed, the workflow queues another JMS message. If this transaction commits, the transaction ensures the unit of work has executed in a transaction. When the workflow is invoked again due to the second JMS message, the workflow can continue its operation in a different transaction.

Abstract: An easy-to-use workflow language can be created by extending an existing, common language such as Java. The language can be extended by adding those constructs that are missing but desirable. Such desirable constructs can include parallelism, asynchrony, loops over asynchronous events, and flexible handling of XML. Such constructs can allow a user to define a virtual program using the extended Java syntax. For example, XML can be placed inside a Java class that defines the high-level orchestration logic a workflow should follow. That orchestration logic can refer to the Java class to carry out work, such that the logic to handle an incoming message is really in Java. This description is not intended to be a complete description of, or limit the scope of, the invention. Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

Abstract: A transaction management engine, such as a business process management (BPM) engine, can allow an application to define transaction demarcations in order to ensure that portions of a workflow are processed atomically. In one such system, a JMS message is queued to the workflow as part of an existing transaction. If that transaction commits, the queued JMS message ensures that the workflow will be invoked in a new transaction that allows the workflow to perform the next unit of work in the newly initiated transaction. When the unit of work is completed, the workflow queues another JMS message. If this transaction commits, the transaction ensures the unit of work has executed in a transaction. When the workflow is invoked again due to the second JMS message, the workflow can continue its operation in a different transaction.