Tuesday, October 12, 2004

Adventures in .NET Remoting (and Smart Clients too!)

Our team recently rearchitected our system, largely the business and presentation layers, to use the newer .NET "No Touch Deployment" (Smart Client) technology. One of the most compelling reasons was the ability to offer true Windows desktop applications with the ease (kind of) of web based deployment.

Our design included WinForm applications accessing middle tier (business and data access) components over .NET remoting. The middle tier components provides business services and data access using ADO.NET to connect to a separate SQL Server 2000 database. This design allowed us to deploy rich and robust client front ends via IE, control and distribute access to our business logic and scale our data access by taking advantage of ADO.NET connection pooling.

One of our first decisions was to decide how to logically, and physically, distribute our application code. My preference is to locate code as close as possible to where it is needed. What this meant to us was to deploy the application UI/Workflow presentation and business layer with the application front-ends via WinForms and IE. Shared utilities and data access layer were deployed to our middle-tier application server and was accessed by our business layer via remoting. Finally our database engine, Sql Server 2000, was deployed to a dedicated server and exposed via stored procedures.

Another decision we faced was database transaction management. There are a number of techniques on how to start and manage transactions, most notably COM+ and/or Enterprise Services. My preference is to handle transaction managment in the business layer which posed a dilema for us because our business layer was being pushed to the client machine. Further, we wanted to limit opening database connections to the middle-tier server, in other words, client machines cannot open a database connection. We felt this would promote scalability by utilizing connection pooling, etc. I feel we came up with a creative design that maintained our goals: transaction management maitained by the business layer and opening database connections only on the middle-tier server. It wasn't without issue, but we made it happen.

There's still more to cover, but I'll need to finish up in another post. In the meantime check out this article that discusses the performance differences between the various .NET reomoting techniques.

performance study






No comments: