| Author |
Message
|
| qcf |
 Posted: Tue Jul 26, 2005 7:41 pm Post subject: Maintaining Unit of Work with SOAP over JMS |
 |
|
Novice
Joined: 25 Jul 2005
Posts: 10
Location: Australia
|
The scenario:
A transaction request coming from a web browser, the web-application is served from WebSphere Application Server 5.1. The WAS then sent a SOAP request to WBIMB 5.0.4 over JMS (implemented on WMQ). The Request SOAP message is transformed by WBIMB to another SOAP message that is prescribed by a back-end target application (the routing to which application depends on the transaction type and some other business rules). The SOAP from WBIMB to the backend application will also be sent over JMS (on WMQ).
The high level flow is as follow:
| Code: |
Web-Browser ---> WAS ---> WBIMB ---> Application A
Web-Browser <--- WAS <--- WBIMB <------|
|
The initial incoming request is HTTP (to WAS), however we want to maintain a unit of work for this request, i.e. if for some reason the HTTP connection between browser-WAS lost or time-out occured in any of the above connections,i.e. the user will not get a positive confirmation, the transaction occured in the backend application (in the above illustration: Application A) should be rolled-back.
Basically, we only perform/persist all changes in Application A when the user receives a positive confirmation.
Any idea how to do this ?
Thanks a heap for your help... |
|
| Back to top |
|
 |
| JLRowe |
| Posted: Wed Jul 27, 2005 1:16 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
There isn't much you can do as the backend is asynchronous, so when the reply message does not arrive you cannot determine if the request was processed or the reply is delayed.
One option is to provide functionality to examine the user's transaction history, so if something goes wrong they can check if the transaction was actually processed or not. |
|
| Back to top |
|
|
| recallsunny |
| Posted: Wed Jul 27, 2005 7:13 am Post subject: |
|
|
Disciple
Joined: 15 Jun 2005
Posts: 163
Location: Massachusetts
|
Looks like a typical InterChange Server scenario with transactional business process involved... Could be achieved with A HTTP Connector/sync collaboration with Compensation/Destination Connector. Wonder if it can be replicated in MB though.
just thinking out Loud...
 |
|
| Back to top |
|
|
| qcf |
| Posted: Wed Jul 27, 2005 3:42 pm Post subject: |
|
|
Novice
Joined: 25 Jul 2005
Posts: 10
Location: Australia
|
| Quote: |
There isn't much you can do as the backend is asynchronous
|
Will it help if the back-end is synchronous? I don't think so. Doesn't that make it even worse? Since the failure can happen in any of the segment and the UI will not get the confirmation still.
| Code: |
Web-Browser ---> WAS ---> WBIMB ---> Application A
Web-Browser <--- WAS <--- WBIMB <------|
|
In the above same scenario, if say all connections are SOAP over HTTP. When a connection is lost on the response flow after Application A committed the transaction, there is no way to detect this, and we still end up getting a transaction committed in Application A without positive confirmation to the user.
Is this assumption correct? or did I miss something here? or is there anything can be done in the SOAP over HTTP scenario to fulfil the requirement?
Please enlighten.... |
|
| Back to top |
|
|
| recallsunny |
| Posted: Thu Jul 28, 2005 6:23 am Post subject: |
|
|
Disciple
Joined: 15 Jun 2005
Posts: 163
Location: Massachusetts
|
Within the HTTP reply Node there is a option to "IgnoreTransportFailure" option. If you uncheck this, and there is a connection drop by the client before it can recieve the HTTP reply, the Flow will throw an exception.
You can use a try/catch to evaluate this and then rollback the changes to your "backend App". You might have to add few compensation steps if its a non-transactional application.
Cheers
 |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 28, 2005 6:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| recallsunny wrote: |
[color=green]
Within the HTTP reply Node there is a option to "IgnoreTransportFailure" option. If you uncheck this, and there is a connection drop by the client before it can recieve the HTTP reply, the Flow will throw an exception. |
But what if it fails between broker and WAS?
Then WAS has to know to issue a compensating transaction. And broker has to know how to handle a compensating transaction.
Transport is irrelevant to this problem. Using MQ, if you use the Aggregate nodes, you can detect that the back-end application did or did not return a reply in a certain period of time.
And likewise in WAS you can get with WAIT + expiry and know that you didn't get a response from broker. But then you have to issue a compensating transaction...
The decision to do this synchronously or asynchronously should be entirely dependant on what the user is expecting and the nature of the transaction - not on what transport is being used.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| recallsunny |
| Posted: Thu Jul 28, 2005 6:55 am Post subject: |
|
|
Disciple
Joined: 15 Jun 2005
Posts: 163
Location: Massachusetts
|
| Quote: |
But what if it fails between broker and WAS?
|
This is when the HTTP reply node will throw an exception since it was not able to deliver the response correctly. By compensation steps, I meant you will have to have to include some ESQL in the catch terminal of the Flow to rollback your transaction with Backend App...
Here is how I simulated this transaction, HTTPInput Node Timeout 120 Seconds, HTTPReply timeout 60 Sec.
If the back end doesnt not respond within 120 sec, the connection is terminated by HTTPInput Node.
The response from backend (After 120 sec) will be delivered by HTTP reply node, but since the connection is already dropped (by HTTPInput), the reply node waits another 60 secs and generates an exception sayin "Did not recieve Acknowledgement with 60secs".
Either way, you can rollback the transaction without committing changes to the Backend App.
 |
|
| Back to top |
|
|
|
|
