Какую технологию выбрать для трехзвенки?

← →
Andriano (2003-09-17 09:23) [0]

Есть 8 компьютеров в одной сети Интранет с каналами минимум 64кбит/с.
Требуется написать упрощенный оперативный торговский учет.

1.Если тонким клиентом будет Web-браузер, то придется много разбираться с Java или HTML (синтаксис и доступ к данным).
2.Есть ещё возможность использовать Remoute Data Module.

Привык использовать компоненты FIB plus. Получается, чтобы использовать все наработки и опыт, да и вообще писать в любимой среде Delphi, придется выбрать 2-ой вариант. Насколько это надежно и безглючно?

Есть ли другие варианты?
Может вообще обойтись грамотной двухзвенкой (широко использовать внутренние процедуры и тригеры)? При предварительном расмотрении задачи, кажется, что очень больших потоков данных не будет.

Кто писал трехзвенку, поделитесь опытом.

← →
Reindeer Moss Eater (2003-09-17 09:33) [1]

Трехзвенка никогда не решала проблему тонких каналов. Она не для этого придумана.

← →
Jeer (2003-09-17 09:38) [2]

Сервер приложений на базе w2k Terminal

← →
Sergey13 (2003-09-17 09:38) [3]

Если каналы связи более-меннее надежные, то можно вообще без всяких трехзвенок обойтись легко. У меня на 33кбс (реально 26-28) филиал крутится - одновременно до 5 машин (обычно 2). Главное условие - вылизывать программы на предмет минимизации трафика.

← →
stone (2003-09-17 09:43) [4]

Можно использовать SOAP. Обмен данными по HTTP. 64кбит/с более, чем достаточно.
Простенький пример здесь:
http://delphiplus.nagano.ru/articles/delphi/soap_it_is_easy/index.html

← →
Reindeer Moss Eater (2003-09-17 09:49) [5]

64К для двузвенки - за глаза и за уши.
И если про трехзвенку вспомнили только в связи с толщиной канала - то это ошибочный ход мысли.

← →
Andriano (2003-09-17 10:08) [6]

> Reindeer Moss Eater ©
Трехзвенка обеспечивает большую надежность и служит для минимизации трафика. Так написано во всех статьях о трезвенках.

> stone
Прочел. SOAP примерно тоже самое что и MIDAS.

Спасибо за ответы. Буду тестировать двухзвенку.

← →
Reindeer Moss Eater (2003-09-17 10:13) [7]

Трехзвенка обеспечивает большую надежность и служит для минимизации трафика. Так написано во всех статьях о трезвенках.

На сарае тоже много чего написано, а лежат там дрова.

← →
Reindeer Moss Eater (2003-09-17 10:16) [8]

Назначение трехзвенки:
1. Облегчить клиента. Основное назначение.
2. Бизнес-правила. Если на сервере не удается реализовать все бизнес правила, а на клиенте не хочется - то реализуются они в третьем звене.
3. Ну и все пожалуй.

← →
Reindeer Moss Eater (2003-09-17 10:20) [9]

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

и служит для минимизации трафика.

Берем форму классического двузвенного приложения с DataAware контролами. Что бы заполнить их данными с сервера запрашивается запись из таблицы (у нее есть определенный размер).
Переделываем приложение в N-звенное. Вспоминаем про нашу форму редактирования записи и замечаем, что те же самые данные того же размера пришли с сервера приложений на клиента.

← →
Vlad (2003-09-17 10:27) [10]

>Reindeer Moss Eater © (17.09.03 10:16) [8]
>Назначение трехзвенки:
>1. Облегчить клиента. Основное назначение.

Боюсь, что это не основное назначение.
"Более основное" намой взгляд является разгрузка сервера БД.
Если сотни пользователей ежеминутно получают запросы с сервера, а там заложена куча математики (т.е. хранимок, триггеров), то это значительно замедляет процесс. Именно в этом случае вся математика с сервера БД выносится на среднее звено. А их (средних звеньев), может работать несколько штук параллельно, что при грамотной балансировке нагрузки между ними, позволит значительно ускорить выполнение запросов.

