Протокол обмена сообщениями в распределенной среде
Обновлено: 04.07.2024
Различные книги и разные организации предоставляют разные определения для веб-сервисов. Некоторые из них перечислены здесь.
Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.
Веб-сервис — это набор открытых протоколов и стандартов, используемых для обмена данными между приложениями или системами. Программные приложения, написанные на разных языках программирования и работающие на разных платформах, могут использовать веб-сервисы для обмена данными по компьютерным сетям, таким как Интернет, аналогично межпроцессному взаимодействию на одном компьютере. Эта совместимость (например, между приложениями Java и Python или Windows и Linux) обусловлена использованием открытых стандартов.
Таким образом, полный веб-сервис — это любой сервис, который —
Доступен через Интернет или частные (интранет) сети
Не привязан ни к одной операционной системе или языку программирования
Это самоописание через общую грамматику XML
Обнаруживается с помощью простого механизма поиска
Доступен через Интернет или частные (интранет) сети
Не привязан ни к одной операционной системе или языку программирования
Это самоописание через общую грамматику XML
Обнаруживается с помощью простого механизма поиска
Компоненты веб-сервисов
SOAP (простой протокол доступа к объектам)
UDDI (универсальное описание, обнаружение и интеграция)
WSDL (язык описания веб-сервисов)
SOAP (простой протокол доступа к объектам)
UDDI (универсальное описание, обнаружение и интеграция)
WSDL (язык описания веб-сервисов)
Как работает веб-сервис?
Веб-сервис обеспечивает связь между различными приложениями с использованием открытых стандартов, таких как HTML, XML, WSDL и SOAP. Веб-сервис принимает помощь —
XML для пометки данных
WSDL для описания доступности сервиса.
XML для пометки данных
WSDL для описания доступности сервиса.
На Solaris можно создать веб-службу на основе Java, доступную из вашей программы Visual Basic, которая работает в Windows.
пример
Рассмотрим простую систему управления счетами и обработки заказов. Сотрудники бухгалтерии используют клиентское приложение, созданное с помощью Visual Basic или JSP, для создания новых учетных записей и ввода новых заказов клиентов.
Логика обработки для этой системы написана на Java и находится на компьютере Solaris, который также взаимодействует с базой данных для хранения информации.
Шаги для выполнения этой операции следующие:
Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.
Приложение обрабатывает информацию по мере необходимости и отвечает новым уникальным номером учетной записи для этого клиента.
Веб-служба распаковывает запрос SOAP и преобразует его в команду, понятную приложению.
Приложение обрабатывает информацию по мере необходимости и отвечает новым уникальным номером учетной записи для этого клиента.
Вот преимущества использования веб-сервисов —
Разоблачение существующей функции в сети
Interoperability
Стандартизированный протокол
Веб-сервисы используют стандартизированный протокол промышленного стандарта для связи. Все четыре уровня (уровни Service Transport, XML Messaging, Service Description и Service Discovery) используют четко определенные протоколы в стеке протоколов веб-служб. Эта стандартизация стека протоколов дает бизнесу множество преимуществ, таких как широкий выбор, снижение стоимости из-за конкуренции и повышение качества.
Низкая стоимость связи
Веб-сервисы имеют следующие специальные поведенческие характеристики —
XML-Based
Веб-сервисы используют XML на уровнях представления данных и передачи данных. Использование XML устраняет любые сетевые, операционные системы или привязки платформы. Приложения на основе веб-служб обладают высокой функциональной совместимостью на уровне ядра.
Слабо связанный
Потребитель веб-сервиса не привязан к этому веб-сервису напрямую. Интерфейс веб-службы может меняться со временем, не ставя под угрозу способность клиента взаимодействовать со службой. Тесно связанная система подразумевает, что клиентская и серверная логика тесно связаны друг с другом, подразумевая, что если один интерфейс изменяется, другой должен быть обновлен. Использование слабосвязанной архитектуры делает программные системы более управляемыми и упрощает интеграцию между различными системами.
Крупнозернистый
Объектно-ориентированные технологии, такие как Java, предоставляют свои услуги с помощью отдельных методов. Отдельный метод — это слишком хорошая операция, чтобы предоставить какие-либо полезные возможности на корпоративном уровне. Создание Java-программы с нуля требует создания нескольких детализированных методов, которые затем объединяются в грубый сервис, который используется клиентом или другим сервисом.
Предприятия и интерфейсы, которые они выставляют, должны быть крупнозернистыми. Технология веб-сервисов обеспечивает естественный способ определения грубых сервисов, которые получают необходимый объем бизнес-логики.
Способность быть синхронной или асинхронной
Синхронность относится к привязке клиента к выполнению услуги. При синхронных вызовах клиент блокирует и ждет, пока служба завершит свою работу, прежде чем продолжить. Асинхронные операции позволяют клиенту вызывать службу и затем выполнять другие функции.
Асинхронные клиенты получают свой результат в более поздний момент времени, в то время как синхронные клиенты получают свой результат после завершения службы. Асинхронные возможности являются ключевым фактором в создании слабосвязанных систем.
Поддерживает удаленные вызовы процедур (RPC)
Веб-службы позволяют клиентам вызывать процедуры, функции и методы на удаленных объектах с использованием протокола на основе XML. Удаленные процедуры предоставляют входные и выходные параметры, которые должен поддерживать веб-сервис.
Поддерживает обмен документами
Одним из ключевых преимуществ XML является его общий способ представления не только данных, но и сложных документов. Эти документы могут быть такими же простыми, как представление текущего адреса, или такими же сложными, как и представление всей книги или запроса предложения (RFQ). Веб-сервисы поддерживают прозрачный обмен документами для облегчения интеграции бизнеса.
Существует два способа просмотра архитектуры веб-службы:
- Первый заключается в изучении отдельных ролей каждого участника веб-службы.
- Во-вторых, исследовать появляющийся стек протоколов веб-службы.
Роли веб-сервисов
В архитектуре веб-службы есть три основные роли:
Поставщик услуг
Это поставщик веб-службы. Поставщик услуг реализует услугу и делает ее доступной в Интернете.
Запрос на обслуживание
Это любой потребитель веб-сервиса. Запрашивающая сторона использует существующую веб-службу, открывая сетевое соединение и отправляя запрос XML.
Сервисный реестр
Это логически централизованный каталог услуг. Реестр предоставляет центральное место, где разработчики могут публиковать новые сервисы или находить существующие. Поэтому он служит централизованным расчетным центром для компаний и их услуг.
Стек протоколов веб-служб
Второй вариант для просмотра архитектуры веб-службы — это проверка появляющегося стека протоколов веб-службы. Стек все еще развивается, но в настоящее время имеет четыре основных слоя.
Сервисный транспорт
Описание услуг
Этот уровень отвечает за описание общедоступного интерфейса к определенному веб-сервису. В настоящее время описание службы обрабатывается с помощью языка описания веб-служб (WSDL).
Сервис Discovery
Этот уровень отвечает за централизацию сервисов в общем реестре и обеспечивает простую функциональность публикации / поиска. В настоящее время обнаружение служб обрабатывается с помощью универсального описания, обнаружения и интеграции (UDDI).
По мере развития веб-сервисов могут быть добавлены дополнительные уровни и дополнительные технологии могут быть добавлены к каждому уровню.
Следующая глава объясняет компоненты веб-сервисов.
Несколько слов о сервисном транспорте
Блокирует расширяемый протокол обмена (BEEP)
За последние несколько лет три основные технологии стали мировыми стандартами, составляющими основу современных технологий веб-сервисов. Эти технологии обсуждаются ниже.
XML-RPC
Это самый простой протокол на основе XML для обмена информацией между компьютерами.
XML-RPC не зависит от платформы.
XML-RPC позволяет различным приложениям общаться.
Java-клиент может передавать XML-RPC на сервер Perl.
XML-RPC — это самый простой способ начать работу с веб-сервисами.
Cтек протоколов TCP/IP широко распространен. Он используется в качестве основы для глобальной сети интернет. Разбираемся в основных понятиях и принципах работы стека.
Основы TCP/IP
Стек протоколов TCP/IP (Transmission Control Protocol/Internet Protocol, протокол управления передачей/протокол интернета) — сетевая модель, описывающая процесс передачи цифровых данных. Она названа по двум главным протоколам, по этой модели построена глобальная сеть — интернет. Сейчас это кажется невероятным, но в 1970-х информация не могла быть передана из одной сети в другую, с целью обеспечить такую возможность был разработан стек интернет-протоколов также известный как TCP/IP.
Разработкой этих протоколов занималось Министерство обороны США, поэтому иногда модель TCP/IP называют DoD (Department of Defence) модель. Если вы знакомы с моделью OSI, то вам будет проще понять построение модели TCP/IP, потому что обе модели имеют деление на уровни, внутри которых действуют определенные протоколы и выполняются собственные функции. Мы разделили статью на смысловые части, чтобы было проще понять, как устроена модель TCP/IP:
Уровневая модель TCP/IP
Три верхних уровня — прикладной, транспортный и сетевой — присутствуют как в RFC, так и у Таненбаума и других авторов. А вот стоит ли говорить только о канальном или о канальном и физическом уровнях — нет единого мнения. В RFC они объединены, поскольку выполняют одну функцию. В статье мы придерживаемся официального интернет-стандарта RFC и не выделяем физический уровень в отдельный. Далее мы рассмотрим четыре уровня модели.
Канальный уровень (link layer)
Предназначение канального уровня — дать описание тому, как происходит обмен информацией на уровне сетевых устройств, определить, как информация будет передаваться от одного устройства к другому. Информация здесь кодируется, делится на пакеты и отправляется по нужному каналу, т.е. среде передачи.
Этот уровень также вычисляет максимальное расстояние, на которое пакеты возможно передать, частоту сигнала, задержку ответа и т.д. Все это — физические свойства среды передачи информации. На канальном уровне самым распространенным протоколом является Ethernet, но мы рассмотрим его на примере в конце статьи.
Межсетевой уровень (internet layer)
Каждая индивидуальная сеть называется локальной, глобальная сеть интернет позволяет объединить все локальные сети. За объединение локальных сетей в глобальную отвечает сетевой уровень. Он регламентирует передачу информации по множеству локальных сетей, благодаря чему открывается возможность взаимодействия разных сетей.
Межсетевое взаимодействие — это основной принцип построения интернета. Локальные сети по всему миру объединены в глобальную, а передачу данных между этими сетями осуществляют магистральные и пограничные маршрутизаторы.
Маска подсети и IP-адреса
Маска подсети помогает маршрутизатору понять, как и куда передавать пакет. Подсетью может являться любая сеть со своими протоколами. Маршрутизатор передает пакет напрямую, если получатель находится в той же подсети, что и отправитель. Если же подсети получателя и отправителя различаются, пакет передается на второй маршрутизатор, со второго на третий и далее по цепочке, пока не достигнет получателя.
Протокол интернета — IP (Internet Protocol) используется маршрутизатором, чтобы определить, к какой подсети принадлежит получатель. Свой уникальный IP-адрес есть у каждого сетевого устройства, при этом в глобальной сети не может существовать два устройства с одинаковым IP. Он имеет два подвида, первым был принят IPv4 (IP version 4, версии 4) в 1983 году.
IPv4 предусматривает назначение каждому устройству 32-битного IP-адреса, что ограничивало максимально возможное число уникальных адресов 4 миллиардами (2 32 ). В более привычном для человека десятичном виде IPv4 выглядит как четыре блока (октета) чисел от 0 до 255, разделенных тремя точками. Первый октет IP-адреса означает его класс, классов всего 4: A, B, C, D.
IPv6 имеет вид восьми блоков по четыре шестнадцатеричных значения, а каждый блок разделяется двоеточием. IPv6 выглядит следующим образом:
Так как IPv6 адреса длинные, их разрешается сокращать по следующим правилам: ведущие нули допускается опускать, например в адресе выше :00FF: позволяется записывать как :FF:, группы нулей, идущие подряд тоже допустимо сокращать и заменять на двойное двоеточие, например, 2DAB:FFFF::01AA:00FF:DD72:2C4A. Допускается делать не больше одного подобного сокращения в адресе IPv6.
IP предназначен для определения адресата и доставки ему информации, он предоставляет услугу для вышестоящих уровней, но не гарантирует целостность доставляемой информации.
ICMP и IGMP
ICMP никогда не вызывается сетевыми приложениями пользователя, кроме случаев диагностики сети, к примеру, пинг (ping) или traceroute (tracert). ICMP не передает данные, это отличает его от транспортных TCP и UDP, расположенных на L3, которые переносят любые данные. ICMP работает только с IP четвертой версии, с IPv6 взаимодействует ICMPv6.
Сетевые устройства объединяются в группы при помощи IGMP, используемый хостами и роутерами в IPv4 сетях. IGMP организует multicast-передачу информации, что позволяет сетям направлять информацию только хостам, запросившим ее. Это удобно для онлайн-игр или потоковой передаче мультимедиа. IGMP используется только в IPv4 сетях, в сетях IPv6 используется MLD (Multicast Listener Discovery, протокол поиска групповых слушателей), инкапсулированный в ICMPv6.
Транспортный уровень (transport layer)
Постоянные резиденты транспортного уровня — протоколы TCP и UDP, они занимаются доставкой информации.
TCP (протокол управления передачей) — надежный, он обеспечивает передачу информации, проверяя дошла ли она, насколько полным является объем полученной информации и т.д. TCP дает возможность двум хостам производить обмен пакетами через установку соединения. Он предоставляет услугу для приложений, повторно запрашивает потерянную информацию, устраняет дублирующие пакеты, регулируя загруженность сети. TCP гарантирует получение и сборку информации у адресата в правильном порядке.
UDP (протокол пользовательских датаграмм) — ненадежный, он занимается передачей автономных датаграмм. UDP не гарантирует, что всех датаграммы дойдут до получателя. Датаграммы уже содержат всю необходимую информацию, чтобы дойти до получателя, но они все равно могут быть потеряны или доставлены в порядке отличном от порядка при отправлении.
UDP обычно не используется, если требуется надежная передача информации. Использовать UDP имеет смысл там, где потеря части информации не будет критичной для приложения, например, в видеоиграх или потоковой передаче видео. UDP необходим, когда делать повторный запрос сложно или неоправданно по каким-то причинам.
Протоколы L3 не интерпретируют информацию, полученную с верхнего или нижних уровней, они служат только как канал передачи, но есть исключения. RSVP (Resource Reservation Protocol, протокол резервирования сетевых ресурсов) может использоваться, например, роутерами или сетевыми экранами в целях анализа трафика и принятия решений о его передаче или отклонении в зависимости от содержимого.
Прикладной уровень (application layer)
В модели TCP/IP отсутствуют дополнительные промежуточные уровни (представления и сеансовый) в отличие от OSI. Функции форматирования и представления данных делегированы библиотекам и программным интерфейсам приложений (API) — своего рода базам знаний. Когда службы или приложения обращаются к библиотеке или API, те в ответ предоставляют набор действий, необходимых для выполнения задачи и полную инструкцию, каким образом эти действия нужно выполнять.
Зачем нужен порт и что означает термин сокет
IP присваивается каждому компьютеру межсетевым уровнем, но обмен данными происходит не между компьютерами, а между приложениями, установленными на них. Чтобы получить доступ к тому или иному сетевому приложению недостаточно только IP, для идентификации приложений применяют порты. Комбинация IP-адреса и порта называется сокетом или гнездом (socket). Поэтому обмен информацией происходит между сокетами. Нередко слово сокет употребляют как синоним для хоста или пользователя, также сокетом называют гнездо подключения процессора.
Из привилегий у приложений на прикладном уровне можно выделить наличие собственных протоколов для обмена данными, а также фиксированный номер порта для обращения к сети. Администрация адресного пространства интернет (IANA), занимающаяся выделением диапазонов IP-адресов, отвечает еще за назначение сетевым приложениям портов.
Процесс, кодирования данных на прикладном уровне, передача их на транспортном, а затем на межсетевом и, наконец, на канальном уровне называется инкапсуляцией данных. Обратная передача битов информации по иерархии, с канального на прикладной уровни, называют декапсуляцией. Оба процесса осуществляются на компьютерах получателя и отправителя данных попеременно, это позволяет долго не удерживать одну сторону канала занятой, оставляя время на передачу информации другому компьютеру.
Стек протоколов, снова канальный уровень
После ознакомления с уровневой структурой модели становится понятно, что информация не может передаваться между двумя компьютерами напрямую. Сначала кадры передаются на межсетевой уровень, где компьютеру отправителя и компьютеру получателя назначается уникальный IP. После чего, на транспортном уровне, информация передается в виде TCP-фреймов либо UDP-датаграмм.
На каждом этапе, подобно снежному кому, к уже имеющейся информации добавляется служебная информация, например, порт на прикладном уровне, необходимый для идентификации сетевого приложения. Добавление служебной информации к основной обеспечивают разные протоколы — сначала Ethernet, поверх него IP, еще выше TCP, над ним порт, означающий приложение с делегированным ему протоколом. Такая вложенность называется стеком, названным TCP/IP по двум главным протоколам модели.
Point-to-Point протоколы
Отдельно расскажем о Point-to-Point (от точки к точке, двухточечный) протоколе также известном как PPP. PPP уникален по своим функциям, он применяется для коммуникации между двумя маршрутизаторами без участия хоста или какой-либо сетевой структуры в промежутке. При необходимости, PPP обеспечивает аутентификацию, шифрование, а также сжатие данных. Он широко используется при построении физических сетей, например, кабельных телефонных, сотовых телефонных, сетей по кабелю последовательной передачи и транк-линий (когда один маршрутизатор подключают к другому для увеличения размера сети).
У PPP есть два подвида — PPPoE (PPP по Ethernet) и PPPoA (PPP через асинхронный способ передачи данных — ATM), интернет-провайдеры часто их используют для DSL соединений.
PPP и его старший аналог SLIP (протокол последовательной межсетевой связи) формально относятся к межсетевому уровню TCP/IP, но в силу особого принципа работы, иногда выделяются в отдельную категорию. Преимущество PPP в том, что для установки соединения не требуется сетевая инфраструктура, а необходимость маршрутизаторов отпадает. Эти факторы обуславливают специфику использования PPP протоколов.
Заключение
Стек TCP/IP регламентирует взаимодействие разных уровней. Ключевым понятием в здесь являются протоколы, формирующие стек, встраиваясь друг в друга с целью передать данные. Рассмотренная модель по сравнению с OSI имеет более простую архитектуру.
Сама модель остается неизменной, в то время как стандарты протоколов могут обновляться, что еще дальше упрощает работу с TCP/IP. Благодаря всем преимуществам стек TCP/IP получил широкое распространение и использовался сначала в качестве основы для создания глобальной сети, а после для описания работы интернета.
Оглавление
характеристики
По крайней мере, один сервер XMPP (аналогичный агенту пересылки почты ) необходим для работы в сети XMPP . Он может существовать как единственный интерфейс связи в интрасети или может устанавливать соединения с другими серверами XMPP (федерация XMPP) через Интернет.
Большим преимуществом XMPP является то, что есть клиенты XMPP почти для каждой операционной системы и для каждого языка программирования. Однако решения различаются степенью поддержки протокола.
Функции
Одноранговые сеансы
Эта статья или следующий раздел не обеспечены должным образом подтверждающими документами ( например, индивидуальными доказательствами ). Информация без достаточных доказательств может быть вскоре удалена. Пожалуйста, помогите Википедии, исследуя информацию и добавляя убедительные доказательства.
С помощью расширения jingle XMPP может организовывать одноранговые сеансы. Эта функция в основном используется для IP-телефонии (VoIP) и очень похожа на протокол инициации сеанса (SIP).
В настоящее время мы работаем над профилями для обмена данными и виртуальных частных сетей .
Многопользовательский чат
XMPP поддерживает конференции с несколькими пользователями. Сегодня спецификация многопользовательского чата (MUC) является наиболее распространенной и сейчас все чаще заменяется терминами чат, комната, группа, даже в XMPP. Он поддерживает такие функции, как назначение ролей для пользователей в чате, защищенных паролем или невидимых комнатах, и обратно совместим с предыдущей спецификацией группового чата . Конференц-залы также представлены идентификаторами Jabber . С точки зрения обычного пользователя, многопользовательский чат можно сравнить с ретрансляционным чатом в Интернете (IRC-чат), и обычно он не заметит разницы.
Общение с другими чат-сетями
история
Джереми Миллер начал разработку протокола потоковой передачи XML в реальном времени в 1998 году , который он опубликовал в 1999 году под названием Jabber. В 2004 году IETF приняла протокол с некоторыми изменениями в качестве официального стандарта, получившего название Extensible Messaging and Presence Protocol . С тех пор Фонд стандартов XMPP (XSF) отвечает за стандартизацию протоколов, основанных на XMPP, так называемых протоколов расширения XMPP . Питер Сен-Андре - директор и автор большинства XEP .
распределение
Другими известными клиентами являются Trillian от Cerulean Studios , LJ Chat от LiveJournal , Ovi от Nokia (которая также предлагает клиент Jabber для своих мобильных устройств) и Miranda NG .
По всему миру насчитывается несколько тысяч серверов XMPP. Некоторые частные лица, а также ассоциации, такие как Chaos Computer Club , используют свои собственные серверы без коммерческих намерений. Пиратская партия также работает сервер, с тех пор было прекращено. Фонд стандартов XMPP предлагает список общедоступных серверов, на которых могут регистрироваться операторы. Кроме того, xmpp-server-scanner - это бот, который автоматически запрашивает сервер и генерирует список с информацией о доступности и поддерживаемых функциях.
В 2009 году купила Cisco Jabber Inc. Планируется интеграция в собственные программные решения.
Шифрование
Даже если соединения клиентов с их соответствующими серверами зашифрованы, связь между серверами является возможной точкой атаки. Поэтому многие серверы шифруют свои соединения с другими серверами ( межсерверное шифрование). Комбинация с шифрованием клиент-сервер имеет смысл, в противном случае соединение в самом слабом месте, т.е. ЧАС. где соединение не зашифровано - уязвимо. Если используются оба метода, безопасность значительно повышается, но серверы по-прежнему остаются точкой атаки, поскольку данные дешифруются на обоих серверах даже с помощью комбинации межсерверного и клиент-серверного шифрования. В марте 2014 года многие операторы крупных общедоступных серверов XMPP подписали манифест, в котором они обязались предлагать межсерверное шифрование и отключать небезопасные протоколы, такие как SSLv2.
Таким образом, сквозное шифрование обеспечивает еще более высокий уровень безопасности . Поскольку все данные зашифровываются исходным клиентом, а затем снова дешифруются соответствующим целевым клиентом, точки атаки сводятся к минимуму. Соединение обязательно всегда зашифровано, и серверы не могут расшифровать данные, которые они пересылают. Таким образом, оператор сервера и потенциальные злоумышленники могут делать выводы только о времени, продолжительности и приблизительном объеме разговора.
OMEMO - это расширение протокола XMPP, которое обеспечивает сквозное шифрование между пользователями. Кроме того, OMEMO выполняет требования Совершенной прямой секретности и достоверного отрицания . Все распространенные серверы XMPP используют это расширение протокола, а также многочисленные клиенты Jabber, такие как Б. Гаджим , Дино или Беседы .
Поскольку на межсерверное шифрование XMPP не может повлиять конечный пользователь, потому что оно происходит в юрисдикции администраторов сервера, максимально возможная безопасность для конечного пользователя обеспечивается одновременным использованием межсерверного шифрования. и сквозное шифрование.
Расширения, такие как Б. Аудио- и видеочат через Jingle по умолчанию не шифруются.
Смотри тоже
Нормы и стандарты
XMPP стандартизирован несколькими RFC . Есть основная строка и связанные с ней дополнения или обновления RFC:
- RFC 6120 - Extensible Messaging and Presence Protocol (XMPP): Core , с 2011 г.
- Обновление RFC 7590 - Использование безопасности транспортного уровня (TLS) в протоколе Extensible Messaging and Presence Protocol (XMPP) с 2015 г.
- Обновление RFC 8553 - изменения DNS AttrLeaf: исправление спецификаций, использующих имена узлов с нижнимуказателем , с 2019 г.
литература
веб ссылки
Индивидуальные доказательства
-
Эта страница последний раз была отредактирована 15 июля 2021 в 21:12.
В этом разделе рассматриваются сведения о реализации WCF для следующих протоколов, которые TextMessageEncodingBindingElement и MtomMessageEncodingBindingElement используются.
В этом разделе рассматриваются сведения о реализации WCF для следующих протоколов, которые MtomMessageEncodingBindingElement используют.
В этом разделе используются следующие пространства имен XML и соответствующие префиксы:
SOAP 1.1 и SOAP 1.2
Конверт и модель обработки
WCF реализует обработку конверта SOAP 1,1, следующую за базовым профилем 1,1 (BP11) и Basic Profile 1,0 (SSBP10). Обработка конверта SOAP 1.2 реализована в соответствии со спецификацией SOAP12-Part1.
В этом разделе объясняются некоторые варианты реализации, принимаемые WCF в отношении BP11 и SOAP12-Part1.
Обработка обязательных заголовков
WCF соответствует правилам обработки заголовков mustUnderstand , помеченных в спецификациях soap 1,1 и soap 1,2, со следующими вариантами.
Такая многоуровневая обработка обеспечивает разделение уровней инфраструктуры и уровней приложения узла SOAP:
B1112: WCF выдает mustUnderstand значения 0 и 1 для версий soap 1,1 и soap 1,2 конверта SOAP. WCF принимает все пространство значений xs:boolean для mustUnderstand заголовка (0, 1, false , true )
Ошибки SOAP
Ниже приведен список реализаций ошибок SOAP, зависящих от WCF.
B2121: WCF возвращает следующие коды ошибок SOAP 1,1: s11:mustUnderstand , s11:Client и s11:Server .
B2122: WCF возвращает следующие коды ошибок SOAP 1,2: s12:MustUnderstand , s12:Sender и s12:Receiver .
R2221: параметр действия application/soap+xml , если он присутствует в запросе SOAP 1.2, должен соответствовать атрибуту soapAction элемента wsoap12:operation в соответствующей привязке WSDL.
WS-Addressing
WCF реализует 3 версии WS-Addressing:
W3C Web Services Addressing 1.0 Core (ADDR10-CORE) и SOAP Binding (ADDR10-SOAP)
WS-Addressing 1.0 ― метаданные
Ссылки на конечные точки
Все версии WS-Addressing, которые WCF реализует, используют ссылки на конечные точки для описания конечных точек.
Ссылки на конечные точки и версии WS-Addressing
WCF реализует ряд протоколов инфраструктуры, использующих WS-Addressing и в частности EndpointReference элемент и W3C.WsAddressing.EndpointReferenceType класс (например, WS-RELIABLEMESSAGING, WS-SECURECONVERSATION и WS-Trust). WCF поддерживает использование любой из версий WS-Addressing с другими протоколами инфраструктуры. Конечные точки WCF поддерживают одну версию WS-Addressing на каждую конечную точку.
Например, если конечная точка WCF реализует WS-ReliableMessaging, AcksTo заголовок, возвращаемый такой конечной точкой в, CreateSequenceResponse использует версию WS-Addressing, которую EncodingBinding элемент определяет для этой конечной точки.
Ссылки на конечные точки и метаданные
В ряде сценариев требуется передача метаданных или ссылки на метаданные для определенной конечной точки.
B3121. WCF использует механизмы, описанные в разделе 6 спецификации WS-MetadataExchange (MEX), чтобы включить метаданные для ссылок на конечные точки по значению или по ссылке.
Параметры и свойства ссылок
WCF реализует обработку параметров ссылки на конечную точку и ссылочные свойства в соответствии с соответствующими спецификациями.
B3221: Если настроено использование WS-Addressing 2004/08, конечные точки WCF не различают ссылочные свойства и ссылочные параметры.
B3312: запрашивающая сторона может включить заголовки MessageID , ReplyTo и FaultTo . Инфраструктура принимающей стороны не учитывает их, и они передаются в приложение.
Запрос-ответ
R3321: инициатор запроса должен включать в запрос wsa:To , wsa:Action , wsa:MessageID и заголовки для всех ссылочных параметров или ссылочных свойств (или обоих), указанных ссылкой на конечную точку.
R3322: если используется WS-Addressing 2004/08, в запрос также должен быть включен параметр ReplyTo .
Ошибки Web Services Addressing
R3411: WCF создает следующие ошибки, определенные WS-Addressing 2004/08.
R3412: WCF создает следующие ошибки, определенные WS-Addressing 1,0.
Код в предыдущих таблицах соответствует параметру FaultCode в SOAP 1.1 и параметру SubCode (с Code=Sender) в SOAP 1.2.
Привязка WSDL 1.1 и утверждения WS-Policy
Указание использования WS-Addressing
WCF использует утверждения политики, чтобы указать поддержку конечных точек для определенной версии WS-Addressing.
Это утверждение политики дополняет спецификацию WS-Addressing 2004/08.
Элемент wsaw10:UsingAddressing заимствован из [WS-Addressing-WSDL] и используется в контексте WS-Policy в соответствии с этой спецификацией, раздел 3.1.2.
Полный код утверждения политики может выглядеть следующим образом.
Полный код утверждения политики может выглядеть следующим образом.
Определение действия
Спецификация WS-Addressing 2004/08 определяет атрибут wsa:Action для элементов wsdl:portType/wsdl:operation/[wsdl:input | wsdl:output | wsdl:fault] . Привязка WS-Addressing 1.0 WSDL (WS-ADDR10-WSDL) определяет аналогичный атрибут, wsaw10:Action .
Единственное отличие между этими двумя атрибутами заключается в семантике шаблона действия по умолчанию, описанной в разделе 3.3.2 спецификации WS-ADDR и в разделе 4.4.4 спецификации WS-ADDR10-WSDL соответственно.
Разумно, чтобы две конечные точки имели одинаковый portType (или контракт, в терминологии WCF), но использовали разные версии WS-Addressing. Однако с учетом того, что действие определяется параметром portType и не должно изменяться между конечными точками, реализующими portType , одновременная поддержка обоих шаблонов действия по умолчанию становится невозможной.
Чтобы устранить эту споров, WCF поддерживает одну версию Action атрибута.
Использование ссылки на конечную точку внутри порта WSDL
Раздел 4.1 спецификации WS-ADDR10-WSDL расширяет элемент wsdl:port , включая в него дочерний элемент для описания конечной точки в терминах WS-Addressing. WCF расширяет эту служебную программу на WS-Addressing 2004/08, что позволяет отображаться как дочерний элемент wsdl:port .
R3531: если к конечной точке прикреплена альтернативная политика с утверждением политики ``wsdl:port .
R3532: Если объект wsdl:port содержит дочерний элемент , wsa10:EndpointReference/wsa10:Address значение дочернего элемента должно соответствовать значению @address атрибута родственного wsdl:port / wsdl:location элемента.
R3533: если к конечной точке прикреплена альтернативная политика с утверждением политики ``wsdl:port .
R3534: Если объект wsdl:port содержит дочерний элемент , wsa:EndpointReference/wsa:Address значение дочернего элемента должно соответствовать значению @address атрибута родственного wsdl:port / wsdl:location элемента.
Сочетаемость с WS-Security
Примеры
Кодировка XML и механизм упаковки, описываемый [XOP], который оптимизирует информационные элементы XML, содержащие двоичные данные в кодировке base64, в отдельные двоичные части.
Инкапсуляция MIME пакета XOP, которая сериализует набор сведений XML и каждую двоичную часть пакета XOP в отдельную часть MIME.
Кодирование MIME XOP, примененное к конверту SOAP 1.x.
В спецификации [XOP], раздел 3.1, описывается процесс кодирования XML с информационными единицами элемента, содержащими base64-значения, в абстрактно определенный пакет XOP.
Приведенная ниже последовательность этапов описывает специфичный для MTOM процесс кодирования.
Создайте пустой пакет MIME.
Определите в исходном наборе сведений XML информационные единицы элементов, подлежащие оптимизации. Для оптимизированных элементов символы, составляющие [children] элемент сведений об элементе, должны быть в канонической форме xs:base64Binary (см. xsd-2, 3.2.16 base64Binary) и не должны содержать пробелов, предшествующих, встроенных в или следующих за содержимым, не являющимся пробелом.
Создайте конверт XOP SOAP, являющийся копией исходного конверта SOAP, но в котором дочерние элементы всех информационных единиц элементов, определенных на предыдущем шаге, заменены информационной единицей элементов xop:Include , построенной следующим образом:
Преобразуйте замененные символы в двоичные данные, обработав их как данные в кодировке base64.
Создайте уникальное значение заголовка Content-ID, удовлетворяющее требованиям R3133 и R3134.
Создайте заголовок Content-Transfer-Encoding MIME со значением binary.
Если оптимизируемая информационная единица элемента ([parent] вновь вставленной информационной единицы xop:Include ) имеет информационную единицу атрибута xmime:contentType , создайте заголовок Content-Type MIME со значением атрибута xmime:contentType .
Создайте новую двоичную часть MIME с содержимым, образованным двоичными данными, декодированными из замененных символов, обработанных как base64, заголовка Content-ID из шага 4b, заголовка Content-Transfer-Encoding из шага 4c, заголовка Content-Type, если он создан в шаге 4d.
Добавьте атрибут href в элемент xop:Include со значением cid: uri, полученным из значения заголовка Content-ID, созданного на шаге 4b. Удалите вложенные символы " ", URL-адрес, чтобы отключать оставшуюся строку и добавить префикс cid: . В соответствии с RFC1738 и RFC2396 в escape-последовательности должен преобразовываться указанный ниже минимальный набор символов. Возможно преобразование в escape-символы и других символов.
Создайте корневую часть MIME с конвертом XOP SOAP из шага 4.
Запишите пакет MIME.
Убедитесь, что корневая часть MIME имеет Content-Type application/xop+xml .
Постройте конверт SOAP, проанализировав корневую часть MIME пакета как документ XML. Кодировка символов определяется параметром charset заголовка Content-Type корневой части MIME.
Для каждой информационной единицы элементов в построенном конверте SOAP, которая имеет, как единственный член своего свойства [children], информационную единицу элемента xop:Include :
Удалите префикс cid: и выполните обратное преобразование из escape-представления всех escape-последовательностей универсального кода ресурса (URI) (RFC 2396) в значении атрибута @href элемента xop:Include . Заключите результирующую строку в " ".
Найдите часть MIME в значении заголовка Content-ID, соответствующую строке, полученной на шаге 3a.
Замените информационную единицу элемента xop:Include , имеющуюся в свойстве children каждой единицы, информационными единицами символов, представляющими каноническую кодировку base64 (см. XSD-2, 3.2.16 base64Binary) тела сущности части MIME, указанной в шаге 3b (эффективно это означает, что надо заменить информационную единицу элемента xop:Include данными, восстановленными из части пакета).
Хотя требование использовать двойные кавычки в RFC 2387 не является явным, текст следит, чтобы все составные или связанные параметры типа мультимедиа, скорее всего, содержали зарезервированные символы, такие как " @ " или "/", и поэтому требуют двойных кавычек.
Часть Infoset MIME
Конверт SOAP 1.x инкапсулируется как корневая часть пакета XOP MIME и часто называется частью infoset .
R4142: часть SOAP Infoset должна содержать следующие заголовки MIME: Content-ID , Content-Transfer-Encoding и Content-Type .
Формат заголовка Content-ID определяется в RFC 2045 как
где msg-id определяется в RFC 2822 (которая заменяет RFC 822, указанную в RFC 2045) следующим образом:
и фактически является адресом электронной почты, заключенным в " ". Префикс и суффикс [CFWS] были добавлены в RFC 2822 для внесения комментариев и не должны использоваться, чтобы не нарушать совместимость.
R4143: значение заголовка Content-ID для части Infoset MIME должно задаваться в соответствии с правилами для msg-id из RFC 2822 без частей с префиксом и суффиксом [CFWS] .
Ряд реализаций MIME неограниченные требования для значения, заключенного в " ", в качестве адреса электронной почты и используемого absoluteURI в " " в дополнение к адресу электронной почты. В этой версии WCF используются значения заголовка MIME Content-ID в формате:
R4144: процессоры MTOM должны воспринимать значения заголовка Content-ID, соответствующие следующему ослабленному требованию к msg-id .
R4145: часть SOAP Infoset должна содержать заголовок Content-Transfer-Encoding.
R4147: если для конверта SOAP принята кодировка символов UTF-16, значение заголовка Content-Transfer-Encoding должно быть binary.
В соответствии с [XOP], раздел 5,
R4148: компонент информационного набора SOAP 1.1 должен содержать заголовок Content-Type с типом носителя Application/XOP + XML и параметрами Type = "Text/XML" и charset
R4149: часть набора сведений SOAP 1,2 должна содержать заголовок Content-Type с типом носителя application/xop+xml и параметрами Type и charset .
Хотя в XOP параметр charset для application/xop+xml определяется как необязательный, он необходим для совместимости, аналогично требованию BP 1.1 к параметру charset для типа носителя text/xml .
R41410: в заголовке Content-Type части SOAP 1.x Infoset должны присутствовать параметры type и charset .
Поддержка MTOM конечной точкой WCF
R4151: любая информационная единица элемента, содержащая данные в кодировке base64, может быть оптимизирована.
B4152: WCF оптимизирует элементы сведений об элементе, содержащие данные в кодировке Base64, и длину более 1024 байт.
Утверждение WS-Policy для MTOM
WCF использует следующее утверждение политики для указания использования MTOM по конечной точке:
B4212. Если настроено использование оптимизации MTOM, конечная точка WCF добавляет утверждение политики MTOM к политике, прикрепленной к соответствующему объекту wsdl:binding .
Сочетаемость с WS-Security
Примеры
Читайте также: