Здравствуйте, Аноним, Вы писали:

А>XML-RPC и RPC это разные вещи (RPC -- бинарный протокол, причем общего стандарта нет. XML-RPC -- текстовый). По сути, сервер XML-RPC это и есть сервер приложений. Это веб-сервер с особым обработчиком метода POST. Все предельно просто и реализуемо различными способами. Про XML-RPC почитайте на http://www.xmlrpc.com/spec. XML-RPC не накладывает каких бы то ни было ограничений на архитектуру, как сервера так и клиента. Сервисы построенные на XML-RPC могут быть, как stateless так и staetful. Могут следовать любой идеологии, как плоского API так и реализующими объектную модель. Использование XML-RPC не завязывает разработчика на какой либо инструмент/платформу/архитектуру приложений. В общем, XML-RPC -- очень гибкая штука

Скорее — "В общем всё придеться делать своими руками."

Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.
Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.
Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое.
Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете?
Может быть проще будет реализовать межпроцессорное взаимодействие самому?

Возможно кто-то сталкивался с подобными задачами.

Спасибо.

Здравствуйте, _kaimonomah_, Вы писали:

__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.
__>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.
__>Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое.
__>Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете?
__>Может быть проще будет реализовать межпроцессорное взаимодействие самому?

__>Возможно кто-то сталкивался с подобными задачами.

__>Спасибо.

Если плата ваша то определитесь с потоком данных и где по отношению к клиенту она
будет находиться, а то может так оказаться что придется использовать
собственный протокол на UDP ( если это конечно распределенная система )
или простую буфферизацию в память / файл

а так можете пользовать что больше нравится и в чем разбираетесь

если это готовый девайс то посмотрите какие решания предлагает разработчик

Здравствуйте, _kaimonomah_, Вы писали:

__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.
__>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.

Почему не WebServices? Или на сервере нужна какая-то хитрая объектная модель?

Здравствуйте, ioni, Вы писали:

Девайс наш. Желательно абстрагироваться от железа. Нужна именно модель взаимодействия между клиентом и сервером.

Здравствуйте, TK, Вы писали:

А что позволяет делать WebService? И как с кроссплатформенностью?

Здравствуйте, _kaimonomah_, Вы писали:

__>А что позволяет делать WebService? И как с кроссплатформенностью?

Если по простому — RPC/Обмен сообщениями. с кроссплатформенностью — сложнее сказать где их нет.

Здравствуйте, TK, Вы писали:

TK>Если по простому — RPC/Обмен сообщениями. с кроссплатформенностью — сложнее сказать где их нет.

А какие преимущества у WebService перед COM или CORBA?

Здравствуйте, _kaimonomah_, Вы писали:

Давать конкретную рекомендацию сложно, так как спеков не достаточно. Советую посмотреть вот на эти подходы:
1) http://www.zeroc.com/ice.html
2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).

Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.

Здравствуйте, novitk, Вы писали:

N>Давать конкретную рекомендацию сложно, так как спеков не достаточно. Советую посмотреть вот на эти подходы:
N>1) http://www.zeroc.com/ice.html

спасибо, посмотрю.

N>2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).

А как со скорость. Я слышал что WebService достаточно медленно работают.

N>Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.

Если рассматривать TAO (The ACE ORB) реализацию?

Здравствуйте, _kaimonomah_, Вы писали:

TK>>Если по простому — RPC/Обмен сообщениями. с кроссплатформенностью — сложнее сказать где их нет.
__>А какие преимущества у WebService перед COM или CORBA?

Простота, широкая доступность и не завимость от поставщика.

Здравствуйте, _kaimonomah_, Вы писали:

N>>2) Веб сервисы, и не только на SOAP, a и на ХМЛ-RPC. Так же возможны гибридные подходы с использованием http-протокола и собственного encoding-a для данных (возможно построенного на ХМL, JSON или ASN.1).

__>А как со скорость. Я слышал что WebService достаточно медленно работают.

Да, SOAP тормоза еще те. При гибридном подходе (http+бинарная сериализация) можно приблизится по скорости к CORBA. Если все равно медленно, надо переходить на UDP, но интероп перестает быть дешевым.

