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.
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
. These will be discussed in detail in Chapter 4, Handling Exceptions. 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
, which we will discuss later in this chapter. 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.
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).
