| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Межпрограммное взаимодействие. Собираю идеи. [D7, WinXP]
Людмила © (2007-03-16 19:19:00)Добрый вечер всем!
Я на пороге нового проекта. Есть необходимость обеспечить обмен большими блоками данных между программами, написанными на разных платформах. Я пишу на Delphi. Компетентные люди, кто имел опыт работы с подобными вещами, подскажите пожалуйста варианты технологий. В данный момент собираю разные идеи и рассматриваю все варианты с их плюсами и минусами. Специфика данных - большие потоки чисел. Передаваться должны быстро. Заранее благодарна.
Romkin (2007-03-21 10:49:00) [1]
> Ну эту проблему, наверное, можно решить, дописывая интерфейсы
> "сверху" уже к имеющимся классам?
Можно. Написать адаптеры, пример - TStringsAdapter. Но, опять же - в каждом методе писать вызов метода объекта, и иногда еще преобразовывать данные.
Leonid Troyanovsky (2007-03-20 19:56:00) [2]
> Людмила (20.03.07 17:21) [31]
> > Старый способ: txt файлы
> Не подойдет. Будет медленно и ненадежно.
> насколько реально и быстро перекинуть объект с данными
> порядка пары сотен мегабайт.
Для передачи пары сотен мегабайт ничего надежней файла
еще пока, IMHO, не придумали.
Ну, а насчет быстроты - это, во многом, зависит от исполнения.
Хотя, конечно, "текстовость" тут вовсе не нужна.
--
Regards, LVT.
Людмила (2007-03-20 19:48:00) [3]> По крайней мере, типы и соглашения о вызовах методов, скорее всего, придется поменять
Ну эту проблему, наверное, можно решить, дописывая интерфейсы "сверху" уже к имеющимся классам? В этот момент типы и вызовы методов и можно переопределить при необходимости?
> http://www.sources.ru/wiki/doku.php?id=delphi:interfaces_and_plugins#автоматизация
Круто! :)
Хотя для меня теперь это поле непаханое :( Все равно работы на год.
Romkin (2007-03-20 19:27:00) [4]Для "удобно и красиво" надо иметь хорошее представление о COM :)
По крайней мере, типы и соглашения о вызовах методов, скорее всего, придется поменять, подшить фабрики классов, решить вопрос о контроле ссылок (например, у потомков TCOMObject традиционно есть контроль ссылок, а у TComponent - нет, его время жизни контролируется владельцем), о том, публичный объект или нет, об агрегации...
Лучше всего, кстати, сначала создать библиотеку типов со всеми интерфейсами, а потом их реализовывать, примерно как здесь http://www.sources.ru/wiki/doku.php?id=delphi:interfaces_and_plugins#автоматизация
И я бы рекомендовал использовать именно библиотеку типов для описания интерфейсов, не придется переводить с языка на язык :)
Людмила (2007-03-20 19:07:00) [5]> Romkin © (20.03.07 18:31) [34]
> 1. Эрик Хармон. Разработка COM-приложений в среде Delphi. http://www.williamspublishing.com/Books/X_DelphiCOM.html
> Увы, распродано. Но книга хорошая :)
Ура! Я нашла эту книгу у нас на работе! Спасибо. Будем обдумывать :)
> можно и внедрить интерфейсы, либо просто воспользовавшись визардом создать аналогичную новую иерархию, и заполнить методы сопи/пасте
Для всего, что понаписано, это работа на год :)
> либо просто дописать интерфейсы к имеющимся объектам, поменяв объявления классов и их методов.
А вот это уже и удобно и красиво :).
Romkin (2007-03-20 18:42:00) [6]Насчет передачи больших массивов данных: есть 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;
Цапнул первый попавшийся файл. Вот и все, передача потока между приложениями готова.
Romkin (2007-03-20 18:31:00) [7]1. Эрик Хармон. Разработка COM-приложений в среде Delphi. http://www.williamspublishing.com/Books/X_DelphiCOM.html
Увы, распродано. Но книга хорошая :)
2. Производительность СОМ зависит от того, как программировать: Скажем так, для раннего связывания вызов метода интерфейса сравним по скорости с вызовом метода объекта. Для позднего - стоимость вызова на порядок больше. Поясняю: именно стоимость вызова.
Быстро перекинуть объект - опять же, смотря как кидать будете :) Путей много.
Перевести существующую модель на интерфейсы можно, причем на любом уровне (см например TComponent). Все зависит от того, что там понаписано, точнее, как это все ложится на модель COM.
Можно написать врапперы, а можно и внедрить интерфейсы, либо просто воспользовавшись визардом создать аналогичную новую иерархию, и заполнить методы сопи/пасте, либо просто дописать интерфейсы к имеющимся объектам, поменяв объявления классов и их методов.
Из недостатков СОМ можно назвать более высокие требования к ресурсам по сравнению с низким уровнем (скажем так, размер оперативной памяти для приложения от 3 Мб и выше), и меньшее разнообразие типов.
Из достоинств - компонентная, языконезависимая модель, прозрачная передача данных между процессами, практически автоматический менеджмент потоков через апартаменты.
Людмила (2007-03-20 18:07:00) [8]> Ш-К (20.03.07 17:21), Romkin © (20.03.07 17:24)
Я вот тоже облизываюсь на COM, просто никогда с ним не работала. Поэтому не знаю, насколько он производителен - насколько реально и быстро перекинуть объект с данными порядка пары сотен мегабайт.
Попутный вопрос - реально перевести существующую объектную модель, написанную на Delphi, в COM? Или придется все писать заново? У нас уже есть нормальная модель данных, хоть и слегка устаревшая. Есть соблазн пользоваться ею дальше - просто опубликовать ее интерфейсы для сторонних приложений.
Пока в качестве альтернативы вижу либо БД, либо Mapped Files и WM_COPYDATA с набором врапперов под каждый тип даных.
Romkin (2007-03-20 17:24:00) [9]Низкий уровень предполагает написание врапперов, для обмена информацией. В конце все сведется к библиотеке интерфейсов.
Вопрос, зачем делать то, что уже есть? :)
Есть СОМ. Достаточно просто делается на Delphi и C++. Объектная (компонентная) технология, но при желании можно и спускаться на более низкие уровни ;)
Людмила (2007-03-20 17:21:00) [10]> еще вариант - WM_COPYDATA
Спасибо, пригодится. Но остается проблема - под каждый тип данных писать спецификацию, что и в каком порядке записывается в буфер при передаче (типа, сигнал стольки-то мерный, получен в таких-то условиях, сами данные, и т.п.). Чтоб читающее приложение знало, как ему этот буфер читать. И таких типов данных - целое ветвистое дерево. Вот этот процесс записи/чтения хочется унифицировать, чтоб пришущее и читающее приложения не заморачивались, какой конкретно тип данных они сейчас пишут или читают, сколько это займет места в буфере, и что в каком порядке туда писать.
> Старый способ: txt файлы
Не подойдет. Будет медленно и ненадежно.
Ш-К (2007-03-20 17:21:00) [11]1. MMF
2. Named Pipes (забудь про 98)
3. DDE
4. WM_COPYDATA
5. COM (можно расширить, и на ассинхронность, и на слабосвязность, и на удаленность)
5.1 СОМ+, MTS (пушкой по воробъям)
6. Сокеты (нужно открывать порт)
7. Ну и по таймеру дергать что-нибудь.
Fin (2007-03-20 17:00:00) [12]Старый способ: txt файлы.
До сих пор их используем для обмена данных от клиенбанка в наши проги.
Дёшево и сердито и в меру универсально!
clickmaker (2007-03-20 16:37:00) [13]еще вариант - WM_COPYDATA
Людмила (2007-03-20 16:28:00) [14]И от одного пользователя.
Людмила (2007-03-20 16:27:00) [15]> А сие программы, которые обмениваются, запущены в одной ОС?
Да. Точно.
Ш-К (2007-03-20 16:26:00) [16]И от одного пользователя?
Ш-К (2007-03-20 16:24:00) [17]А сие программы, которые обмениваются, запущены в одной ОС?
Людмила (2007-03-20 16:11:00) [18]> Слово "платформа" настораживает. )
Еще раз - конечно не платформа, а среда и язык разработки. Платформа - Windows.
Ш-К (2007-03-20 15:53:00) [19]
> P.S. Интересно, а почему никто не предлагает COM?
Слово "платформа" настораживает. )
Сергей М. (2007-03-20 14:41:00) [20]
> Людмила (20.03.07 14:28) [20]
> Цитирую техзадание
Фтопку такое ТЗ, которое допускает неоднозначное толкование требований)
А по сабжу - NamedPipes.
| |
Страницы: 