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!
::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.
>>::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.
<< 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.
>>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...
<< 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 :)
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!
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.
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.
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?
Bluemagics Weblog: "I'll always make your dark sky blue!"
fredlewis7
Member
305 Points
61 Posts
asp.net middle tier architecture
Nov 14, 2004 08:27 PM|LINK
thona
Member
20 Points
2923 Posts
Re: asp.net middle tier architecture
Nov 15, 2004 05:04 AM|LINK
rsmoke21
Contributor
3931 Points
792 Posts
Re: asp.net middle tier architecture
Nov 15, 2004 01:01 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: asp.net middle tier architecture
Nov 15, 2004 01:18 PM|LINK
rsmoke21
Contributor
3931 Points
792 Posts
Re: asp.net middle tier architecture
Nov 15, 2004 01:34 PM|LINK
m7
Contributor
4225 Points
843 Posts
Re: asp.net middle tier architecture
Nov 15, 2004 01:51 PM|LINK
fredlewis7
Member
305 Points
61 Posts
Re: asp.net middle tier architecture
Nov 16, 2004 02:01 AM|LINK
thona
Member
20 Points
2923 Posts
Re: asp.net middle tier architecture
Nov 16, 2004 05:57 AM|LINK
thenetrealto...
Participant
940 Points
197 Posts
Re: asp.net middle tier architecture
Nov 16, 2004 06:46 AM|LINK
Bluemagics
Participant
1955 Points
391 Posts
Re: asp.net middle tier architecture
Nov 16, 2004 08:16 AM|LINK