АРИС Текст 2. Водяхо А. И., Выговский Л. С., Дубенецкий В. А., Цехановский В. В. Архитектурные решения информационных систем
 Скачать 4.65 Mb.
|
|
11.3. REST REST (Representational State Transfer) иногда этот термин переводят как — «передача состояния представления», но чаще всего используют термин REST без расшифровки. Обычно REST определяют как архитектурный стиль, ориентированный на использование в распределенных системах. Термин REST был предложен еще в 2000 году Роем Филдингом [30], одним из авторов HTTP-протокола. Системы, поддерживающие REST, называются RESTful-системами. Основная идея REST архитектуры состоит в том, что мир (Интернет) состоит из множества ресурсов, каждому из которых ставится в соответствие URL, используя который можно обращаться к ресурсу для того, чтобы узнать или изменить его состояние. Для работы с ресурсами пользователю предоставляется набор методов, таких как GET, POST, PUT и DELETE. Данные должны передаваться в виде небольшого количества стандартных форматов (например, HTML, XML, JSON). Иногда REST противопоставляют RPC. Подход, основанный на RPC позволяет использовать выполнять произвольные процедуры на стороне сервера, а REST позволяет выполнять ограниченный набор действий, поэтому можно говорить, что REST, с точки зрения пользователя, более простой протокол. Для передачи данных REST обычно использует HTTP протокол, а RPC работает напрямую через сокеты, т.е. скорость работы RPC будет выше. Несомненным достоинством REST является использование URI в качестве системы именований. REST архитектура предполагает наличие клиента и сервера. Клиент инициирует запросы к серверу; который обрабатывает запрос и возвращает ответы. Запрос и ответ формируются в терминах представлений ресурсов. Ресурс может любым адресуемым объектом, а его представлением может быть документ, отражающий текущее или требуемое состояние ресурса. В конкретный момент времени клиент может находиться либо в состоянии покоя, либо в состоянии перехода между состояниями. В состоянии покоя клиент может взаимодействовать с пользователем. Когда клиент хочет перейти в новое состояние, то он посылает запрос серверу. Пока один или более запросов не выполнены, клиент находится в состоянии перехода. REST является относительно простым интерфейсом управления информацией, каждая единица которой каждая единица которой однозначно определяется глобальным идентификатором, таким как URL. Каждая единица информации однозначно определяется URL, который можно рассматривать как первичный ключ для соответствующей единицы данных. Например, если формируется сборник статей, то, например пятая статья в сборнике определяется как /book/5, а вторая страница этой статьи — /book/5/page/2. При этом не уточняется, в каком формате представлена статья. Это может быть pdf, docx или rtf. Чаще всего в рамках REST используется протокол http, для которого действия над данными задается с помощью методов: GET (получить), PUT (добавить, заменить), POST (добавить, изменить, удалить), DELETE (удалить). Таким образом, действия CRUD (Create-Read-Updtae-Delete) могут выполняться как со всеми 4-мя методами, так и только с помощью GET и POST. Например: GET /book/ — означает получить список всех статей, GET /book/12/ — получить статью номер 12, PUT /book/ — добавить статью (данные в теле запроса), POST /book/12 – изменить статью (данные в теле запроса), DELETE /book/12 – удалить статью. Архитектура REST используется достаточно часто при построении таких приложений как интернет-магазины, поисковые системы и прочие системы, основанные на данных. В частности эта архитектура является ключевой при построении микросервисных систем [151]. 11.4. Web cepвисы В самом общем виде понятие Web-сервиса можно определить как сервис (услугу) которая предоставляется через WWW с использованием языка XML и протокола HTTP. Практически все ведущие ИТ-компании положительно относятся к использованию Web-сервисов, поэтому Web-сервисы можно использовать в качестве механизма интеграции приложений, реализованных на любых платформах. Существует много разных определений понятия Web-сервиса. В качестве «официального» определения можно рассматривать определение, которое дается консорциумом W3C: «Web-сервис представляет собой приложение, которое идентифицируется строкой URI. Интерфейсы и привязки данного приложения описываются и обнаруживаются с использованием XML средств. Приложения взаимодействуют посредством обмена сообщениями, которые пересылаются с использованием Интернет протоколов». Иногда вместо термина Web-сервисы используется термин Web-услуги, в данной книге эти термины рассматриваются как синонимы. Web-сервис – это парадигма реализации сервисов через Web. Иногда говорят о Web-сервис как об атрибуте Web третьего поколения. При этом к первому поколению относят статический Web, использующие преимущественно статический HTML, а ко второму – интерактивный Web, использующий такие технологии как PERL, ASP, JSP и т.п. как компоненты, используемые для построения распределенных приложений, которые работают принципу черного ящика. Web-сервис в полной мере и практически без всяких ограничений поддерживают кроссплатформенность, независимость от языка программирования и хорошо работают через файерволы. Для обмена данными Web-сервис используют такие протоколы как XML, HTTP,TCP/IP, т.е. протоколы, которые поддерживаются практически все производители. Web-сервис оказали очень существенное влияние на подходы к построению распределенных систем, поскольку обладают такими ценными свойствами как самоописываемость, их легко создавать размещать, регистрировать и находить в репозитариях. Для того чтобы работать с сервисами, достаточно знать их интерфейсы. Унаследованные приложения могут быть относительно легко оформлены в виде Web-сервисов. Появление данной технологии дало существенный толчок в развитии таких технологий как e-Commerce, B2B, Enterprise Application Integration (EAI). Сервисно-ориентированная парадигма программирования имеет много общего с компонентно-ориентированной парадигмой. Некоторые авторы, например [140], рассматривают Web-сервис как одну из разновидностей компонентов. Это касается возможности повторного использования сервисов и наличие некоторой «склеивающей» среды, которая используется в качестве инструмента для создания приложений на базе Web-сервис. Уже в первые годы текущего века появились тысячи общедоступных сервисов. Большое число производителей, включая всех основных производителей ИТ-систем, предлагают инструментальные средства для разработки Web-сервисов. К наиболее давно и успешно используемым можно отнести следующие инструментальные средства для создания Web-сервис: Apache Tomcat next generation Web service – AXIS, Microsoft .NET Web service studio based on IIS server, IBM Web Sphere Web service, BEA Web Logic Workshop, Java Web Service Development Pack (JWSDP), Mind Electric GLUE и многие другие. Значительное количество из них – свободно распространяемые. Web-сервисы, в частности, можно создавать с помощью таких средств разработки как NetBeans и Eclipse. Web-сервисы представляют собой это самостоятельные модульные приложения, которые могут быть описаны, опубликованы, размещены и вызваны как локально, так и удаленно. Web-сервисы могут инкапсулировать как простейшие бизнес-функции типа «запрос-ответ», до полномасштабных взаимодействий бизнес-процессов. Службы могут создаваться заново или строиться на основе существующих приложений методом «обертывания». Все Web-сервисы обладают следующими свойствами: являются самодостаточными, т.е. с клиентской стороны не требуется никакого дополнительного программного обеспечения кроме языка программирования, поддерживающего работу с XML и HTTP, а на серверной стороне требуются только HTTP-сервер, поддерживающий работу с посланиями. являются самоописываемыми, поскольку метаданные, описывают сообщения передается вместе с сообщением и не требуется никаких внешних хранилищ метаданных; могут быть опубликованы, обнаружены и вызваны через Интернет причем для этого используют простые установившиеся стандарты, такие как HTTP и существующая сетевая инфраструктура; являются модульными, т. е. простые Web-сервисы могут объединяться в более сложные, причем это может быть сделано разными способами, либо при помощи механизма рабочих процессов, либо посредством прямого вызова Web-сервисов из других реализации Web-сервисов; инвариантны к способу реализации, т.е. клиент и сервер могут быть реализованы в разных средах с использованием разных языков программирования, причем для клиента не имеет значения на какой именно платформе реализован сервер и наоборот; открыты и основаны на стандартах, технической основой Web-сервисов являются XML и HTTP, значительная часть технологии Web-сервисов создана с использованием проектов с открытым исходным кодом; имеют свободные связи, по сравнению с другими, в частности, компонентными технологиями для Web-сервисов требуется более простой уровень координации, который позволяет осуществлять достаточно гибкую реконфигурацию для обеспечения интеграции нужных сервисов; являются динамическими, поскольку имеется возможность обнаруживать службы в процессе функционирования, при этом имеется возможность из распространения не влияя на работу клиентов, которые их используют; являются действенным средством интеграции унаследованных приложений. СОА и Web-сервисы. Разница между СОА и Web-сервисами состоит в том, что СОА представляет собой общую архитектуру интеграции приложений, а Web-сервисы - один из методов реализации СОА. Между Web-сервисами и СОА существует много логических связей, которые предполагают, что они могут дополнять друг друга. Web-сервисы представляют собой модель на основе открытых стандартов, которая может быть обработана автоматически и позволяет создавать формальные, не зависящие от реализации описания интерфейсов сервисов. Web-сервисы предоставляют механизмы коммуникации, которые обеспечивают прозрачность местоположения и возможность взаимодействия. Можно сказать, что Web-сервисы являются одной из реализаций сервисно-ориентированного подхода. Архитектура Web-сервисов. Наиболее важными компонентами архитектуры Web-сервисы являются: пользователь сервиса (клиент) и провайдер сервиса (север). Провайдер должен опубликовать (зарегистрировать сервис в репозитарии, который может быть реализован, в частности, как UDDI реестр (Universal Description, Discovery, and Integration (UDDI) registry). UDDI реестр внешне выглядит как Web-сервис и в нем хранится информация о зарегистрированных сервисах. Клиент может обращаться к UDDI реестру с запросами о месте нахождения отдельных сервисах и способах обращения к ним. Следует отметить, что для обращения к Web-сервисам клиент не обязательно должен предварительно обращаться к тому или иному репозитарию. Если клиенту известны место нахождения сервиса и его интерфейс, то он может обращаться к сервису напрямую. Множество протоколов, используемых для работы с Web-сервисами составляют стек (рис. 11.1).
Рис. 11.1. Стек протоколов, используемых для работы с Web-сервисами На нижнем уровне находятся транспортные протоколы, которые отвечают за доставку сообщений (HTTP, JMS, FTP, SMTP). Протоколы, определяющие форматы сообщений (SOAP, XML-RPC), располагаются на следующем уровне. На третьем уровне располагается протокол WSDL (Web Services Description Language, язык описания Web-служб). На четвертом уровне располагаются протоколы, определяющие механизмы обнаружения Web-сервисов такие как UDDI и ebXML. Кроме перечисленных, имеется большое число вспомогательных протоколов, которые часто называют WS*. Эти протоколы будут рассмотрены ниже. Язык XML при работе с Web-сервисами. Язык XML (eXtensible Markup Language) является основным при работе с Web-сервисами. Ниже дается краткое введение в XML. Более подробную информацию об этом языке можно найти, например в [152] и многих других книгах, посвященных XML. XML можно рассматривать как надмножество HTML. В XML пользователь может вводить и использовать собственные теги. Любой XML документ регламентируется метаданными, которые находятся в специальном файле. Метаданные – это данные, которые описывают данные, например, можно указать, что в году ровно 12 месяцев, в месяце может быть от 28 до 31 дня, в почтовом индексе должно быть ровно 6 цифр и. т. д. Для представления метаданных используется либо Document Type Definition (DTD), либо XSD файла. DTD является устаревшим. В 2001 году консорциум W3C (WWW Consortium) рекомендовал описывать структуру документов XML на языке описания схем XSD. Основным достоинством XML файлов является то, что имеется возможность их машинной обработки. Практически все современные языки программирования имеют средства для работы с XML. XML используется в качестве универсального формата обмена данными, в качестве средства для хранения данных (XML базы данных), а также в разного рода конфигурационных файлов и файлах размещения (deployment descriptors). Рассмотрим в качестве примера простейший XML документ, содержащий записи о студентах и их рейтинге (среднем балле): Документ XML начинается с пролога, в котором указывается версия языка XML, способ кодировки (по умолчанию - UTF-8) и ряд других элементов. Все элементы XML документа находятся внутри корневого элемента (root element), в данном случае — это элемент < students>. Имя корневого элемента должно совпадать с именем документа. Внутри корневого элемента имеются два вложенных элемента типа Для приведенного выше примера XSD Schema выглядит следующим образом: targetNamespace=http://www.myuniver.ru” xmlns=”http://www.myuniver.ru”> minOccurs=”1” maxOccurs=”unbounded”/> Использование пространств имен (namespace) является средством предотвращения коллизии имен. Для этого имена тегов и атрибутов снабжают префиксом, который отделяется от имени двоеточием. Префикс имени связывается с идентификатором, определяющим пространство имен. Все имена тегов и атрибутов, префиксы которых связаны с одним и тем же идентификатором, образуют одно пространство имен. Идентификатор пространства имен имеет форму URI, причем адрес такой, например, как http://www.myuniver.ru/2011/mns, может не соответствовать никакому реальному адресу, а представляет собой просто уникальный идентификатор. Каждый пользователь может создавать любое количество собственных пространств имен и пользоваться общедоступными пространствами имен. В рассматриваемом примере в качестве разделяемого пространства имен выступает xsd:schema, которой соответствует пространство имен xmlns:xsd=http://www.w3.org/2001/XMLSchema. В данном пространстве имен определены теги, относящиеся к XSD Schema. Появление имени тега без префикса в документе, использующем пространство имен, означает, что имя принадлежит пространству имен по умолчанию (default namespace). В рамках схемы можно определять новые типы данных, например: В данном случае определяется новый комплексный тип. Тег Протокол XML-RPC. Непосредственным предшественником Web-сервисов являлся протокол XML-RPC. Это очень простой протокол, предназначенный для вызова удаленных процедур. В отличие от традиционного RPC для вызова удаленной процедуры используются XML послания. Ответ приходит также в форме XML послания. Рассмотрим простейший пример. Пусть имеется удаленная процедура, осуществляющая поиск синонимов в словаре. Для обращения к процедуре используется строка вида public String getSynonym (String word). В качестве аргумента используется исходное слово (word). Процедура возвращает слово, являющееся синонимом исходного слова. Запрос в рассматриваемом случае выглядит следующим образом: Корневым является элемент Если произошла ошибка при выполнении запроса, то в ответном пакете указывается код ошибки. При работе с XML-RPC данные могут быть целые, строки, вещественные, структуры, массивы. Механизм XML-RPC был создан в середине 90-х годов прошлого века, однако не получил широкого распространения. Причины этого достаточно понятны и состоят в следующем: 1. Запросы, выполняемые в рамках XML-RPC только отчасти являются самоописываемыми, поскольку пространства имен в нем не определены. 2. XML-RPC подобно классическому RPC не поддерживают работу с объектами. 3. При работе с XML-RPC появляются проблемы, вызванные использованием XML. На стороне клиента необходимо сформировать запрос. На стороне сервера необходимо его разобрать. То же самое требуется сделать с ответом. Все это усложняет код и требует существенных временных затрат. 4. Сообщения, отправляемые в формате XML, за счет тегов имеют большую избыточность. Несмотря на отмеченные недостатки, данная технология получила дальнейшее развитие [23]. Протокол SOAP. SOAP – это основанный на XML протокол, определяющий механизм обмена сообщениями. Протокол SOAP появился в 1998 году как W3C спецификация. В ранних версиях спецификации SOAP расшифровывался как Simple Object Access Protocol. В последних версиях этот термин не никак расшифровывается. На момент написания данной книги последней была версия 1.2 от апреля 2007 года (спецификация находится по адресу http://www.w3.org/TR/2007/). Хотя SOAP имеет много общего с XML-RPC, но имеются и принципиальные отличия. Во-первых, протокол SOAP не различает вызов процедуры и ответ на него, а просто определяет формат послания (message) в виде документа XML, который может содержать вызов процедуры, ответ на него, запрос на выполнение каких-то других действий или просто текст, а, во вторых, SOAP послание представляет собой самоописываемый документ, включающий, в частности, описания пространств имен. Структуру SOAP послания определяет соответствующая ему XML Schema. Для пересылки SOAP посланий обычно используется HTTP POST метод, хотя можно использовать и другие протоколы, такие как FTP, SMTP. SOAP послание включает два элемента: заголовок (Header) и тело (Body), которые помещаются в контейнер (Envelope). SOAP послание представляет собой правильный XML документ. Заголовок является факультативным элементом, а тело – обязательным. В качестве примера рассмотрим сервер, который находит синоним слова посредством вызова метода getSynonym: 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/"> < getSynonym> < В теле запроса в элемент word, который имеет тип XSD string, помещается исходное слово. В ответ на запрос клиенту поступает ответное послание, которое имеет вид: xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="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">самолет Рассмотрим пример создания простейшей службы, которая может находить синоним. Имеется много разных систем поддержки работы с 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 послание в которое помещается результат. Послание отправляется клиенту. Там оно разбирается. Для клиента результат доступен как результат выполнения метода invoke () [152]. WSDL описание. WSDL используется для описания интерфейсов Web-сервисов. Средствами WSDL можно описать, где находится Web-сервис и каким образом к нему следует обращаться. WSDL описание позволяет создавать независимое от платформы и языка реализации описание Web-сервиса. Нетрудно заметить, что WSDL имеет много общего с IDL, используемым в RPC. WSDL описание представляет собой XML документ, структура которого показана на рис. 11.2.
Рис. 11.2. Структура XML В качестве корневого элементы WSDL описания используется элемент В качестве основных выступают следующие элементы: - - - - В качестве вспомогательных выступают элементы: - - Каждый элемента имеет собственное имя, определяемое обязательным атрибутом name. Имена используются для ссылки на отдельные элементы. Элемент Элемент Элемент |