Вопросы по реализации 3-х звенного приложения...

← →
Ro-man © (2006-08-17 14:57) [0]

...+подключение отчётов в виде DLL на сервере приложения (среднее звено).
Планирую воспользоваться технологией DataSnap (протокол соединения - сокеты TCP/IP)

А теперь несколько вопросов к вам, уважаемые коллеги, кто тесно связан с subj"ем ;-)

1. Возможно ли такое в принципе (динамическое подключение отчётов (dll) именно на среднем звене)?
2. Если возможно, расскажите, пожалуйста, об этом подробнее (возможно, ссылку или пример).
2.1. Не хотелось бы столкнуться с необходимостью build"ить и сервер и dll с runtime пакетами.

Возможно, я изобретаю велосипед, но тогда подскажите, пожалуйста, наилучшее решение в следующей ситуации (пока ничего не реализовано и предлагаемая на ваше обсуждение реализация ПО - это только IMHO, которое вы можете коренным образом улучшить!):
итак, существует 3 группы пользователей:
1). численностью 2-30чел. - работают в локальной сети (от 10 до 100Mbit/s) c "БД1" (тип OLTP) через среднее звено, пользуясь "тонким клиентом" (не Inet browser!);
2). численностью 2-5чел. - работают со своей "БД2" (тип OLTP), аналогично группе 1, но сервер приложения "БД2" при необходимости подключается к серверу приложения "БД1" (инициирование соединения возможно с обеих сторон (но не одновременно), если соединение ещё не установлено) через модемное соединение (прямой провод) со скоростью от 14400 до 28800bps для записи относительно небольшого объёма данных с обеих сторон. Здесь могу ещё отметить, что связь на этом участке ОЧЕНЬ неустойчивая и это изменить к лучшему НЕ светит в перспективе;
3). численностью до 50чел. - работают с "БД3" (тип ODS) через Интернет (используя IE или другой Inet browser). Данные в "БД3" должны записываться пакетами, полученными посредством e-mail из "БД1"
Количество групп типа "1" может быть до 50.
Для каждой группы типа "1" может существовать от 0 до 30 групп типа "2" (модемов, соответственно, на стороне группы типа "1" столько же).
Группы типа "1", "2" и "3" разнесены территориально на достаточно большие расстояния.
Для групп типа "1" и "2" необходимы различные отчеты (по "БД1" и "БД2" соответственно), которые хотелось бы поместить только на серверах приложений (чтобы не "разбрасывать" по клиентским компам вновь созданные отчеты), причём сам сервер приложения при добавлении/изменении отчётов не должен перекомпилироваться.
Для группы типа "3" отчёты, используемые группами типа "1" и "2" тоже нужны, но далеко не все (здесь совместимость не столь важна, но желательна :) ). Для группы типа "3" отчеты обязательно должны подключаться, НЕ останавливая работу пользователей.

Заранее благодарю всех, принявших участие в обсуждении,
буду рад выслушать все ваши предложения!

← →
unknown © (2006-08-17 15:53) [1]

> Ro-man © (17.08.06 14:57)
> ...+подключение отчётов

FastReport Server - должен подойти.
http://www.fast-report.com/ru/products/products.php?BID=44

← →
unknown © (2006-08-17 15:54) [2]

И, собственно, непонятно - зачем 3-х звенка?

← →
Ro-man © (2006-08-17 17:34) [3]

> FastReport Server - должен подойти

Работали уже с ним? Я слышал, что вышел он относительно недавно и к тому же ещё сыроват (+стОит немалых денег).

> И, собственно, непонятно - зачем 3-х звенка?

