Oracle SOA 10G Tricks: Optimize calling path between ESB

and BPEL
In SOA 10G, it is a good practice to have BPEL and ESB co-located at the same JVM. Doing so will not
only improves performance but also allows JTA global transaction propagates between the two. However,
these advantages will not be fully materialized, or even will totally disappear, if wrong protocols was
chosen when these two components call each other.

1. BPEL calling ESB

When developer write BPEL processes that call ESB, many don't think about the protocols used in the
calls. The fact of the matter is, if you don't pay attention you may end up making the call via SOAP,
instead of a more efficient protocol, even if the ESB endpoint is running on the same JVM. The problems
of having the call going through SOAP are
Problem 1: It breaks the JTA transaction. Often time you want a JTA global transaction propagate from
BPEL to ESB
Problem 2: It is less performant. The call may first have to go to the HTTP load balancer and then routed
back, only to the same JVM from which the call is initiated.
Here is the syntax of making BPEL -> ESB invocation native:
Original partner binding at bpel.xml
<partnerlinkbinding name="PLESBSalesOrderOrchastrationEBS">
<property
name="wsdlLocation">http://xxx:7777/esb/wsil/AIASystem/EBS/SalesOrderOrchastra
tionEBS?wsdl</property>
</partnerlinkbinding>

Should be changed to:

<partnerlinkbinding name="PLESBSalesOrderOrchastrationEBS">
<property
name="wsdlLocation">http://xxx:7777/esb/wsil/AIASystem/EBS/SalesOrderOrchastra
tionEBS?wsdl</property>
<property name="preferredPort">__esb_{partnerlink}_{porttype}</property>
</partnerlinkbinding>

You should get the actual value of __esb_{partnerlink}_{porttype} from the ESB's WSDL file
http://xxx:7777/esb/wsil/AIASystem/EBS/SalesOrderOrchastrationEBS?wsdl

2. ESB calling BPEL

On the other hand, when you have ESB call BPEL at the same JVM, there are three possibilities for the
calling protocols:
A. SOAP
B. RMI

C. EJB local interface.

EJB local interface would typically deliver better performance than RMI (which involves JNDI look-up,
serialization, etc), and RMI often time delivers better performance than SOAP. Both RMI and EJB local
interface could allow the JTA transaction context to be propagated (as long as both ESB and BPEL are in
OC4J), while SOAP will break the JTA transaction boundary as we mentioned earlier.
For best performance and also preserving the transaction context, you typically want to choose the EJB
local interface. In the SOA 10g's term, it is call "local invocation".
To choose the right protocol, you start at the design time. You want to choose the BPEL endpoint from the
auto generated "BPEL services" from the ESB designer. If you create an "external service" using the
WSDL of BPEL, the designer will choose the communication protocol to be SOAP. To verify whether the
BPEL endpoint is treated as a "BPELService" or "External Service", you can simply open the *.esbvc file
for that BPEL endpoint. You should be able to find "BPELService" in the esbvc file.
Now, once the designer creates the BPEL endpoint as a BPELService, the default protocol would be RMI.
You can then further optimize this call by changing the protocol from RMI to local interface. The latter
means ESB calls BPEL as if one EJB calls another EJB in the same JVM via local interface. The
configuration for this optimization is a bit more tricky than optimizing the BPEL -> ESB route.
Step 1: Enable the global JNDI for the OC4J container by adding global-jndi-lookup-enabled="true" to the
application-server element in server.xml.
Step 2: Add an endpoint property called InvocationMode to the Oracle ESB service that represents the
BPEL process, and specify a value of local. Do this through the Properties tab on the ESB Service
Definition page in Oracle ESB Control. Possible values for this property are local and remote. The default
value is remote, which implies that by default Oracle ESB calls BPEL processes over RMI. RMI protocol
still allows the JTA transactions can be propagated except it incur more latency than 'local'. The "local"
invocation mode only applies when ESB and BPEL are running within the same JVM.
Step 3: (to work around a known issue), to ensure that the routing service can call a BPEL process using
InvocationMode=local, you must make sure that property is available by adding the InvocationMode
property to the bpel.xml of the BPEL process being called, as shown in the following example.

<bpelsuitcase>
<bpelprocess id="BPElProcess1" src="BPElProcess1.bpel">
<partnerlinkbindings>
<partnerlinkbinding name="client">
<property name="wsdlLocation">BPElProcess1.wsdl</property>
</partnerlinkbinding>
</partnerlinkbindings>
<configurations>
<property name="InvocationMode">local</property>
</configurations>
</bpelprocess>
</bpelsuitcase>

Step 4. ESB to BPEL communication uses "oc4jinstancename" property defined in "antorabpel.properties" to determine the instance name of the current oc4j node. This is required for
successful lookup of BPEL delivery service. In clustered environment this property takes a different
meaning (it is used for group name) and cannot be used as "oc4jinstancename" so another property

called "local.oc4jinstancename" should be defined to specify the local oc4j instance name, for the lookup
to function correctly.
Step 5: Restart the server (required for step 1 above). Setting the global JNDI attribute to true flattens the
JNDI tree. This means that any J2EE application can access any JNDI object in the container without
providing credentials. This may increase security
Posted by Francis Ip at 12:02 PM
Email ThisBlogThis!Share to TwitterShare to Facebook

2 comments:
1.
Francis IpJanuary 11, 2012 at 2:18 PM
I have just updated the the "ESB -> BPEL" portion of this blog. The changes are:
1.
Some
design
time
consideration
2. Settings in ant-orabpel.properties.
Reply
2.
HussainiJanuary 25, 2012 at 5:25 PM
Thanks Francis for the blog. As rest of the world is on 11g, I think a similar note would be helpful to
them
as
well...
Ok, coming back to my comment, I knew about this except EJB local invocation. Thanks. In the
BPEL to ESB call, if we use preffered port it is creating problems in dynamic parterlink execution.
Often the call goes to design time specified end point. It used to work prior to SOA 10.1.3.4
Reply