| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Вопросы по реализации 3-х звенного приложения... [Firebird1.5]
Ro-man © (2006-08-17 14:57:00)...+подключение отчётов в виде 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" отчеты обязательно должны подключаться, НЕ останавливая работу пользователей.
Заранее благодарю всех, принявших участие в обсуждении,
буду рад выслушать все ваши предложения!
roottim (2006-08-18 09:01:00) [21]Чем же FastReport Server не подходит для остальных отчетов?
Вы хоть посмотрели все его возможности в онлайн демонстрации http://80.254.117.74/
и мое имхо: трехзвенка тут нафиг не нужна , browser+ssl-http-server+cgi-rdbms достаточное решение.
evvcom (2006-08-18 08:46:00) [22]
> [3] Ro-man © (17.08.06 17:34)
> используя для реализации всей бизнес-логики никак НЕ клиентское
> ПО и ср-ва сервера БД (ХП и т.п.),
Почему не БД?
> а среднее звено (сервер приложений),
ну хозяин - барин. Но по-любому серверный запрос отработает гораздо быстрее, чем твои фильтрации и т.п. на сервере приложений, реализующем бизнес-логику.
> которое, скорее всего, будет находиться на отдельном компе
ну ясное дело. На то он и сервер.
> (а уж постоянные соединения-отключения от СУБД и того хуже)
> для обычных клиент-серверных приложений - это просто КОНЕЦ
Я не знаю как для жарптицы постоянные дисконнекты, с ораклом у меня на этот счет проблем нет. Добавлена обработка ошибки на дисконнект и автоматический перелогон и повторная отправка запроса на клиенте и нет проблем.
> Также, (это уже есть в вопросе) отчёты - каким образом в
> случае обычной 2-х звенки ничего не перекомпилируя (имеются
> ввиду ХП) на сервере БД и не "распихивая" по клиентам сделать
> так, чтобы новые отчёты были доступны ВСЕМ пользователям
> БД?
Мы используем Crystal Reports. Его *.rpt храним на сервере в блобе, имена параметров процедур собраны в отдельной табличке с русским названием параметра и прочими аттрибутами для того, чтобы программа знала, как пользователю его преподнести: то ли ввод числа, даты, то ли вызов справочника с получением ID и проч. С добавлением нового отчета не перекомпилируем ни клиента, ни ХП в СУБД, только пишем новую ХП под отчет (запрос, кот. вероятно ты собираешься поместить в сам отчет), раздаем полномочия, заливаем отчет на сервер, регистрируем его и параметры. Причем клиент прежде, чем запустить отчет, проверяет, не появилась ли новая версия? Естественно изначально мы даже не паримся с тем, чтобы отчет скопировать пользователю на машину, все это клиент сам сделает.
Ro-man (2006-08-18 01:00:00) [23]
> unknown ©
> Да. Вышел недавно. 14970 р. - это дорого?
нет, за 1 не дорого - это, я думаю, приемлемое решение для публикации данных в Inet. Благодарю за полезную ссылку.
А насчет остальных отчетов FastReport Server - это не вариант, поэтому жду новых советов и предложений!
unknown (2006-08-17 18:44:00) [24]
> Ro-man © (17.08.06 17:34) [3]
> вышел он относительно недавно и к тому же ещё сыроват (+стОит немалых денег).
Да. Вышел недавно. 14970 р. - это дорого?
> Одна из главных причин - создать "тонкого клиента", используя
> для реализации всей бизнес-логики никак НЕ клиентское ПО
Хозяин - барин :)
> Плюс при таком "безбашенном" "модемном connect'е"
Всего-то на клиентах правильно обрабатывать дисконнекты. А траффик
можно сжимать. И шифровать. см. ZeBeDee - http://www.winton.org.uk/zebedee/
Ro-man (2006-08-17 17:34:00) [25]
> FastReport Server - должен подойти
Работали уже с ним? Я слышал, что вышел он относительно недавно и к тому же ещё сыроват (+стОит немалых денег).
> И, собственно, непонятно - зачем 3-х звенка?
Одна из главных причин - создать "тонкого клиента", используя для реализации всей бизнес-логики никак НЕ клиентское ПО и ср-ва сервера БД (ХП и т.п.), а среднее звено (сервер приложений), которое, скорее всего, будет находиться на отдельном компе.
Плюс при таком "безбашенном" "модемном connect'е" (см. выше) постоянное соединение (а уж постоянные соединения-отключения от СУБД и того хуже) для обычных клиент-серверных приложений - это просто КОНЕЦ :-)
Также, (это уже есть в вопросе) отчёты - каким образом в случае обычной 2-х звенки ничего не перекомпилируя (имеются ввиду ХП) на сервере БД и не "распихивая" по клиентам сделать так, чтобы новые отчёты были доступны ВСЕМ пользователям БД? ;-)
unknown (2006-08-17 15:54:00) [26]И, собственно, непонятно - зачем 3-х звенка?
unknown (2006-08-17 15:53:00) [27]
> Ro-man © (17.08.06 14:57)
> ...+подключение отчётов
FastReport Server - должен подойти.
http://www.fast-report.com/ru/products/products.php?BID=44
| |
Страницы: 