Few basic concepts of business process management are briefly described below.
A business process is typically a collection of related and structured activities or tasks, that depicts a business use case and produces a specific service or output. A process may have zero or more well-defined inputs and an output. During the execution of the business process, it executes its sub-processes synchronously or asynchronously for producing the final output. During the execution, it may interact with both humans or equipment.
For example, a banking customer requesting a bank loan is a simple process. The following diagram depicts this process and through that, explains some of the key workflow components of a typical business process.
Figure: Bank loan request process
Process Initiator: In the "Bank Loan Request" process, a banking customer is the client who initiates a loan request.
Well-Defined Input: Banking customer provides the inputs required for the initialization of the process. It may contain the personal details of the customer, his financial information and accounts etc.
Request Processing: This is typically a sub process that produces an output internally during the execution of the business process. It analyzes the input data, verifies loan eligibility of the client through the execution of several logical expressions etc.
Human Task: This is where a human interaction is involved in the business process. In this particular example, a bank employee sends an acknowledgement to the bank customer regarding his loan request approval.
Final Output: Sends acknowledgement. This is the final output which is sent back to the client who initiated the business process.
An instance of a process is a specific example of a process workflow. For example, if a particular process defines a banking customer requesting a bank loan, then an example instance of this process is Mr. Smith requesting for 50,000 USD and getting approval for it. Every time a banking customer makes a request for a loan, that request triggers a new process instance in the BPM system, which flows through the elements of the process workflow according to its design.
Business Process Execution Language (BPEL)
BPEL is the industry standard for business process orchestration. It is an XML-based language used for the definition and execution of business, as well as scientific workflows using Web services. In other words, BPEL is used to write business processes by composing Web services together with orchestration. The outcome is a composite Web service.
Although these business processes may interact with humans, the WS-BPEL standard does not specify human interactions. As a result, a business process defined by WS-BPEL alone can not have human interactions but only with Web services. The WSO2 BPS facilitates defining and using human tasks in business processes.
Orchestration Vs. Choreography
Web services can be composed using two approaches: orchestration and choreography. In orchestration, there is a central director to coordinate the services. In contrast, choreography contains no central director and each contributing service should have an understanding of participant services.
For composing Web services for a business process, orchestration is a better option for reasons such as simpler process management, loose-coupling between participating Web services, ease in error handling, standardization etc.
Abstract and Executable Processes
Based on the definition of the actual behavior required by a business process, it can design in two ways using WS-BPEL: abstract and executable. Abstract processes are intended to hide some operational details of the process. As a result, they do not include executable details like process flows. Executable business processes are used to model the actual implementation of the business process.
An abstract process is denoted under the "http://docs.oasis-open.org/wsbpel/2.0/process/abstract" namespace and an executable process is denoted under the "http://docs.oasis-open.org/wsbpel/2.0/process/executable". Additionally, there are syntactical differences between an abstract and an executable BPEL process.
Asynchronous and Synchronous Communication
BPEL processes can also be categorized based on how it invokes an operation of a partner service: synchronous and asynchronous. It is not possible to use both methods when invoking a partner service's operation, as it is dependent on the type of the partner service operation also.
Asynchronous transmission - Assume a BPEL process invokes a partner service. After the invokation of the partner process, the BPEL process continues to carry on with its execution process while that partner service completes performing its operation. The BPEL process then receives a response from the partner service, when the partner service is completed.
Synchronous transmission - Assume a BPEL process invokes a partner service. The BPEL process then waits for the partner service's operation to be completed, and responded. After receiving this completion response from the partner service, the BPEL process continues to carry on its execution flow. This transmission is not applicable to the In-Only operations defined in the WSDL of the partner service.
Usually asynchronous services are used for long-lasting operations and synchronous services for operations that return a result in a relatively short time. Typically, when asynchronous Web services are used, the BPEL process is asynchronous.
In addition to the above terms, the following article in WSO2 Oxygen Tank explains how to deploy a sample service and a BPEL process, establish a link with a Web service, invoke the process from a client, along with related topics to better understand how the WSO2 BPS works overall: http://wso2.org/library/articles/writing-simple-ws-bpel-process-wso2-bps-apache-ode.