Здравствуйте, 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).

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

А>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 -- очень гибкая штука

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

Здравствуйте, 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, то два порядка это еще скромно.

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