Межпрограммное взаимодействие. Собираю идеи.

← →
Людмила (2007-03-16 19:19) [0]

Добрый вечер всем!
Я на пороге нового проекта. Есть необходимость обеспечить обмен большими блоками данных между программами, написанными на разных платформах. Я пишу на Delphi. Компетентные люди, кто имел опыт работы с подобными вещами, подскажите пожалуйста варианты технологий. В данный момент собираю разные идеи и рассматриваю все варианты с их плюсами и минусами. Специфика данных - большие потоки чисел. Передаваться должны быстро. Заранее благодарна.

← →
Belorus © (2007-03-16 19:53) [1]

Написано заумным языком и слишком мутно.... Напишите попроще... Больше конктретики....

Разводить палемику о неизвестных платформах, неизвестных задачах и.т.д это в ПРОЧЕЕ.

← →
Virgo_Style © (2007-03-16 23:14) [2]

было бы интересно узнать, что подразумевается под разными платформами, учитывая, что

> Я пишу на Delphi.

← →
Германн © (2007-03-17 02:21) [3]

> Людмила (16.03.07 19:19)
>
> Добрый вечер всем!
> Я на пороге нового проекта. Есть необходимость обеспечить
> обмен большими блоками данных между программами, написанными
> на разных платформах.

TCP/IP - "рулёз форева"!

← →
MsGuns © (2007-03-17 20:38) [4]

БД

← →
Desdechado © (2007-03-17 21:02) [5]

MsGuns © (17.03.07 20:38) [4]
Вряд ли подойдет, если это "потоки" и "обрабатываться должно быстро". Хотя конкретики нет, все может быть.

← →
Loginov Dmitry © (2007-03-17 21:04) [6]

Memory Mapping
Все остальное от лукавого :)

← →
Desdechado © (2007-03-17 21:12) [7]

> Memory Mapping
мдя, а как его на наладоннике сделать?

← →
Loginov Dmitry © (2007-03-17 21:25) [8]

Не слышал здесь упоминание о наладонниках. Что касается термина "разные платформы" - как-то здесь туманно все.

← →
clickmaker © (2007-03-18 12:23) [9]

> [0] Людмила (16.03.07 19:19)

если ключевой момент именно "между программами, написанными на разных платформах", то tcp/ip, сокеты. А какие еще варианты?

← →
Людмила (2007-03-19 18:08) [10]

> было бы интересно узнать, что подразумевается под разными платформами
Как минимум C, и наверняка что-то еще. Конкретики нет. Возможность стыковки с разными платформами - это требование, и оно видимо принципиально не уточняется.

> Memory Mapping
Самый приятный вариант в плане скорости. Но в чистом виде - недостаточный. Каждое из приложений будет лезть в разделяемую память и побайтово считывать мегабайты данных, а потом перегонять их в какой-нибудь внутренний формат. Т.е. каждое приложение вынуждено писать конвертер "разделяемая память - внутренной формат". Хочется как-то этого избежать. Что-нить универсальное выдумать.

> БД
Лучше, потому что там данные уже будут структурированными, да и отслеживать транзакции будет легче. Проблема - скорость. Вот как запросит какое-нибудь приложение 30 мегабайт, и чтоб моментально. Надо пробовать каждую конкретную СУБД. Пробовали 3 года назад Oracle 8 - было медленно, отказались. Да и проблемы с лицензированием и поставкой.

> сокеты
Для небольших порций данных - пробовали, нормально. Но что будет, если сразу те же 30 метров передать? Да и необходимость перекачивать данные из сокетов в какой-нибудь внутрений формат остается. В этом случае разделяемая память лучше.

P.S. Данные - цифровые сигналы разного характера, разного и большого объема, в разных условиях и т.п. В общем, не очень структурированные, но и не один сплошной поток.

← →
Belorus © (2007-03-19 18:44) [11]

> > было бы интересно узнать, что подразумевается под разными
> платформами
> Как минимум C

С - это не платформа, а один из языков программирования...

← →
zdm © (2007-03-19 21:05) [12]

IMHO, тока камни сразу не кидайте. По сколько конкретики нет, то есть только мысли...
. Большие перемещающиеся блоки подразуамевают, в основном нагрузку на CPU-Cach_Lavel2_Memory и по этому , нагружать только сервак, конечно правильно, но лучше уже (с подрузомиванием мощности современных компов) рассредоточить расчет математеки на клиентские машины, а серваку пусть достанутся только запросы и процедуры.

← →
zdm © (2007-03-19 21:11) [13]

> Людмила (16.03.07 19:19)

Ты пишешь, что пишешь на Delphi и тебе скажут, что тут лучше писать на Accambler-переучишся? ;)
а под обменом данных , ты что подрузомиваешь? если БД, то и пиши как писала, а если Edit чужого запущенного окна словить, то API-FindWindow

← →
Dust © (2007-03-20 00:25) [14]

лучшие средства IPC предоставляет MSDN.
и не только сокеты MMF и окна, но так же Pipe"s, Named Pipe"s, Mail Slot"s, etc
и ещё, без внутренних буферов в этом случае не обойтись, вообще

← →
clickmaker © (2007-03-20 12:24) [15]

> Возможность стыковки с разными платформами - это требование,
> и оно видимо принципиально не уточняется

весьма расплывчатое требование. Что, заказчик сам не в курсе, чего он хочет? Платформа - если это ОС (Windows - Unix etc) - в этом случае сокеты - пожалуй, единственное приемлимое решение.

> Для небольших порций данных - пробовали, нормально. Но что
> будет, если сразу те же 30 метров передать?

музычку и прочее из сети качаешь? Если канал выделенный (типа ADSL), то хоть 3, хоть 30 метров - особо не почувствуешь. А это все сокеты.

← →
Romkin © (2007-03-20 14:04) [16]

Чем СОМ плохо? Универсально.

← →
Людмила (2007-03-20 14:07) [17]

> С - это не платформа, а один из языков программирования...

Платформа - имеется ввиду платформа разработчика - Delphi, С#, C++ и возможно что-то еще.

> По сколько конкретики нет, то есть только мысли...

Именно мысли мне сейчес и нужны :)

> Ты пишешь, что пишешь на Delphi и тебе скажут, что тут лучше писать на > Accambler-переучишся? ;)

Нет, я спрошу, чтоб мне такое использовать, чтобы ко мне могли пристыковаться те, кто пишет на Assembler ;)

> а под обменом данных , ты что подрузомиваешь?

Речь о том, чтоб выбрать этот способ обмена данными - БД, Mapped Files или что другое. То, что удобно при передаче больших объемов цифровых сигналов между приложениями, которые эти сигналы отрисовывают, обсчитывают и т.п.

> и ещё, без внутренних буферов в этом случае не обойтись, вообще

Похоже :(. Просто хотелось эти буферы как-нибудь унифицировать. Поскольку структура данных-то у всех приложений будет одинаковая. Типа, предъявить всем некоторый стандарт.

> Что, заказчик сам не в курсе, чего он хочет?

Заказчик не в курсе, кто участвует в проекте и на каких языках пишет. Отсюда требование - чтоб все общались независимо от платформы разработчика.

P.S. Интересно, а почему никто не предлагает COM?

← →
Людмила (2007-03-20 14:08) [18]

Идеи пришли с разницей в 4 минуты :)

← →
clickmaker © (2007-03-20 14:11) [19]

> имеется ввиду платформа разработчика - Delphi, С#, C++

это не платформа.
Это среда разработки + язык

Грамотно сформулированный вопрос быстрей приведет к ответу :)

← →
Людмила (2007-03-20 14:28) [20]

>> имеется ввиду платформа разработчика - Delphi, С#, C++

> это не платформа.
> Это среда разработки + язык

Цитирую техзадание - там упоминается платформа, хотя явно имеется ввиду среда. Может, это просто вопрос терминов ;) ?

← →
Сергей М. © (2007-03-20 14:41) [21]

> Людмила (20.03.07 14:28) [20]

> Цитирую техзадание

Фтопку такое ТЗ, которое допускает неоднозначное толкование требований)

А по сабжу - NamedPipes.

← →
Ш-К (2007-03-20 15:53) [22]

> P.S. Интересно, а почему никто не предлагает COM?

Слово "платформа" настораживает. )

← →
Людмила (2007-03-20 16:11) [23]

> Слово "платформа" настораживает. )

Еще раз - конечно не платформа, а среда и язык разработки. Платформа - Windows.

← →
Ш-К (2007-03-20 16:24) [24]

А сие программы, которые обмениваются, запущены в одной ОС?

← →
Ш-К (2007-03-20 16:26) [25]

И от одного пользователя?

