CSLA and MSMQ

JohnB posted on Tuesday, November 18, 2008

Just curious if anyone out there has successfully implemented CSLA and MSMQ?

We are using CSLA 3.0.4 with remoting and it works great but were wondering if there was a potential "fit" between the two technologies.

We have access to an existing solid code base for MSMQ and the conversation came up about potentially using it in place of remoting.

At this point I am relatively new to MSMQ but would be interested in feedback from those who have been down this road.

Thanks,
John

RockfordLhotka replied on Tuesday, November 18, 2008

The data portal is designed around synchronous service calls. In other words, it can work with nearly any network protocol, as long as the calls are synchronous.

MSMQ is, by definition, asynchronous, and so the data portal can't use MSMQ - at least not easily.

You could create a data portal proxy/host channel using MSMQ, you'd just have to make the proxy be smart enough to simulate a synchronous call. There are well-established patterns for doing this sort of thing - blocking the calling thread until the async return message arrives on another thread - but it isn't clear to me what you'd gain by doing this?

JohnB replied on Wednesday, November 19, 2008

I agree with you, I don't see what we would gain. Basically we have another development team who is not familiar with CSLA but started a discussion to see if there were any merits of "combining" the two. That this would somehow or potentially reduce the size of the object traveling across the wire by using MSMQ. Our application will run across our corporate WAN and the bandwidth is tight although so far our initial test have worked fine.

I think I have enough information from your reply in addition to several post that I found here in the forum to remove this discussion from the table.

Thanks,
John

RockfordLhotka replied on Wednesday, November 19, 2008

One thing to consider with MSMQ is a service-oriented architecture. In other
words, don't try to use it inside the data portal, but rather use it between
different applications.

MSMQ is one way to build a "service bus" that allows different applications
to send messages to each other in a reliable and scalable manner. This is
why WCF uses MSMQ (behind the scenes) to implement reliable messaging.

Just don't confuse n-tier with SOA - they are very different things. The
data portal helps enable n-tier. CSLA can be used to implement applications
in an SOA system, with or without asynchronous reliable messaging.

Rocky

tdrake replied on Thursday, November 20, 2008

I too are using MSMQ with CSLA, but as Rocky suggesting as part of SOA. All tracnsaction creation (data and bus rules) are handled by CSLA via a MSMQ (or WCF tcpnet) end point servie which 'looks' like a client to CSLA's data portal. It allows me to use the same object plumming for user UI for the business to see the results of the tracsaction (BPM tool!!), as well as ensures my ESB business logic is in one place.

I've basically build a project that opens the MSMQ, see(or sends) the 'transaction' (Mostly a 'message notifier' - I also use WCF events for non MSMQ integration in a pub/sub pattern), which then runs up the transaction in core CSLA - it's got no UI as such, as it runs as a Windows Service.

I've also a ESB monitor using observable objects (CSLA or course) with a WPF Client to allow the IT Pros to know the health of integration.

I sold it to the business as 'Biztalk light'....

So, while you may not be able to use the MSMQ libraries between tiers in CSLA, they can be a great 'Entry point/End point'

Tony Drake