Hello
We're about to embark on testing the possible use of having the standard CSLA DataPortal exposed on a WCF channel using IBM's WebSphere MQ WCF provider. The idea is to have a transactional asynchronous communication channel due to very poor legacy database performance resulting in things timing out and needing re-tried.
So posting here to see if anyone else has attempted such a feet and could provide a glowing orb of knowledge that would help us expedite the success or dismissal of this option.
thanks!
I love your avatar graphic - SPOON!! :)
The data portal only really requires a synchronous binding. But I'm guessing that the MQ binding is async, so it probably won't work, at least not easily.
To put it another way, the client-side data portal proxy must appear to be synchronous. So you could perhaps simulate this behavior with some thread locking, though that's very tricky.
All that said, in version 4.5 and higher the data portal does support the async/await behaviors of .NET 4.5. And the data portal in 4.5.11 and higher has two internal implementations: sync and async.
The async implementation consistently flows async calls through to the WCF call. This might mean that you can use an async binding - as long as the task representing the WCF call doesn't complete until the result is returned from the server.
I believe you will get into problems using this as a channel for the DataPortal.
I have used WebSphere MQ on a number of occasions as a messaging transport layer but never the WCF channel. Our apps require high throughput and we were recommended to use the MQ .NET Classes rather than the WCF channel by IBM.
I believe your DataAccess classes should rather transform data into a XmlMessage on MQ and send to a queue. Then you have a separate application to read from the queue and do whatever updates are necessary. And if it fails - then put the message back into queue for new processing later.
The CSLA DataPortal is syncronous, meaning that the client must have a well defined response or your app will get a TimeoutException and is left in an undetermined state.
Thank you both. I was hoping to be able to leverage the asynchronous nature of the the Q as well as distributed transactions on the communication channel as a slick way to get the behavior. Apparently not such a good option. Very sad. It would have made for a slick solution.
So we'll go back to plan B which is exactly as you describe JonnyBee. I was just hoping to avoid having a side process for ease of maintenance/management.
Thanks
Copyright (c) Marimer LLC