Одна из главных причин - создать "тонкого клиента", используя для реализации всей бизнес-логики никак НЕ клиентское ПО и ср-ва сервера БД (ХП и т.п.), а среднее звено (сервер приложений), которое, скорее всего, будет находиться на отдельном компе.
Плюс при таком "безбашенном" "модемном connect"е" (см. выше) постоянное соединение (а уж постоянные соединения-отключения от СУБД и того хуже) для обычных клиент-серверных приложений - это просто КОНЕЦ :-)
Также, (это уже есть в вопросе) отчёты - каким образом в случае обычной 2-х звенки ничего не перекомпилируя (имеются ввиду ХП) на сервере БД и не "распихивая" по клиентам сделать так, чтобы новые отчёты были доступны ВСЕМ пользователям БД? ;-)

← →
unknown © (2006-08-17 18:44) [4]

> Ro-man © (17.08.06 17:34) [3]
> вышел он относительно недавно и к тому же ещё сыроват (+стОит немалых денег).

Да. Вышел недавно. 14970 р. - это дорого?

> Одна из главных причин - создать "тонкого клиента", используя
> для реализации всей бизнес-логики никак НЕ клиентское ПО

Хозяин - барин :)

> Плюс при таком "безбашенном" "модемном connect"е"

Всего-то на клиентах правильно обрабатывать дисконнекты. А траффик
можно сжимать. И шифровать. см. ZeBeDee - http://www.winton.org.uk/zebedee/

← →
Ro-man © (2006-08-18 01:00) [5]

> unknown ©

> Да. Вышел недавно. 14970 р. - это дорого?

нет, за 1 не дорого - это, я думаю, приемлемое решение для публикации данных в Inet. Благодарю за полезную ссылку.
А насчет остальных отчетов FastReport Server - это не вариант, поэтому жду новых советов и предложений!

← →
evvcom © (2006-08-18 08:46) [6]

> [3] Ro-man © (17.08.06 17:34)
> используя для реализации всей бизнес-логики никак НЕ клиентское
> ПО и ср-ва сервера БД (ХП и т.п.),

Почему не БД?

> а среднее звено (сервер приложений),

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

> которое, скорее всего, будет находиться на отдельном компе

ну ясное дело. На то он и сервер.

> (а уж постоянные соединения-отключения от СУБД и того хуже)
> для обычных клиент-серверных приложений - это просто КОНЕЦ

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

> Также, (это уже есть в вопросе) отчёты - каким образом в
> случае обычной 2-х звенки ничего не перекомпилируя (имеются
> ввиду ХП) на сервере БД и не "распихивая" по клиентам сделать
> так, чтобы новые отчёты были доступны ВСЕМ пользователям
> БД?

Мы используем Crystal Reports. Его *.rpt храним на сервере в блобе, имена параметров процедур собраны в отдельной табличке с русским названием параметра и прочими аттрибутами для того, чтобы программа знала, как пользователю его преподнести: то ли ввод числа, даты, то ли вызов справочника с получением ID и проч. С добавлением нового отчета не перекомпилируем ни клиента, ни ХП в СУБД, только пишем новую ХП под отчет (запрос, кот. вероятно ты собираешься поместить в сам отчет), раздаем полномочия, заливаем отчет на сервер, регистрируем его и параметры. Причем клиент прежде, чем запустить отчет, проверяет, не появилась ли новая версия? Естественно изначально мы даже не паримся с тем, чтобы отчет скопировать пользователю на машину, все это клиент сам сделает.

← →
roottim © (2006-08-18 09:01) [7]

Чем же FastReport Server не подходит для остальных отчетов?
Вы хоть посмотрели все его возможности в онлайн демонстрации http://80.254.117.74/
и мое имхо: трехзвенка тут нафиг не нужна , browser+ssl-http-server+cgi-rdbms достаточное решение.

← →
novill © (2006-08-18 11:29) [8]

> и мое имхо: трехзвенка тут нафиг не нужна , browser+ssl-
> http-server+cgi-rdbms достаточное решение.

Вы привели пример классифеской трехзвенки :)

← →
roottim © (2006-08-18 11:43) [9]

я так не считаю..
cgi - rdbms клиент-серверное прилолжение
а web его морда(interface) и только.

видел разные споры об этом но мое имхо такого.

