Tiered architecture question

  • Thread starter Thread starter Ken Ross
  • Start date Start date
K

Ken Ross

I'm in the early stages of working up the design for a large .Net web
application and want to make sure that we have the best possible physical
architecture to support the logical architecture and implementation. To
my way of thinking, that means that no only do we follow a 3-tier
approach from a logical view (data access, business logic, and UI) but
that we also separate the application into physical layers to improve
scalability and security.

My thoughts now, keeping it simple, are to have a SQL Server (SQL), a
Business Rules Server (BRS), and Web Server (UI). The Web server would
host the pages that make up the UI and it would make requests for data
(read/write) to the BRS which in turn would talk to the SQL server
through a logical data access layer.

The big question for me in all this is whether I should use Web Services
as the communications mechanism between the UI and BRS or if I should use
Remoting instead. I have experience with both so it's not a learning
curve issue and at the moment it would only be code that we control
talking to the BRS (later we may have a need for SOA functionality at
this layer).

Certainly the web services style is better supported in the IDE and
therefore easier to work with but that [for now] comes with a performance
penalty when compared with Binary Remoting over TCP. The thing is, even
though slower, web services could very well be "fast enough" since I
don't anticipate moving huge numbers of records between the BRS and UI
layers anyway.

Any comments/advise on this is greatly appreciated!

Ken
 
Ken,

My rule of thumb is:
DotNet only. Use Remoting.
Hetereogeneous. Use Web Service.

You haven't listed Remoting thru IIS, which is another alternative. The
pro's of this approach is that you get all the built in "stuff" with IIS.
Aka, when the server reboots, IIS comes back up.
And you don't have to create a windows service to handle the tcp traffic.
I find the IIS approach is good, because it simplifies deployment
tremendously, but all I have to do is switch out a connection string if I
change from IIS to tcp.

Notice this example below:
//Use this syntax for a TCP deployed Remoting Service
//string sourceURL =
"tcp://localhost:9932/ShippingCostsCalculatorTCPListener";
//Use this syntax for a IIS deployed Remoting Service
string sourceURL =
"http://localhost/DotNetAssemblies/GranadaCoder/Applications/RemotingExample
/IISRemotingSampleDeploy/MyFirstRem.rem";

See my blog
http://sholliday.spaces.live.com/?_...842A!125&_c11_BlogPart_FullView=1&_c=BlogPart
(which is Page "2" of the listings) for a downloadable remoting example.
Mine talks about "secret code", but that's not a big issue for you if you're
doing a web based gui.



As far as the tiers,
see
http://sholliday.spaces.live.com/ 6/5/2006 5/24/2006

and I usually have the BizLayer and DataLayer on the same physical layer.
I find it more important to write good DAL code, which uses IDataReaders
(primarily) and when it updates the database, it gets in and out of the
database as quickly as possible.
(aka, no biz logic in the usp's (user stored procedures in Sql Server)

I'd suggest the IIS/Remoting approach. It would be much easier to go from
this .. to tcp/remoting then from webservices ... if you don't get the
performance you need.

...

Ken Ross said:
I'm in the early stages of working up the design for a large .Net web
application and want to make sure that we have the best possible physical
architecture to support the logical architecture and implementation. To
my way of thinking, that means that no only do we follow a 3-tier
approach from a logical view (data access, business logic, and UI) but
that we also separate the application into physical layers to improve
scalability and security.

My thoughts now, keeping it simple, are to have a SQL Server (SQL), a
Business Rules Server (BRS), and Web Server (UI). The Web server would
host the pages that make up the UI and it would make requests for data
(read/write) to the BRS which in turn would talk to the SQL server
through a logical data access layer.

The big question for me in all this is whether I should use Web Services
as the communications mechanism between the UI and BRS or if I should use
Remoting instead. I have experience with both so it's not a learning
curve issue and at the moment it would only be code that we control
talking to the BRS (later we may have a need for SOA functionality at
this layer).

Certainly the web services style is better supported in the IDE and
therefore easier to work with but that [for now] comes with a performance
penalty when compared with Binary Remoting over TCP. The thing is, even
though slower, web services could very well be "fast enough" since I
don't anticipate moving huge numbers of records between the BRS and UI
layers anyway.

Any comments/advise on this is greatly appreciated!

Ken
Click to expand...
 
Thanks much!! I've been reading some other articles on your blog re this
sort of architecture although I hadn't run across the discussion of
hosting a Remoting interface through IIS - haven't looked at that before
and am looking forward to reading about it.

I'm like you with the DAL and BL - I want the business logic and DAL on
the same physical box, separate from both the SQL and UI boxes. Likely as
not we'll end up publishing *some* web services from the business layer,
if not for our application then for partners to connect through. My
thinking was that if I'm going to have web services there anyway, it
might just be cleaner to have everything use the same technology.

Thanks again for your feedback and insight!

Ken
 
Back
Top