Файл: Архитектура информационных.pdf

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 04.12.2023

Просмотров: 165

Скачиваний: 2

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

73


Roses are red,
Violets are blue.
-Alix

Документ 2:

Alix Krakowski


Roses are red,
Violets are blue.
-Alix

В обоих примерах приложение получает сообщение, что все пробелы в строках стихотворения следует сохранить, но пробелы в других частях документа обрабатываются по необходимости.
По умолчанию службы Microsoft XML Core Services (MSXML) не обрабатывают атрибут xml:space. Если приложение должно учитывать атрибут xml:space, то перед синтаксическим анализом для свойства preserveWhiteSpace объекта DOMDocument следует задать значение True. xmldoc= new ActiveXObject("Msxml2.DOMDocument.5.0"); xmldoc.preserveWhiteSpace = true; xmldoc.load(url);
В службах MSXML также предусмотрены параметры, которые позволяют

74 перепоручить обработку пробелов в приложении средству синтаксического анализа. Дополнительные сведения см. в разделе «White Space and the DOM»
(пробелы и модель DOM) документации по пакету MSXML SDK.
Приложения по обработке XML сохраняют все пробелы в содержимом элементов, но часто нормализуют пробелы в значениях атрибутов. Символы табуляции, символы возврата каретки и пробелы обрабатываются как единичные пробелы. В определенных типах атрибутов удаляются пробелы, находящиеся до или после тела значения. Повторяющиеся пробелы внутри значения заменяются на один пробел. (При наличии определения DTD эта обработка проводится для всех атрибутов, не принадлежащих к типу CDATA).
Например, XML- документ может содержать следующие данные:

Средство синтаксического анализа XML передаст оба значения атрибута в виде "this is a note." с преобразованием разрывов строк в одиночные пробелы.
Средства синтаксического анализа XML обрабатывают сочетание символов возврата каретки и перевода строки (CRLF) как одиночные символы возврата каретки или перевода строки. Все они передаются как единичные символы перевода строки (LF). При сохранении документов приложения могут использовать соответствующие соглашения об обработке конца строки.
7.5. Пространства имен XML-документа
Поскольку имена элементов в XML не фиксированы, часто случаются конфликты, когда два различных документа используют одно и то же имя для описания двух различных типов элементов, например:


Jane Doe
U2

Пространства имен XML дают возможность избежать конфликтов имен элементов. Они задаются при помощи уникальных идентификаторов URI.
Чтобы упростить работу, были разработаны специальные префиксы пространств имен, которые позволяют с легкостью определить, какой схеме принадлежит тот или иной элемент документа. Общий синтаксис:
http://contoso.msft/namespace_for_examples
">
Some Data
More Data
Например:

1   2   3   4   5   6

Jane Doe
Developer
The Joshua Tree
U2

Префиксы пространств имен задаются как атрибуты с именами, которые начинаются последовательностью xmlns. Созданный префикс пространств имен может использоваться только в собственном имени и во вложенных элементах, но не за пределами элемента в котором он был создан. Сами префиксы не относят элемент к той или иной схеме. Эту функцию выполняют уникальные идентификаторы, которые поставлены в соответствие этим префиксам. Таким образом, два элемента с разными префиксами которым заданы одинаковые идентификаторы будут считаться принадлежащими к одной схеме.
Существует еще один способ, который позволяет не проставлять

76 префиксы в элементах. Для этого достаточно задать пространство имен по умолчанию. В этом случае все вложенные элементы будут принадлежать пространству имен родительского элемента. При этом не теряется возможность использовать другие пространства имен для дочерних элементов. Для этого достаточно вручную прописать нужное пространство имен, используя атрибут xmlns.


Jane Doe
U2

В представленном примере прослеживается так называемое наследование. Если для элемента не указано пространство имен, то ему автоматически присваивается пространство имен ближайшего родительского элемента.
Обычно вышеприведенный способ не очень популярный и чаще всего используются префиксы пространств имен. Но в некоторых случаях их можно опустить и использовать способ с заданием пространства имен по умолчанию.
Появление имени тега без префикса в документе, использующем пространство имен, означает, что имя принадлежит пространству имен по умолчанию (default namespace).
В рамках схемы можно определять новые типы данных, например:


77


