Monday, January 6, 2014

#301 Invoking BPM processes programmatically - when to use what?

- A big thank you to my colleague David R. for his comments -

For invoking the process (initial BPM process instance creation) we could --

1. Create a web service proxy based on the BPM process WSDL.

2. Create an EJB Service Client to front the BPM process and call this.

3. Create a direct binding interface to the BPM process.

4. Explicitly use the BPM API as per

Other variations -

5. Use Technology Adapters

6. Use EDN

Some heuristics

Direct binding enables Java clients to directly invoke composite services, bypassing the intermediate conversion to XML required with web service binding.
Direct binding for propagating identity/transaction context
Direct binding for native connectivity between OSB and SOA/BPM Suite.
Direct binding for HiAv / Clustering support

Web Services when this is the preferred canonical model for integration.

Web Service Proxy - loose coupling, simple to develop.

In each of the above,  the caller is responsible for detecting failures and preserving the original message, The caller is responsible for retrying if required.  

EJB Service Client - useful for those who have standardised on EJBs - allows propagating identity/transaction context

BPM API - tightly coupled - for those who want full control. Not that simple to develop.


Use of the adapters can move error handling/recovery off the client.  For example using JMS adapter or Database adapter.  For example, an integration with Mainframes where WLS/SOA Suite were not running when the process is started on the mainframe. 

Another common pattern would be a local queue with store & forward to the SOA instance, or inserting row into the DB. Then leveraging the DB adapter to start the process.  

EDN (Signal) can also be used. has it’s benefits, but does not currently have durable subscription. EDN thus decreases coupling, but does not ensure the message/event will be handled.

No comments: