Я в командировке. Строчу из отеля... Извините за сумбур, спешу...
_рубльПО размещенное на сервере приложений имеет интерфейс не только работы с пользователем но с аналогичным по структуре ПО размещенным на других
серверах приложений.
MS SQL Server 2000 имеет интерфейс не только для работы с пользователем, но и с аналогичным MS SQL Server 2000 по структуре БД. "Репликация" называется. Что самое интересное, в отличие от сервера приложений, MS SQL Server 2000 нет необходимости писать. Он уже написан, и написан неплохо.

_рубльДля клиента безразлично какая физическая структура исходных данных, он работает с ее представлением сформированным на сервере (серверах) приложений. ОТЧЕНТОСТЬ ФОРМИРУЕТСЯ ТОЛЬКО НА ОСНОВАНИИ ДАННЫХ СЕРВЕРОВ ПРИЛОЖЕНИЙ
Для клиента безразлично, в файле с каким расширением и в каком именно формате находятся данные. Он работает с представлениями (View), сформированными на SQL-сервере (серверах) всегда с SQL-запросами. Отчетность формируется ТОЛЬКО НА ОСНОВАНИИ ДАННЫХ SQL-серверов (а не какого-то двоичного файла).

_рубльПри соединении серверов приложений инженеры технологи в режиме реального времени могут легко контролировать(именно контролировать, управление только с рабочих мест в подразделении) ход технологических процессов любых подразделений, и неважно где расположено оборудование, и где находятся инженеры
При соединении SQL-серверов инженеры технологи в режиме реального времени могут легко контролировать(именно контролировать, управление только с рабочих мест в подразделении) ход технологических процессов любых подразделений, и неважно где расположено оборудование, и где находятся инженеры.

_рубльОбъединение того, что само по себе не объединится. Тем более что одним из условий объединения является изоляция одного от другого. Размещение логики, логики которую нельзя (или нет смысла) размещать на одной из сторон.
Репликация объединяет то, что само по себе не объединяется. Разместив логику на одном из SQL-серверов, можно из этой логики управлять данными других SQL-серверов.
ЗЫ. А что ты будешь делать с 20-ю серверами приложений, когда выяснится, что одновременно на всех в одинаковом русле нужно исправить код? Примерно то же самое, что на 20-ти SQL-серверах, верно? Только в репликации можно еще задействовать репликацию хранимых процедур, и писать для этого заумного кода не треба... Получается, вроде как, проще...

_рубльО том что на сторону сервера БД (серверов БД) логику не разместить, это уже объяснил. А я не понял. Где объяснил?
А про число "пи" вообще нифига не понял.

_рубльОтчетность в стандартном ПО скупая, достаточна для технологического процесса управления, но для анализа работы непригодна. СУБД разношерстны, возможность “залезть” в их и разместить там бизнес логику формирования отчетности есть, но делать этого не нужно.
Если СУБД разношерстны, и базы данных разношерстны, то это, конечно же, проблема. Достаточно серьезная. И тогда действительно без сервера приложений - никак. Правда, трудно догадаться, кто и зачем создал себе такие проблемы. Примерно с таким же успехом он мог натворить для себя разношерстных серверов приложений, которые между собой связать еще труднее, чем разношерстные СУБД. Разношерстные СУБД хоть в какой-то мере поддерживают ANSI-92, а вот разношерстные сервера приложений - это уже неизлечимо...


2 _рубль. Не обижайся, это я так шучу... :) Безо всякой злобы м ехидства, по-дружески. Не надо терять веру в человечество. Нужно всего лишь напрячь лобную мышцу и привести какие-то более существенные аргументы, нежели те, в которых словосочетание "сервер приложений" с легкостью заменяется на словосочетание "SQL-сервер" практически без искажения смысла.

TSQL, конечно, не самый лучший язык программирования. В нем нет даже цикла FOR. В нем нет возможности создать пользовательский класс и в принципе нет возможности реализовать принципы ООП. Тогда, когда бизнес-логика сложна, когда эта бизнес-логика плохо ложится на реляционную модель, когда для ее реализации начинаются всерьез ощущаться ограничения TSQL, тогда - и тут я согласен - может возникнуть соблазн сотворить собственный сервер приложений.

И у меня он тоже возникал. Но я вовремя себя одернул. Такие "пустяки", как взаимодействие данных при большом количестве одновременно открытых сессий, их непротиворечивость, проблемы грязного чтения и блокировок, проблемы пропускной способности (чтобы сервер приложений не стал узким местом)... Нужно самому организовать пулы очередей. Нужно самому отслеживать непротиворечивость информации, которая буферизирована на уровне сервера приложений, нужно быть готовым к тому, что информация в переменных, в пулах и очередях сервера приложений уже не соответствует той информации, которая находится в СУБД (потому что кто-то ее мог изменить в другой сессии, через другой сервер приложений или вообще напрямую с помощью SQL-запроса), может не соответствовать тому, что пользователь видит на экране. В одной сессии могут выполняться действия, которые противоречат действиям, запущенным в другой сессии, сервер приложений может оперировать неактуальными данными и -... получить отлуп от СУБД . Или НЕ получить отлуп, а получить кашу вместо достоверных данных. В том случае, если сервер приложений на своем собственном уровне игнорирует такие понятия как "уровни изоляции", "транзакции", "блокировки", "логическая целостность (DRI, в частности)". Обработать на сервере приложений все возможные совокупности ошибок, которые могут возникать по подобным причинам, очень и очень не просто. Еще сложнее избежать их появления. Точнее, можно избежать их появления, если сессии допускать к данным СУБД только по очереди, а не одновременно. Но тогда упадет пропускная способность. А чтобы она не падала, необходимо предусмотреть параллельную обработку данных, практически вынеся на уровень сервера приложений ту работу, которой обычно занимается SQL-сервер. То есть, реальная трудоемкость написания такого приложения, оказывается соизмерима с трудоемкостью написания самого ядра СУБД (например, MS SQL Server). Если же все функции, необоходимой для многосессионной параллельной обработки данных НЕ переносятся на сервер приложений, то разработчику сервера приложений так или иначе приходится затрачивать усилия, продумывая все комбинации всех возможных фаз параллельных действий пользователей, экстраполируя их через собственную бизнес-логику (которая на сервере приложений) и тщательно продумывая - а не возникнут ли дедлоки, например, на уровне СУБД. И получается, что никакого существенного выигрыша в плане трудоемкости разработки от сервера приложений нет. Не удастся в достаточной степени абстрагироваться от тех вопросов, с которыми обычно приходится работать на уровне TSQL, работая над разработкой приложений в мидлтаер.

Вопрос обработки ошибок тоже может добавить головной боли. Всем известно, что в любом более-менее сложном ПО наверняка содержатся какие-то ошибки. В приложении, работающем по технологии "клиент-сервер" сообщение выводится прямо на экран пользователя. Сообщения СУБД тоже могут выводиться на экран пользователя. Если клиентское приложение в плане обработки ошибок СУБД плохо спроектировано, ошибки можно отследить на самом SQL-сервере. При использовании сервера приложений как можно быть уверенным, что вообще вся информация об ошибках попадет во-время и по адресу? Одни мои знакомые зафигачили вывод сообщений об ошибке в системный журнал приложений. В их приложении возникла циклическая ошибка, которая вызвала переполнение журнала приложений. А в это время юзер продолжал работать, ни сном, ни духом не ведая о происходящем.
Допустим, о факте возникновения ошибки мы уже знаем, даже не смотря на то, что на экран пользователя информация о ней не выводится. На SQL-сервере можно запустить хранимые процедуры или триггеры в режиме отладки, пошагово, посмотреть, что поступает на сервер, как он на эту информацию реагирует. С сервером приложений процесс отладки может существенно усложниться. Особенно, если отладка выполняется на "живом", запущенном в работу приложении (например, когда выявилась какая-то ошибка в процессе текущей работы). Особенно, если ошибка возникает только при большом количестве параллельных сессий и именно на уровне СУБД. При этом нужно каким-то образом сопоставить конкретные действия конкретного пользователя с реакцией на эти действия сервера приложений (отфильтровав эту реакцию в куче реакций на все остальные действия во всех остальных сессиях), и затем на следующем уровне искать телодвижения на уровне СУБД, которые соответствуют только некоторой части отфильтрованных действий сервера приложений, запуская некоторые фильтры уже на уровне СУБД. Но как вы будете производить эту многоуровневую фильтрацию? Я знаю программистов, которые вот таким образом намучилившись с отладкой мидлтаер и уже десяток раз прокляли тот день, когда им в голову стукнуло делать сервер приложений.

Еще раз, чтобы не возникло недопонимания. Я не против сервера приложений. Но не считаю, что "3-tier своими руками" нужно делать в большинстве случаев. Только в некоторых, исключительных случаях, заранее тщательно продумав, предварительно взвесив все "за" и "против", осознав и заведомо согласившись на те проблемы, которые при этом возникнут. Потому что, плюсы трехзвенки совершенно точно перевесили ее минусы. И не забывая о том, что многие поставщики СУБД развивают свои продукты и вводят непосредственно в них все более развитые возможности, в частности, в MS SQL Server 2005 уже можно будет на уровне сервера вкусить прелести ООП, а в Oracle они давно есть. Но почему-то как-то редко и мало используются. Кстати, почему? Не потому ли, что быстродействие и пропускная способность как правило проигрывают при переходе на более высокие уровни абстрагирования? Игнорировать же вопросы быстродействия, логической целостности, пропускной сопсобности и т.п. на сегодня врядли удастся...

ИМХО

_рубльИ если эта логика, по сути своей, различна. Где ее разместить?Конкретно в рассматриваемом случае лично я бы разместил ее на сервере BizTalk. Он как раз очень хорошо приспособлен для решения подобных задач. В некотором смысле это мидлтаер. В некотором смысле он даже лучше, чем традиционный сервер приложений. Потому что позволяет автоматизировать многие операции по преобразованию плохо стыкующихся форматов данных поставщика и клиента. А также позволяет реализовать на его стороне ту часть логики, которая не реализована внутри взаимодействующих приложений через этот центр их интеграции.
Наконец, поставщик может предоставить портал в виде WEB-служб. А мы у себя можем осуществить стандартные процедуры установки соответствий данных нашего справочника и справочника поставщика. В конце концов, разработаны (и продолжают разрабатываться) стандарты E-Commerce, для обмена B2B и B2C. Правда, я не слышал о том, чтобы в этих стандартах шла речь о СОДЕРЖИМОМ справочников. Все больше об их структуре (например, оговаривается XML-схема по составу полей для обмена информацией о контрагентах). ИМХО, эти стандарты еще очень и очень сырые (например, они не учитывают, что предприятие может сменить название, оставшись прежним предприятием, к которому должны оставаться привязанными все прежние связанные с ним движения ресурсов). Но время идет, и светлые мысли все чаще посущают наши светлые головы... :)
Во всяком случае, во всех тех случаях, когда нам на практике предлагали использовать многоуровневое приложение, находя для этого достаточно веские основания, мы выходили из ситуации с помощью MS BizTalk Server, с помощью которого все задачи решались быстро и изящно. Самое главное - это минимум ручной работы. МИ-НИ-МУМ.