The most common question in bpel is what is sync vs async. And the answer is mostly sync is request-response in a blocking thread and async is non blocking one-way request with a callback later. From the bpel pm perspective the simple answer is sync is two-way invoke and async is one-way invoke. So if your operation has only [input] its async and if it has [input], [output] both then its sync.
Now how does it make a difference performance wise? async requests go through what is called invoke_message table in bpel pm. So when an async request is made this is basically a two-step process -
Step1 - the message is persisted to dehydaration store / invoke_message table and also sent to a JMS queue
Step2- a worker MDB picks up the message from JMS queue and invokes the bpel
Both these steps happen in two separate threads/transactions.
The configuration property which make all these happen is DeliveryPersistPolicy=on
So whenever there is a one-way invoke, its important to recognize that from the client perspective only step1 happens. Step2 happens internally and performance depends on resources (threads, MDBs) availability.
One more property to keep in mind is CompletionPersistPolicy, this policy basically says how much to write while dehydration.
Dehydration happens during 7 different points (middle of the bpel)
1. receive (if first node and transaction=participate set)
2. pick (on message, on alarm)
3. wait
4. invoke (idempotent=false)
5. flow/flowN (nonblockingInvoke = true)
6. reply (idempotentreply=false)
7. dspMaxRequestDepth has reached (default 600)
dehydration happens at two levels, metadata and auditdata.
If there is dehydration in between the bpel flow, its called a durable process else transient. Dehydration helps recover processes in case of any node failures.
I will cover some bpel best practices, esb internals, tuning parameters in coming up posts.