← →
Людмила (2007-03-20 16:27) [26]

> А сие программы, которые обмениваются, запущены в одной ОС?

Да. Точно.

← →
Людмила (2007-03-20 16:28) [27]

И от одного пользователя.

← →
clickmaker © (2007-03-20 16:37) [28]

еще вариант - WM_COPYDATA

Старый способ: txt файлы.
До сих пор их используем для обмена данных от клиенбанка в наши проги.
Дёшево и сердито и в меру универсально!

← →
Ш-К (2007-03-20 17:21) [30]

1. MMF
2. Named Pipes (забудь про 98)
3. DDE
4. WM_COPYDATA
5. COM (можно расширить, и на ассинхронность, и на слабосвязность, и на удаленность)
5.1 СОМ+, MTS (пушкой по воробъям)
6. Сокеты (нужно открывать порт)
7. Ну и по таймеру дергать что-нибудь.

← →
Людмила (2007-03-20 17:21) [31]

> еще вариант - WM_COPYDATA

Спасибо, пригодится. Но остается проблема - под каждый тип данных писать спецификацию, что и в каком порядке записывается в буфер при передаче (типа, сигнал стольки-то мерный, получен в таких-то условиях, сами данные, и т.п.). Чтоб читающее приложение знало, как ему этот буфер читать. И таких типов данных - целое ветвистое дерево. Вот этот процесс записи/чтения хочется унифицировать, чтоб пришущее и читающее приложения не заморачивались, какой конкретно тип данных они сейчас пишут или читают, сколько это займет места в буфере, и что в каком порядке туда писать.

> Старый способ: txt файлы
Не подойдет. Будет медленно и ненадежно.

Низкий уровень предполагает написание врапперов, для обмена информацией. В конце все сведется к библиотеке интерфейсов.
Вопрос, зачем делать то, что уже есть? :)
Есть СОМ. Достаточно просто делается на Delphi и C++. Объектная (компонентная) технология, но при желании можно и спускаться на более низкие уровни ;)

← →
Людмила (2007-03-20 18:07) [33]

> Ш-К (20.03.07 17:21), Romkin © (20.03.07 17:24)

Я вот тоже облизываюсь на COM, просто никогда с ним не работала. Поэтому не знаю, насколько он производителен - насколько реально и быстро перекинуть объект с данными порядка пары сотен мегабайт.
Попутный вопрос - реально перевести существующую объектную модель, написанную на Delphi, в COM? Или придется все писать заново? У нас уже есть нормальная модель данных, хоть и слегка устаревшая. Есть соблазн пользоваться ею дальше - просто опубликовать ее интерфейсы для сторонних приложений.
Пока в качестве альтернативы вижу либо БД, либо Mapped Files и WM_COPYDATA с набором врапперов под каждый тип даных.

1. Эрик Хармон. Разработка COM-приложений в среде Delphi. http://www.williamspublishing.com/Books/X_DelphiCOM.html
Увы, распродано. Но книга хорошая :)
2. Производительность СОМ зависит от того, как программировать: Скажем так, для раннего связывания вызов метода интерфейса сравним по скорости с вызовом метода объекта. Для позднего - стоимость вызова на порядок больше. Поясняю: именно стоимость вызова.
Быстро перекинуть объект - опять же, смотря как кидать будете :) Путей много.
Перевести существующую модель на интерфейсы можно, причем на любом уровне (см например TComponent). Все зависит от того, что там понаписано, точнее, как это все ложится на модель COM.
Можно написать врапперы, а можно и внедрить интерфейсы, либо просто воспользовавшись визардом создать аналогичную новую иерархию, и заполнить методы сопи/пасте, либо просто дописать интерфейсы к имеющимся объектам, поменяв объявления классов и их методов.
Из недостатков СОМ можно назвать более высокие требования к ресурсам по сравнению с низким уровнем (скажем так, размер оперативной памяти для приложения от 3 Мб и выше), и меньшее разнообразие типов.
Из достоинств - компонентная, языконезависимая модель, прозрачная передача данных между процессами, практически автоматический менеджмент потоков через апартаменты.

Насчет передачи больших массивов данных: есть IStream, и в Delphi даже врапперы для него написаны :)
Вот например: создаем приложение, для него создаем Automation object (чтобы было ;)), с именем, например, FileRead. В интерфейсе - один метод, принимающий имя файла и возвращающий IUnknown, у меня так получилось:
[ uuid(41D4E28E-FFA6-421D-8694-312F9949F062), version(1.0), helpstring("Dispatch interface for FileStream Object"), dual, oleautomation ] interface IFileRead: IDispatch { [ id(0x00000001) ] HRESULT _stdcall GetStream([in] BSTR FileName, [out, retval] IUnknown ** Result ); };
В реализации метода - пара строк,
function TFileRead.GetStream(const FileName: WideString): IUnknown; var Stream: TStream; begin Stream := TFileStream.Create(FileName, fmOpenRead or fmShareDenyWrite); Result := TStreamAdapter.Create(Stream, soOwned) as IUnknown; end;
Запускаем, чтобы была регистрация. Создаем второе приложение, и импортируем в него библиотеку типов. На форму - кнопочку:
procedure TForm2.Button1Click(Sender: TObject); var FileRead: IFileRead; Stream, FileStream: TStream; obj: IStream; begin FileRead := CoFileRead.Create; OleCheck(FileRead.GetStream("d:\sp6i386.exe").QueryInterface(IStream, obj)); Stream := TOleStream.Create(obj); try ShowMessage(IntToStr(Stream.Size)); FileStream := TFileStream.Create("d:\sp6i386.~xe", fmCreate); try FileStream.CopyFrom(Stream, Stream.Size); finally FileStream.Free; end; finally Stream.Free; end; end;
Цапнул первый попавшийся файл. Вот и все, передача потока между приложениями готова.

← →
Людмила (2007-03-20 19:07) [36]

> Romkin © (20.03.07 18:31) [34]
> 1. Эрик Хармон. Разработка COM-приложений в среде Delphi. http://www.williamspublishing.com/Books/X_DelphiCOM.html
> Увы, распродано. Но книга хорошая :)

Ура! Я нашла эту книгу у нас на работе! Спасибо. Будем обдумывать :)

> можно и внедрить интерфейсы, либо просто воспользовавшись визардом создать аналогичную новую иерархию, и заполнить методы сопи/пасте

Для всего, что понаписано, это работа на год :)

> либо просто дописать интерфейсы к имеющимся объектам, поменяв объявления классов и их методов.

А вот это уже и удобно и красиво :).

Для "удобно и красиво" надо иметь хорошее представление о COM :)
По крайней мере, типы и соглашения о вызовах методов, скорее всего, придется поменять, подшить фабрики классов, решить вопрос о контроле ссылок (например, у потомков TCOMObject традиционно есть контроль ссылок, а у TComponent - нет, его время жизни контролируется владельцем), о том, публичный объект или нет, об агрегации...
Лучше всего, кстати, сначала создать библиотеку типов со всеми интерфейсами, а потом их реализовывать, примерно как здесь http://www.sources.ru/wiki/doku.php?id=delphi:interfaces_and_plugins#автоматизация
И я бы рекомендовал использовать именно библиотеку типов для описания интерфейсов, не придется переводить с языка на язык :)

← →
Людмила (2007-03-20 19:48) [38]

> По крайней мере, типы и соглашения о вызовах методов, скорее всего, придется поменять

Ну эту проблему, наверное, можно решить, дописывая интерфейсы "сверху" уже к имеющимся классам? В этот момент типы и вызовы методов и можно переопределить при необходимости?

> http://www.sources.ru/wiki/doku.php?id=delphi:interfaces_and_plugins#автоматизация

Круто! :)
Хотя для меня теперь это поле непаханое :( Все равно работы на год.

> Людмила (20.03.07 17:21) [31]

> > Старый способ: txt файлы
> Не подойдет. Будет медленно и ненадежно.

> насколько реально и быстро перекинуть объект с данными
> порядка пары сотен мегабайт.

Для передачи пары сотен мегабайт ничего надежней файла
еще пока, IMHO, не придумали.
Ну, а насчет быстроты - это, во многом, зависит от исполнения.
Хотя, конечно, "текстовость" тут вовсе не нужна.

--
Regards, LVT.

> Ну эту проблему, наверное, можно решить, дописывая интерфейсы
> "сверху" уже к имеющимся классам?

Можно. Написать адаптеры, пример - TStringsAdapter. Но, опять же - в каждом методе писать вызов метода объекта, и иногда еще преобразовывать данные.

Межпрограммное взаимодействие. Собираю идеи. Найти похожие ветки