grexhideа) трехзвенка - это ничего хорошего
б) трехзвенка от Microsoft - говно в квадрате

Обоснования будут?
Каков опыт работы с трехзвенкой и трехзвенкой от MS в частности?

Да, можно и так понимать.

В догонку:
Правда понятие "трехзвенная архитектура" плавно перетекло в "многозвенная архитектура", а сейчас так и вовсе SOA.
Причем хранилище совсем не обязательно MSSQL, и не обязательно одно.
Веб-сервисы тоже могут быть реализованы совершенно по-разному, не обязательно на основе протокола SOAP. Хотя чаще всего это так.

Albatrossя не могу понять, что такое сервер приложений, если мы броузер не будем использовать. Кажется, только веб-сервисы и остаются, если только что-то самопальное не писать, которое будет висеть на порту и слушать команды с клиентского приложения.
Сервер приложений - скорее логическое понятие, чем физическое. Важно, что он предоставляет сервисы бизнес-логики (как, например, сервер баз данных предоставляет сервисы хранения и манипулирования реляционными данными). Протокол, по которому эти сервисы доступны извне, может быть любым. Сейчас промышленным стандартом является SOAP.
MS в качестве хоста для сервера приложений предлагает в том числе и IIS. IIS обеспечивает базовые сервисы для разработки специализированных серверов приложений: масштабируемость, безопасность, надежность и т.д. Он как раз и избавляет от необходимости писать, как вы выразились, "что-то самопальное, которое будет висеть на порту". Он за вас повисит на порту и позволит сосредоточиться на описании прикладной логики бизнес-решения. ASP.NET - ни что иное, как расширение IIS. Оно позволяет быстро создавать сервисы, основанные на SOAP.

Перечитал написанное и кажется понял до конца суть вопроса.
Сервер приложений в вашем понимании и реализации MS это IIS+ASP.NET (ну еще можно много чего сюда приплести: COM+, MSMQ и т.д.). На базе них вы можете создавать свои прикладные серверы приложений.

мод NonsensВажно, что он предоставляет сервисы бизнес-логики (как, например, сервер баз данных предоставляет сервисы хранения и манипулирования реляционными данными).
сервер баз данных предоставляет доступ к единому и разделяемому ресурсу - БД, сервисы бизнес-логики таковыми не являются.
И что?

мод NonsensИ что?
А это значит что СП не предоставляет какмие-то сервисы, а просто исполняет приложения, заменяя тем самым клиента полностью.
Смелое утверждение.

модзаменяя тем самым клиента полностью.
А UI где?

мод
Как в любом терминале, на СП формируется описание картинки и отсылается на терминал. Терминал его воспроизводит.
Хм, про терминальный режим здесь вообще речь не шла.
Если вы имеете в виду веб-приложения с UI на основе HTML, то это не терминальный режим.
Но, даже если принять вашу точку зрения, как в этом случае быть с Rich-клиентами (Windows-приложениями, не содержащими бизнес-логики)? Им что, запрещено пользоваться сервером приложений?

Это:

мод NonsensИ что?
А это значит что СП не предоставляет какмие-то сервисы, а просто исполняет приложения, заменяя тем самым клиента полностью.

противоречит этому:

мод Nonsensкак в этом случае быть с Rich-клиентами (Windows-приложениями, не содержащими бизнес-логики)?
Это программируемый терминал, но как известно, непрограммируемые терминалы лучше, т.к. не надо делить логику между терминалом и приложением.
Если на клиенте есть хотя бы броузер, я уж не говорю о Rich-клиенте, то ПОЛНОСТЬЮ заменить клиента уже не получается.
Терминал - это действительно только картинка. Т.е. UI исполняется на сервере. Даже в случае с HTML это не так (как минимум нужен броузер, который исполняется на клиенте). Я уж не говорю про Win-UI.

А вообще, в последнее время, с развитием SOA, нивелируются понятия "сервер" и "клиент". Правильнее говорить "сервис" и "потребитель сервиса". Сервер приложений, предоставляющий сервисы отделу сбыта (т.е. CRM) например легко может быть потребителем сервиса складской подсистемы - он будет при оформлении заказов смотреть (и уменьшать) остатки на складе.
Причем оба этих сервера (и CRM, и Склад) будут иметь свои собственные отдельные UI (для менеджеров по продажам и кладовщиков соответственно).

мод Nonsensпротиворечит этому:
противоречит, поэтому программируемые терминалы не прижились в свое время, да сейчас не очень.

Т.е. из-за логической ошибки в ваших рассуждениях терминалы не прижились? Сильно.

мод
Nonsens
Правильнее говорить "сервис" и "потребитель сервиса". Сервер приложений, предоставляющий сервисы отделу сбыта (т.е. CRM) например легко может быть потребителем сервиса складской подсистемы - он будет при оформлении заказов смотреть (и уменьшать) остатки на складе.

Ущербная технология - нельзя включить чужие сервисы в свою транзакцию.

Ошибка. Протоколы WS-*. Поддерживаются WCF.

мод
Тут и и проблемы-то нет - используй соответсвующие библиотеки - вот и все.

Не понял. Какие библиотеки, чему они соответствуют. Если можно, с примером.

мод
Сервис нужен только тогда, когда есть общий и разделяемый ресурс. Кроме БД токовых не наблюдается а значит и потребности в сервисах нет.
Вообще не понял. Как это связано? Откуда следует нужность сервиса только при наличии совместно используемого ресурса?

Резюме: если у вас не получилось что-то использовать, или вы не обладаете достаточными знаниями в обсуждаемых технологиях, это не значит, что они ущербны, не имеют права на жизнь и не имеют широкого применения.