Tiered architecture question

[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

[sloan]

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/ShippingCostsCa lculatorTCPList ener";
//Use this syntax for a IIS deployed Remoting Service
string sourceURL =
"http://localhost/DotNetAssemblie s/GranadaCoder/Applications/RemotingExample
/IISRemotingSamp leDeploy/MyFirstRem.rem" ;

See my blog
http://sholliday.space s.live.com/?_c11_BlogPart_ n=1&_c11_BlogPa rt_handle=cns!A 68482B9628A842A !125&_c11_BlogP art_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" <kr***@horizo n-boss.comwrote in message
news:Xn******** *************** **********@207. 46.248.16...

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 Ross]

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
"sloan" <sl***@ipass.ne twrote in
news:e#******** ******@TK2MSFTN GP05.phx.gbl:

>
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/ShippingCostsCa lculatorTCPList ener";
//Use this syntax for a IIS deployed Remoting Service
string sourceURL =
"http://localhost/DotNetAssemblie s/GranadaCoder/Applications/RemotingEx
ample /IISRemotingSamp leDeploy/MyFirstRem.rem" ;

See my blog
http://sholliday.spaces.live.com/?_c...BlogPart_handl
e=cns!A68482B96 28A842A!125&_c1 1_BlogPart_Full View=1&_c=BlogP art (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.

..