LINUX.ORG.RU

Объектно-ориентированное взаимодействие процессов


0

0

Как в линуксе организовать ОО-взаимодействие процессов (типа COM/DCOM в Windows?)

Дело в следующем: есть некая прога-сервис, которая что-то делает. Хочется встроить работу с ней в уже существующий сайт (ну и возможность встраивания в другие сайты). Следовательно, нужен какой-то способ обращения из сайтовых скриптов к работающему сервису.

Прога кроссплатформенная, работает как в Linux, так и в Windows. Нужен какой-то единообразный механизм подключения к ней для управления.

Конечно, можно сделать в проге сокет, и подключаться к нему, но тогда нужно заморачиваться парсингом сообщений и т.п., короче, писать свой IPC. А у проги куча свойств, параметров и т.п., которые хорошо моделируются объектами и интерфейсами (т.е. подходит COM в Windows).

На ум приходит только одно -- CORBA, но она уже вроде загибается?

Какие сейчас существуют средства ОО-взамодействия в Linux'е?

А, да. Сама прога -- на C++, сайт -- на PHP, в будущем планируется Ruby. Для простоты можно предположить, что прога работает там же, где и Web-сервер (т.е. вполне можно сделать взаимодействие через Shared Memory, но тогда нужно писать парсер C++-объектов на PHP).

XMLRPC? MPI?

anonymous
()

0. ИМХО ОО-взаимодействие процессов (типа COM/DCOM в Windows) НЕ НУЖНО.

1. CORBA -- не загибается пока.

2. Руби -- наше все. Там все есть.

3. "...можно сделать взаимодействие через Shared Memory, но тогда нужно писать парсер C++-объектов на PHP" -- а зачем? Просто маленький (ПХП->ЦеПП) враппер, который должным образом работает на каждой целевой платформе...

Die-Hard ★★★★★
()
Ответ на: комментарий от Svoloch

> SOAP?

Гы! Типа, чтобы "обойти проблему firewall'а"?

ИМХО SOAP придумали исключительно для того, чтобы обойти проблему умолчательных политик типичного Видовз-файерволла, закрывающего все, кроме восьмидесятого порта. Других разумных применений сему "индустриальному стандарту" (как и вообще "уеб-сервисам") мне как-то не видится...

Впрочем, я верю, что в скором будущем на место DCOM придет SOAP, ибо известно, что на рынке всегда побеждает наиболее кривое техническое решение!

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

Лично мы для таких целей - Web морда к работающей программе - используем или XMLRPC или встраиваем Web-сервер в программу (тут можно реализовать cgi или fastcgi - а то и всю Web-морду целиком). А уж встроенный Web-сервер общается с остальной программой через IPC.

anonymous
()

Используй протокол от Plan9.

Com/Dcom это не надо
на яве была какая-то своя система

p.s. читаем дедушку Таненбаума и много думаем

anonymous
()

да что душе угодно. посмотри ZeroC ICE, если хочется именно CORBA-подобного - у него клиентские байндинги к PHP и Ruby есть

jtootf ★★★★★
()

главный вопрос еще в том, какие из этих замечательных оо-ipc поддерживает сам пых-пых, ы? ;)

наиболее переносимый вариант -- ipc на базе сообщений, а не объектов. и вместо парсинга с++-объектов, для представления сообщений лучше выбрать один из сотни стандартизированных форматов (http, xmlrpc, jsonp и т.п что лучше понимаешь...). можно через shared memory :)

Lucky ★★
()

> На ум приходит только одно -- CORBA, но она уже вроде загибается?

почему загибается, живет старуха. одной из ее реализаций в гноме пользуются, google for ORBit. Но вообще корба - это почти такой же ужос как COM.

> Какие сейчас существуют средства ОО-взамодействия в Linux'е?

Как насчет кидаться google protocol buffers месагами по TCP-сокету? биндинг для php там есть.

gods-little-toy ★★★
()
Ответ на: комментарий от gods-little-toy

>одной из ее реализаций в гноме пользуются

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

inb4 кастую сву в этот тред

anonymous
()
Ответ на: комментарий от Die-Hard

А чем плох SOAP? RPC поверх HTTP - почему бы и нет? К тому же, много где поддерживается.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.