<< 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 :)