N>>Если смотреть в сторону CORBA, то немаловажно какая реализация использована и какие пары клиент/сервер нужны. Иначе граблей на интеропе и скорости можно огрести по полной.

__>Если рассматривать TAO (The ACE ORB) реализацию?

Никогда не использовал, но слышал о ней хорошие вещи. Советую написать еcho-server и проверить со следушими клиентами: .NET(http://iiop-net.sourceforge.net/), JDK(используя встроенный ORB) и Python(http://omniorb.sourceforge.net/). Не должно занять больше дня.

Здравствуйте, _kaimonomah_, Вы писали:

__>Возникла задача разработать систему сбора и анализа данных от устройств. Приложение, принимающее данные решил сделать ввиде отдельного сервера, а приложения обрабатывающие данные (архиваторы, визуализаторы, управляющие панели и т.д.) ввиде клиента.

Из личного опыта: У нас стояла задача получить данные с 22 устройств находящихся на большлм уделении друг от друга. Данные с устройств считывались с помощью контроллеров ipc con.

__>Вопрос в том, как организовать связь между клиентом и сервером. Желательно, но не обязательно, кроссплатформенное решение.
__>Думал об использовании COM и OPC, но вроде COM уже не развивается. Писали, что OPC строят на другой не-COM технологии, но так и не понял, получилось ли что-то приемлемое.

Данные с контроллеров получает OPC- сервер по протоколу modbus. Причем клиенты должны получать информацию через web-интерфейс.
Задача была решена немного многозвенно,но все же: клиент опрашивает opc- сервер и держит инфу по всем устройствам в памяти.

Клинты наблюдают данные через web-интерфейс, который(сайт) в свою очередь забирает данные через веб-службу, а веб- служба забирает данные у opc- клиента. Веб-служба и opc-клиент взаимодействуют через .net remoting.

Почему веб- служба: потому что кроме веб-интервейса есть программа написанная для кпк, которая также получает данне через веб-слжубу.

__>Есть ли смысл использовать CORBA? Если да, то какую свободную реализацию посоветуете?
__>Может быть проще будет реализовать межпроцессорное взаимодействие самому?

Кросс-платформенность вообще нужна???

__>Возможно кто-то сталкивался с подобными задачами.

__>Спасибо.

Здравствуйте, RobertSZ, Вы писали:

RSZ>Кросс-платформенность вообще нужна???

Очень желательно, т.к. в дальнейшем возможно придется строить систему на базе *nix

Здравствуйте, _kaimonomah_, Вы писали:

__>Здравствуйте, RobertSZ, Вы писали:

RSZ>>Кросс-платформенность вообще нужна???

__>Очень желательно, т.к. в дальнейшем возможно придется строить систему на базе *nix

Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.

Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (

Здравствуйте, RobertSZ, Вы писали:


RSZ>Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.

RSZ>Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (

А разве существует OPC спецификация для *nix систем? Вроде OLE for Process Control. Привязана в Windows.

Здравствуйте, _kaimonomah_, Вы писали:

__>Здравствуйте, RobertSZ, Вы писали:


RSZ>>Тогда советую следующее использовать для получения данных с устройств программируемые контроллеры с поддержкой протокола modbus, тогда если найдешь opc-сервер под *nix- серверную часть вообще писать не надо будет. Клиенты будут через data access automation wrapper(это длл-ка такая например graybox-бесплатная) коих много бесплатных забирать данные с opc- сервера. Если не найдешь opc или найдешь, а это дорого$$$ напишешь серверную часть сам на Java. А клиенты будут забирать с твоей серверной части любым удобным методом например через tcp. Вот это будет действительно 100% кросс-платформенное решение.

RSZ>>Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (

__>А разве существует OPC спецификация для *nix систем? Вроде OLE for Process Control. Привязана в Windows.

мда...честно говоря я не задумывался))

ну да ладно....

тогда все равно рекомендую контроллеры с поддержкой протокола modbus. просто твоя программа сервер будет отправлять на контроллер запросы как opc-сервер и получать ответы.

Здравствуйте, RobertSZ, Вы писали:

RSZ>Только цена вопроса возрастет- потому что я например не знаю ни одного java-программиста (

хватает java-программистов, платформе не первый год все же.

Здравствуйте, RobertSZ, Вы писали:

RSZ>мда...честно говоря я не задумывался))

RSZ>ну да ладно....

RSZ>тогда все равно рекомендую контроллеры с поддержкой протокола modbus. просто твоя программа сервер будет отправлять на контроллер запросы как opc-сервер и получать ответы.

Вычитал, что новая спецификация OPC строится на базе Web Serivce. Реально ли их создавать на C++ (без титанический усилий типа COM на Си)?
На чём они обычно пишутся?

Здравствуйте, _kaimonomah_, Вы писали:

__>Вычитал, что новая спецификация OPC строится на базе Web Serivce. Реально ли их создавать на C++ (без титанический усилий типа COM на Си)?
__>На чём они обычно пишутся?

Сделайте на XML-RPC.

1. Абсолютно кросплатформенно
2. Высокая скорость (при использовании boxcarring'а -- зверская)
3. Доступны библиотеки для всех, сколь нибудь популярных, ЯП (для C/C++ -- http://xmlrpc-c.sourceforge.net/)
4. Доступность всех прелестей транспорта HTTP (сжатие, шифрование)
5. Простота отладки взаимодействия клиента с сервером (любой снифер, пакеты легко читаются человеком)
6. Бинарные данные можно передавать без кодирования (зависит от библиотеки, впрочем)

__>>А как со скорость. Я слышал что WebService достаточно медленно работают.

N>Да, SOAP тормоза еще те. При гибридном подходе (http+бинарная сериализация) можно приблизится по скорости к CORBA. Если все равно медленно, надо переходить на UDP, но интероп перестает быть дешевым.

Можно ещё WCF или Remoting. Первый относительно кросплатформенное решение. Второе — нет.
Зато оба работают и с SOAP и с бинарными форматами по любым каналам. Производительность высокая. WCF на IIS7 заявлено быстрее WebServices причём и жавовских тоже. Remoting — на уровне COM+ (принцип тот же), т.е. ещё выше.

Здравствуйте, VGn, Вы писали:

N>>Да, SOAP тормоза еще те. При гибридном подходе (http+бинарная сериализация) можно приблизится по скорости к CORBA. Если все равно медленно, надо переходить на UDP, но интероп перестает быть дешевым.

VGn>Можно ещё WCF или Remoting. Первый относительно кросплатформенное решение. Второе — нет.
VGn>Зато оба работают и с SOAP и с бинарными форматами по любым каналам. Производительность высокая. WCF на IIS7 заявлено быстрее WebServices причём и жавовских тоже. Remoting — на уровне COM+ (принцип тот же), т.е. ещё выше.

Вычитал, что WebService требует сервер приложений. В роли сервера приложений выступает только IIS? Есть ли отдельный небольшой сервер приложений для WebSerivce?

А при использовании XML RPC нужен сервер приложений? По-идее это достаточно универсальное решение, т.к. RPC вроде есть во многих ОС. Или я ошибаюсь?

Здравствуйте, _kaimonomah_, Вы писали:

__>Вычитал, что WebService требует сервер приложений. В роли сервера приложений выступает только IIS? Есть ли отдельный небольшой сервер приложений для WebSerivce?

Веб-сервисы строятся не только на SOAP.

__>А при использовании XML RPC нужен сервер приложений? По-идее это достаточно универсальное решение, т.к. RPC вроде есть во многих ОС. Или я ошибаюсь?

XML-RPC и RPC это разные вещи (RPC -- бинарный протокол, причем общего стандарта нет. XML-RPC -- текстовый). По сути, сервер XML-RPC это и есть сервер приложений. Это веб-сервер с особым обработчиком метода POST. Все предельно просто и реализуемо различными способами. Про XML-RPC почитайте на http://www.xmlrpc.com/spec. XML-RPC не накладывает каких бы то ни было ограничений на архитектуру, как сервера так и клиента. Сервисы построенные на XML-RPC могут быть, как stateless так и staetful. Могут следовать любой идеологии, как плоского API так и реализующими объектную модель. Использование XML-RPC не завязывает разработчика на какой либо инструмент/платформу/архитектуру приложений. В общем, XML-RPC -- очень гибкая штука , а такие вещи, как introspection и boxcarring делают его использование еще более приятным.

Где применяется:

1. Движки блогов.
2. Различные CMS/BugTracking
3. Системная шина в KDE (в Gnome, кажется, CORBA)
4. Приложения, где XML-RPC используется для IPC (SpamBayes, PopFile).

Здравствуйте, dotidot, Вы писали:

D>Скорее — "В общем всё придеться делать своими руками."

Что значит "все"? Выбрать модель сервиса (flat/object) и соответствующую логику реализовать?

__>>Вычитал, что WebService требует сервер приложений. В роли сервера приложений выступает только IIS? Есть ли отдельный небольшой сервер приложений для WebSerivce?
А>Веб-сервисы строятся не только на SOAP.

SOAP можно так же использовать без IIS, смотри здесь

А>[Skipped описание XML-RPC]

Для полноты картины, вот пара недостатков XML-RPC:

1) ХМЛ-RPC существенно проигрывает по скорости бинарным системам
2) Большинство (возможно все имеющиеся?) XML-RPC реализаций не предоставляют высокоуровневых средств разработки. То есть отсутствуют компиляторы для генерации stubs, proxies и автоматических преобразование данных в структуры целевого языка. В принципе это палка о двух концах, так как добавляет простоты, но кода писать придется больше.

Здравствуйте, VGn, Вы писали:

VGn>Можно ещё WCF или Remoting. Первый относительно кросплатформенное решение. Второе — нет.

WCF кросплатформенное решение? Это про Моно что ли?

N>WCF кросплатформенное решение? Это про Моно что ли?

Не обязательно.
Я имел в виду интероперабельность.
http://blogs.msdn.com/nathana/archive/2007/05/29/custom-soap-headers-wcf-and-java.aspx

Здравствуйте, novitk, Вы писали:

N>SOAP можно так же использовать без IIS, смотри здесь

Я этого и не говорил. У индейцев тоже есть своя реализация SOAP, так что я в курсе

А>>[Skipped описание XML-RPC]

N>Для полноты картины, вот пара недостатков XML-RPC:

N>1) ХМЛ-RPC существенно проигрывает по скорости бинарным системам