В данном случае определяется новый комплексный тип.
7.6. Протокол XML-RPC.
Непосредственным предшественником Web-сервисов являлся протокол
XML-RPC.
Это очень простой протокол, предназначенный для вызова удаленных процедур. В отличие от традиционного RPC для вызова удаленной процедуры используются XML-послания. Ответ приходит также в форме XML-послания.
Рассмотрим пример.
Пусть имеется удаленная процедура, осуществляющая поиск синонимов в словаре. Для обращения к процедуре используется строка вида public String getSynonym (String word). В качестве аргумента используется исходное слово (word). Процедура возвращает слово — синоним исходного.
Запрос в рассматриваемом случае выглядит следующим образом:


getSynonym

cai*«MeT


Корневым является элемент , в который вложен элемент
, в теле которого записывается имя вызываемой процедуры.
Параметры вызываемой процедуры помещаются в элемент
. В элемент


78 вложены нуль или несколько элементов <рагаш>, в которые помещаются параметры вызываемой процедуры.
В рассматриваемом примере требуется получить синоним слова
«самолет».
Ответ также поступает в форме XML-сообщения:


a3pomiaH

Если произошла ошибка при выполнении запроса, то в ответном пакете указывается код ошибки. XML-RPC позволяет использовать такие типы данных как целые строки, вещественные, структуры, массивы.
Механизм XML-RPC был создан в середине 1990-х гг., однако не получил широкого распространения. Причины этого достаточно понятны и состоят в следующем:

запросы, выполняемые в рамках XML-RPC, только отчасти являются самоописываемыми, поскольку пространства имен в нем не определены;

XML-RPC подобно классическому RPC не поддерживают работу с объектами;

при работе с XML-RPC обнаруживаются проблемы, вызванные использованием
XML.
На стороне клиента необходимо сформировать запрос. На стороне сервера необходимо его разобрать. То же самое требуется сделать с ответом. Все это усложняет код и требует существенных временных затрат;

79

сообщения, отправляемые в формате XML, за счет тегов имеют большую избыточность.
Несмотря на отмеченные недостатки, данная технология получила дальнейшее развитие [25].
7.7. Протокол SOAP.
SOAP — это основанный на XML протокол, определяющий механизм обмена сообщениями. Протокол SOAP появился в 1998 г. как W3C спецификация. В ранних версиях спецификации SOAP расшифровывался как
Simple Object Access Protocol. В последних версиях этот термин никак не расшифровывается. На данный момент написания была версия 1.2 от апреля
2007 г. (спецификация находится по адресу https://www.w3.org/TR/soap/).
Хотя SOAP имеет много общею с XML-RPC, но имеются и принципиальные отличия от него.
Во-первых, протокол SOAP не различает вызов процедуры и ответ на него, а просто определяет формат послания (message) в виде документа XML, который может содержать вызов процедуры, ответ на него, запрос на выполнение каких-то других действий или просто текст.
Во вторых, SOAP-послание представляет собой самоописываемый документ, включающий, в частности, описания пространств имен. Структуру
SOAP-послания определяет соответствующая XML Schema. Для пересылки
SOAP-посланий обычно используется метод HTTP POST, хотя можно использовать и другие протоколы, такие как FTP, SMTP.
SOAP-послание включает два элемента: заголовок (Header) и тело (Body), которые помещаются в контейнер (Envelope). SOAP-послание представляет собой правильный XML-документ. Заголовок является факультативным элементом, а тело — обязательным.
В качестве примера рассмотрим пример сервера, который находит синоним слова с посредством вызова метода getSynonym:



80
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAPENV=" http://schemas.xmlsoa.org/soap/envelope/
" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/
XMLSchema-instance" xmlns:SOAPENC=" http://schemas.xmlsoap.org/soap/encoding/">

a3ponnaH



В теле запроса в элемент word, который имеет тип XSD string, помещается исходное слово. В ответ на запрос клиенту поступает ответное послание, которое имеет вид:

http://www.w3.org/2001/XMLSchema xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance
>

SOAP-ENV:encodingStyle= http://schemas.xmlsoap.org/soap/encoding/
>
"xsd:string">самолет



81

Рассмотрим пример создания простейшей службы, которая может находить синоним.
Имеется много разных систем поддержки работы с Web-сервисами.
Одной из популярных является Apache extensible Interaction System (AXIS).
Создание серверной части не вызывает проблем. Для работы с AXIS достаточно написать текст сервиса.
Для этого создаем файл
SynonymService.java:
// SynonymService.java public class SynonymService { public String getSynonym(String word) {
//Находим в словаре требуемый синоним
//Возвращаем синоним return "" + synonym;
}
}
Данный файл необходимо переименовать в SynonymService.jws и не компилируя поместить в каталог webapps (при работе с AXIS). После этого сервис готов к использованию.
Клиентская часть приложения. При работе с AXIS вначале создается объект класса service, который предназначен для установления связи с Web- сервисом. Он предоставляет экземпляр класса call, в который заносятся параметры запроса, в частности, адрес и имя Web-сервиса «getSynonym». После того как запрос сформирован, AXIS обращается к Web-сервису посредством вызова метода invoke(). Запрос направляется серверу приложений, работающему по указанному в запросе адресу. На сервере запускается сервлет
AxisServiet, разбирающий SOAP-послание. Он находит требуемый jws-файл, компилирует и запускает с требуемыми параметрами. После выполнения требуемых действий сервлет формирует SOAP-послание, в которое помещается

