Understanding Message Exchange Patterns of an Oracle Mediator

24 Understanding Message Exchange Patterns of an Oracle Mediator

This chapter describes common message exchange patterns between an Oracle Mediator service component and other applications.

This chapter includes the following sections:

Note:

The following exchange patterns show the default handling of responses, faults, and callbacks by Oracle JDeveloper when a routing rule is created. Keep in mind the following points for all cases:

When a response, fault, or callback is sent back to the caller, it is also possible to route the same message to a different target service or event by clicking the button next to the target and selecting a different target.
When the caller of the Mediator expects a response, one or more routing rules may route the request to a target that does not return a response, but there should be at least one sequential routing rule that returns a response.
When there are multiple routing rules in a request-response pattern with multiple rules sending a response back to the initial caller, the first response that is received is the one delivered to the caller. The other responses are ignored. Thus, the routing rules that send the response should precede other routing rules that forward the response (if any).

24.1 One-way Message Exchange Patterns

In a one-way interaction, the Mediator is invoked, but it does not send a response back to the caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-1:

Note:

Event subscriptions follow the same exchange pattern as one-way interactions.

Table 24-1 Response When Mediator's WSDL Is a One-way Interaction

Routing Rule Target Type	Response
Request	No response.
Request Response	Response is forwarded to another target or event.
Request Response Fault	Response and fault are forwarded to another target or event.
Request Callback	Callback is forwarded to another target or event.
Request Response Callback	Response and callback are forwarded to another target or event.
Request Response Fault Callback	Response, fault, and callback are forwarded to another target or event.

Figure 24-1 illustrates the one-way message exchange pattern.

Figure 24-1 One-way Message Exchange Pattern

Description of "Figure 24-1 One-way Message Exchange Pattern"

24.1.1 The one.way.returns.fault Property

The one.way.returns.fault property controls how faults and one-way messages are handled for one-way interface SOAP calls. You can add this property to the service binding component of the web service section for one-way web services in the composite.xml file. This property is not applicable to references. It is applicable only to services and only to the binding.ws binding type. Table 24-2 provides more details on this property.

Table 24-2 one.way.returns.fault Property

If one.way.returns.fault Is... Then...

If one.way.returns.fault Is...	Then...
Set to `true`: . . . <service name="Mediator1_2" ui:wsdlLocation="ReadFile.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/file /LocalSandbox/Project1/ReadFile%2F#wsdl.interface(Read_ ptt)"/> <binding.ws port="http://xmlns.oracle.com/pcbpel/adapter/file /LocalSandbox/Project1/ReadFile%2F#wsdl.endpoint (Mediator1/Read_pt)"> <property name="one.way.returns.fault" type="xs:string" many="false" override="may">true</property> </binding.ws> </service> . . .	Any fault that occurs during downstream processing returns a SOAP fault to the client and an HTTP response code of 500. (The same behavior as 11g Release 1.)
Set to `false`: . . . <service name="Mediator1_2" ui:wsdlLocation="ReadFile.wsdl"> <interface.wsdl interface="http://xmlns.oracle.com/pcbpel/adapter/file/ Local Sandbox/Project1/ReadFile%2F#wsdl.interface(Read_ ptt)"/> <binding.ws port="http://xmlns.oracle.com/pcbpel/adapter/file/LocalSan dbox/Project1/ReadFile%2F#wsdl.endpoint(Mediator1/Read_ pt)"> <property name="one.way.returns.fault" type="xs:string" many="false" override="may">false</property> </binding.ws> </service> . . .	Any fault that occurs during downstream processing returns only an HTTP response code of 500. No SOAP fault is returned to the client.
Not set (the default case)	Any fault that occurs during downstream processing returns a SOAP fault to the client and an HTTP response code of 500. (The same behavior as 11g Release 1.)

Set to true:

. . .
<service name="Mediator1_2"
 ui:wsdlLocation="ReadFile.wsdl">
    <interface.wsdl
 interface="http://xmlns.oracle.com/pcbpel/adapter/file
 /LocalSandbox/Project1/ReadFile%2F#wsdl.interface(Read_
