Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Часто схожие B2B/ETL задачи решают так: 24.05.08 20:11 Число просмотров: 1575
Автор: void <Grebnev Valery> Статус: Elderman
|
Часто схожие B2B/ETL задачи решают так:
1) создают приложения, которые переодически или "реал-тайм" (постоянно слушают удалённый источник данных) обновляют свои структуры даных. Пусть это "DOWNLOADER" (в вашем случае - часть кода в составе вашего COM)
2) в составе "DOWNLOADER" или отдельно от него создают ETL модуль ("ETL parser"), который преодразует данные в удобном виде и записывает эти данные в DBMS (в вашем случае это что нибудь free - *.mdb или MySQL, или MSSQL2005 Express, ....)
Синхронизация "DOWNLOADER" и "ETL parser" - особенно простая, если "ETL parser" есть часть "DOWNLOADER". Самое простое в этом случае - "ETL parser" обрабатывает сообщения DOWNLOADER-а синхронно, или асинхронно, выбирая их из очереди. Если "DOWNLOADER" и "ETL parser" в разных процессах - можно использовать именованые event/mutex для синхронизации. Для организации IPC в этом случае - COM самое простое решение. Можно и shared memory/pipe/socket, что гораздо более многодельно.
Таким образом вы сможете обрабатывать следующую цепочку: [Internet soure]->[DOWNLOADER]->[ETL parser]->DBMS.
3) Как вы и хотели, на Delphi пишите клиента своего BackOffice, "CLIENT".
Для синхронизации "CLIENT" можно сделать одно из следующего:
3.1) "CLIENT" "висит" на именованном объекте ядра. Когда "ETL parser" закончил очередное обновление - он "поджигает" event\mutex.
3.2) "ETL parser" снабжает свои данные timestamp и записывает их в DBMS. В этом случае, "CLIENT" может периодически (если это допустимо в бизнес логике) читать последние обновления, сравнивая timestamp.
Как-то так.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
