"Ken Ross" <kr***@horizon-boss.com> wrote in message
news:Xns9838A33746E12krosshorizonbosscom@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

"sloan" <sl***@ipass.net> wrote in
news:e#5DjV40GHA.4128@TK2MSFTNGP05.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/ShippingCostsCalculatorTCPListener";
>    //Use this syntax for a IIS deployed Remoting Service
>    string sourceURL =
> "http://localhost/DotNetAssemblies/GranadaCoder/Applications/RemotingEx
> ample /IISRemotingSampleDeploy/MyFirstRem.rem";
>
> See my blog
> http://sholliday.spaces.live.com/?_c11_BlogPart_n=1&_c11_BlogPart_handl
> e=cns!A68482B9628A842A!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.
>
> ..