информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 С наступающим 
 Серьезная уязвимость в Apache Log4j 
 Крупный взлом GoDaddy 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Часто схожие B2B/ETL задачи решают так: 24.05.08 20:11  Число просмотров: 1381
Автор: 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.

Как-то так.
<programming> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach