![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
MIDAS: Child RemoteDataModule в подгружаемых BPL [D6, Win2k]
mvg_first © (2002-11-12 17:23:00)Хочу написать продвинутый сервер приложений который можно настраивать за счет подключения плагинов. Под плагинами я подразумеваю BPL который подключаю к основному приложению. (технологию использования BPL как плагинов - взял с сервера delphikingdom).
Так же в справке по MIDAS-у вычитил что можно создавать дочерние модули данных и получать к ним доступ через базовый модуль данных. С этим вроде бы вопросов нет, - если все работает в одном экзшнике.
Вопрос: возможно ли дочерние модули данных хранить в подключаемых BPL-ах??? Если да то вкратце расскажите как это сделать?
Набережных С. (2002-11-15 17:42:00) [1]А то! Еще как!:))) Смотри почту.
mvg_first (2002-11-15 17:19:00) [2]Набережных С. Отзовись пожалуста, еще пару вопросов нужно задать :)
mvg_first (2002-11-15 12:54:00) [3]Набережных С.
Я тебе письмо кинул - глянешь?
Набережных С. (2002-11-14 20:09:00) [4]>Как я понял - это совершенно не обязательно :) Так ведь?
Конечно, нет. Как удобно, так и подключай. Идея-то в том, что юзер клиента может выбрать нужный плагин из списка, а список удобно хранить в реестре. При этом для подключения новых плагинов достаточно зарегистрировать его в собственном разделе реестра. Считал список, юзер выбрал и можно загружать, преобразовав строку в GUID. А клиент-плагин уже сам знает, какие ему объекты запросить у сервера.
А ICQ у меня нет, мне вера не позволяет:) Да и свободного времени не шибко много. Так что, если что - в почту. Правда, я и почту иногда подолгу не проверяю. Да тему понятно указывай, а то я некоторые письма не читая в мусор отправляю:)
mvg_first (2002-11-14 19:50:00) [5]Еще вопросец по примерам: У тебя там Сервер, серверный плагин, Клиент и клиентский плагин. А обязательно ли клиентский плагин поюключать через CreateComObject?
Как я понял - это совершенно не обязательно :) Так ведь?
mvg_first (2002-11-14 19:43:00) [6]Вообщем, пасматрел, почесал затылок, ПРОЗРЕЛ!!! И выражаю тебе величайшую благодарность, будете у нас на ... с меня много пива :)
А можно ли получить твой ICQ номер для общения, потому как я чуствую несколько вопросов мне еще придется задать.
Мой номер ICQ (84705448)
Большинство из них концептуальные, но могут быть и чисто-технические. Гладишь и поможешь чем :)
mvg_first (2002-11-14 19:25:00) [7]Вообщем по первому шото идет :) Размером с ~64к :)
Набережных С. (2002-11-14 19:21:00) [8]Ты опоздал с поправкой:) Посмотри, может по первому пройдет.
Набережных С. (2002-11-14 19:20:00) [9]Ушло на оба.
mvg_first (2002-11-14 19:18:00) [10]Абшибся второй адрес mvgfirst@myrealbox.com
mvg_first (2002-11-14 19:12:00) [11]А можешь продублировать на
mvg@0day.ru
и на
mvgfirst@myrealbox.ru
А то
nm.ru глючит последних два дня по черному :(
Набережных С. (2002-11-14 18:23:00) [12]Смотри почту. Только пути поиска поправь перед компиляцией
Набережных С. (2002-11-14 17:15:00) [13]Подожди пол-часа, накидаю пример.
mvg_first (2002-11-14 16:52:00) [14]Блин запутано объяснил.
Я имел ввиду что на одной физической машине может находится большое количество отдельных приложений каждое из которых является СОМ сервером.
Не будет ли такой подход к организации "сервера приложений", торомзить физическую машину. И какие еще побочные эффекты могут быть при таком подходе?
mvg_first (2002-11-14 16:50:00) [15]Я вот тут посидел подумал, а может лучше сделать несколько отдельных серверов, каждый из них будет заточен на определенную функциональность?
Например, будет несколько базовых серверов: Один отвечает за права пользователей, второй за журналирование событий, и т.д. остальные сервера, будут отвечать за бизнес логику, (склад,зарплата,еще что-либо).
Не будет ли наличее большого количества компонент сильно грузить сервер?
Или может это "извращения"?
mvg_first (2002-11-14 16:44:00) [16]А можно пример привести? А то я тоже чего то торможу совсем. Идеологию понимаю, а вот как это в реальный код задвинуть осознать не могу.
И вот еще вопрос "набор параметров" - каким образом передавать?
OpenArray?
Набережных С. (2002-11-14 15:10:00) [17]От, блин, дошел до кондиции. Отдыхать надо больше, а не сидеть пол-ночи за ящиком.
>mvg_first ©
Ты на слова о маршаллинге внимания не обращай. Не к месту они тут, зациклился.
Набережных С. (2002-11-13 21:49:00) [18]Простейший вариант:
Клиент передает серверу ClassID плагина, набор параметров и ID метода. Сервер стандартными средствами COM загружает требуемый объект, вызывает у него Invoke и результат возвращает клиенту.
Есть и более эффективные методы, но их реализация несколько сложнее. Например, клиент передает серверу ClassID. Тот создает объект, маршалирует его IUnknown или IDispatch в буфер и возвращает буфер клиенту. Клиент демаршалирует интерфейс из буфера и сам работает с клиентом. Ну и т.д.
mvg_first (2002-11-13 20:24:00) [19]Ну что? Никто никаких идейных соображений не добавит? Может поправит кто? Укажет на концептуальный ошибки?
А может кто желает поучаствовать в разработке такового ядра?
mvg_first (2002-11-13 12:55:00) [20]Чтоб легче было понимать мои вопросы, немножечко расскажу о цели моей разработки.
Я пытаюсь создать ядро некой системы (предполагается достаточно крупная система) работающей по 3-х звенной схеме. Т.е. есть сервер БД, есть сервер-приложений (СП) и клиент. Так же хочу создать набор плагинов "серверных" и "клиентских", которые будут расширять возможности "бизнес-логики" СП.
К примеру, есть на предприятии, складская система, и захотел я добавить новый документ в складскую систему - написал плагин, для сервера и для клиента, подключил к системе и все. Система знает и умеет работать с данным типом документа.