82 результат. Послание отправляется клиенту. Там оно разбирается. Для клиента результат доступен как результат выполнения метода invoke() [15].
7.8. WSDL-описание
WSDL используется для описания интерфейсов Web-сервисов.
Средствами WSDL можно описать, где находится Web-сервис и каким образом к нему следует обращаться. WSDL-описание позволяет создавать независимое от платформы и языка реализации описание Web-сервиса. Нетрудно заметить, что WSDL имеет много общего с IDL, используемым в RPC. WSDL-описание представляет собой XML-документ, структура которого показана на рисунке.
В качестве корневого элемент WSDL-описания используется элемент
«definitions;», в который вкладываются семь элементов, пять из которых являются основными, а два — вспомогательными.
В качестве основных выступают элементы ; ;
; ; . В качестве вспомогательных выступают элементы , .
Таблица 2.
Структура XML-документа


Что делается


Как делается

Где находится



Каждый элемент имеет собственное имя, определяемое обязательным атрибутом name. Имена используются для ссылки на отдельные элементы.
Элемент присутствует, если требуется определить сложные типы с помощью языка XSD. В противном случае данный элемент отсутствует.


83
Элемент описывает каждое из SOAP посланий в терминах
«запрос-ответ». В этот элемент вкладываются элементы
. При использовании процедурного стиля в каждый такой элемент описывается имя и тип одного аргумента запроса или возвращаемого значения. При использовании документного стиля элементы могут описывать отдельную часть послания MIME-типа «multipart/related».
Элемент <рог<Тyре> описывает интерфейс Web-сервиса, который также называют пунктом назначения (endpoint) или портом (port) сервисов, называемых операциями. Отдельная операция описывается как вложенный элемент , который описывает отдельный сервис. Имеются четыре вида сервисов: два простых действия (получение послания и отправка ответа) и два комбинированных действия (отправка послания — получение ответа и получение послания — отправка ответа). Действия типа получение и отправка посланий описываются вложенными элементами и , а также сообщением об ошибке (элемент ). Элемент содержит множество вложенных элементов
. Один и тот же порт может быть связан с несколькими сервисами.
Элемент описывает формат пересылки послания: протоколы и его тип. Каждый элемент может быть связан с несколькими такими элементами <
binding >, по одному для каждого способа пересылки.
Элемент определяет местонахождение сервиса как один или несколько портов, каждый из которых описывается вложенным элементом
, содержащим адрес интерфейса Web-сервисы.
Элемент включает файл с XSD схемой описания WSDL или другой WSDL-файл.
Элемент представляет собой комментарий, который можно включить в любой элемент описания WSDL.
Принято говорить, что элементы , и определяют, какие именно услуги предоставляет данный сервис.

84
Элементы определяет, как реализована Web-служба, т. е. как к ней обращаться.
Элементы определяет, где располагается сервис.
В качестве примера рассмотрим фрагмент WSDL-описания.
name="SynonymService" targetNamespace="http://www.vocab.ru/Thesaurus.wsdl" xmlns=
http://www.w3.org/ns/wsdl




"SOAP-ENC:string"/>