Здравствуйте, IB, Вы писали:
IB> H>Очень даже предполагалось. В спеку (2.2.2 Remote Procedure Calls) загляни.
IB> Упс, my bad.. Тем не менее, это не значит, что SOAP следует использовать таким образом. И опять таки, в первую очередь это именно stateless протокол удаленной передачи данных, все остальное уже наворочено сверху.
Конечно не следует, RPC лишь одна из ипостасей SOAP. SOAP это вообще, по идее, формат обмена сообщениями, а уж их интерпретация дело договорившихся сторон. Ну и по поводу stateless. В аббревиатуре SOAP наличие Object уже намекает на инкапсуляцию, что очень даже stateful (хотя, разумеется, возможны и варианты, поэтому я бы не взялся однозначно все трактовать). В тоже время RPC совсем не означает, что сервис будет выполнен как stateful. Ну а вообще, конечно, SOAP был сделан гигантами для того, чтоб небыло ни одной человеческой реализации, дабы породить vendor lock-in
Здравствуйте, Sharov, Вы писали:
S>А каким образом его следует использовать?
Таким же каким и REST
S>И для чего, на Ваш взгляд, он все-таки был разработан?
Для передачи данных между приложениями.
Здравствуйте, hattab, Вы писали:
H> В аббревиатуре SOAP наличие Object уже намекает на инкапсуляцию,
Object — не намекает ни на что, кроме Object. Хотя бы в силу того, что термин Object на столько перегружен, что каждый понимает его по своему, а формальное определение отсутствует.
H>В тоже время RPC совсем не означает, что сервис будет выполнен как stateful.
Давай с терминологией разберемся. Формально RPC — это просто передача сообщения другому приложению. Однако, обычно, когда говорят RPC — подразумевают работу с удаленным кодом в стиле CORBA или DCOM, когда вызывающий код делает вид, что все выполняется локально. В этом месте и появляется состояние.
H>Ну а вообще, конечно, SOAP был сделан гигантами для того, чтоб небыло ни одной человеческой реализации, дабы породить vendor lock-in
Это уже вообще какая-то теория заговора. SOAP как раз совершенно вендоронезависимая конструкция и делался в первую очередь для того, чтобы быть кроссвендорным, ровно по этому в качестве формата сообщений брался XML, а транспорта HTTP. И получилось, надо сказать, весьма не плохо. Недостаток ровно один — очень высокий порог вхождения, и это губит всю идею.
Здравствуйте, IB, Вы писали:
IB> H> В аббревиатуре SOAP наличие Object уже намекает на инкапсуляцию,
IB> Object — не намекает ни на что, кроме Object. Хотя бы в силу того, что термин Object на столько перегружен, что каждый понимает его по своему, а формальное определение отсутствует.
Если опять же почитать спеку, понятно о каких объектах идет речь. Это можно почитать в спеке SOAP 1.1 (Design Goals) и в спеке SOAP 1.2 (4.1.3 Web Architecture Compatible SOAP Usage) которую я даже процитирую:
There are many instances when SOAP messages are designed for uses which are purely for information retrieval, such as when the state of some resource (or object, in programming terms) is requested, as opposed to uses that perform resource manipulation. In such instances, the use of a SOAP body to carry the request for the state, with an element of the body representing the object in question, is seen as counter to the spirit of the Web because the resource is not identified by the Request-URI of the HTTP GET. (In some SOAP/RPC implementations, the HTTP Request-URI is often not the identifier of the resource itself but some intermediate entity which has to evaluate the SOAP message to identify the resource.)
Что в общем не удивительно, коль скоро мы говорим о программных системах
IB> H>В тоже время RPC совсем не означает, что сервис будет выполнен как stateful.
IB> Давай с терминологией разберемся. Формально RPC — это просто передача сообщения другому приложению. Однако, обычно, когда говорят RPC — подразумевают работу с удаленным кодом в стиле CORBA или DCOM, когда вызывающий код делает вид, что все выполняется локально. В этом месте и появляется состояние.
Говоря об RPC обычно имеют ввиду именно RPC и ничего больше А CORBA и DCOM это распределенные системы для работы, опять же, с компонентами-объектами (о чем на и говорят их аббревиатуры), которые могут быть построены поверх RPC (в случае DCOM так оно и есть), но тождественными ему не являются.
IB> H>Ну а вообще, конечно, SOAP был сделан гигантами для того, чтоб небыло ни одной человеческой реализации, дабы породить vendor lock-in
IB> Это уже вообще какая-то теория заговора. SOAP как раз совершенно вендоронезависимая конструкция и делался в первую очередь для того, чтобы быть кроссвендорным, ровно по этому в качестве формата сообщений брался XML, а транспорта HTTP. И получилось, надо сказать, весьма не плохо. Недостаток ровно один — очень высокий порог вхождения, и это губит всю идею.
На то и намек. SOAP настолько всеобъемлющ (типичный пример overdesign), что качественно реализовать его под силу только гигантам. Я сам не раз видел на форумах вопросы о совместимости т.к. реализации разных вендоров не могли нормально взаимодействовать. Об этом же говорит и википедия:
Хотя SOAP является стандартом, некоторые программы часто генерируют сообщения в несовместимом формате. Например, запрос, сгенерированный AXIS-клиентом, не будет понят сервером WebLogic.
Здравствуйте, hattab, Вы писали:
H>Если опять же почитать спеку, понятно о каких объектах идет речь. Это можно почитать в спеке
В спеке ровно это и написано, "мы говорим про объекты, которые объекты", то есть масло маслянное.
Не существует определения object, in programming terms. В этом смысле state of some resource гораздо конкретнее дает понять о чем идет речь.
H>Говоря об RPC обычно имеют ввиду именно RPC и ничего больше
Ок. Я имел ввиду CORBA и DCOM и понял как CORBA и DCOM.
H>На то и намек.
Давай без намеков.
H>SOAP настолько всеобъемлющ (типичный пример overdesign), что качественно реализовать его под силу только гигантам.
Вот это не правда. Он очень качественно порезан на кусочки, так что объемлить только то что нужно проблем не составляет.
H> Я сам не раз видел на форумах вопросы о совместимости т.к. реализации разных вендоров не могли нормально взаимодействовать.
Базовые версии типа httpBasic прекрасно взаимодействуют, тем более что альтернативы все равно нет.
Здравствуйте, IB, Вы писали:
IB> Не существует определения object, in programming terms.
Ну как же не существует, когда даже спека сразу поясняет, в скобочках, что за state of some resource имеется ввиду Object in programming term это те самые объекты из ООП. Понятнее некуда, кмк.
IB> В этом смысле state of some resource гораздо конкретнее дает понять о чем идет речь.
Вот-вот. Stateful в полный рост
IB> H>SOAP настолько всеобъемлющ (типичный пример overdesign), что качественно реализовать его под силу только гигантам.
IB> Вот это не правда. Он очень качественно порезан на кусочки, так что объемлить только то что нужно проблем не составляет.
Конечно правда. У меня после чтения спецификации создалось впечатление, что они пытаются решить вообще все существующие проблемы. И, как показывает практика, в такой фрагментации SOAP ничего хорошего нет т.к. частичная реализация приводит к частичной совместимости (что в деле решения проблемы взаимодействия гетерогенных систем кажется немного странным).
IB> H> Я сам не раз видел на форумах вопросы о совместимости т.к. реализации разных вендоров не могли нормально взаимодействовать.
IB> Базовые версии типа httpBasic прекрасно взаимодействуют, тем более что альтернативы все равно нет.
Альтернативы всемогущности SOAP? А кому она нужна? Универсальные решения одинаково плохо решают задачи, решение которых, вроде бы, универсализируют В области межплатформенного взаимодействия и интеграции гетерогенных систем альтернативы есть А всяческая заумь, типа каталога сервисов (будто бы даже взаимозаменяемых) и value-added посредников, нужна только астронавтам архитектуры
Здравствуйте, IB, Вы писали:
IB>SOAP как раз совершенно вендоронезависимая конструкция и делался в первую очередь для того, чтобы быть кроссвендорным, ровно по этому в качестве формата сообщений брался XML, а транспорта HTTP. И получилось, надо сказать, весьма не плохо. Недостаток ровно один — очень высокий порог вхождения, и это губит всю идею.
Здравствуйте, TYuD, Вы писали:
IB>>SOAP как раз совершенно вендоронезависимая конструкция и делался в первую очередь для того, чтобы быть кроссвендорным, ровно по этому в качестве формата сообщений брался XML, а транспорта HTTP. И получилось, надо сказать, весьма не плохо. Недостаток ровно один — очень высокий порог вхождения, и это губит всю идею.
TYD>А что значит термин "порог вхлждения"?
Что бы быть специлистом по SOAP надо сначала стать специалистом по SOAP
Здравствуйте, TYuD, Вы писали:
TYD> Повторюсь, что не собираюсь быть специалистом по SOAP, но по определенным причинам меня интересуют ее плюсы и минусы, перспективы.
Небольшое уточнение: SOAP ≠ SOA. То есть, и SOAP, и REST, и всевозможные RPC — это все SOA.
Здравствуйте, hattab, Вы писали:
H>Ага. Только тот пример, что ты показал, рестом не является Это некий гибридный вариант реста и рпц. Операции реста ограничены методами хттп, а у тебя операция есть ресурс. Это от попытки натянуть идеологию на задачу.
Ага. В тру-ресте там было бы PUT на адрес конкретной pipe, где состояние = stopped и reason = maintenance.
А список операций бы формировался неявно, триггером на запись в pipe.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Tanker, Вы писали: T>Ты наверное не в курсе, что wcf data services это рест и не в курсе, что там есть обработка ошибок "искаропки". Загляни на досуге. T>А вообще скажем кеширование гораздо более важно нежели информация об ошибках.
Не, ну если мы так начнём рассуждать, то в WCF есть и SOAP из коробки, со всеми плюшками типа секурити, WSDL, и прочего.
Ты же предлагал соревноваться в равных условиях, т.е. без готовой инфраструктуры.
Внезапно окажется, что если оставить разработчика один-на-один с вебсервером — ну, например, Apache+PHP, то для среднестатистического сервиса что SOAP, что REST API выставить будет примерно одинаково тяжело.
SOAP потребует чуточку больше приседаний для поддержки "начального набора" (ибо есть стандарты), REST — чуточку больше затрат на проектирование (ибо стандартов нет).
Ещё пять лет назад по имеющейся инфраструктуре SOAP уделывал всех в лоскуты — тупо благодаря чудовищному объёму ресурсов, вваленых в его развитие монстрами рынка (типа Microsoft, IBM, и прочими).
Сейчас, судя по твоим постам, REST уже вырос из состояния "чистой идеи", и обзавёлся прикольными инструментами.
Но если хочется сранивать — тогда в честных условиях, WCF против WCF, или LAMP против LAMP. А не LAMP против WCF.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
вообще мало соотносятся с клиентской частью т.к. она (производительность), по большому счету, определяется стороной сервера.
Она, в частности, определяется структурой выставленного API. В вебе перформанс = кэширование. Надёжность = предсказуемость.
Одно реализуется путём концепции safe methods, второе — idempotent methods.
То, что SOAP простандартил вдоль и поперёк всё, кроме концепции этих метаданных о глаголах, наглядно демонстрирует то, что оба требования не входили в top-10 list у его авторов.
Понятно, что вооружённый пониманием концепции идемпотентности разработчик может придумать свой SOAP сервис чуть более надёжным, чем в среднем.
Но если мы говорим о готовом сервисе, то к нему прикрутить идемпотентность без смены интерфейса невозможно.
Вооружённый концепцией safe methods разработчик может попробовать прикрутить кэширование к SOAP, но это будет либо копец, либо копец-копец в зависимости от того, насколько серьёзную задачу он себе поставит. А в HTTP есть коробочная концепция conditional get и куча механизмов по управлению кэшированием, и всё из этого опционально как для сервера, так и для клиента. У меня есть гарантия, что я могу запустить сервис без единой мысли о кэшировании, и через прикрутить его. При этом мне не придётся судорожно синхронизовывать обновления на клиентах и на серверах.
И все остальные плюшки SOAP я могу заретрофиттить в REST-сервис задним числом, сохраняя 100% обратную совместимость.
Для SOAP такая гибкость остаётся недостижимой мечтой.
И именно в этом — основное преимущество REST-архитектуры.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
H>Нет не АПИ. В АПИ входят соглашения о взаимодействии. Модель вообще не в курсе ни каких соглашений. Если твоя в курсе, значит у тебя проблема с дизайном.
Налицо путаница "внутренней модели" и той моделью, которая показывается на публику. В SOAP вся внешняя сторона модели — это набор методов с некоторыми аргументами. Модель там присутствует неявно; например, из наличия методов OrderInfo GetOrder(GUID orderID) и GUID PlaceOrder(OrderInfo order) можно сделать некоторый вывод о существовании в модели понятия Order, с не очень понятными пока взаимосвязями с другими объектами модели. Конечно же, это не означает, что внутри сервиса всё так и устроено — он может быть тонкой обёрткой над тупой SQL-таблицей.
В REST наружу выставляется модель каких-то ресурсов, с прозрачной иерархией и навигационным доступом. Даже без метаданных мы можем делать некоторые предположения о возможных способах взаимодействия — скажем, из наличия ссылки типа http://domain.tld/service/orders/12312312312312312.xml, по которой мы достали объект ордера, мы можем предположить, что PUT на этот адрес аналогично сформированного XML даст нам возможность подправить ордер. Получив код ошибки мы быстро поймём, что происходит — например, 405 method not allowed сразу скажет нам, что должен быть какой-то другой способ редактировать ордера.
Из общих соглашений мы знаем, что POST на адрес http://domain.tld/service/orders/ должен дать нам разместить новый order и получить его адрес. Получив в ответ 403 forbidden мы поймём, что не всем можно размещать ордера, и так далее.
В общем оказывается, что 95% т.н. RPC в среднестатистическом сервисе — это тупой CRUD. Тогда можно обойтись минимумом соглашений.
Ещё 4% — это CRUD, который приводит к интересным изменениям в других частях системы — типа заплейсив Payment можно внезапно обнаружить изменение статуса связанного Order.
И ещё 1% — это всякие сложные сценарии с поддержкой составных транзакций.
В REST первые 95% проектируются вчетверо быстрее, чем в SOAP, т.к. каждый ресурс, будучи описан, сразу даёт 4 глагола.
Дополнительные метасоглашения, типа GData, позволяют свести ещё заметную часть SOAP-кунсткамеры к одному пункту типа "standard query syntax is also supported".
H>Как бы там ни было, рпц не на много сильнее утилизирует канал.
Для того, чтобы это стало правдой, RPC придётся научить делать partial get и conditional get.
H>И какие же трудности возникнут при реализации клиента рпц руками по сравнению с рест в такой ситуации?
Например, 90% типичного "клиента REST" встроено в браузер, что позволяет веб-страничке напрямую потреблять данные из веб-сервиса.
Для вызовов SOAP лично я JS-библиотек не встречал.
H>И как же клиент поймет, что это ошибка, а главное, в чем её суть, без стандартов на данное действо (статус коды хттп проблему не решают)? Как сможет корректно на нее отреагировать? Или предлагается вываливать xml/json/html юзеру нехай разбирается?
Статус коды — прекрасно решают. Чтобы корректно отреагировать на проблему в первом приближении, достаточно вообще анализировать только первую цифру статуса.
Потому, что "корректных реакций" всего три:
— зафейлить операцию с комментарием "мы пытаемся делать фигню, надо что-то исправить на нашей стороне"
— попробовать повторить операцию с теми же параметрами через некоторое время
— попробовать повторить операцию с теми же параметрами по другому адресу.
Это как раз в SOAP надо каждый раз изобретать заново всю стандартную семантику. Скажем, банальный редирект для балансировки или в связи с переездом сервиса в SOAP недостижим как космос для блохи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали:
TYD>>И еще он говорил про преимущество кеширования в REST. Предполагаю на уровне HTTP. IB>Нет там никакого преимущества, у SOAP точно такие же возможности, даже больше. Для SOAP HTTP один из возможных транспортов вместе со всем что этот транспорт предлагает, в том числе и кеширование.
Иван, ты не ткнёш меня носом в кэширование для SOAP? Я что-то не в курсе, каким образом его можно туда прикрутить.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, IB, Вы писали: H>>В тоже время RPC совсем не означает, что сервис будет выполнен как stateful. IB>Давай с терминологией разберемся. Формально RPC — это просто передача сообщения другому приложению.
Не соглашусь. RPC — это Remote Procedure Call, т.е. подразумевается стандартная императивная семантика.
Вместе со всеми её недостатками, типа зависимости результата от порядка вызовов, и фокусирования на параметрах собственно "процедуры".
Идея RPC — изолировать программиста от факта удалённости вызова. Т.е. я как бы делаю Procedure Call, а инфраструктура делает его удалённым.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S> H>Как бы там ни было, рпц не на много сильнее утилизирует канал.
S> Для того, чтобы это стало правдой, RPC придётся научить делать partial get и conditional get.
Все решается на прикладном уровне. Равно как и в REST, за исключением того, что в REST прикладным уровнем является транспортный.
S> H>И какие же трудности возникнут при реализации клиента рпц руками по сравнению с рест в такой ситуации?
S> Например, 90% типичного "клиента REST" встроено в браузер, что позволяет веб-страничке напрямую потреблять данные из веб-сервиса. S> Для вызовов SOAP лично я JS-библиотек не встречал.
Я не совсем понял почему SOAP, когда я все это время говорил о XML-RPC/JSON-RPC. И для того и для другого есть реализации на JS.
S> H>И как же клиент поймет, что это ошибка, а главное, в чем её суть, без стандартов на данное действо (статус коды хттп проблему не решают)? Как сможет корректно на нее отреагировать? Или предлагается вываливать xml/json/html юзеру нехай разбирается?
S> Статус коды — прекрасно решают. Чтобы корректно отреагировать на проблему в первом приближении, достаточно вообще анализировать только первую цифру статуса. S> Потому, что "корректных реакций" всего три: S> — зафейлить операцию с комментарием "мы пытаемся делать фигню, надо что-то исправить на нашей стороне" S> — попробовать повторить операцию с теми же параметрами через некоторое время S> — попробовать повторить операцию с теми же параметрами по другому адресу.
Предположим сервис конвертирования картинок. Параметры: картинка, её content-type и content-type результирующей картинки. Результат — конвертированная в указанный тип картинка. В RPC вся работа будет заключаться в вызове единственного метода, и в случае неудачи анализе причины. 1. Неизвестный тип исходной картинки. 2. Неизвестный тип результирующей картинки. 3. Ошибка чтения картинки (как вариант несоответствие картинки указанному типу). В REST, по идее, сервер должен выругаться 415 кодом, а клиент гадать, к какому content-type у сервера претензии.
S> Это как раз в SOAP надо каждый раз изобретать заново всю стандартную семантику. Скажем, банальный редирект для балансировки или в связи с переездом сервиса в SOAP недостижим как космос для блохи.
Я, как и ранее, скажу за XML-RPC. Так вот, клиенту XML-RPC ничто не мешает (и даже вменяется в обязанность) реагировать на статус коды транспорта соответствующим образом.
Здравствуйте, Sinclair, Вы писали:
S>Не соглашусь. RPC — это Remote Procedure Call, т.е. подразумевается стандартная императивная семантика. S>Вместе со всеми её недостатками, типа зависимости результата от порядка вызовов, и фокусирования на параметрах собственно "процедуры". S>Идея RPC — изолировать программиста от факта удалённости вызова. Т.е. я как бы делаю Procedure Call, а инфраструктура делает его удалённым.
Совершенно верно, это то как это обычно понимают, о чем я уже и писал. Но _формально_ это просто передача данных удаленному методу.
Мы уже победили, просто это еще не так заметно...