ptt)"/>
    <binding.ws
 port="http://xmlns.oracle.com/pcbpel/adapter/file
/LocalSandbox/Project1/ReadFile%2F#wsdl.endpoint
(Mediator1/Read_pt)">
   <property name="one.way.returns.fault" type="xs:string" many="false"
     override="may">true</property>
    </binding.ws>
</service>
. . .

Any fault that occurs during downstream processing returns a SOAP fault to the client and an HTTP response code of 500. (The same behavior as 11g Release 1.)

Set to false:

. . .
<service name="Mediator1_2"
 ui:wsdlLocation="ReadFile.wsdl">
    <interface.wsdl
 interface="http://xmlns.oracle.com/pcbpel/adapter/file/
Local Sandbox/Project1/ReadFile%2F#wsdl.interface(Read_
ptt)"/>
    <binding.ws
port="http://xmlns.oracle.com/pcbpel/adapter/file/LocalSan
dbox/Project1/ReadFile%2F#wsdl.endpoint(Mediator1/Read_
pt)">
      <property name="one.way.returns.fault"
 type="xs:string" many="false"
                override="may">false</property>
    </binding.ws>
  </service>
. . .

Any fault that occurs during downstream processing returns only an HTTP response code of 500. No SOAP fault is returned to the client.

Not set (the default case)

Any fault that occurs during downstream processing returns a SOAP fault to the client and an HTTP response code of 500. (The same behavior as 11g Release 1.)

24.1.1.1 To add the one.way.returns.fault property:

In the SOA Composite Editor, select the service binding component to which you want to add the one.way.returns.fault property.
Go to the Property Inspector section in the lower right part of the editor.
In the Binding Properties section, click the Add icon.

The Create Property dialog is displayed.
In the Name field, enter one.way.returns.fault.
In the Value field, enter true or false.
Click OK.

24.2 Request-Reply Message Exchange Patterns

In a request-reply interaction, the Mediator is invoked and sends a reply to the caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-3:

Table 24-3 Response When Mediator's WSDL Is a Request Reply

Routing Rule Target Type	Response
Request	There is no response from the target, but there should be at least one sequential routing rule with a request-response service.
Request Response	The response is sent back to the caller. The response can be forwarded to another target or event, but there should be at least one sequential routing rule that returns a response back to the caller.
Request Response Fault	The response is sent back to the caller. The fault is forwarded to another target or event.
Request Callback	There is no response from the target, but there should be at least one sequential routing rule with a request-response service. The callback is forwarded to another target or event.
Request Response Callback	The response is sent back to the caller. The callback is forwarded to another target or event.
Request Response Fault Callback	The response is sent back to the caller. The callback and fault are forwarded to another target or event.

Figure 24-2 illustrates the request-reply message exchange pattern.

Figure 24-2 Request-Reply Message Exchange Pattern

Description of "Figure 24-2 Request-Reply Message Exchange Pattern"

24.3 Request-Reply-Fault Message Exchange Patterns

In a request-reply-fault interaction, the Mediator is invoked and sends a reply and one or more faults back to the caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-4:

Table 24-4 Response When Mediator's WSDL Is a Request Reply Fault

Routing Rule Target Type	Response
Request	There should be at least one sequential routing rule with a request-response-fault service. Mediator returns `null` when there is no response to be sent.
Request Response	The response is sent back to the caller. Any exception in Mediator message processing may result in a fault.
Request Response Fault	The response and fault are sent back to the caller. Any exception in Mediator message processing may result in a fault.
Request Callback	There is no response from the target, but there should be at least one sequential routing rule with a request-response service. Mediator returns `null` when there is no response to be sent. The callback is forwarded to another target or event.
Request Response Callback	The response is sent back to the caller. Any exception in Mediator message processing may result in a fault.
Request Response Fault Callback	The response and fault are sent back to the caller. Any exception in Mediator message processing may result in a fault.

Figure 24-3 illustrates the request-reply-fault message exchange pattern.

Figure 24-3 Request-Reply-Fault Message Exchange Pattern

Description of "Figure 24-3 Request-Reply-Fault Message Exchange Pattern"

24.4 Request-Callback Message Exchange Patterns

In a request-callback interaction, the Mediator is invoked and may send an asynchronous reply to the caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-5:

Table 24-5 Response When Mediator's WSDL Is a Request Callback

WSDL of the Routing Rule Target	Response
Request	There should be at least one sequential routing rule with a request-callback service. No callback is sent to the caller if there is no routing rule with a defined callback.
Request Response	The response is sent back to the caller, as a callback, in a separate thread. You can create additional routing rules to forward the response to another target or event.
Request Response Fault	The response is sent back to the caller, as a callback, in a separate thread. The fault is forwarded to another target or event. As above, you can create additional routing rules to forward the response to another target or event.
Request Callback	The callback is sent back to the caller.
Request Response Callback	The callback is sent back to the caller, and the response is forwarded to another target or event.
Request Response Fault Callback	The callback is sent back to the caller. The response and fault are forwarded to another target or event.

Figure 24-4 illustrates the request-callback message exchange pattern.

Figure 24-4 Request-Callback Message Exchange Pattern

Description of "Figure 24-4 Request-Callback Message Exchange Pattern"

24.5 Request-Reply-Callback Message Exchange Patterns

In a request-reply-callback interaction, the Mediator is invoked and sends a response and an asynchronous reply to the initial caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-6:

Table 24-6 Response When Mediator's WSDL Is a Request Response Callback

Routing Rule Target Type	Response
Request	There should be at least one sequential routing rule that returns a response. No callback is sent to the caller if there is no routing rule with a defined callback.
Request Response	There should be at least one sequential routing rule that returns a response. No callback is sent if there is no routing rule with a defined callback.
Request Response Fault	There should be at least one sequential routing rule that returns a response. No callback is sent to the caller if there is no routing rule with a defined callback. The fault is forwarded to another target or event.
Request Callback	There should be at least one sequential routing rule that returns a response. Mediator returns `null` when there is no response to be sent.
Request Response Callback	The response and callback are sent back to the caller.
Request Response Fault Callback	The response and callback are sent back to the caller. The fault is forwarded to another target or event.

Figure 24-5 illustrates the request-reply-callback message exchange pattern.

Figure 24-5 Request-Reply-Callback Message Exchange Pattern

Description of "Figure 24-5 Request-Reply-Callback Message Exchange Pattern"

24.6 Request-Reply-Fault-Callback Message Exchange Patterns

In a request-reply-fault-callback interaction, the Mediator is invoked and sends a response, an asynchronous reply, and one or more fault types to the initial caller. Depending on the type of routing rule target, the responses, faults, and callbacks are handled as shown in Table 24-7:

Table 24-7 Response to a Request Response Fault Callback Mediator

WSDL of the Routing Rule Target	Response
Request	There should be at least one sequential routing rule with a request-callback service and at least one sequential routing rule that returns a response. No callback or response is sent unless the required routing rules are defined.
Request Response	There should be at least one sequential routing rule with a request-callback service and at least one sequential routing rule that returns a response. No callback or response is sent unless the required routing rules are defined.
Request Response Fault	There should be at least one sequential routing rule with a request-callback service and at least one sequential routing rule that returns a response. No callback or response is sent unless the required routing rules are defined.
Request Callback	There should be at least one sequential routing rule that returns a response. Mediator returns `null` when there is no response to be sent.
Request Response Callback	The response and callback are sent back to the caller. Any exception in Mediator message processing may result in a fault.
Request Response Fault Callback	The response, fault, and callback are sent back to the caller.

Figure 24-6 illustrates the request-reply-fault-callback message exchange pattern.

Figure 24-6 Request-Reply-Fault-Callback Message Exchange Pattern

Description of "Figure 24-6 Request-Reply-Fault-Callback Message Exchange Pattern"