Каким обр. оптимально реализовать межпрограммное взаимодействие?

← →
Dot (2009-02-03 17:11) [0]

Здравствуйте!
Посоветуйте пожалуйста, каким образом можно, а точнее нужно, реализовать интерфейс в такой ситуации: на машине работает служба, её пользовательский интерфейс реализован в виде отдельного приложения, которое уже загружается под конкретным пользователем.
Как максимально просто и эффективно наладить быстрый обмен данными между службой и интерфейсом (работают они соответственно всегда на одной машине).
На ум приходит DDE, но может есть более современные методы?

← →
Юрий Зотов © (2009-02-03 17:19) [1]

Один из вариантов - сокеты.

← →
Медвежонок Пятачок © (2009-02-03 17:26) [2]

http

← →
Dot (2009-02-03 17:30) [3]

>>Юрий Зотов
Про сокеты думал, но оба приложения гарантированно выполняются на одной машине, по этому есть ли смысл, DDE в данной ситуации точно проще получается (???)
>>Медвежонок Пятачок
Сорри, а можно подробней, о межпрограммном взаимодействии по http я чего-то не слышал ничего :(

← →
Медвежонок Пятачок © (2009-02-03 17:36) [4]

Как максимально просто и эффективно наладить быстрый обмен данными между службой и интерфейсом

убрать специализированный клиентский интерфейс как ненужное звено.
команды сервису : http get и post запросы браузера.
ответы сервиса : xml документ, с визуализацией на странице посредством xsl.

все легко, быстро, гибко и удобно.
плюсом: минус одно win32-приложение

← →
Dot (2009-02-03 17:42) [5]

>>Медвежонок Пятачок
Однако шарите :))) Я про такой вариант даже и не подумал.
Только одна проблема, с интернет-делами не разу не связывался (Сокеты не в счет), поэтому нужно где-то кармы пособирать :)
Может быть подскажите примеры какие, а лучше статейку с теорией, если не затруднит?

← →
Медвежонок Пятачок © (2009-02-03 17:46) [6]

нужно всего лишь реализовать встроенный http север.
или взять готовый TidHTTPServer и написать обработчики запросов.

← →
DVM © (2009-02-03 18:01) [7]

> Медвежонок Пятачок © (03.02.09 17:26) [2]

+1
Это лучший способ

← →
Сергей М. © (2009-02-03 19:40) [8]

> Это лучший способ

В некоем частном случае - да.
В другом некоем частном случае - дерьмовей способа не придумать.

Мне, к примеру, в каком то случае нафих не нужны "услуги" http, браузеров, джавы и прочей интерпретирующей/псевдокомпилирующей, изначально подразумевающей "тормоза" тырнет-лабуды - мне нужна немедленная визуальная реакция интерфейса на события сервиса, на конкретной же интересующей меня платформе)

← →
DVM © (2009-02-03 19:48) [9]

> Сергей М. © (03.02.09 19:40) [8]

> мне нужна немедленная визуальная реакция интерфейса на события
> сервиса, на конкретной же интересующей меня платформе)

http этому нисколько не мешает.

> джавы и прочей интерпретирующей/псевдокомпилирующей, изначально
> подразумевающей "тормоза" тырнет-лабуды

Как мы уже выяcняли и выяснили недавно - java далеко не тормоз. Да что там тормоз - во многих случаях быстрее нативного кода Delphi.

> В другом некоем частном случае - дерьмовей способа не придумать.

Ну вероятно найдутся и такие ситуации. Только мало их.

← →
Сергей М. © (2009-02-03 20:02) [10]

> DVM © (03.02.09 19:48) [9]

> Только мало их

И они имеют право на жизнь.
При отсутствии уточняющих условий автора я бы поостерегся обзывать все это гипертекстово-браузерно-монстрообразное хозяйство "лучшим способом".

Все то что шагает под флагом "Универсальное и кроссплатформенное", никогда не было и не будет "лучшим" ни при каких условиях.

← →
Медвежонок Пятачок © (2009-02-03 20:40) [11]

Все то что шагает под флагом "Универсальное и кроссплатформенное", никогда не было и не будет "лучшим" ни при каких условиях.

