Ответ 1
SOAP может быть отправлен через разные транспорты. HTTP является лишь одним из них.
Ниже приведено демо-сообщение SOAP-запроса:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:SessionOrder
xmlns:t="http://example.com"
xsi:type="xsd:int" mustUnderstand="1">
5
</t:SessionOrder>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<GetStockQuote
xmlns="http://someexample.com">
<Price>MSFT</Price>
</GetStockQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
И мы можем видеть, что это сообщение SOAP закодировано, как если бы оно было веб-страницей. Почему мы должны использовать протокол HTTP? Сообщение SOAP - это всего лишь некоторый XML, почему бы нам просто не использовать XML в качестве протокола обмена информацией и избавиться от HTTP-заголовков (таким образом, оставить только HTTP).
Большое спасибо.
HTTP не является протоколом транспортного уровня. Это всего лишь протокол уровня приложения. Это не имеет никакого отношения к транспорту. На самом деле, мой вопрос заключается в том, какой мотив добавления HTTP-материала в сообщение SOAP?
SOAP может быть отправлен через разные транспорты. HTTP является лишь одним из них.
SOAP - это протокол обмена сообщениями, и в двух словах это еще один язык XML.
Его целью является обмен данными по сетям. Его задачей является инкапсуляция этих данных и правила их передачи и получения.
HTTP - это протокол приложений, а сообщения SOAP помещаются как полезная нагрузка HTTP.
Хотя есть накладные расходы на HTTP, он имеет то преимущество, что это протокол, открытый для брандмауэров, хорошо понятый и широко поддерживаемый. Таким образом, веб-службы могут быть доступны и доступны через уже существующие технологии.
Сообщения SOAP обычно обмениваются через HTTP. Хотя можно использовать другие (прикладные) протоколы, например. SMTP или FTP, привязки не-HTTP не указываются спецификациями SOAP и не поддерживаются WS-BP (спецификация совместимости).
Вы можете обмениваться сообщениями SOAP через raw TCP, но тогда у вас будут веб-службы, которые не совместимы (не совместимы с WS-BP).
В настоящее время дискуссия объясняется тем, что накладные расходы SOAP вообще и не отправлять данные через HTTP (RESTful WS).
Я попытаюсь более подробно рассмотреть вопрос в OP, спрашивая, зачем использовать HTTP для SOAP:
Прежде всего SOAP определяет формат инкапсуляции данных и что.
Теперь большая часть трафика в Интернете через HTTP. HTTP литературный EVERYWHERE и поддерживается хорошо развитой инфраструктурой серверов и клиентов (а именно браузеров). Кроме того, это очень хорошо понятый протокол.
Люди, которые создали SOAP, хотели использовать эту готовую инфраструктуру и
Туннелирование по HTTP было бы и помогло бы в этом быстрое принятие. Поскольку инфраструктура HTTP уже на месте, компаниям не придется тратить лишние деньги на другой вид реализации. Вместо этого они могут открывать и получать доступ к веб-сервисам с использованием уже развернутой технологии.
В частности, в Java веб-служба может быть развернута либо как конечная точка сервлета, либо как конечная точка EJB. Таким образом, все основные сетевые сокеты, потоки, потоки, транзакции HTTP и т.д. Обрабатываются контейнером, а разработчик фокусируется только на полезной нагрузке XML.
Таким образом, у компании есть Tomcat или JBoss, работающие в порту 80, и веб-сервис также развернут и доступен.
Нет усилий для программирования на транспортном уровне, а надежный контейнер обрабатывает все остальное.
Наконец, тот факт, что брандмауэры настроены не ограничивать HTTP-трафик, является третьей причиной предпочтения HTTP.
Поскольку HTTP-трафик обычно разрешен, связь клиентов/серверов намного проще, и веб-службы могут функционировать без проблем блокировщиков сетевой безопасности в результате туннелирования HTTP.
SOAP - это XML = обычный текст, поэтому брандмауэры могут проверять содержимое тела HTTP и блокировать соответственно. Но в этом случае они также могут быть расширены, чтобы отклонять или принимать SOAP в зависимости от содержимого. Эта часть, которая, кажется, беспокоит вас, не связана с веб-сервисами или SOAP, и, возможно, вам следует начать новый поток, касающийся работы брандмауэров.
Сказав это, тот факт, что HTTP-трафик неограничен, часто вызывает проблемы с безопасностью, поскольку брандмауэры по существу не передаются, и именно поэтому приходят шлюзы приложений.
Но это не связано с этой записью.
Итак, чтобы подвести итоги использования HTTP:
Мотивом использования HTTP было проникновение через брандмауэры. Вы видите, что большинство сетевых ИТ-пользователей не разрешают открывать какой-либо порт, но по какой-то причине они всегда открывали порт 80 для веб-страниц. Поскольку веб-серверы были протестированы на протяжении многих лет, их "легче" обеспечить. Используя HTTP, у вас есть существующий набор инструментов для работы с протоколом связи.
вы также можете использовать TCP, и он был назван .NET Remoting до и теперь его частью WCF...
Разработчик может выбрать уровень переноса для протокола простого доступа к объектам. XML не является сетевым протоколом, поэтому данные не могут передаваться с использованием только XML. Он должен быть упакован во что-то.
Еще одна причина может заключаться в том, что (если я правильно помню) HTTP также обозначается как "золотой стандарт" для того, как должен выглядеть/работать интернет-протокол, поэтому, если вы должны разработать собственный протокол, (по крайней мере, в идеальном мире) заканчиваются чем-то очень похожим, если вы следовали всем RFC. Поэтому почему бы не использовать HTTP, один из самых распространенных и хорошо понятых протоколов в мире.
В основном SOAP - это стандарт веб-сервисов, который содержит описания сообщения, которые в форме XML. Эта структура сообщений будет передаваться во время веб-службы, вызванной реквестером службы. В SOA-архитектуре одной из наиболее важных характеристик является совместимость, в SOA SOAP играют огромную роль, которые передаются через HTTP/HTTPS и поэтому могут пересекать брандмауэры, другая архитектура, такая как DCOM, CORBA и RPC, не пересекает брандмауэр.
SOAP не нужно отправлять по HTTP. Разработчики чаще всего используют HTTP и POST мыло, как если бы это был обычный HTTP POST, потому что мы, скорее всего, более знакомы с HTTP, чем другие протоколы, такие как SMTP, добавляем это к тому, что мы уже реализуем REST через HTTP. Например, вот как мы отправляем SOAP через SMTP-протокол электронной почты. Отправка SOAP через SMTP
Это обычная практика использования HTTP
Все браузеры поддерживают HTTP для совместимости и наиболее широко используемый Интернет-протокол. SOAP - это протокол связи, который определяет формат отправки сообщений. RPC и CORBA имеют проблемы совместимости и безопасности, тогда как HTTP совместим со всеми браузерами. Теперь, когда HTTP обменивается данными через TCP/IP. Метод SOAP представляет собой HTTP-запрос/HTTP-ответ, который компилируется с правилами кодирования SOAP. используя протокол SOAP, протокол, переданный в данные W3C, может быть заключен в XML и передан с использованием любого количества интернет-протоколов.