Web-сервис
| Веб-сервисы сегодня на слуху у западных сообществ разработчиков, аналитиков и менеджеров. Однако, в России технологии веб-сервисов пока новы и нуждаются в представлении. В этой серии статей мы попробуем познакомить Вас с этой концепцией. Каждая статья серии будет выходить примерно раз в месяц, поэтому просим следить за публикациями нашего сайта. Немного истории Чтобы понять, почему в головы IT-специалистам пришла концепция веб-сервисов, чем эта концепция отлична от иных попыток создания технологий разработки распределенных информационных систем (ИС) и, самое важное, чем она так хороша, как это следует из уст ведущих экспертов крупных компаний-вендоров и аналитиков IT-сектора, уместно вернуться на несколько лет назад и посмотреть как развивались технологии построения распределенных ИС, что было создано и с какими проблемами пришлось столкнуться. Как это обычно бывает, почти во всем “виноваты” деньги. Когда компьютерные сети вышли за рамки сугубо научных и военных учреждений (вспомним ARPAnet), они стали достоянием энтузиастов-частных лиц. Когда же частных лиц, пользующихся компьютерными сетями, стало достаточно много, сообразили, что компьютерные сети могут быть использованы для производства денег. Так компьютерные сети общего пользования, основная и самая распространенная из которых сегодня называется Интернет, стали бизнес-инструментом. Чтобы с помощью этого инструмента вести бизнес, он должен удовлетворять некоторому набору требований, главные из которых – безопасность и скорость передачи информации. Задачу выполнения этих требований стали решать на самом низком уровне – на уровне транспортных протоколов. Различные компании предложили различные реализации сетевых протоколов. Сетевые протоколы, как известно, задают правила формирования сетевых пакетов и обмена ими. Использующие эти правила (повторимся - различные для различных протоколов) сетевые приложения тем самым жестко привязываются к определенным протоколам. Между тем быстроразвивающиеся бизнес-отношения требовали, чтобы сетевые приложения, использующие различные протоколы, могли обмениваться между собой данными – таким образом, встала задача интеграции приложений. Вот здесь-то и начались мытарства. На протяжении нескольких лет было создано несколько технологий взаимодействия распределенных приложений, так или иначе позволявших реализовать обмен данными между приложениями (среди получивших наибольшее развитие - Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) и Common Object Request Broker Architecture (CORBA)), однако каждая из них была довольно сложна в реализации, не обладала необходимой универсальностью (т. е. все же зависела от выбора, например, одной и той же операционной системы для всех участников обмена) и, что особенно плохо, эти технологии с большим трудом стыковались между собой. Т. е. произошло лишь укрупнение групп невзаимодействующих между собой приложений, что, разумеется, не могло устраивать ни бизнес, ни IT-специалистов. Тогда был избран иной, противоположный, подход: обратились к базисным веб-технологиям, попробовали найти то немногое, что является основой Интернета. А эта основа состоит из следующих технологий: · TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA; · HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей; · XML – универсальный язык для работы с любыми типами данных. Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС. В этом и заключается основное принципиальное отличие веб-сервисов от предшественников. Уже сейчас ясно, что наиболее широкое применение веб-сервисы найдут в сфере интеграции корпоративных приложений (Enterprise Application Integration (EAI)). С помощью веб-сервисов можно несколько, порой сильно разнящихся между собой, бизнес-процессов выстроить в один-единственный цельный бизнес-процесс, достигнув при этом существенно более высоких показателей эффективности бизнеса – начиная от прямого увеличения выручки за счет улучшения продаж и обслуживания клиентов и кончая “банальным” сокращением накладных расходов при обмене данными. Так ли все хорошо? И все же веб-сервисы нельзя рассматривать как лекарство от всех бизнес-проблем, имеющихся сейчас или могущих возникнуть в будущем. Хотя веб-сервисы и являются логичным и уже вполне зрелым продолжением предшествовавших им технологий построения распределенных ИС, они – такая же технология, как и многие другие, имеющая свои плюсы и минусы и, как следствие, рамки применимости. Непонимание и неучет этих ограничений в реальных проектах может привести к весьма печальным последствиям. Подробнее остановимся на плюсах и минусах. К плюсам веб-сервисов можно отнести следующее: · Веб-сервисы позволяют компании интеграцию собственных бизнес-процессов с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости нежели с использованием иных интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для SMB (Small and Medium Business), что откроет для таких компаний новые перспективы развития; · Поскольку веб-сервисы организуются в публичные реестры (UDDI-реестры, ebXML-реестры или иные), доступные заинтересованным лицам по всему миру, порог выхода компаний на новые рынки снижается, возможности же для наращивания клиентской базы напротив возрастают; · Веб-сервисы обеспечивают преемственность в отношении уже имеющихся в компании ИС, т. е. можно сказать, что веб-сервисы надстраиваются над существующими ИС, но не вместо них. Таким образом, обеспечивается сохранность уже сделанных инвестиций в IT-инфраструктуру и не идет увеличения требуемых, поскольку нет необходимости в радикальных изменениях; · Построение новых корпоративных решений с применением веб-сервисов реализуется быстрее и совокупно дешевле, поскольку основное внимание сосредотачивается на создании бизнес-логики решения, программирование самих веб-сервисов лишь по необходимости “обрамляет” этот процесс, не требуя больших трудозатрат за счет эффективного применения повторно используемого кода и адаптированных средств разработки (IDE и SDK). Не менее подробно остановимся и на минусах веб-сервисов: · Стандарты интеграции бизнес-процессов, вопросы управления транзакциями и выработка единых бизнес- и IT-политик взаимодействующих посредством веб-сервисов компаний находятся пока на стадии разработки (мы отметим следующие начинания: Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS (аббревиатура “BPEL” произносится кратко как “бипль”)) корпорации IBM, XLANG корпорации Microsoft и спецификации WS-Coordination и WS-Transaction – результат сотрудничества IBM, Microsoft и BEA). Очевидно, без их четкой формализации и опубликования построение ИС на основе веб-сервисов может идти лишь с переменным успехом; · Динамическое использование информации бизнес-реестров веб-сервисов, вызов веб-сервисов “на лету”, требует решения вопросов доверительности отношений между различными бизнес-реестрами. Кроме того, есть трудности в совместном использовании бизнес-реестров различных форматов (например, задача поиска определенного веб-сервиса в UDDI-реестре и ebXML-реестре требует различных подходов в силу различия XML-документов, описывающих один и тот же веб-сервис в каждом из этих реестров. Хотя, надо отметить, что есть попытки решить эту проблему созданием единого браузера реестров. В качестве примера - графическая утилита Registry Browser корпорации Sun Microsystems, реализующая набор интерфейсов JAXR (Java API for XML Registries)); · Добавление к функциям сервера приложений функциональности провайдера веб-сервисов (в т. ч. SOAP-сервера) в силу новизны технологий может представлять определенную трудность; · Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация WS-Security – продукт деятельности корпораций IBM и Microsoft – в настоящее время достаточно молода, не “устоялась” и частично все еще дорабатывается. Однако, в силу общности положений спецификации WS-Security, уже готовится к выпуску следующий слой спецификаций, посвященных вопросам безопасности: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation. Анализируя вышеизложенное, на наш взгляд, можно заметить, что плюсы являют собой бизнес-преимущества стратегического плана, минусы же носят технологический характер и происходят больше от новизны технологий веб-сервисов и, мы уверены, решение этих проблем является лишь вопросом времени (причем не столь отдаленного, учитывая темпы развития IT-мысли). Web-сервисы как таковые Web-сервисы - это автономные модульные приложения, которые можно публиковать и вызывать по сети (например, Интернет). Каждый Web-сервис описывается предоставляемыми им интерфейсами. Web-сервисы проектируются с тем, чтобы свободно объединять клиентские приложения с серверами. Реализация сервера не требует, чтобы клиент работал на специфической платформе или был написан с использованием определенного языка программирования. Кроме определения интерфейсов, независимых от языка, в Web-сервисах реализована поддержка множественных механизмов соединения. Теперь поговорим о стандартах, лежащих в основе Web-сервисов. Прежде всего необходимо сказать о средствах публикации Web-сервисов в сети. Публикация означает, что Web-сервис должен быть "зарегистрирован" в некотором списке, чтобы клиентское приложение могло его найти. В настоящее время публикация осуществляется согласно стандарту UDDI (Universal Description, Discovery and Integration), созданному при сотрудничестве компаний Ariba, IBM и Microsoft. Основная идея стандарта состоит в объединении всех поставщиков товаров и услуг, доступных через Web, в едином реестре UDDI. Для создания такого реестра требовался формат описания сервисов, и он был предложен все теми же Ariba, IBM и Microsoft в виде языка описания Web-сервисов - Web Services Description Language (WSDL), построенного на основе XML. WSDL предназначен для описания сетевых сервисов как коллекций конечных точек сетевого взаимодействия, отвечающих за обмен сообщениями. WSDL позволяет описывать возможности Web-сервиса, перечислять доступные для каждого сервиса операции и описывать формат данных для каждого действия. Использование XML в качестве основы в какой-то степени упрощает создание таких WSDL-описаний, однако делать это вручную зачастую оказывается сложно. Реализация Web-сервисов Для работы с Web-сервисами используется протокол SOAP (Simple Object Access Protocol), служащий для обмена информацией в децентрализованных, распределенных средах. Для создания удаленных процедур в рамках этого протокола служит язык XML, а в качестве коммуникационного протокола применяется HTTP. Основанная на применении SOAP технология формирует базу для разработки кросс-платформенных распределенных приложений. При использовании Web-сервисов нет необходимости устанавливать специальное клиентское ПО, как это было при работе с распределенными приложениями на базе технологии CORBA. Использование HTTP-сообщений позволяет ориентироваться на самые различные типы программно-аппаратного обеспечения. Определение веб-сервиса Дадим формальное определение веб-сервиса. Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи публичные интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов. Внимательно прочитав это крайне общее, но, тем не менее, очень точное по сути определение (именно в его общности и заключается, как ни парадоксально, его точность), можно увидеть, что единственное упоминание конкретной технологии сделано в отношении XML. Не говорится ни о применяемом сетевом протоколе, ни о языке программирования, ни о программной платформе. И хотя, как правило, для передачи сообщений в ИС на основе веб-сервисов в качестве транспортного протокола используется стандартный HTTP, его использование совершенно не обязательно, и можно использовать (посредством так называемых протокольных привязок (protocol bindings)), например, SMTP-протокол. На применение языков программирования также не накладывается никаких ограничений – уже разработаны веб-сервисы на Java, C++, C#, COBOL и других языках. С программными платформами, операционными системами и серверами приложений, дело обстоит еще проще (лучше) – возможны любые сочетания (например, можно найти и вызвать веб-сервис, развернутый на IBM WebSphere Application Server под управлением Linux, с рабочей станции Macintosh). Единственное условие – использование XML-сообщений (точнее SOAP-сообщений), поскольку реальной альтернативы XML как языку, позволяющему работать с различными типами данных, на сегодняшний день нет. | ||||||||||||||||||||||||||||||||||||||||||||||
Стек технологий веб-сервисов
Итак, концепция сервисно-ориентированной архитектуры подразумевает реализацию бизнес-процессов предприятия в виде совокупности сервисов, взаимодействующих друг с другом либо с пользователями в определенной последовательности и в соответствии с определенными правилами. Отметим, что, вообще говоря, это весьма нетривиальная задача - определить эту "определенную последовательность" и "определенные правила" таким стандартным для индустрии (разработки бизнес-приложений) образом, чтобы покрыть весь спектр существующих сценариев взаимодействия бизнес-объектов, учитывая исторически сложившееся многообразие технической и технологической реализации этого взаимодействия и самих бизнес-объектов. Решить эту задачу в рамках какой-либо единой технологии пока не удалось. И хотя тенденция консолидации существующего множества технологий веб-сервисов в настоящее время налицо, для реализации сервисно-ориентированных архитектур с помощью веб-сервисов сейчас применяется совокупность технологий, образующих так называемый стек технологий веб-сервисов (см. Рис. 1).
Рис. 1: Стек технологий веб-сервисов
Стек технологий веб-сервисов принципиально разбивается на следующие две составляющие:
· технологии, обеспечивающие функциональность веб-сервисов (Functions);
· технологии, обеспечивающие качество сервиса веб-сервисов (Quality of service).
Эти составляющие в свою очередь образуются несколькими слоями (layers):
· технологии, обеспечивающие функциональность веб-сервисов:
o транспортный слой (transport layer);
o коммуникационный слой (service communication layer);
o слой описаний сервисов (service description layer);
o сервисный слой (service layer);
o слой бизнес-процессов (business process layer);
o слой реестров сервисов (service registry layer).
· технологии, обеспечивающие качество сервиса веб-сервисов:
o слой политик (policy layer);
o слой безопасности (security layer);
o слой транзакций (transaction layer);
o слой управления (management layer).
В целях понимания назначения слоев, дадим краткое описание каждого из них.
Представленный выше стек технологий веб-сервисов вводит иерархию во множество технологий веб-сервисов в соответствии с их функциональным назначением. При этом в таблице указаны лишь наиболее широко применяемые и устоявшиеся технологии. Стандартными названы технологии, получившие официальный статус стандартов международных консорциумов по разработке IT-стандартов (W3C, OASIS либо WS-I). В действительности, спектр технологий, описывающих те или иные аспекты использования веб-сервисов либо сервисно-ориентированных архитектур, крайне широк (см. раздел Стандарты нашего сайта), в частности, потому, что процесс разработки данных технологий является открытым - любая компания, некоммерческое объединение специалистов или даже один специалист может разработать и опубликовать спецификацию разработанной им технологии. В настоящее время это даже стало серьезной проблемой рынка веб-сервисов - количество спецификаций стало столь велико, что при фактической нерегламентированности глобального (в рамках всей индустрии) процесса их разработки, ввода в действие и использования, появляется опасность ввергнуть индустрию в хаос и технологическую разобщенность. А технологическая разобщенность - как раз то, от чего хотели уйти прежде всего, разрабатывая веб-сервисы и закладывая в качестве их концептуальной и технологической основы открытые и наиболее широко применяемые IT-технологии. |
| Лекция Web-сервис. Протокол SOAP Web-сервисы и Snap-технологии В версии Kylix 2 компания Borland реализовала новое семейство технологий, названное Snap. На данный момент предлагаются три технологии из этого семейства, соответствующие трем уровням структуры приложений. Самый нижний, базовый уровень представлен технологией DataSnap, которая по сути выступает логическим продолжением механизмов работы с XML, реализованных в предыдущих версиях Delphi и Kylix, в частности, механизма MyBase. Используя DataSnap API, разработчики смогут реализовать доступ к любым широко распространенным базам данных на основе SQL, поставляя информацию в XML-синтаксисе под управлением протокола SOAP. Доступ к базам данных предоставляется большому кругу клиентских программ, включая так называемые "тонкие клиенты" и Web-сервисы, причем разработка такого доступа оказывается намного дешевле, чем раньше. Следующий уровень модели Snap, технологияWebSnap, позволит значительно ускорить процесс разработки сложных Web-сайтов, предлагающих наряду с элементарным доступом к информации и более серьезные возможности. WebSnap позволяет объединить в едином процессе дизайнерскую работу и создание самой логики приложения. Кроме того, использование компонентов WebSnap позволяет отлаживать серверные приложения с помощью механизма WebSnap Debugging Web Server, который обеспечивает высокоуровневый мониторинг всех процессов взаимодействия, происходящих на сайте. В инструментарий WebSnap также входят серверные компоненты для реализации Web-страниц, предусматривающие написание сценариев на JavaScript. Верхний уровень модели Snap - это технология BizSnap, которая полностью внедряет Web-сервисы в объектно-ориентированную среду разработки. Опережая появление стандартной XML-схемы, средства BizSnap модернизируют определение модульных XML-преобразований, которые позволяют приложению работать с XML-данными, имеющими одно и то же содержание, но различную структуру. BizSnap позволяет создавать Web-сервисы на основе промышленных стандартов и пускать их в обращение, используя WSDL. Предусмотрено также создание - путем импорта WSDL-документов - программ-клиентов для работы с существующими Web-сервисами, созданными с использованием Microsoft .NET, Sun ONE или других технологий. Инструментарий для создания Web-сервисов Как и любой новой экосистеме, архитектуре Web-сервисов для выживания необходимы развитые поддерживающие структуры. Руководство корпорации Microsoft (Редмонд, шт. Вашингтон) надеется, что созданная специально для этой цели платформа .Net окажется, несмотря на отсутствие практики ее применения, более приспособленной к выживанию, чем конкурирующая архитектура Sun ONE (Open Network Environment — открытая сетевая среда) фирмы Sun Microsystems, основанная на успевшей уже завоевать прочное положение платформе Java. Ключевыми компонентами этих ИТ-экосистем являются инструментальные средства, упрощающие разработчикам задачу создания кода для .Net или Sun ONE. Тестовый центр eWeek Labs провел испытания предварительных версий сред разработки корпорации Microsoft и фирмы Sun — Visual Studio .Net Enterprise Architect Beta 2 и Forte for Java 3.0 Enterprise Edition beta (Early Access release) соответственно — чтобы определить, насколько хороша каждая из них в деле создания Web-сервисов для корпоративного применения. Visual Studio .Net поступит в продажу к концу года; никакой официальной информации о ценах пока нет. Forte for Java 3.0 Enterprise Edition поставляется с сентября в редакциях для Windows NT 4.0, Solaris 8 и Red Hat Linux 6.2 по цене $1995. Прежде чем делать стратегический выбор в пользу того или иного инструментария, каждой конкретной службе ИТ необходимо тщательно исследовать вопрос, какая платформа ей больше подходит. Пользуясь удачной возможностью начать с нуля, Microsoft разработала для .Net новую модель, предназначенную специально для построения Web-сервисов и написания ПО для Интернета. В результате нас ожидает самая дорогостоящая и самая сложная модернизация Windows-среды за последнее десятилетие. Она потребует значительного переобучения персонала, а также внесения изменений — от небольших до довольно крупных — в существующий код, в частности в программы на языке Visual Basic и в Web-страницы, использующие скрипты ASP (Active Server Pages — активные серверные страницы) на базе языка VBScript. Среда Visual Studio .Net незаменима для будущих разработчиков .Net-приложений не только потому, что отличается интегрированностью, но и просто потому, что у нее пока нет конкурентов. Платформа Java, появившаяся более шести лет назад, требовала не менее серьезных перемен, но теперь это зрелый, проверенный практикой и заслуживший широкое признание язык программирования для написания серверных приложений. И как следствие, Java-разработчики располагают значительно более широким выбором инструментов. Дополнительную привлекательность Forte for Java придают средства для создания EJB-компонентов (Enterprise JavaBeans), Web-сервисов на базе XML (Extensible Markup Language — расширяемый язык разметки) и развертывания кода в среде сервера приложений iPlanet Application Server фирмы Sun-Netscape Alliance (мы использовали при тестировании версию iPlanet Application Server 6.0). Вместе с тем этому продукту приходится соревноваться с такими серьезными конкурентами, как JBuilder корпорации Borland Software. К тому же у Forte for Java есть крупный недостаток — отсутствие встроенной поддержки протокола SOAP (Simple Object Access Protocol — простой протокол доступа к объектам). Впрочем, и Forte for Java, и Visual Studio .Net не свободны от существенных пробелов в наборах функциональных возможностей — более по причинам “политического” выбора производителей, нежели из-за технологических сложностей. Первая поддерживает только один язык программирования (естественно, Java), а вторая использует единый редактор для написания программ на языках Cи++, C#, Visual Basic и ECMAScript (но не Java). Правда, представители Sun уверяют, что в последующих версиях Forte for Java будет реализована поддержка разработки на нескольких языках. Что такое SOAP Протокол, основанный на спецификации XML и включающий: o "оболочку", которая определяет инфраструктуру для описания содержания сообщения и способов его обработки; o набор правил кодирования информации о специальных типах данных, используемых в приложениях; o соглашение о способе представления вызовов удаленных процедур и ответов от них. SOAP Версия 1.2: |
| HTTP-привязка SOAP HTTP имеет хорошо известную модель взаимодействия и шаблон обмена сообщениями. Клиент идентифицирует сервер по URI, подсоединяется к нему с помощью TCP/IP сети, отсылает HTTP-сообщение-запрос и получает HTTP-сообщение-отклик по тому же TCP-соединению. HTTP полностью коррелирует сообщение-запрос и соответствующий ему сообщение-отклик, поэтому приложение, использующее эту привязку, может реализовать корреляцию между отправленным в теле HTTP-запроса SOAP-сообщением и SOAP-сообщением, возвращенным в качестве HTTP-отклика. Подобным образом, HTTP идентифицирует конечный сервер по URI, URI-запросу, который может также служить идентификатором SOAP-узла сервера. HTTP могут использовать многочисленные посредники между начальным клиентом и сервером, инициировавшим обмен сообщениями, идентифицируемые по URI-запросу, в этом случае модель запрос/отклик является по существу сериями таких пар. Необходимо отметить, что HTTP-посредник и SOAP-посредник не являются тождественными понятиями. HTTP-привязка [SOAP Часть 2] использует функцию SOAP Web-метода, позволяющую приложениям выбирать один из так называемых Web-методов - GET или POST - чтобы использовать для обмена сообщениями с помощью HTTP. Кроме того, она использует два шаблона обмена сообщениями, которые дают приложениям два способа обмена SOAP-сообщениями посредством HTTP: 1) использование HTTP-метода POST для передачи SOAP-сообщений в теле HTTP-запроса и HTTP-отклика, и 2) использование HTTP-метода GET в HTTP-запросе для возвращения SOAP-сообщения в теле HTTP-отклика. Первый шаблон использования является HTTP-реализацией функции привязки - шаблона обмена SOAP-сообщениями типа "запрос-отклик", второй - шаблона обмена SOAP-сообщениями типа "отклик". Цель разработки этих двух способов - реализовать две парадигмы взаимодействия, одинаково хорошо подходящие для World Wide Web. Первый тип взаимодействия позволяет использовать данные в теле HTTP-метода POST для создания или изменения состояния ресурса, идентифицируемого по URI, в соответствии с которым направлен HTTP-запрос. Второй тип шаблона взаимодействия дает возможность использовать HTTP-запрос GET для получения представления о ресурсе без какого-либо изменения его состояния. В первом случае касающийся SOAP аспект вопроса состоит в том, что тело HTTP-запроса POST является SOAP-сообщением, которое кроме того, что должно быть обработано (согласно модели обработки SOAP) в соответствии со специфичной для приложения обработкой, должно также соответствовать семантике POST. Во втором случае типичной реализацией является получение представления запрашиваемого ресурса в виде SOAP-сообщения, а не в виде HTML- или XML-документа. То есть HTTP-заголовок типа содержимого сообщения идентифицирует это как медиа-тип "application/soap+xml". Вероятно, найдутся создатели Web-ресурсов, которые впоследствии обнаружат, что такие ресурсы проще всего найти и сделать доступными в виде SOAP-сообщений. Надо отметить, однако, что ресурсы могут быть доступны в виде различных представлений; желаемое или предпочтительное представление может быть получено путем опроса приложения с помощью HTTP-заголовка Accept. Следующим аспектом HTTP-привязки SOAP является проблема определения, какой из вышеуказанных двух шаблонов обмена сообщениями использовать. [SOAP Часть 2] содержит руководство, описывающее в каких обстоятельствах приложения могут использовать тот или иной определенный шаблон обмена сообщениями. Шаблон обмена SOAP-сообщениями с использованием HTTP-метода GET, используется в том случае, если приложение использует этот шаблон только для поиска информации, а сам ресурс в результате взаимодействия остается "нетронутым". Подобные взаимодействия трактуются в спецификации HTTP как безопасные и идемпотентные. Поскольку использование SOAP HTTP-метода GET не разрешено для SOAP-сообщения, содержащегося в запросе, приложения, которым необходим доступ к функциям взаимодействия с внешними объектами, которые поддерживаются только специфичным для привязки выражением внутри информационного множества SOAP (то есть в качестве заголовочных SOAP-блоков), не могут использовать этот шаблон обмена сообщениями. Необходимо отметить, что HTTP-метод POST привязки может применяться во всех случаях. |
Дата добавления: 2015-09-14; просмотров: 1434;