← →
Ro-man © (2006-08-18 11:43) [10]

> evvcom © (18.08.06 08:46) [6]
> Я не знаю как для жарптицы постоянные дисконнекты, с ораклом
> у меня на этот счет проблем нет. Добавлена обработка ошибки
> на дисконнект и автоматический перелогон и повторная отправка
> запроса на клиенте и нет проблем.

имелась ввиду связь на скорости порядка 14400 или несколько выше и соединеие с БД ведь должно быть установлено не ради самого соединения, а чтобы выполнить какой-либо запрос (вот что я имел ввиду сказав "соединения/отключения с/от БД"), а если в этот момент произойдет обрыв модемной связи, куда пойдёт незавершенный запрос? (IMHO - в #@пу). На этом участке (возможно?) 3-х звенка покажет себя с лучшей стороны, т.к. (поправьте меня, если не прав) одно из её преимуществ - значительно меньшая "перекачка" по сети как служебной инфы, так и данных (когда это возможно)

> С добавлением нового отчета не перекомпилируем ни клиента,
> ни ХП в СУБД, только пишем новую ХП под отчет (запрос,
> кот. вероятно ты собираешься поместить в сам отчет), раздаем
> полномочия, заливаем отчет на сервер, регистрируем его и
> параметры.

Вопрос, надеюсь, не на засыпку :-) - сколько всего клиентов и как далеко они находятся от Вас? И второй (точно не на засыпку! :-) ) Вы не используете 3-х звенку?
И вдогонку третий - вариант с DLL-отчётами вами рассматривался как возможно более простой?

← →
Ro-man © (2006-08-18 11:52) [11]

> roottim © (18.08.06 09:01) [7]
> Чем же FastReport Server не подходит для остальных отчетов?

А Вы внимательно вопрос прочитали? Вы представляете себе, сколько таких серверов понадобится и в какую сумму это может вылиться???
P.S. пи$&енное ПО по определению в данной ситуации использоваться не может!

← →
Ro-man © (2006-08-18 11:53) [12]

> roottim ©
> novill ©

(горячие финские парни :-) )
не спорьте, пожалуйста, об этом:

> browser+ssl-http-server+cgi-rdbms достаточное решение.

roottim © просто невнимательно прочитал вопрос:

> итак, существует 3 группы пользователей:
> 1). численностью 2-30чел. - работают в локальной сети (от
> 10 до 100Mbit/s) c "БД1" (тип OLTP) через среднее звено,
> пользуясь "тонким клиентом" (не Inet browser!);

:-))

← →
unknown © (2006-08-18 11:54) [13]

> Ro-man ©

В сторону сервера терминалов не смотрели?

← →
evvcom © (2006-08-18 12:01) [14]

> [10] Ro-man © (18.08.06 11:43)
> имелась ввиду связь на скорости порядка 14400 или несколько
> выше и соединеие с БД ведь должно быть установлено не ради
> самого соединения, а чтобы выполнить какой-либо запрос (вот
> что я имел ввиду сказав "соединения/отключения с/от БД")
> , а если в этот момент произойдет обрыв модемной связи,
> куда пойдёт незавершенный запрос? (IMHO - в #@пу)

Не понял, к чему это? Ты соединяешься/отсоединяешься при каждом запросе? Незавершенный запрос? Элементарно! Получишь ошибку. В блоке try except ее обрабатываешь (я унаследовался от соответствующего DataSet), если это дисконнект, то реконнект и повторный Open. В чем проблема? Пользователь ничего даже не замечает.

> одно из её преимуществ - значительно меньшая "перекачка"
> по сети как служебной инфы, так и данных

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

> сколько всего клиентов

на отчет? или всего? Всего сотни 3 или может уже больше.

> как далеко они находятся от Вас?

В основном все рядом в сети 100 МБит, есть некоторые на модеме, скорость, конечно, не 100 МБит, но терпимая. Некоторые на расстоянии 20-30 км, не знаю что за шлюз у них, но жалоб вроде тоже не слышал. Эти сильно удаленные не мои юзера, а моих коллег по программному продукту :)

> Вы не используете 3-х звенку?

Не использую. Клиент - ПО на Delphi, сервер - СУБД Oracle.

> вариант с DLL-отчётами вами рассматривался как возможно
> более простой

имеется ввиду движок, реализованный в dll? Он рассматривался именно как вариант без перекомпиляции исходников с неущербными возможностями.

← →
roottim © (2006-08-18 12:01) [15]

> (не Inet browser!)

Для Web - FastReportServer
Для не вэб - простой FastReport. Отчеты хранятся в базе...
FastReportServer преобразует эти-же отчеты в выходные форматы для вэба.
И в чем проблема? Думаю не в деньгах!

← →
Ro-man © (2006-08-18 12:35) [16]

> evvcom © (18.08.06 12:01) [14]
> Почему? Твой сервер приложений хранит результаты всех запросов,
> анализирует изменяемость данных, как они влияют на результат
> того или иного запроса, т.е. все это кеширует? Не вижу преимуществ.

А теперь вопрос действительно на засыпку!!! :-) Ты создавал 3-х звенные приложения? Если да, то это хорошо (я - нет, поэтому и спрашиваю совета), тогда перечисли, пожалуйста, основные их преимущества перед обычной архитектурой клиент-сервер. Если ответ - "нет", то это тоже хорошо :-), буду считать, что первого противника 3-х звенной архитектуры я выслушал, хотя дальнейшие ОБОСНОВАННЫЕ советы "против" тоже приветствуются - обсуждение продолжается!!!
И по поводу вот этого хотелось бы узнать подробнее (почему остановился на другом варианте?):

> имеется ввиду движок, реализованный в dll? Он рассматривался
> именно как вариант без перекомпиляции исходников с неущербными
> возможностями.

← →
Ro-man © (2006-08-18 12:48) [17]

> roottim © (18.08.06 12:01) [15]
> Для Web - FastReportServer
> Для не вэб - простой FastReport. Отчеты хранятся в базе...
> FastReportServer преобразует эти-же отчеты в выходные форматы
> для вэба.
> И в чем проблема? Думаю не в деньгах!

возможно я не так выразился... :-) С БД (основная работа, собственно, не с отчетами!!!) они работают, используя "тонкий клиент" (не Inet browser!)
интерфейс для работы с БД (просмотр и изменение информации) имеется ввиду!!! Теперь, надеюсь, объяснил... :-)
P.S. Причём тут деньги? (если не ставить по FastReport серверу для каждой из 50-ти групп).

← →
Ro-man © (2006-08-18 12:51) [18]

> unknown © (18.08.06 11:54) [13]
> В сторону сервера терминалов не смотрели?

что за зверь такой? (терминальный сервер, может? :-) )

← →
evvcom © (2006-08-18 12:59) [19]

> [16] Ro-man © (18.08.06 12:35)
> Ты создавал 3-х звенные приложения?

Нет :)
Не видел необходимости. Может потому, что не знаю их преимуществ. Некоторые называют преимуществом отсутствие разграничения полномочий в СУБД. Не понимаю этого преимущества. Тогда приходится городить систему безопасности на сервере приложений. В чем кайф?
В общем, сам с удовольствием выслушаю другие мнения.

> И по поводу вот этого хотелось бы узнать подробнее

Чего? Почему не нравится перекомпиляция ради добавления отчета? Один раз написал и забыл. Сейчас для добавления отчета надо написать запрос (ХП), в среде Crystal Reports нарисовать шаблон отчета, залить шаблон на сервер, зарегистрировать его.
Если встроенный в exe: запрос, шаблон, перекомпиляция, залить exe на сервер.
Недостатки: если работаешь в группе, то перекомпиляция обычно делается на "сборочной" машине, что не всегда удобно. Растет количество модулей, форм. Увеличивается объем exe, что с наличием модемов не есть хорошо.
Crystal - очень продвинут, потому к недостатку можно отнести некоторую сложность в программировании доступа. Насколько мне известно, движок его халявный, но платна среда разработки отчета. Но из-за продвинутости в нем можно реализовать практически любые фантазии пользователя! :)

> evvcom © (18.08.06 12:59) [19]
> Почему не нравится перекомпиляция ради добавления отчета?
> Один раз написал и забыл. Сейчас для добавления отчета
> надо написать запрос (ХП), в среде Crystal Reports нарисовать
> шаблон отчета, залить шаблон на сервер, зарегистрировать
> его.

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

как и кем у тебя производится вышеупомянутое действие (автомат/полуавтомат, админ/юзверь)? Если не тривиальное копирование и после запуск к.-л. спец.утилиты, то поподробнее, пожалуйста.
З.Ы. похоже, нам пора переходить в чат... :-))

> буду считать, что первого противника 3-х звенной архитектуры
> я выслушал, хотя дальнейшие ОБОСНОВАННЫЕ советы "против"
> тоже приветствуются - обсуждение продолжается!!!

> В общем, сам с удовольствием выслушаю другие мнения.

Да господи, наберите в поисковике, копий ломано море. На SQL.ru каждая ветка на эту тему не менее 500 постов. Мнения за и против примерно 50/50 и там, и там мелкие преимущества и мелкие недостатки. Ни одного серьезного плюса вроде ни кто не высказал.

> atruhin © (18.08.06 13:18) [21]
> Мнения за и против примерно 50/50 и там, и там мелкие преимущества
> и мелкие недостатки. Ни одного серьезного плюса вроде ни
> кто не высказал.

:-)) интересуют мнения в КОНКРЕТНОЙ ситуации (см. выше!)

> Ro-man © (18.08.06 13:16) [20]
> в моей "задумке"

Странная задумка. можно всего-навсего организовать в бд таблицу, в которой
будут храниться отчеты и хранимую процедуру выборки из таблицы.
Юзерам дать право только на процедуру, процедуре права на таблицу, и в
самой процедуре уже разруливать кому по запросу какой отчет дать. или не дать.
Шаблоны должен заливать ответственный за разработку шаблонов,
готовые отчеты (я так понял, по т.з. сами юзвери не формируют отчетов)
- ответственный за это дело сервис.

> [20] Ro-man © (18.08.06 13:16)
> как и кем у тебя производится вышеупомянутое действие (автомат/полуавтома
> т, админ/юзверь)?

Я создал, я залил. Через админское ПО, нами же разработанное (наполовину или того меньше :( , в смысле разработано на половину).

> [21] atruhin © (18.08.06 13:18)
> Мнения за и против примерно 50/50 и там, и там мелкие преимущества
> и мелкие недостатки. Ни одного серьезного плюса вроде ни
> кто не высказал

Вот-вот. И я о том же. Один флуд.

> [24] unknown © (18.08.06 13:37)

Поддерживаю.

> [25] Ro-man © (18.08.06 13:49)

Окна - в смысле для передачи параметров? Можно и так, и так. Если поручить CR, то увидишь диалог на английском с именами параметров, что пользователю вряд ли понравится. А можешь свое перед построением отчета и передать в параметрах значения. У нас типа второе.

> evvcom © (18.08.06 14:03) [26]
> ...А можешь свое перед построением отчета и передать в параметрах
> значения. У нас типа второе.

Хорошо, "...свое перед построением отчета..." - создаётся динамически (т.е. в disign time его не существует), а значения всех переопределённых свойств формы (и м.б. сама форма?), VCL-компонентов, принадлежащих форме и т.д. и т.п. хранятся в БД???
P.S. Какие компоненты (компонент?) на форме у Вас используются для ввода параметров пользователями? Неужели один DBGrid или аналогичный???

Вопросы по реализации 3-х звенного приложения... Найти похожие ветки