I don't know much about efficiency of method remoting (and I haven't done
much programming in .NET), but it does NOT seem logical to introduce another
layer b/w data and presentation layers.

Steve, what you described, is something that sounds excellent on paper, but
fails when you try to implement it in reality.

Having a dedicated server for business logic makes all the calls from
presentation layer go across your physical connection between 2 machines.
And even if you go over fiber, it will still be many times slower than if
you do it on the same machine. If you want to get the best performance, all
your calls should happen in the same process.

Also, what kind of business logic are you talking about? You should be doing
most (preferably all) of your business logic in the Stored Procedures within
SQL Server. 

So we end up with 2 machines: Web Server (which hosts Presentation and
Business logic (if there is a need)) and SQL Server. And even though the
above logic applies here also: if you have SQL Server on the same machine as
Web Server, you will get faster results, b/c of the processor utilization
and memory, you are better off putting SQL Server on a different machine.
Get a pair of fiber network cards and connect Web Server and SQL Server that
way.

Also, do some performance testing. You might find out that the best way is
to have all your business logic which cannot be done within Stored
Procedure, done right within ASP page and not in a COM object. With
introduction of ASP.NET, every page is compiled before it is processed, so I
don't see what is the benefit of creating extra COM object. If you want to
separate Developers from Graphic designers, use CODEBEHIND.

just my $.02

Mike

P.S. When I say you have "2 machines", I don't mean that you are limited to
2 machines. You can scale out your web servers and your SQL boxes.

-----Original Message-----
From: dirk.neethling@g... [mailto:dirk.neethling@g...]
Sent: Sunday, April 21, 2002 6:41 AM
To: ASPX_Professional
Subject: [aspx_professional] Re: Distributed .NET components in a 3-tier
architecture


Have a serious look at .NET services (SOAP). I've used them extensively and
they solve the problem of method remoting. This way you can really convert
your problem to a 2-tier system since keeping the .NET services (SOAP) and
SQL
server close together (on the same machine) is the way to go, so 
1. Presentation apsx (rather use xml/xslt if you can, get the web-services
to speak xml and then only transofrm these on the aspx using xslt.
2. lifting (sql and services)
dirk

> Hi,
> 
> I am having a very difficult time finding any kind of explanation or 
> documentation on the recommended design for a 3-tier architecture based on
> 
> the .NET framework.
> 
> I am looking for placing the presentation (the ASPx pages) on the 1st Tier
> 
> (a cluster of Web servers), and the business logic (the VB.NET coding) on 
> the 2nd Tier (a cluster of App servers), and then the data (SQL server and
> 
> stored procedures) on the 3rd Tier (high availability for the Database 
> backend).
> 
> The idea is to optimize performance for a high volume of users, and place 
> the CPU-intensive business logic on the middle tier (app server).
> 
> My 3 specific questions are:
> 
> 1) How would the 1st Tier (ASPx pages) communicate to the .NET components 
> (VB.NET compiled code) on the second tier?
> 
> 2) For the ASPx pages on the 1st Tier, when using the CODEBEHIND option, 
> I'm assuming the VB code would reside locally on the machine.  So, there 
> will be code on the Presentation Tier.  Is there another way of doing this
> 
> so that only a specialist in Graphic design needs to go to the 1st Tier?
> 
> 3) Does it make sense to create .NET components specific for DATA ACCESS 
> functions and place them locally on the 3rd Tier, so that all Data 
> specific functions can be optimized for performance by executing locally 
> on the database servers, and then returning the results to the .NET 
> components from the middle tier components.  Or is that a bad idea?
> 
> Thanks,
> 
> Steve
> 
> 
> 
> 

-- 
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net