Берем что-нибудь другое. Например сокеты или дде.
Что потребуется?
- реализовывать сервер-приемник
- реализовывать протокол.
- реализовывать клиента.

что в случае http?
реализовать обработчики и определиться со структурами возвращаемых данных.
Все.

вклосипед уже готов и едет в отличие от.

← →
Медвежонок Пятачок © (2009-02-03 20:44) [12]

мне нужна немедленная визуальная реакция интерфейса на события сервиса, на конкретной же интересующей меня платформе)

походу здесь сам сервис здесь не нужен.
нужен его функционал в обычном гуи-приложении.
чтобы все моргало и звенело в реалтайме.

← →
Медвежонок Пятачок © (2009-02-03 21:06) [13]

мне нужна немедленная визуальная реакция интерфейса на события сервиса

Это как бы как ни крути, но клиент-серверная архитектура.
А что обычно здесь говорят начинающим, которым позарез требуется немедленное обновление грида без инициативы пользователя на одной машине, если на второй произошел апдейт таблицы?

← →
Германн © (2009-02-04 01:32) [14]

> Медвежонок Пятачок © (03.02.09 20:40) [11]
>
> Все то что шагает под флагом "Универсальное и кроссплатформенное",
> никогда не было и не будет "лучшим" ни при каких условиях.
>
>
> Берем что-нибудь другое. Например сокеты или дде.
> Что потребуется?
> - реализовывать сервер-приемник
> - реализовывать протокол.
> - реализовывать клиента.
>

Для некоего конкретного приложения вполне простая и нормальная задача. Весьма легко решаемая.

← →
Медвежонок Пятачок © (2009-02-04 09:06) [15]

автор спрашивал про как наиболее просто и эффективно.

← →
Dot (2009-02-04 09:29) [16]

О, дискуссия развернулась не шуточная, родилось много интересных мнений, большое спасибо, вчера посмотрел поближе TidHTTPServer, вроде бы все более-менее ясно. Однако Сергей М. телепатически видимо :) доразвил не ясно выраженную мною задачу: в моем случае, видимо, без клиентского приложения не обойтись по причине того, что оно не только реализует GUI для службы, а выполняет непосредственное взаимодействие с пользователем и системой. Служба же отвечает в основном за передачу информации.
Таким образом хотелось бы узнать про методы реализации в событийном духе, когда действие оболочки (необязательно самого пользователя) влекло за собой реакцию в службе и соответственно наоборот.

← →
Сергей М. © (2009-02-04 09:32) [17]

> Медвежонок Пятачок © (04.02.09 09:06) [15]

И "простота" и "эффективность" - понятия весьма растяжимые.

мое предложение прекрасно укладывается в обе модели.

встроив веб сервер в сервис вы получаете возможность взаимодействовать с ним посредством браузера.

и не теряете возможности иметь событийного гуи-клиента с фонариками и бантиками, работающего по тому же протоколу с теми же форматами данных

> Dot (04.02.09 09:29) [16]

Вопрос не в событийности - событийное взаимодействие здесь само по себе очевидно и не проблемно в реализации - а во время- и/или ресурсоемкости той или иной выбранной для реализации технологии/механизма.

Ради оперативной передачи туда-сюда небольшого числа параметров фиксированного или меняющегося в прогнозируемых пределах размера городить огород с HTTP вряд ли оправдано.
Вероятно, достаточным будет выбор именованых пайпов или MMF+объекты синхронизации (ивенты, мьютексы, семафоры).

с именоваными пайпами придется городить не меньший огород. а даже больший.

> Медвежонок Пятачок © (04.02.09 09:50) [20]

Использовать пайпы вполне резонно в случае необходимости трансляции поточных данных.

все равно "олени лучше"

Конечно, строка "адын" всегда будет понятней байта со значением 1)

через DCOM можно
MIDAS тот же взять, который, кстати, и через http может работать

← →
jetus (2009-02-05 09:57) [25]

Юзать IPC.
Тем более, что уже готовые компоненты есть.

Каким обр. оптимально реализовать межпрограммное взаимодействие? Найти похожие ветки