asp.net middle tier architecture

Hi All! I'm in the process of building a large public web site and need some advice on designing the middle tier. I have a decent amount of experience in asp.net but limited architectural knowledge. I have three main questions 1) Is OO the best approach for designing the business logic in the middle tier? 2) Is it a necessity to use either .net remoting or web services for scalability for a large web site? 3) Should a public web site be architectured a lot different than an internal web application? I've previously worked on a large internal web application and the senior architect designed our system as follows asp.net web forms connect to a data access layer which consists of two dll classes which handle the database connectivity. The middle tier was done through .net remoting with the proxy object sitting on the web server and the server object on the database server. No OO was used to design the application for performance reasons. I didn't fully understand this but I think it was the way that serializing and deserializing objects through .net remoting was very expensive. Any advice or help would be great! Thanks!

Re: asp.net middle tier architecture

::1) Is OO the best approach for designing the business logic in the middle tier? Depends on whom you ask. By now I would say OO is the best approach to code ANY logic, which naturally will include the business logic in the middle tier. ::2) Is it a necessity to use either .net remoting or web services for scalability for a large ::web site? No. Why should you? The most scalable approach for a high volume website is not to have a physical middle tier. ::3) Should a public web site be architectured a lot different than an internal web application? Depends. THe typical external website has way les traffic than the typical intranet - unless you are amazon, ebay, intel, microsoft etc., noone really cares too much about what you put up onto your extranet. And no, 3000 visitors a day do not quantify as traffic -they quantify as boredom for your hardware. SO, in about 80% of the time, scalabilityon an external website is about the last thing you care about. You sadly talk of large public website, but you fail to give any clue on what you consider large. This is critical - come up with some numbers. I was running a site with 4000 concurrent users, totally db driven, off a dual PIII some years ago (I think I remember 450 Mhz or so), including the db on the same server, running cpu utilization less than 50%. Most people will consider 4000 active users on a site large. This is nothing by todays standards. ::I've previously worked on a large internal web application and the senior architect designed ::our system as follows Just one mark - his approahc qualifies him as a trainee, not as a professional commercial system architect. ::asp.net web forms connect to a data access layer which consists of two dll classes which ::handle the database connectivity. The middle tier was done through .net remoting with the ::proxy object sitting on the web server and the server object on the database server. No ::OO was used to design the application for performance reasons. Someone will hit me with this, but this imho a total bullshit approach. First problem - without specific reason (srecurity ONLY) there is no freaking need to have a middle tier as a physical tier. Web-servers are easy to maintain anyway (local, only a handfull even for large sites), and if you are not totally clueless as admin, distributing new business dll's is FAST. Remoting and web services within an app add tremendously towards slowness, so if you CAN get rid of one physical tier, do it. In practice you may want to keep the database local, too, but this simpl will limit your scalability TOO much, so this is not an option except you are SMALL on volume. Second, not using OO for programming an application is a valid approach, but saying this is done for performance reasons is lying. Outright lying. OO is a method to formulate an API, if nothing more, and how you define the API within the boundaries of OO makes or breaks you, but OO per se has nothing in it that says you have to be slow. ADO.NET, Managed DirectX, are good examples of OO interfaces that are designed in a way that does not necessarily make their use slow. Naturally, if you have no clue what you are doing, you may end up making stupid mistakes in designing your API and be slow. More important, if you want scalability, is to use caching as far in the front as possible as agressive as possible. Output cache can make you app. ::Any advice or help would be great! Tell the architect to go back to school. Beginner class.

Re: asp.net middle tier architecture

>>::Any advice or help would be great! Tell the architect to go back to school. Beginner class. LMAO! I needed something to wake me up this morning, thanks Thona. Hopefully no one takes offense at your style. >>1) Is OO the best approach for designing the business logic in the middle tier? I agree with Thona that OO is pretty much the best approach. The reason being that it is the simplest type of architecture to maintain and extend (assuming it is designed effectively), usually. On top of this a lot of work has gone into making it fast and with today's CPU speeds there shouldn't be a noticeable performance difference. Obviously, if you wrote in ASM it would be FASTEST, but I think we all understand why we use a high level language. >>2) Is it a necessity to use either .net remoting or web services for scalability for a large web site? I've never used remoting and haven't worked on a 30 million hits/day site, either. But, it seems to me that you would only need to use remoting in a few situations: 1) Your web servers are so overwhelmed with traffic that they CANNOT support the execution of any business logic because a large performance degradation will occur. 2) You need to share business logic "state" that is not persisted in the database/DAL. In both of these cases I see a valid need for a physically seperated middle tier - though there often might be a work around for these issues also.

Re: asp.net middle tier architecture

