In his blog Jason Baragry provides a very interesting use case where JBI and BPEL constraints create a dead lock. In that use case, a BPEL defines a two parts conversation where the second part is started by a callback invoked by the first part outbound partner.

When you develop and implement this use case, the application blocks without issuing error or exception. Jason explains in detail the reason of this deadlock.

When the BPEL invokes the EJB, it expects an acknowledgement in return. This acknowledgement will be returned when the EJB method invoked will be finished. To finish, the EJB method waits for an acknowledgement from the SOAP connector. The SOAP acknowledgement will be sent only when the BPEL will be available to receive the SOAP Message. But unfortunately, the BPEL is waiting for the EJB acknowledgement to receive the SOAP message. In brief, we designed a vicious deadlock.

Jason found out a workaround by putting the EJB outside the BPEL composite application. The connectors between the two composite applications will provide acknowledgement that will unlock the process.

Some drawbacks

However, JEE SE has been designed to improve the performance in a JBI environment. By putting an EJB and a BPEL (and using JEE SE) in the same composite application, we create a direct communication between the two components and improve the performances. So it would be nice to find another workaround for the Jason use case.

What is the real matter?

How could we end the deadlock in our application?

A simple way is to provide an ACK to the BPEL before the EJB starts to run and invokes the callback service. To do it, we propose a very simple solution. We add another BPEL (named “Bridge BPEL”) component between the first BPEL and the EJB. Of course, the bridge BPEL is not set to atomic. The inbound and outbound WSDLs for the “Bridge BPEL” are exactly the same and are the EJB inbound WSDL. We design the simplest process possible.

The bridge provides the same entry than the EJB and after a simple assign invokes the EJB.

Then in our casa application we insert the bridge between the BPEL and the EJB

The connection in orange indicates that the BPEL does not call directly the EJB but invokes the bridge as intermediary.

What’s happen at the acknowledgement level?

The first BPEL invokes the bridge that sends back immediately an acknowledgment (The “Bridge BPEL” is not set to atomic) then the first BPEL is able to continue the process and waits for the SOAP invocation. The bridge invokes the EJB and waits for an ACK from the EJB. The EJB invokes the first BPEL callback. A SOAP message is received by the first BPEL and an ACK is returned to the EJB. Finally, the EJB returns an ACK to the bridge. All the partners are now unlocked.

Conclusion

Writing a Bridge BPEL is very easy and takes less than one minute. Even if this workaround makes more complex the global process, this pattern is very simple to design, implement and understood.