Async call in OSB

Question

Hi,
Our requirement is when the front end calls the proxy service, the proxy service should call the back end web service and give the response to front end service, This can be achieved.
But the other requirement is in case if the back end service is down .. we need to keep on retrying till the back end is UP and then send the response back to front end(Or we can send the response when the front end calls again) . But the front end will not wait for the response. Front end will fire and forget. its proxy service responsibility to keep on trying for the back end service to be up and store/send the response to front end.
Can we achieve this in OSB 11g? Or we need to go for BEPL.
Please post the steps to achive this.

Answer 1

As already being stated by @vladodias, OSB is better fit for stateless designs. If you need to keep the response until a later poll comes, you may be better off with BPEL.
But not necessary.
Consider this design:
1. Front end calls OSB.
2. OSB generates an unique token for the request and saves this request into an JMS queue. The token is stored into a header.
3. OSB returns the token to the caller. Caller saves it locally for future poll and closes the connection.
4. A JMS proxy transactionally reads the message from the queue (along with the token) and calls the backend service.
5. If the backend service is down, the transaction is rolled back, and the message is returned back to the queue for retry later (retry period is configured on the queue).
6. If the backend is up, the message is placed into a persistent storage using the token as a key. The storage is not JMS queue, because OSB proxies cannot programmatically read queues with filter, and also cannot read the queues on demand. So the store should be a database. (You cannot use disk as a store in a cluster unless the disk is also shared).
7. Front end calls OSB with the token.
8. OSB checks the persistent store and, if the response with the given token is found, sends it back to the the caller.
Now, you may notice that front-end always initiates the call, i.e. there is no callbacks. I do not like callbacks in OSB designs, makes a mess when you get more than one consumer. However, you may implement it, too -- i.e in step 6, instead of persisting the message, just do an outbound call to the front-end application.
Also, this design is always asynchronous. You may improve it by trying to do a synchronous call to backend first, and only if it is down, switch into asynchronous mode.
P.S. If you're not familiar with using JMS/transactions with OSB, read my post: Transactions in OSB. Reliable Messaging.
P.P.S. You can also use JMS queue as a persistent store for the responses, but then you'll have to use a Java callout that connects to the queue with a filter (by token) to extract the only message.