CSLA .NET

Vibrant discussion about CSLA .NET and using the framework to build great business applications.

Forum has moved

New location: CSLA .NET forum


CSLA .NET Resources:
  • CSLA .NET forum
  • CSLA .NET home page
  • WCF Over WebSphere MQ

    rated by 0 users
    Not Answered This post has 0 verified answers | 3 Replies | 2 Followers

    Not Ranked
    2 Posts
    dragonlips posted on Tue, Feb 19 2013 4:02 PM

    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! 

    All Replies

    Top 10 Contributor
    9,475 Posts

    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.

    Rocky

    Top 10 Contributor
    2,279 Posts
    JonnyBee replied on Mon, Feb 25 2013 12:33 AM

    dragonlips:
    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.

    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.

    Jonny Bekkum, Norway CslaContrib Coordinator

    Not Ranked
    2 Posts

    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

    Page 1 of 1 (4 items) | RSS

    Copyright (c) 2006-2014 Marimer LLC. All rights reserved.
    Email admin@lhotka.net for support.
    Powered by Community Server (Non-Commercial Edition), by Telligent Systems