<< 1) Your web servers are so overwhelmed with traffic that they CANNOT support the execution of any business logic because a large performance degradation will occur. >> for this one, you should be scaling up your server, not scaling to a new server. more processors, more memory, more servers in the cluster... any of those work fine and would perform a lot better than a multi-physical-tier approach. << 2) You need to share business logic "state" that is not persisted in the database/DAL. >> yes thats valid, but i would argue that you should just persist it to the database. why re-invent the wheel? the situation where i think remoting is valid, is when you want that processing to occur on a specific machine. a pretty standard example is a situation where you might be connecting to a legacy system and need some legacy dlls (or runtimes) installed on the machine connecting to the legacy system. rather than installing them everywhere, you might install them in one place and put a .net remoting interface to it. of course another situation would be for sharing data with external partners.. but most would go for web services to do that.

Re: asp.net middle tier architecture

>>the situation where i think remoting is valid, is when you want that processing to occur on a specific machine. Thanks for the info. I haven't encountered a situation where I need remoting, so any information on where I should apply it will help me identify if/when I need to use it. Are most people avoiding remoting totally and staying with 2 physical tiers and n logical tiers? I personally see remoting as introducing another potential point of failure and a much higher level of complexity (thus try and avoid it). However, since I haven't worked in depth with it I don't know EXACTLY how complex it is...

Re: asp.net middle tier architecture

<< Are most people avoiding remoting totally and staying with 2 physical tiers and n logical tiers? >> i TRULY hope so (they should be using it ONLY when absolutely necessary), but i fear not. 5-10+ years ago, glossy brochures were put together by marketing departments trying to sell products by pushing the fact that they are distributed (n-tier). managers/cio's/directors were suckered in, buying these solutions which just didn't scale. the fact that they didn't scale was blamed on the fact that there weren't ENOUGH remote tiers.. so more remote tiers were added.. making performance even worse. and so the cycle went. some people made a LOT of money out of this. fast-forward to today, and it's still easy to sucker in 90% of vp's with the perceived "scalability" of remoting solutions. remember, most decision makers of today in corporate environments come from a mainframe background, so it is pretty easy to persuade them that n-tier distributed is the way to go (it WAS when there were dumb terminals connected to a HUGE mainframe.. but it isn't anymore). as a result, these decision makers put "must have n-tier distributed experience" on job specs.. which pushes up the price of people who can do that. so people do it (hell, why not. i mean if i was told here's 100k for doing things wrong, or 50k for doing things right, i know what id take!!). it's sad, but thats how i see it. i believe it was martin fowler who said something along the lines of "the first rule of distributed computing is don't distribute your objects". it was something to that effect and oh so true :) << However, since I haven't worked in depth with it I don't know EXACTLY how complex it is... >> it isn't wildly complex, but isn't trivial either. frameworks can help with this. but the fact is, you're making a (potentially totally unnecessary) network call.. which is BOUND to throttle your performance. the vast majority of times, any bottleneck in an application is when it has to make a cross-network trip.. so where possible, don't do it :)

Re: asp.net middle tier architecture

Thanks all, for your replies! Wow I didn't expect my post would generate such intense discussion :) Thats great! Appologies for sounding ignorant I'm just trying to learn as much as I can. Ok so from what I gather, 1) OO is a good approach if designed properly as it is easy to maintain and extend on. We are currently designing our site using OO and would be interested in performance testing it and benchmarking the design. Could anyone recommend any good resources for OO design and performance testing? 2) Sounds like remoting and having a physical middle tier is not favourable for the majority of cases. I think I might of been unclear though with my example I used as I didn't deal much with the architectural design of that project. But from what I remember we had a web server hosting IIS, web forms and the proxy object which was all within a DMZ. The database server hosted the server objects and SQL Server and ran within the corporate domain. Is this approach completely wrong for a large intranet system? 3) I definitely agree it is good to validate what I mean by "large". The company has pretty ambitious business requirements. In essence the site should scale beyond 5000 concurrent users and 30000 regularly active users (ie logging in once every few weeks). However, whats concerning me is there will be a lot of heavy interaction from users. By this I mean its not an informative web site like cnn or something. Users will have something like a project space and interact with other users. It will also have a lot multimedia content etc. If anyone has any more information or advice on how to deal with a site like this I would greatly appreciate it. Many Thanks!

Re: asp.net middle tier architecture

