Greg Leake: Stocktrader Demo, 3 of 3

"This application is an end-to-end sample application for .NET Enterprise Application Server technologies. It is a service-oriented application based on Windows Communication Foundation (.NET 3.0) and ASP.NET, and illustrates many of the .NET enterprise development technologies for building highly scalable, rich "enterprise-connected" applications. It is designed as a benchmark kit to illustrate alternative technologies within .NET and their relative performance.
The application offers full interoperability with J2EE and
IBM WebSphere's Trade 6.1 sample application. As such, the application offers an excellent opportunity for developers to learn about .NET and building interoperable, service-oriented applications."
Tune in!
<Inserts elevator music at the end of the video>
It was a pretty funny ending, there are two more parts to this. See if you can find themMinh wrote:You cut part 1 at a very interesting segment, CharlesHope to still see Greg on the flip side
He had to re-configure his server app set up. Didn't want to film it. Not really that interesting of a cut...
C
How is the MSMQ Queue load balanced?
Since you're using transactions there is no way, at least in MSMQ 3.0, to do remote transactional reads. This means that you can't have your processing apps on multiple servers and have them all connect to a single MSMQ server.
Futhermore, you can't have multiple MSMQ servers acting as a single load balanced cluster because MSMQ transactions require what amounts to a session. This prevents load balancing of queues using things like virtual IPs or hardware load balancers.
The best you can do is setup an MSMQ Windows Cluster, but that's active/passive cluster and it just gives you fault tolerance, not horizontal scalability. Not to mention the fact you'll need shared storage in the form of an SAS array or a NAS array.
So how do you scale Stock Trader's MSMQ queue server? I read the documentation, and it seems to only mention scaling the UI and business logic layers. It completely glosses over the server(s) hosting the target MSMQ queue.
I have a complex enterprise application that heavily utilizes MSMQ, and scaling this tier has proven to be basically impossible. There is always a node that won't horizontally scale. Because of this, I'm considering moving to something like SQL Server Service
Broker.
The load balancing of MSMQ is performed by the WCF client, which will round-robin against servers that are running the OrderProcessor service host. This is built into the StockTrader AsyncOrderClient itself.
With WCF, actually, when using an MSMQ binding, the client app is not directly communicating with the OrderProcessor.exe service host; rather it is talking to MSMQ.
Also, MSMQ will work with Windows Network Load Balancing; there are some good articles on MSDN about this.
Very interesting but I have one question - you mention that the entire cluster reads it's configuration from a single SQL Server - isn't that a design flaw in that the entire cluster is dependant upon a single machine?
Say for example you have a power outage that fries the SQL Server - all servers in the cluster restart and then try to get their config and fail... The entire cluster is down.
No more so than rotuing all load balanced requests via a single hardware loadbalancer, switch, or other single resource such as backend functional database.
Redundancy is key, just as would be for the backend functional database (StockTraderDB); you would, for highest reliability, want to use Windows Clustering Services (as you might also for the transacted msmq previously discussed)
to ensure you have at least one backup node for the SQL repository database configured/ready to come online should the primary node fail; as well as backup power supply; databases using RAID arrays with a mirrored (RAID 10 for example) format, etc.
-Greg
Very Good explanation