Я слышал некоторые мнения о том, что стек вызовов службы веб-службы SOAP/HTTP "толстый" или "тяжеловес", но я не могу точно определить, почему. Будет ли это считаться толстым из-за сериализации/десериализации конверта SOAP и сообщения? Это действительно тяжелая операция?
Или это просто считается "толстым" по сравнению с сырой/двоичной передачей данных по фиксированному соединению?
Или это какая-то другая причина? Может ли кто-нибудь пролить свет на это?
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, исходная проблема была в основном решена для начала.
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, в отличие от тяжелого веса, это с точки зрения необработанного количества данных. Я думаю, что необработанное количество данных менее важно (хотя оно быстро складывается, если вам нужно обрабатывать множество небольших запросов), а насколько концептуально тяжелый он очень важен, потому что это означает, что есть намного больше мест, где что-то может пойти не так, где может быть несовместимость и т.д.
Я согласен с первым плакатом, но хотел бы добавить к нему. Толстое и тонкое определение относительное. С транспортом, таким как JSON или REST, появление SOAP выглядит тяжело на поверхности для примеров "привет мир". Теперь, как вы уже знаете, что делает SOAP тяжелым, а WS 2.0 в целом - это корпоративные/надежные функции. JSON не защищен так же, как и WS 2.0. Я не слышал, чтобы SOAP назывался толстым, но многие не-XML-орехи рассматривают эти спецификации как тяжелые или толстые. Чтобы быть ясным, я не говорю ни за, ни против того, как оба имеют свое место. XML более подробный и удобочитаемый и, следовательно, "толще". Последняя часть состоит в том, что некоторые люди считают HTTP постоянным протоколом соединения, чтобы быть тяжелым, учитывая новые веб-тенденции, такие как AJAX, а не выступать на большой странице. Накладные расходы на подключение являются большими, поскольку нет никакой выгоды.
Таким образом, нет реальной причины, за исключением того, что кто-то хочет называть SOAP/HTTP толстым, это все относительно. Меньше стандартов являются идеальными и для всех сценариев. Если бы мне пришлось угадать, какой-то умный веб-разработчик считает, что он настолько умный, говоря о том, как мыслит XML-технологии и как супер JSON. У каждого есть место.
Отношение сигнал-шум SOAP слишком низкое. Для простого разговора слишком много структурных накладных расходов без значения данных; и требуется слишком большая явная конфигурация (по сравнению с неявной конфигурацией, например JSON).
Это не началось именно так, но в итоге это был плакат-ребенок за то, что происходит с хорошей идеей, когда участвует комитет по стандартам.
Прежде всего, во многом зависит от того, как ваши службы реализованы (т.е. вы можете многое сделать для уменьшения полезной нагрузки, просто заботясь о том, как выполняются подписи вашего метода).
Тем не менее, не только мыльный конверт, но и само сообщение может быть намного более громоздким в xml, а не упрощенным бинарным форматом. Просто выбор правильного класса и имен участников может значительно уменьшить его...
Рассмотрим следующие примеры сериализованных методов, возвращаемых из методов, возвращающих коллекцию материала. Просто выбирая правильное имя [serialization] для классов/оболочек и членов, может иметь большое значение в многословии сериализованного запроса/ответа на мыло, если вы возвращаете повторяющиеся данные (например, списки/коллекции/массивы).
Краткие/короткие имена:
<?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>
1 - XML-схемы, которые являются ключевой частью спецификации WSDL, действительно, действительно большие и сложные. На практике вы, инструменты, которые делают такие схемы, как схема XML XML, в конструкции языка программирования только в конечном итоге поддерживают часть возможностей схемы XML.
2 - Спецификации WS- *, например WS-Security и WS-SecureConversation, снова являются большими и сложными. Они почти разработаны таким образом, что никто не будет иметь меньше ресурсов, чем Microsoft или IBM могли бы полностью реализовать их.
Я считал его "толстым" из-за относительно больших накладных расходов, связанных с упаковкой и распаковкой сообщения (сериализация и десериализация).
Рассмотрим веб-сервис с веб-методом под названием Add, который принимает два 32-разрядных целых числа. Абонент отправляет два целых числа и получает в ответ одно целое число. Там, где на самом деле передается только 96 бит информации, добавление SOAP-пакетов, вероятно, добавит около 3000 или более дополнительных бит в каждом направлении. Увеличение в 30 раз.
К этому относится сравнительно низкая производительность, связанная с сериализацией и десериализацией сообщения в UTF-8 (или что-то еще) XML. По общему признанию, это довольно быстро в эти дни, но это, конечно, не тривиально.
Я думаю, в основном, что конверт SOAP добавляет большой объем накладных расходов для построения сообщения, особенно для обычного случая простого запроса с несколькими, а не глубоко структурированными параметрами. Сравните это с веб-службой стиля REST, где параметры просто включены в запрос URL.
Затем добавьте к этому сложность WSDL и типичные реализации "корпоративных" библиотек...