From the back: ::In essence the site should scale beyond 5000 concurrent users and 30000 regularly active ::users (ie logging in once every few weeks). Not large. Basically do not do stupid mistakes (i.e. do not write awfully slow code) and this is nothing a dual or quad opteron should not be able to handle. Pretty easily. Just throw some more RAM at it and go into a web-garden configuration with ASP.NET. You will relaly get another impression what scalability means then. ::Sounds like remoting and having a physical middle tier is not favourable for the majority of ::cases. Exactly. ::from what I remember we had a web server hosting IIS, web forms and the proxy object ::which was all within a DMZ. The database server hosted the server objects and SQL Server ::and ran within the corporate domain. Why? Why not put the IIS web server into the corporate domain, too, and run the incoming requests through a firewall? Or put the database into the DMZ, too? Is security SUCH a hugh reason? Can it not be worked around (like most banks do)? See, you pay a price for the DMZ thing. Crossing a physical boder is SLOW. Period. Do you have enough reason to justify it? I would NOT think so for a system that handles projects. If I HAD to cross a physical border, I would TRY (if possible) to make so asynchronously, using MSMQ and other systems allowing the front-end to do it's job without waiting for the backend. ::Could anyone recommend any good resources for OO design and performance testing? Testing - any test suite does it. Performance testing is performance testing, OO or not. Design: books I personally love are from Scott Ambler (http://www.ambysoft.com). "The Object Primer" and "Building Object Applications That Work" are on my top list. ::Wow I didn't expect my post would generate such intense discussion :) Where? There was no intense discussion. This is under one page.

Re: asp.net middle tier architecture

Unfortunately, most of the advice you are receiving is based upon an interactive model of object lifetime. If, and your implications are not clear, your "objects" must continue to live and react to external events beyond user interaction, then the advice above is not of much help. An example would be a simple portfolio trading application which allows users to interact with it for the purposes of control and monitoring, but which continues to operate even if no users are connected. In this case, a seperate server, accessed via remoting or otherwise, would be a viable alternative as the "objects" would continue to react to changes in the environment, bids-offers, interest and currency rate changes, as required, (portfolio example), the control interface being web-server-based. As far as disk-based, database or otherwise, state maintainance, this is again a function of event frequency and associated state changes. If the rate of change is high, and you have competition for a limited number of oppurtunities, i.e., he with the fastest gun wins, then the db method would be inapproriate, unless you like being last to react to changes. The last system of this type which incorporated a database in a critical transaction path was probably back in the early 80's. Without a more detailed model of what your problem domain is, it is not possible to really give any solid advice.

Re: asp.net middle tier architecture

hey experts ;-) I have a question about remoting in windows applications, even If I know that is is the ASP.net forum, but I believe there are enough experts here who (hopefully) will help me with this one... how about remoting in win apps? I'm building a new application now.. SQL server backend. I'n not sure how to seperate the layers, put all the layers on the client computers and just use the (central) SQL server... or put only the 'presentation' part' on the clients and the rest on the same server where the SQL is running.. or only putting the DAL there ? and another question. What will be the best approach when I'm launghing updates? I'm trying to use the updater application block, when I seprate the layers fysiclally on different machines, will I need to stop ALL the clients when I update... or will it work like updates for websites - just copy the new one?

Re: asp.net middle tier architecture

:: when I seprate the layers fysiclally on different machines why do this? this will kill performance and scalability. or maybe you just misunderstood .net remoting.

Re: asp.net middle tier architecture

:::: when I seprate the layers fysiclally on different machines ::why do this? this will kill performance and scalability. or maybe you just misunderstood .net remoting. I don't mean separate them all (3 machines in this case just for the fun).. But i saw some winforms starterskit//sample-apps where they try to run the DAL as a service, even a webservice, so you can seperate it for the rest.. I'm not sure If this will have any advantages, that was my question. I didn't used remoting for so far...

Re: asp.net middle tier architecture

>>But i saw some winforms starterskit//sample-apps where they try to run the DAL as a service, even a webservice, so you can seperate it for the rest.. I'm not sure If this will have any advantages One advantage of a webservice is that you can usually expose it to the external world. So, theoretically your app could run inside the co. firewall and outside the co. firewall (assuming correct DMZ setup, etc). If remote access is a requirement and it cannot be only a web app and you cannot implement a VPN then this type of architecture MIGHT be appealing. However, webservices are SLOW, so you would have to accept the performance hit in return for a wider range of access. I would suggest though doing a web app or VPN before doing this type of architecture.

Re: asp.net middle tier architecture

You said "webservices are SLOW". Would remoting be any faster? If not, what could be the best solution?
Thanks much.

Re: asp.net middle tier architecture

You can put your BLL in the client and DAL in the server and use either web service or remoting to call your DAL from your client.

>>What will be the best approach when I'm launghing updates?
Did you try smart client?

Re: asp.net middle tier architecture

What do BLL and DA stand for in full? Thanks.

Re: asp.net middle tier architecture

thuhue
What do BLL and DA stand for in full?

BLL = Business Logic Layer
DAL = Data Access Layer (or Data Abstraction Layer)