(For more resources related to this topic, see here.)
Inter-process communication refers to the ability for instances of processes to communicate—with other instances of the same process, with instances of other processes, and with services. Such communication is usually implemented so that process instances can work collaboratively to achieve a given goal. Common scenarios when this may occur include:
When common logic is extracted from a number of processes into a reusable "utility" process
When the occurrence of an event in one process means that another, perhaps separate, process needs to be started—this is often seen where the second process is an audit or investigation process
Where a process has a set of data, needs to run a common set of logic over each item in that data set, and then consolidate the results
Through normal decomposition of a business process into various levels of granularity, resulting in the need for the process to invoke one or more sub-processes to accomplish its work
There are different mechanisms available for processes to communicate with each other. In this article, we will explore the options and when we should employ each.
A conversation is a set of message exchanges. The message exchanges can be synchronous or asynchronous, but they should all be about the same subject matter, for example, a particular order, customer, case, and so on. The set of messages that forms the conversation is typically a request and a response, or a request and several (possible) responses.
A single process instance can participate in more than one conversation simultaneously.
The collaboration diagram allows you to visualize the process in the context of its conversations. You can access the collaboration diagram using the Collaboration Diagram tab at the bottom of the process editor in JDeveloper. An example of a collaboration diagram is shown in the following diagram:
This example includes a number of features that will be discussed in this book. The small, disconnected process that begins with Order Over Limit is an event sub-process. Briefly, they are invoked if a particular event (set of circumstances) occurs at any time during the execution of the process they belong to, the ProcessOrder process in this example. If at any time it is determined that the order is over some predefined limit, then an audit is required. The event sub-process sends a message to start the Audit process using a throw message event. The collaboration diagram allows us to see both of the processes that are involved in this collaboration and shows us visually where the interaction between them occurs (with the dotted arrow from the throw message event to the start of the Audit process).
Conversations may also be scoped; this means that they may be defined in a smaller scope than the process as a whole. For example, you can define a conversation inside an embedded sub-process. To define a scoped conversation, you must do so in the Structure pane so that the conversation is placed in the correct scope. If you do not define the conversation in the Structure pane, it will inherit the process scope. The following image shows a process with two conversations defined: myconv1 at the process (global) scope, and the scoped conversation scopeConv, which is inside an embedded sub-process:
In addition to defining conversations for communication with other processes, each service that you want to interact with will also require a conversation. When implementing your process, you need to create a conversation for each service, choose Service Call as the type, and then select the service you wish to interact with.
The default conversation
Each process has a default conversation. The default conversation is used to expose services provided by the process, and it therefore controls the interface for invocation of the process. This interface manifests itself as the WSDL port type.
The default conversation can be defined "top down" by starting with WSDL (service contract) for the process and creating the conversation from that, or "bottom up" by defining the arguments for the process and having the service interface (WSDL) generated from the process.
If we are using the bottom-up approach, the interface is defined by adding arguments to the start node, as shown in the following screenshot. You need to select Define Interface as the message exchange type to use the bottom-up approach. The arguments can have simple types (String, Date, Integer, and so on) or complex types, that is, they can be based on the business object (which in turn can be based on an element or type definition in an XSD).
Correlation is the mechanism that is used to associate a message with the conversation that it belongs to. There are two main classes of correlation:
Automatic correlation refers to mechanisms where the correlation is handled automatically. BPM uses mechanisms like WS-Addressing and JMS Message IDs to achieve automatic correlation.
Message-based correlation refers to the mechanism the process developer needs to define some keys, which can be extracted from the message in order to determine which conversation a message belongs to. Examples are given in the next section.
There are some occasions when message-based correlation is necessary because automatic correlation is not available, for example:
When the other participant does not support WS-addressing, or
When a participant joins the conversation part way through but has only the data values, but no other information about the conversation
If you do not specify any settings for message-based correlation, the runtime engine will attempt to use automatic correlation. If it is not possible to do so, then you will get a correlation fault. The engine checks to see if the called process or service supports WS-addressing, in which case it will insert a WS-addressing header into the call. It will then wait for a matching reply. Similarly, if JMS is being used to transport the message, it will look for a reply message with the JMS correlation ID that matches the JMS message ID of the message it sent.
Correlation is especially important inside a loop construct, as there may be multiple threads/receives waiting at once, and the engine needs a way to know which reply belongs with which receive.
In this article, we have explored the inter-process communication and the default conversation.
This article has introduced us to the theory of how processes can communicate with each other and with other components. A number of topics are covered such as: conversations—what they are, and the default conversation.
Resources for Article :
- Author Podcast - Ronald Rood discusses the birth of Oracle Scheduler [Article]
- Oracle Integration and Consolidation Products [Article]
- Author Podcast - Aleksander Seovic Talks About Oracle Coherence 3.5 [Article]