← →
Reindeer Moss Eater (2003-09-17 10:29) [11]

Vlad ©

Ну значит бизнес правила в середине - основное назначение, а не облегчение клиента.

Но только не минимизация трафика.

← →
Sandman25 (2003-09-17 10:33) [12]

Vlad & Reindeer Moss Eater

Я вижу, вы неплохо разбираетесь в этом. А в чем выигрыш, если сервером приложений служит сервер БД? Или применение здесь трехзвенной архитектуры связано только с тем, что не всю бизнес-логику легко реализовать в хранимых процедурах и триггерах?

← →
Vlad (2003-09-17 10:38) [13]

>Reindeer Moss Eater © (17.09.03 10:29) [11]
Согласен,трафик тут совсем не причем.

>Andriano (17.09.03 09:23)
Почему бы не использовать в качестве упрощения COM/DCOM, коль сеть локальная ? MIDAS в Дельфи неплохо с этим справляется, я вроде лично пользовался...

← →
Vlad (2003-09-17 10:41) [14]

>Sandman25 © (17.09.03 10:33) [12]
>сервером приложений служит сервер БД
В этом случае единственный выигрыш может быть, как сказал Reindeer Moss Eater, в облегчении клиента.
Поскольку сервер БД - один (если не кластерная система) и несколько App-серверов внутри него в параллель не поставишь :)

← →
app (2003-09-17 10:47) [15]

Основное назначение изоляция клиента от БД, остальное все в придачу и трафик и процее. Бизнес правила делаются на промежуточном звене. При отсутствии безнес правил не получается даже разгрузки БД

← →
Sandman25 (2003-09-17 10:49) [16]

[14] Vlad © (17.09.03 10:41)

Понятно, спасибо. У них на этом сервере стоит много разных БД и много разных App-серверов, недавно вынуждены были сделать upgrade машины, чтобы справляться с нагрузкой. Вот я и подумал, может, им стоит перенести часть бизнес-логики на клиента. Клиентские машины у них совсем не слабые, и математические операции можно было бы выполнять на них.

← →
Sandman25 (2003-09-17 10:53) [17]

[15] app © (17.09.03 10:47)

>изоляция клиента от БД

Вы имеете ввиду, чтобы можно было изменить структуру БД без изменения клиента (аналог инкапсуляции в ООП)? Но если изменений в системе не планируется (и даже точно не будет), то главное преимущество трехзвенки исчезает?

← →
Vlad (2003-09-17 10:56) [18]

>app © (17.09.03 10:47) [15]
Да уж, кому как не Вам знать об этом все от и до! :)

← →
Romkin (2003-09-17 10:56) [19]

2Reindeer Moss Eater
>Система из трех компонентов не может быть надежнее системы из двух компонентов по определению.
Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...
И трафик минимизируется, достаточно его замерить. По нескольким причинам, кстати. У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.
Получается так во-первых, потому, что в MIDAS передача пакетная, и пакеты весьма компактны, а во-вторых, достаточная доля данных просто не доходит до клиента, не нужны ему данные для расчета, только то, что видеть надо. В-третьих, уж выбор по минимизации трафика гораздо шире, мне постоянно выбирать приходится, как минимум, между количеством обращений к серверу и размером данных

← →
Reindeer Moss Eater (2003-09-17 11:05) [20]

Ну это ты погорячился. Следуя этой логике, клиент-сервер менее надежен, чем файл-сервер :) Лишнее звено же есть...

Клиент-сервер и файл сервер сожержат принципиально разные компоненты. Это как один запорожец и один лексус.
Трехзвенка и двузвенка имеют 2 почти идентичных компонента плюс в трехзвенке одно дополнительное звено.
Так что все верно.

У меня при юзании IB трафик между клиентом и сервером приложений был 56 КБайт (самая массивная операция), сжимался модемом на 60 % а между сервером приложений и IB та же самая операция уже 1.2 Гб (правда, сжатие на 80%). Вот и прикинуть можно.

Ну модем и сжатие данных - это не принадлежность исключительно той или иной технологии. У АДО и SQLlinks тоже трафик различный, но это не значит, что изобретались они именно для снижения трафика.

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

