Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото).
Вот и подумалось. какие есть уже готовые вещи для общения между процессами которые могут быть физически разнесены по машинам, доступными друг другу через прокси, несколько подсетей итд.)
Желательно с поддержкой подписок (аналог subscribe в opc стандарте). Кто что может посоветовать?
Здравствуйте, ironwit, Вы писали:
I>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото). I>Вот и подумалось. какие есть уже готовые вещи для общения между процессами которые могут быть физически разнесены по машинам, доступными друг другу через прокси, несколько подсетей итд.)
I>Желательно с поддержкой подписок (аналог subscribe в opc стандарте). Кто что может посоветовать?
Corba
.Net remoting
Java RMI
DCOM
Если открыл Америку, то сорри
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Здравствуйте, ironwit, Вы писали:
I>>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото). I>>Вот и подумалось. какие есть уже готовые вещи для общения между процессами которые могут быть физически разнесены по машинам, доступными друг другу через прокси, несколько подсетей итд.)
I>>Желательно с поддержкой подписок (аналог subscribe в opc стандарте). Кто что может посоветовать? ДВ>Corba
это по сути обмен xml файлами если я верно вычленил суть? ДВ>.Net remoting
разработка на Delphi. ДВ>Java RMI
аналогично верхнему я вот думаю. а что если на erlang мост реализовать. чистА по приколу
то есть delphi server --> erlang --> network --> erlang --> delphi client.
а в erlang е уже есть обмен ... вот и думаю... думаю... ДВ>DCOM
боюсь я DCOM — плохо он ходит через файерволы, другие подсети итд. поэтому и не хочу орс применять для этого. ДВ>Если открыл Америку, то сорри
Здравствуйте, ironwit, Вы писали:
I>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но,
еще. поискал по инету наткнулся на DDObjects с http://delphi-online.at/
вот и думаю. может ее заюзать как библиотеку связи, и по ней гонять просто данные...
кто то сталкивался с данной библиотекой?
Здравствуйте, ironwit, Вы писали:
I>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото). I>Вот и подумалось. какие есть уже готовые вещи для общения между процессами которые могут быть физически разнесены по машинам, доступными друг другу через прокси, несколько подсетей итд.)
I>Желательно с поддержкой подписок (аналог subscribe в opc стандарте). Кто что может посоветовать?
Я думаю, подойдёт это:
BEEP идет на смену HTTP
Сети #01-02/2002
Валерий Коржов
Идя навстречу веяниям времени, группа IETF разработала и утвердила новый протокол BEEP — Blocks Extensible Exchange Protocol (протокол для расширяемого обмена блоками информации). Он создан с целью адекватной замены HTTP и предназначен для передачи данных в формате XML. Его ключевыми особенностями являются поддержка нескольких каналов передачи данных в одном сеансе и возможность одновременной транспортировки нескольких независимых информационных блоков. Каждый блок соответствует стандарту MIME, то есть, как и почтовое сообщение, может содержать несколько типов данных. За протоколом даже «закреплен» определенный MIME-тип данных application/beep+ xml — он используется для передачи служебных сообщений, обеспечивающих настройку сеанса и управление каналами. Блок состоит из заголовка, «тела» и завершающей строки. Как и в HTTP, заголовок от тела отделяется пустой строкой. Блок заканчивается строкой END, за которой может следовать новый блок.
Новый стандарт предусматривает три режима взаимодействия клиента с сервером: «запрос — ответ», «запрос — сообщение об ошибке» и режим уточняющих запросов. Первые два примерно соответствуют возможностям, обеспечиваемым протоколом HTTP, а последний позволяет серверу запрашивать у клиента уточняющую информацию. В этом случае обмен сообщениями выполняется до тех пор, пока клиент и сервер не передадут друг другу нулевое сообщение, после которого сеанс прекращается. Таким образом, протокол предусматривает пять типов сообщений: запрос (MSG), ответ (RPY), сообщение об ошибке (ERR), уточняющий запрос сервера (ANS) и финальное нулевое сообщение (NUL).
Важной особенностью протокола BEEP является управление каналами. С каждым каналом связан определенный профиль, который позволяет взаимодействующим сторонам договариваться о правилах работы с передаваемой информацией. Во время сеанса организуется один служебный (tuning) канал, который может быть дополнен несколькими информационными каналами. Отметим, что BEEP является протоколом уровня приложения, то есть установление самих сеансов связи и правила передачи данных в этом протоколе не описываются. Сейчас существуют только рекомендации по использованию BEEP поверх TCP, однако возможно, что вскоре появятся аналогичные правила его применения поверх другого протокола сеансового уровня — SCTP.
Изначально предполагалось использовать BEEP для передачи сообщений между приложениями в формате SOAP, поэтому группа разработчиков стандарта активно взаимодействовала с W3C. В частности, вся служебная информация протокола передается в формате XML. Так, чтобы настроить служебный канал (номер «0»), клиент и сервер должны обменяться сообщениями, включающими в себя тег greeting, а для создания нового канала — передать друг другу тег start с указанием номера канала (см. листинг). Внутри этих тегов приложения могут содержать дополнительную информацию, определяющую, где искать профили канала или на каком естественном языке нужно выдавать информацию.
Основным применением BEEP является передача коротких сообщений между приложениями в формате SOAP. Поскольку приложений, поддерживающих этот формат, пока не так уж много, своевременное принятие стандарта BEEP позволяет разработчикам сразу перейти на новый протокол, а не следовать рекомендациям W3C, в соответствии с которыми в качестве транспорта предполагается использовать HTTP. Таким образом, BEEP явно имеет большое будущее, поскольку он удовлетворяет современным требованиям создания Web-приложений.
Здравствуйте, iZEN, Вы писали:
ZEN>Здравствуйте, ironwit, Вы писали:
I>>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото). I>>Вот и подумалось. какие есть уже готовые вещи для общения между процессами которые могут быть физически разнесены по машинам, доступными друг другу через прокси, несколько подсетей итд.)
I>>Желательно с поддержкой подписок (аналог subscribe в opc стандарте). Кто что может посоветовать?
ZEN>Я думаю, подойдёт это: ZEN>[q] ZEN>BEEP идет на смену HTTP
спасибо. но ... как то все это пока мутно
да и... подписку реализовать не выйдет и придется грузить сервер лишними запросами с клиентов о наличии данных...
Здравствуйте, ironwit, Вы писали:
I>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером
Здравствуйте, Боб Морган, Вы писали:
БМ>Здравствуйте, ironwit, Вы писали:
I>>Тут встал вопрос о сабжевом взаимодействии... Сначала как всегда начал реализовывать свой велосипед (точнее пока только дизайнить ), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером
БМ>Может SOAP?
та вроде почитал про Re: протокол обмена между client и server
Если клиент в интернете, то у него всего два варианта — tcp или http. Если файервол препятствует прямому сокетному соединению по tcp, то используется http. По такому принципу работает, например, RMI. Для упрощения и если скорость обмена не критична, клиент может всегда использовать только http. А передаваемый поток байтов — это или xml(SOAP,..), или сериализованный обьект (RMI,NET,..) или данные в каком-то другом формате.
I>аналогично верхнему я вот думаю. а что если на erlang мост реализовать. чистА по приколу I>то есть delphi server --> erlang --> network --> erlang --> delphi client. I>а в erlang е уже есть обмен ... вот и думаю... думаю...
Здравствуйте, ironwit, Вы писали:
I>я вот думаю. а что если на erlang мост реализовать. чистА по приколу I>то есть delphi server --> erlang --> network --> erlang --> delphi client.
Мост для этого не требуется.
С Erlang идут исходники C-шной либы, которая может быть собрана в dll и подключена к delphi.
Если работать по ip-адресам, то этого достаточно.
Несли хочется работать по именам (нод и процессов) то потребуется запустить еще менеджеры портов.
Это тоже небольшие штучки, весь Erlang запускать не требуется.
Если реактивность не очень критична, и работа через XML устраивает — можешь посмотреть еще на протокол Jabber-а.
К нему тоже всяких библиотек достаточно.
Здравствуйте, Alex EXO, Вы писали:
AE>Здравствуйте, ironwit, Вы писали:
I>>я вот думаю. а что если на erlang мост реализовать. чистА по приколу I>>то есть delphi server --> erlang --> network --> erlang --> delphi client.
AE>Мост для этого не требуется.
), но, слишком много вещей напоминают то одно то второе. а потом задумался о том, что точно ведь есть уже готовые протоколы общения между клиентом и сервером (к примеру тонкий клиент --> сервер приложений --> сервер субд (железо еще чтото).
