...+подключение отчётов в виде 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" отчеты обязательно должны подключаться, НЕ останавливая работу пользователей.

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

bas gybsonНа чем пишите то?
Да, правильно, если выбрали уже ЯП, то нужно идти в профильный форум, там лучше подскажут.
ЯП - Delphi. Так как с dll уже практически определился (подсказали другие варианты реализации отчётов - вопрос задавался в том числе и на форумах по Delphi :-) ), то всё ещё остаётся открытым вопрос к спецАм, уже имеющим опыт создания подобных ИС. Поделитесь опытом, пожалуйста - с помощью каких средств реализовывали, какие грабли и т.п. :) Хотелось бы, так сказать, идти "по протоптанным граблям"...

gybson
Я бы посоветовал даже не COM, а DCOM, получится сервер приложения :) В msdn есть хорошие статьи по принципу организации
C помощью DCOM хотелось бы в самую последнюю очередь. "...не COM, а DCOM" - без COM всё равно не обойтись - TRemoteDataModule и есть COM-объект, точнее сервер автоматизации. "...получится сервер приложения" - но при помощи сокетов тоже может получиться СП ;)
По поводу статей - посмотрю, как время будет, но если есть под рукой ссылочки на "хорошие статьи по принципу организации" - все сюда, за что заранее спасибо и респект!

gybson
но при помощи сокетов тоже может получиться СП ;)


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

iscrafm , перечислите хотя бы основные (грабли), если не секрет! ;) Я хотя бы начну готовиться.
З.Ы. Вы являетесь одним из тех, кому доводилось создавать ИС, подобные subj'у?

обо всём по-порядку (постараюсь всем ответить и никого не обидеть ;) )

iscrafm Petro123зря вы так резко.
Конкретики у вас тоже маловато ("основные грабли - сервер приложений").

Больше не скажешь. Дальше идут только описания безграблевых алгоритмов. Кто ж их даст :)
Конкретики действительно маловато... Вас, iscrafm , как специалиста уже освоившего подобные ИС я и хотел спросить, какие ОСНОВНЫЕ (я не знаю, как по-другому сформулировать - ГЛОБАЛЬНЫЕ, что-ли, т.е. те, с которыми столкнётся ЛЮБОЙ разработчик типового СП) проблемы встречаются при создании СП /по пунктам, если можно ;)/ и основные проверенные пути их разрешения... если, конечно, не жаль времени (или опыта :) ) чтобы делиться опытом.
P.S. алгоритмы и, так сказать, направления (куда надо копать :)) ) - это несколько разные вещи IMHO.

Alexey Kudinov 2 Ro-man
Я не уверен, что понял в чем именно состоит ваша задача (деталей вы привели много, но суть как-то ускальзывает), но возможно, вам стоит задуматься о готовых reporting-серверах. У нас популярен Crystal reports, но есть и другие
насчёт "ускользает" Вы правы на 100%! Что же, постараюсь восполнить пробел :)
Между всеми 3-мя типами баз данных существуют следующие потоки данных:
"БД3":
- входными данными для неё являются большая часть данных (практически всё), поступающих в "БД1"
- исходящие данные - это данные из таблиц-справочников, которые должны поступать в "БД1" (и затем уже в "БД2") и ДОЛЖНЫ БЫТЬ СИНХРОНИЗИРОВАНЫ во всех 3-х типах БД.
"БД1":
- входной поток данных - см. исходящ. для "БД3" и данные, поступающие в "БД2" (практически всё). Также все данные, генерируемые пользователями 1-й группы.
- исходящие данные - это данные из таблиц-справочников, которые должны поступать в "БД2" и ДОЛЖНЫ БЫТЬ СИНХРОНИЗИРОВАНЫ во всех 3-х типах БД. Также некоторая часть данных, генерируемая пользователями 1-й группы.
"БД2":
- входные данные - см. исходящ. для "БД1" и все данные, генерируемые пользователями 2-й группы.
- исходящие данные (поступают в "БД1") - вся необходимая информация для пользователей 1-й группы.

Вот, вкратце всё! Надеюсь, что не запутал ещё сильнее :)
P.S. Для публикации данных в Inet предварительно выбран FastReport Server (выборка будет ТОЛЬКО из "БД3"). Если есть лучшие решения (в том же ценовом диапазоне) - предлагайте, не стесняйтесь! :)

Petro123 ЗЫ. Сам почитал перед новым проектом (спасибо форуму) и отказался от 3-х звенки.
Как Вы подобное (см. выше) реализовали бы с помощью обычной КС (2-х звенной) архитектуры? Ваши предложения. Если что-то будет конструктивное, возможно, я тоже откажусь, но пока не вижу приемлемой альтернативы.