Все эти приемы так же доступны и для классического клиент-сервера. Трехзвенка тут не причем.

← →
Romkin (2003-09-17 11:06) [21]

2Sandman25 Трехзвенка дает возможность балансировки нагрузки на этапе разработки, разработчик определяет, где и как будут обрабатываться данные. Ничто не мешает и на клиента их перенести, ничто не мешает и сервер сделать невыделенным, вместе с клиентом...

← →
Sandman25 (2003-09-17 11:11) [22]

[21] Romkin © (17.09.03 11:06)
>Ничто не мешает и на клиента их перенести, ничто не мешает и сервер сделать невыделенным, вместе с клиентом...

То же самое верно и для двузвенки - либо DB alias указывает на локальную машину, либо на удаленный сервер. Хотя дополнительная возможность перенести обработку на вообще третью машину - это действительно полезно.
Интересно, есть ли смысл делать 4-звенную архитектуру, с двумя уровнями серверов приложений?

← →
Reindeer Moss Eater (2003-09-17 11:11) [23]

клиент-сервер менее надежен, чем файл-сервер :)
Парадокс, но это так! :) (Не логическая целостность прикладных данных, а как система)

← →
Anatoly Podgoretsky (2003-09-17 11:11) [24]

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

← →
Anatoly Podgoretsky (2003-09-17 11:13) [25]

Vlad © (17.09.03 10:56) [18]
Как раз я не знаю, поскольку не использую. Но общии положения базовых технологий всегда знать полезно.

← →
Vlad (2003-09-17 11:16) [26]

>Anatoly Podgoretsky © (17.09.03 11:11) [24]
Защита сервера БД от посягательств клиента, путем введения промежуточного звена ? Это вы имеете ввиду ? Ну это, думаю, тоже не самое основное преимущество трехзвенки. Это можно сделать и другими средствами.

← →
Romkin (2003-09-17 11:22) [27]

2Reindeer Moss Eater Парадокс в том, что это не так! Просто надежность системы неотделима от технологии, в ней применяющейся.
Сервер БД предусматривает средства для контроля целостности базы, причем такие, которые невозможно реализовать в случае файловой системы. (Это не ссылочная целостность и тд, я говорю именно о физической структуре базы). ТАкже и трехзвенка может отличаться от двухзвенки как боинг от лексуса :)))
2Sandman25 Ага, локальная база. А остальные клиенты тоже каждый со своей базой? :) Тут принцип именно в том, что место обработки данных выбирается произвольно. Для клиента, как правило, объем расчетов выбирается от двухзвенного клиента (много) до плоского клиента (только показывает, браузер, например). Если хочется считать больше, чем в двухзвенке, то увы, придется кропотливо переносить расчеты из БД на клиент, как и в двухзвенке.

← →
Sandman25 (2003-09-17 11:25) [28]

Romkin

Ясно.

← →
Anatoly Podgoretsky (2003-09-17 11:28) [29]

Vlad © (17.09.03 11:16) [26]
Конечно нет, это просто побочный эффект.

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

Ты работаешь с данными, на уровне предоставляемым системой, остальное ее дело. Трафик и процее это тоже побочные эффекты, иногда трафик увеличивается. Безопасность тоже не определяется применением технологии, она может быть и выше и ниже, но как правило выше, за счет изоляции.

Можно применить и тонкого клиента, то есть полное отсутсвие клиентской стороны, в качестве ее может использоваться стандартный Интернет Браузер. Или специализированный клиент, задача которого только отображать и выдавать обратно данные и запросы. По сути многие страницы в сети и есть демонстрация этого принтера, не статические, а хотя и даже статические тоже.
Клиент, сервер, данные.

Дает гибкость за счет сложности.

Да и суть отражена в самом названии три (много) звеньев. Трехзвенка частный случай названия, многозвенка общий случай.

← →
Reindeer Moss Eater (2003-09-17 11:28) [30]

Romkin ©
Ты рассуждаешь про сохранность при выполнении операций (даже не про надежность хранения).
А я рассуждаю про надежность системы.
Так вот надежность системы файлсервера выше надежности системы Клиент-Сервер.

