Почему HTTP / SOAP считается «толстым»

Question

Я слышал некоторые мнения, что стек вызовов веб-сервисов SOAP / HTTP «толстый» или «тяжеловесный», но я не могу точно определить, почему Будет ли он считаться толстым из-за сериализации / десериализации конверта SOAP и сообщения? Это действительно тяжелая операция?

Или это просто считается "толстым" по сравнению с передачей необработанных / двоичных данных по фиксированному соединению?

Или это какая-то другая причина? Кто-нибудь может пролить свет на это?

Answer 1

SOAP разработан достаточно абстрактно, чтобы использовать другие транспорты, кроме HTTP. Это означает, помимо прочего, что не не использует некоторые аспекты HTTP (в основном RESTful использование URL-адресов и методов, например, PUT /customers/1234 или GET /customers/1234).

SOAP также обходит существующие механизмы TCP / IP по той же причине - быть независимой от транспорта. Опять же, это означает, что он не может использовать преимущества транспорта, такие как управление последовательностями, управление потоком, обнаружение службы (например, accept() подключение к известному порту означает, что служба существует) и т. Д.

SOAP использует XML для всей своей сериализации - хотя это означает, что данные являются «универсально читаемыми» с помощью всего лишь синтаксического анализатора XML, он вводит настолько много шаблонов, что для эффективного функционирования вам действительно нужен анализатор SOAP. И в этот момент вы (как потребитель программного обеспечения) в любом случае утратили преимущества XML; кому все равно, как выглядит полезная нагрузка через провод, если вам все равно нужно libSOAP для ее обработки.

SOAP требует WSDL для описания интерфейсов. WSDL сам по себе не является проблемой, но он, как правило, рекламируется гораздо более «динамично», чем на самом деле. Во многих случаях создается один WSDL, и из этого автоматически генерируется код производителя / потребителя, и он никогда не изменяется. В целом, для этого требуется много инструментов без какого-либо лучшего решения исходной проблемы (как общаться между различными серверами). А поскольку большинство служб SOAP работают по протоколу HTTP, исходная проблема была уже , в основном для начала решенной.

Answer 2

SOAP и WSDL являются чрезвычайно сложными стандартами, которые имеют много реализаций, которые поддерживают различные подмножества стандартов. SOAP не очень хорошо сопоставляется с простым интерфейсом внешних функций так же, как XML-RPC . Вместо этого вы должны понимать пространства имен XML, конверты, заголовки, WSDL, схемы XML и т. Д., Чтобы создавать правильные сообщения SOAP. Все, что вам нужно сделать для вызова службы XML-RPC, - это определить конечную точку и вызвать для нее метод. Например, в Ruby:

require 'xmlrpc/client'

server = XMLRPC::Client.new2("http://example.com/api")
result = server.call("add", 1, 2)

Помимо XML-RPC, существуют и другие методы, которые также могут быть намного более простыми и легкими, например простой XML или JSON по HTTP (часто называемый REST , хотя это подразумевает некоторые другие соображения дизайна). Преимущество чего-то вроде XML или JSON перед HTTP заключается в том, что его легко использовать из JavaScript или даже просто глупой веб-страницы с отправкой формы. Его также можно легко написать из командной строки с помощью таких инструментов, как curl . Он работает практически с любым языком, так как HTTP-библиотеки, XML-библиотеки и JSON-библиотеки доступны практически везде, и даже если JSON-анализатор недоступен, написать свой собственный очень легко.

Редактировать: Я должен уточнить, что я имею в виду, как концептуально тяжелый SOAP, в отличие от большого веса это с точки зрения необработанного объема данных. Я думаю, что необработанный объем данных менее важен (хотя он быстро складывается, если вам нужно обрабатывать множество небольших запросов), а то, насколько он концептуально тяжёлый, довольно важен, потому что это означает, что есть гораздо больше мест, где что-то может пойти не так, где может быть несовместимость и т. д.

Answer 3

Я согласен с первым постером, но хотел бы добавить к нему. Толстое и тонкое определение является относительным. С такими транспортными средствами, как JSON или REST, SOAP выглядит тяжело на поверхности для примеров "привет мира". Теперь, как вы, возможно, уже знаете, что делает SOAP тяжелым, а WS 2.0 в целом - корпоративными / надежными функциями. JSON не так безопасен, как WS 2.0. Я не слышал, чтобы SOAP назывался толстым, но многие не-XML-орехи смотрят на эти спецификации как на толстые или толстые. Чтобы было ясно, я не говорю ни за, ни против, так как оба имеют свое место. XML более многословен, удобен для чтения и, следовательно, «толще». Последняя часть заключается в том, что некоторые люди считают HTTP постоянным протоколом соединения тяжелым, учитывая новые веб-тенденции, такие как AJAX, вместо того, чтобы работать на большой странице. Затраты на соединение велики, учитывая, что в действительности нет никакой выгоды.

