I would like to know if anyone has done any horizontal scaling of their application servers hosting CSLA business objects? How you have gone about implementing, and the results you have seen? With the new WCF channel, I am looking to create a cluster of application servers hosting the same sets of business objects and servicing the UI tier web servers. I am trying to get a feel for the practicality of doing this, the best way to implement (how to direct the web servers to the various application servers i.e. hardware load balancers, custom approach, etc) and any technical gotchas to look out for.
For an OLTP type app this is generally not a good architecture. You are better off having the web server talk to the database and not bother with a separate app server. The fewer network hops between the user and the database the better.
However, if your app has substantial back-end processing (like executing workflows or other non-interactive processing that is extensive), then you can gain benefit by having "back-office servers" behind the web servers.
To get that benefit though, you really need asynchronicity, which means queued messaging. Which is why this is the point where we're not talking OLTP anymore, because OLTP requires responsiveness and interactivity, and that's the opposite of this queued processing architecture.
Some apps need both btw. So it isn't necessarily realistic to pick just one or the other. Most apps that have big back-end processing also have a lot of data entry and OLTP style aspects that are where the users spend most of their time - before kicking off those longer-running back-end processes.
The problem with "load balancing" OLTP interactivity is that the web server is already an app server. So you end up load balancing traffic from one app server to another - and the result is almost always merely an increase in overhead (a bad thing).
But load balancing back-end processing can be a good thing, because it allows the web servers to focus on OLTP interactivity without being bogged down by non-interactive processing tasks, that the user isn't waiting for anyway.
Consider Amazon or other sales-oriented web sites. They have a lot of interactivity. Wonderful OLTP type stuff. And when you place an order that process is still mostly OLTP - from the user's perspective. However, once the order has been recorded, a back-end process (one or more) kicks off to do all the hard work of getting that order processed and ultimately delivered.
The CSLA data portal is good at the OLTP client/server, n-tier stuff. Though ideally in a web setting you run the data portal in local mode to minimize overhead.
But when it comes to queued back-end processing, you are talking about a message-based metaphor. Where your business object's data access code not only stores some data, but also queues up a message for subsequent processing.
Some other server (or cluster of servers) listens for those queued messages. When one comes it, it is pulled off the queue and processed. This processing can also be handled by CSLA style objects - that's a fine thing to do. Though even there the data portal is ideally running in local mode to minimize the overhead.
The key is to use that queued messaging - which really should be messaging, not serialized objects - to transfer control from the interactive part of the app to the non-interactive processing part.
WCF can be used for that purpose, as can raw MSMQ or a SQL Server table. And Biztalk Server is an option. In fact, many options exist, depending on how you want to approach it.
Thanks, I really appreciate the feedback. Also, the new book on CSLA 3.0 is very good and has a lot of practical information.
Copyright (c) Marimer LLC