я говорю именно о физической структуре базы.
И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.

← →
Sandman25 (2003-09-17 11:33) [31]

[30] Reindeer Moss Eater © (17.09.03 11:28)

>И те и другие хранят свои данные на жестких дисках, которые ничего не знают про сами системы, и обслуживаются ОС.

Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.

← →
Reindeer Moss Eater (2003-09-17 11:37) [32]

Не всегда так. У нас стоит Informix в режиме raw, он хранит данные не в файлах ОС, а работает с жестким диском напрямую.

Согласен, не всегда. Только raw partition сами по себе опять таки не снижают и не повышают надежности хранения данных.
Разработчики надеются с их помощью увеличить скорость I/O операций.

← →
Sandman25 (2003-09-17 11:40) [33]

[32] Reindeer Moss Eater © (17.09.03 11:37)

Ну да, естественно. Наверное, надежность даже снижается - ведь физическая запись происходит не так часто, как обычно. Впрочем, время между этими checkpoints настраивается.

← →
Romkin (2003-09-17 11:45) [34]

Если файл-сервер не трогать, то пофиг. А вот когда работаешь, то практически любой сервер заботится о своих файлах, даже Interbase контролирует запись в базу, помимо ОС. Хотя он опирается на имеющуюся файловую систему, но его база фактически его файловая система. Остальные сервера делают как минимум так, именно для повышения надежности.

← →
Reindeer Moss Eater (2003-09-17 11:47) [35]

← →
Romkin (2003-09-17 11:50) [36]

Если бы она была выше, то никто бы сервера БД не использовал. И не выше она, не может этого быть. И что ты подразумеваешь под "Система в целом"? Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.

← →
Vlad (2003-09-17 11:51) [37]

В конечном итоге, считаю, что автору стоит задуматься, а нужна ли ему вобще трехзвенка ?
Защиту данных от клиента можно ведь организовать путем запрета их изменения (только через хранимки, например), отображение - через View.
И если соотношение - мощность сервера БД/количество одновременно работающих пользователей, приличное, то тут вполне можно обойтись и двухзвенной архитектурой.

← →
Sergey13 (2003-09-17 11:54) [38]

Вот это дискуссия рарослась!!!
ИМХО, лучше всех (как всегда 8-) АП отразил основные преимущества.
От себя добавлю (в чем то повторяя АП), что многозвенка с ее изоляцией от БД, позволяет использовать в работе разнородные БД и платформы, и делает клиента независимым от изменения этой разнородности (он о ней даже не подозревает). Т.е. не надо ставить всякие клиенты доступа при переходе например с М$ на Оракл. Достаточно поменять сервер приложений. Но это наиболее актуально для ЗДОРОВЕННЫХ и распределенных проектов. В работе с одним сервером БД преимущества смазываются, хотя для разработчиков "коробочных" продуктов удобно "приделывать" к своим проектам разные БД, переписав только сервер приложений.

← →
Reindeer Moss Eater (2003-09-17 11:57) [39]

Romkin ©
Я, например, гарантирую, что данные в моем приложении на IB потеряются только при физическом повреждении диска, остальное - не касает. При файл-сервере такого я гарантировать не могу.

Опять ты про данные. Я что, так неразборчиво пишу по-русски?

Что такое система файл-сервер?
Есть приложение, которое открывает файл на запись/чтение. Все.

Что такое система клиент-сервер?
Есть приложение, которое открывает файл на запись/чтение.
Есть приложение, общающееся с первым приложением. Все.

Вторая система более уязвима. Потому что в ней больше элементов, каждый из которых имеет свою надежность.

Система файл-сервер более надежна чем система клиент-сервер.
Так понятно?

← →
Vlad (2003-09-17 12:03) [40]

>Sergey13 © (17.09.03 11:54) [38]
Согласен, клиентская часть не зависит от сервера, т.е. удобство перевода под другую СУБД, и вобще под другую структуру данных - налицо.
Но зачастую, особенно в небольших компаниях с небольшим числом пользоватетей - соотношение выгоды к затратам - минимальное, при разработке трехзвенки.

Какую технологию выбрать для трехзвенки? Найти похожие ветки