В итоге, нет реальной причины , кроме того, что кто-то хочет назвать SOAP / HTTP толстым, все относительно. Меньше стандартов идеально подходит и для всех сценариев. Если бы мне пришлось догадываться, какой-нибудь умный веб-разработчик думает, что он такой умный, говоря о том, как думают технологии XML и как супер JSON. У каждого есть место.

Answer 4

Соотношение сигнал / шум SOAP слишком низкое. Для простого разговора слишком много структурных издержек без значения данных; и требуется слишком много явной конфигурации (по сравнению с неявной конфигурацией, такой как JSON).

Это не началось таким образом, но в конечном итоге это стало примером для детей в отношении того, что случается с хорошей идеей, когда в нее вмешивается комитет по стандартам.

Answer 5

1 - XML-схемы, которые являются ключевой частью спецификации WSDL, действительно, очень большие и сложные. На практике такие инструменты, как сопоставление схемы XML с конструкциями языка программирования, в конечном итоге поддерживают только часть функций схемы XML.

2 - Спецификации WS- *, например WS-Security и WS-SecureConversation, снова большие и сложные. Они почти спроектированы таким образом, чтобы никто, кроме Microsoft или IBM, не располагал меньшим количеством ресурсов для их полной реализации.

Answer 6

Прежде всего, это во многом зависит от того, как реализованы ваши сервисы (то есть вы можете многое сделать для уменьшения полезной нагрузки, просто следя за тем, как выполняются сигнатуры вашего метода).

Тем не менее, не только мыльный конверт, но и само сообщение может быть намного более громоздким в xml, чем в упрощенном двоичном формате. Просто выбор правильного класса и имен членов может сильно уменьшить его ...

Рассмотрим следующие примеры возвращений сериализованных методов из методов, возвращающих коллекцию материала. Простой выбор правильного имени [serialization] для классов / оболочек и членов может существенно повлиять на многословность сериализованного запроса / ответа на мыло, если вы возвращаете повторяющиеся данные (например, lists / collection / arrays).

Краткое / краткое наименование:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfShortIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ShortIDName>
    <id>0</id>
    <name>foo 0</name>
  </ShortIDName>
  <ShortIDName>
    <id>1</id>
    <name>foo 1</name>
  </ShortIDName>
  <ShortIDName>
    <id>2</id>
    <name>foo 2</name>
  </ShortIDName>
  ...
</ArrayOfShortIDName>

Длинные имена:

<?xml version="1.0" encoding="utf-8"?>
<ArrayOfThisClassHasALongClassNameIDName xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://tempuri.org/">
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>0</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 0</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>1</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 1</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  <ThisClassHasALongClassNameIDName>
    <MyLongMemberNameObjectID>2</MyLongMemberNameObjectID>
    <MyLongMemberNameObjectName>foo 2</MyLongMemberNameObjectName>
  </ThisClassHasALongClassNameIDName>
  ...
</ArrayOfThisClassHasALongClassNameIDName>

Answer 7

Я посчитал это "толстым" из-за относительно больших накладных расходов, связанных с упаковкой и распаковкой сообщения (сериализацией и десериализацией).

Рассмотрим веб-сервис с веб-методом с именем Add, который принимает два 32-разрядных целых числа. Вызывающая сторона упаковывает два целых числа и получает одно целое в ответе. Там, где на самом деле передается только 96 бит информации, добавление пакетов SOAP, вероятно, добавит около 3000 или более дополнительных бит в каждом направлении. 30-кратное увеличение.

К этому добавляется сравнительно низкая производительность, связанная с сериализацией и десериализацией сообщения в XML-код UTF-8 (или любой другой). По общему признанию это довольно быстро в эти дни, но это конечно не тривиально.

Answer 8

Я думаю, это в основном то, что конверт SOAP добавляет большие накладные расходы при построении сообщения, особенно для обычного случая простого запроса только с несколькими неструктурированными параметрами. Сравните это с веб-сервисом в стиле REST, в котором параметры просто включены в URL-запрос.

Затем добавьте к этому сложность WSDL и типичных реализаций библиотеки "Enterprise" ...