Some of the common implementation types of business process that can be implemented using WPS include:
Navigational flow and data aggregation is controlled from a user interface layer rather than in a BPEL process in WPS.
WPS not involved in process navigation, but may be used to provide swiftly-responding synchronous services.
Use for cases where a GUI application performs the process orchestration or control.
Synchronous transactional process:
A slight extension to the GUI intensive process type. A collection of short-running BPEL processes provide real-time responses to graphical user interfaces or for transactional sub-processes.
Transactional and therefore must complete within the global timeout. No state is persisted by the process.
Errors are typically translated for clarity and then passed back to the caller.
Use for cases when you need high performance and the caller needs a response immediately.
Asynchronously initiated transactional process:
Caller transaction is minimal and just makes a request but does not wait for a response. Process is assured to occur at a later time in a separate transaction.
The caller seeks feedback through notifications or e-mail.
Error handling more complex than a simple synchronous transactional process, since the caller is no longer present to take action.
Used for cases when you need high performance and a caller does not need a response immediately, but only an acknowledgement.
A special use of a long-running process where the process completes relatively swiftly. Process lifespan is deliberately short (seconds, maybe minutes), such that process versioning issues can be avoided.
The process must be designed to complete in a timely fashion, so no human tasks are allowed and error handling actions should be passed and pushed out of the process (may not receive in-process events).
Allows parallel processing, so good for aggregation. This is one of the most common motivations for this usage type.
Careful thought must be put to the the error handling implications of this multi-transactional scenario.
A synchronous transactional process is always preferable, if at all possible. For briefly persisted processes, persistence adds a significant overhead and the error handling is much more complex.
Used for cases where the process will take a long time (more than the runtime transaction timeout) and a process instance can be flushed through to enable simple maintenance.
It is a true long-running process that will last a relatively long time (days, weeks, and so on). Process instances will always be present in the systems such that the complex issues of process versioning must be taken into account.
Can contain human tasks and complex error handling such as compensation.
May receive in-process events which need to contain sufficient information to be correlated with the existing process instance.
Invocation typically does not provide a response and late-binding techniques need to be well understood.
Activities can be set to wait for manual intervention on error.
Use for cases where the process will take a long time (more than the runtime transaction timeout) and process contains external system interactions.
Used to balance multiple tasks between a number of different users, possibly in different teams/departments.
Necessitates long-lived processes, and hence must consider process versioning issues.
Allows progressive automation of tasks.
This is a very broad category still and can be broken into four sub-types:
Used for cases where the process will take a long time (more than the runtime transaction timeout) and contains human interactions.