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

← →
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

Ясно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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