1. Поясните "существенность". Речь об абсолютных цифрах или цифрах в контексте задачи? Я на XML-RPC получаю ~3650 вызовов в секунду обычным способом, и чуть больше 19000 с использованием boxcarring'а (вызывается метод currentTime.getCurrentTime возвращающий текущую дату и время). Сколько даст CORBA/DCOM/Remoting?

N>2) Большинство (возможно все имеющиеся?) XML-RPC реализаций не предоставляют высокоуровневых средств разработки. То есть отсутствуют компиляторы для генерации stubs, proxies и автоматических преобразование данных в структуры целевого языка. В принципе это палка о двух концах, так как добавляет простоты, но кода писать придется больше.

2. Реализации для Java и .Net (не говоря уж о PHP, Python, Perl и прочих подобных) точно умеют мапить типы XML-RPC в нативные (языковые) (вообще, примеры есть тут: http://www.opennet.ru/docs/HOWTO/XML-RPC-HOWTO/xmlrpc-howto-legal.html). Прокси делают не все реализации это факт, но есть и те, что делают. Стабы генерировать умеют не все, но там работы на 5 минут (благо, интроспекция реализуется тремя методами. А полное описание так и вообще одним). По части объемов кода не могу не согласиться, но все, опять же, зависит от используемой библиотеки.

Здравствуйте, Аноним, Вы писали:

N>>1) ХМЛ-RPC существенно проигрывает по скорости бинарным системам

А>1. Поясните "существенность". Речь об абсолютных цифрах или цифрах в контексте задачи?

Я конечно говорю только о скорости самого RPC стэка, без учета сети и приложения.

А>Я на XML-RPC получаю ~3650 вызовов в секунду обычным способом, и чуть больше 19000 с использованием boxcarring'а (вызывается метод currentTime.getCurrentTime возвращающий текущую дату и время). Сколько даст CORBA/DCOM/Remoting?

Я не знаю деталей вашего конфига, поэтому сказать трудно. Если сравнивать два стэка, то порядка два разницы говорят. Не вижу причин не верить.

Здравствуйте, novitk, Вы писали:

N>Здравствуйте, Аноним, Вы писали:

N>>>1) ХМЛ-RPC существенно проигрывает по скорости бинарным системам

А>>1. Поясните "существенность". Речь об абсолютных цифрах или цифрах в контексте задачи?

N>Я конечно говорю только о скорости самого RPC стэка, без учета сети и приложения.

В этом случае все верно. Разбирать XML дороже, чем смещения в бинарнике считать. Но мерять скорость без привязки к сети смысла нет.

А>>Я на XML-RPC получаю ~3650 вызовов в секунду обычным способом, и чуть больше 19000 с использованием boxcarring'а (вызывается метод currentTime.getCurrentTime возвращающий текущую дату и время). Сколько даст CORBA/DCOM/Remoting?

N>Я не знаю деталей вашего конфига, поэтому сказать трудно. Если сравнивать два стэка, то порядка два разницы говорят. Не вижу причин не верить.

Какое отношение скорость SOAP имеет к XML-RPC? Пакеты XML-RPC разбирать проще т.к. можно построить стек правил (с SOAP этого сделать нельзя -- только валидация пакета по схеме, если я не ошибаюсь). О скорости бинарников я читал http://www.rsdn.ru/article/dotnet/dcomvsnet.xml

Автор(ы): Игорь Ткачёв
Дата: 15.03.2003
...сегодня мы рассмотрим и сравним две родственные технологии для построения распределённых систем – DCOM и её преемницу .NET Remoting. В первую очередь нас будут интересовать скорость вызова методов и время создания (соединения) удалённого объекта.

, и нужно сказать, что скорости сравнимы (лучший результат бинарного протокола для Method 2 -- 2000 вызовов).

У меня Pentium M 1.7, 512RAM, сеть 100Mb. Клиент и сервер на одной машине (но взаимодействие идет через сеть).

Здравствуйте, Аноним, Вы писали:

А>Какое отношение скорость SOAP имеет к XML-RPC?

Прямое. Обьем работы по маршалингу/демаршалингу примерно одинаковый.

А>Пакеты XML-RPC разбирать проще т.к. можно построить стек правил (с SOAP этого сделать нельзя -- только валидация пакета по схеме, если я не ошибаюсь).

Ошибаешся (на ты дальше, ОК?). Постмотри на реализацию gSOAP, там даже XML-а то нет! Все построено на прямых стабах/прокси сделаных прямо на <string.h> по жестким правилам сгенерированным компилятором, почти без динамической памяти, исключений, с минимизацией копирования для улучшения локальности кэша и т.д. ИМХО ребята очень старались и выжали все лимоны. Так вот ZeroC/Ice на 4-х ядерных машинах с гиговой сеткой рвет это все безбожно. Уверен, что OmniOrb тоже.

На какой(их) реализации XML-RPC ты получил свои бенчи? Интересно было бы посмотреть на детали.

> О скорости бинарников я читал http://www.rsdn.ru/article/dotnet/dcomvsnet.xml

Автор(ы): Игорь Ткачёв
Дата: 15.03.2003
...сегодня мы рассмотрим и сравним две родственные технологии для построения распределённых систем – DCOM и её преемницу .NET Remoting. В первую очередь нас будут интересовать скорость вызова методов и время создания (соединения) удалённого объекта.

, и нужно сказать, что скорости сравнимы (лучший результат бинарного протокола для Method 2 -- 2000 вызовов).
А>У меня Pentium M 1.7, 512RAM, сеть 100Mb. Клиент и сервер на одной машине (но взаимодействие идет через сеть).

Я или не понял или ты сравниваешь их бенчи со своими. Последнее мягко говоря не научно.

Здравствуйте, novitk, Вы писали:

А>>Какое отношение скорость SOAP имеет к XML-RPC?

N>Прямое. Обьем работы по маршалингу/демаршалингу примерно одинаковый.

Нет. SOAP умеет маршалить пользовательские типы, что несравнимо сложнее чем у XML-RPC.

А>>Пакеты XML-RPC разбирать проще т.к. можно построить стек правил (с SOAP этого сделать нельзя -- только валидация пакета по схеме, если я не ошибаюсь).

N>Ошибаешся (на ты дальше, ОК?). Постмотри на реализацию gSOAP, там даже XML-а то нет! Все построено на прямых стабах/прокси сделаных прямо на <string.h> по жестким правилам сгенерированным компилятором, почти без динамической памяти, исключений, с минимизацией копирования для улучшения локальности кэша и т.д. ИМХО ребята очень старались и выжали все лимоны. Так вот ZeroC/Ice на 4-х ядерных машинах с гиговой сеткой рвет это все безбожно. Уверен, что OmniOrb тоже.

Т.е. по WSDL компилятор генерит код для разбора конкретного набора пакетов?

N>На какой(их) реализации XML-RPC ты получил свои бенчи? Интересно было бы посмотреть на детали.

На своей Я искал библиотеку для Delphi, посмотрел пару и решил, что свое написать легче, чем с чужими багами бороться. Разбираю пакеты используя SAX (нативный, сторонний) и стек правил. При разборе строится DOM пакета. Простые типы XML-RPC мапятся на языковые, для сложных создаются объекты-обертки т.к. корректно смапить, скажем, структуру невозможно (.Net реализация http://www.xml-rpc.net/ мапит, но с оговорками).

>> О скорости бинарников я читал http://www.rsdn.ru/article/dotnet/dcomvsnet.xml

Автор(ы): Игорь Ткачёв
Дата: 15.03.2003
...сегодня мы рассмотрим и сравним две родственные технологии для построения распределённых систем – DCOM и её преемницу .NET Remoting. В первую очередь нас будут интересовать скорость вызова методов и время создания (соединения) удалённого объекта.

, и нужно сказать, что скорости сравнимы (лучший результат бинарного протокола для Method 2 -- 2000 вызовов).
А>>У меня Pentium M 1.7, 512RAM, сеть 100Mb. Клиент и сервер на одной машине (но взаимодействие идет через сеть).

N>Я или не понял или ты сравниваешь их бенчи со своими. Последнее мягко говоря не научно.

Ни в коем разе Просто, нужно было с чем-то сравниться (для себя, на момент разработки), вот и посмотрел, что первым нашлось. Условия-то схожие. Стоит добавить, я ни сколько не сомневаюсь в том, что бинарники всегда будут быстрее текстовых протоколов, особенно XML over HTTP/XML-based (но разница на порядок или два, это крутовато даже для бинарников .

Здравствуйте, Аноним, Вы писали:

А>Т.е. по WSDL компилятор генерит код для разбора конкретного набора пакетов?

Ага, и код этот не поверх DOM-a или SAX-a, а прямо над байтовыми строками.

А> (но разница на порядок или два, это крутовато даже для бинарников .

В обычном сервисе над БД, конечно нет. А вот когда начинаешь возить по сету матрицы чисел размером так 500х500, то два порядка это еще скромно.

Здравствуйте, novitk, Вы писали:

А>>Т.е. по WSDL компилятор генерит код для разбора конкретного набора пакетов?

N>Ага, и код этот не поверх DOM-a или SAX-a, а прямо над байтовыми строками.

Да, спасибо, я почитал про gSOAP и бенчи их посмотрел Для скорости подход, однозначно, хорош.

А>> (но разница на порядок или два, это крутовато даже для бинарников .

N>В обычном сервисе над БД, конечно нет. А вот когда начинаешь возить по сету матрицы чисел размером так 500х500, то два порядка это еще скромно.

Так никто же не заставляет для матрицы использовать массив массивов. Можно, точно так же, передавать бинарные данные.