Тестировщик vs SOA. Часть 1

В первой части статьи речь пойдет о web-сервисах. Будут рассмотрены принципы организации SOA архитектуры, структура web-сервисов, WSDL компонент, стандарт SOAP и хранилище UDDI. Во второй рассмотрим общие принципы тестирования web-сервисов, автоматизацию тестирования, используемые инструменты и конкретные примеры.(выйдет в свет позже) Эту тему я представлял в качестве мастер-класс доклада на конференции SQA Days 7 от компании Intetics Co. На самом деле, нет строгого определения SOA, нет комитета, вырабатывающего стандарты сервис-ориентированной архитектуры (хотя это совершенно не относится к технологиям, на которых она может быть реализована), да и быть его, в принципе, не может, поскольку SOA - это никак не технология, а философия, концепция, парадигма, новый подход (называйте, как хотите) к построению корпоративных информационных систем, интеграция бизнеса и информационных технологий. Компонентом данной информационной системы является web-сервис. Что же это такое? Сервисом называется независимый программный компонент, выполняющий определенную задачу, такую как, например, «проверить баланс счёта», не требующей для использования клиентами какой-то определенной программной технологии. SOA характеризует следующие основные принципы, следование которым позволяет сказать, является ли информационная система сервис-ориентированной:

• Сервисы как компоненты информационной системы публикуют свои интерфейсы (контракты). Эти контракты являются независимыми от платформы, языка программирования, операционной системы и других технических особенностей реализации. Сервисы взаимодействуют между собой и вспомогательными службами посредством открытых, широко используемых стандартов.
• Каждый составляющий информационную систему сервис реализует отдельную бизнес-функцию, которая является логически обособленной, повторяющейся задачей, являющейся составной частью бизнес-процесса предприятия.
• Низкая связанность (loose coupling). Сервисы в системах, построенных на SOA, могут быть реализованы вне зависимости от других служб системы, необходимо только знание интерфейса используемых сервисов.

Как видно, каждый из пунктов не является специфической особенностью SОА, многие технологии взяли на вооружение эти принципы. Отличительной особенностью, построенной на SOA системы, является одновременное следование всем указанным принципам. Использование открытых стандартов Использование открытых стандартов является важной характерной особенностью SOA. Это значительно уменьшает время подключения нового бизнес-сервиса к существующей системе, что является часто крайне важным моментом для предприятий, имеющих богатые наработки за предыдущее время. При внедрении SОА нет необходимости переписывать или просто отказываться от проверенных годами и действующих решений. Выбор распределенной технологии Выбор распределенной технологии играет существенную роль. Использование, например, SNA (системная сетевая архитектура, разработанное компанией IBM общее описание структуры, форматов, протоколов, используемых для передачи информации между программами IBM и оборудованием) в качестве средства общения сервисов накладывает такое ограничение, при котором все компоненты в системе обязаны использовать SNA, что ограничивает применимость системы. Когда же говорят о том, что информационная система следует принципам SОА, то сервис, реализованный, например, на языке Java, должен быть применим для использования клиентами, реализованными с использованием других технологий. Сервис выполняет повторяющуюся бизнес-функцию Сервисы в SOA реализуют повторяющиеся бизнес-функции, которые необходимы для организации согласованной работы сложных, состоящих из большого числа различных компонентов приложений. К примеру, возьмем систему, занимающуюся продажей дерева и его доставкой. При заказе товара на определённую сумму, предоставляется 10% скидка, в случае, если дальность перевозки более 1000 км, также предоставляется скидка 5% за каждые последующие 1000 км. Если же при разработке придерживаться принципов сервис-ориентированной архитектуры, то следует реализовать сервис «расчет скидок», к которому обращались бы все сервисы, которым необходимо рассчитать скидку. Таким образом, функциональность используется многочисленными приложениями и существует возможность быстро и относительно просто изменить бизнес-логику, приспосабливая ее к постоянно меняющимся условиям рынка. Причем изменения необходимо вносить только в один-единственный сервис, и сделанные изменения одновременно используются всеми клиентскими приложениями. Организация сервисов как слабосвязанных компонентов для построения систем. Низкая связанность - важный архитектурный принцип при разработке SОА систем. Использование этого принципа позволяет связывать различные компоненты информационной системы во время ее функционирования с помощью так называемого позднего связывания (late binding). Благодаря этой особенности, также значительно облегчается внесение изменений в функциональность сервисов, поскольку это совершенно не затрагивает другие. Благодаря низкой связанности, значительно упрощается пошаговое создание корпоративной системы из-за отсутствия барьеров реализации функциональности сервиса за несколько итераций. Иначе говоря, эта особенность подразумевает тот факт, что мы можем просто подключать новую функциональность к уже существующей системе, не меняя предыдущие звенья. Возможность динамически подключать новые сервисы, так же как и поиск этих сервисов клиентами, является также одним из краеугольных принципов системы, построенной на основе SOA. Рассмотрим непосредственно компоненты SOA систем – веб сервисы: структуру web-сервисов, WSDL компонент, стандарт SOAP и хранилище UDDI. Web service Web-сервис — программная система, чьи общедоступные интерфейсы определены на языке XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней cогласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью интернет-протоколов. Web-service является компонентом сервисно-ориентированной архитектуры приложения. Для описания web-сервиса служит XML-ориентированный язык WSDL (Web Services Description Language), он также определяет расположение сервиса и операции (или методы), предоставляемые им. WSDL Cтруктура WSDL - это всего лишь простой XMLник. Он содержит набор выражений, определяющих web-сервис. Описание (description) web-сервиса является корневым элементов любого документа WSDL. Он используется в качестве контейнера, в котором содержится вся необходимая информация о данном сервисе и его атрибутах, которую можно разделить на 2 части. Абстрактная часть В абстрактной части указываются типы данных, которыми оперирует сервис, входные и выходные параметры для методов, которые использует сервис. Эти элементы составляют программный интерфейс, с которым вы обычно взаимодействуете. Эти детали обычно реализовываются базовой инфраструктурой, а не кодом вашего приложения. Элемент types определяет типы данных, которые используются при обмене сообщениями. Элемент interface содержит поименованный набор абстрактных операций и сообщений. Конкретная часть Конкретная часть содержит в себе информацию о расположении сервиса и способ передачи его параметров. Они описывают конкретные детали того, как абстрактный интерфейс преобразовывается в сообщения при передаче по проводам. Элемент binding определяет базовый транспорт и формат передачи для сообщений. Элемент service описывает набор элементов endpoint, которые указывают на одиночный сетевой адрес для элемента binding. Одним из принципов архитектуры SОА является платформенная независимость, открытые стандарты. Тут весьма важно, чтобы коммуникация между сервисами посредством Интернет не составляла проблемы. Коммуникация с использованием, например, Remote Procedure Calls (RPC) между объектами DCOM и CORBA, создаёт такие проблемы, как совместимость и безопасность - фаерволы и прокси-сервера обычно блокируют такие обращения. Лучший вариант коммуникации приложений - это использование протокола HTTP, так как он поддерживается всеми интернет-браузерами и серверами. SOAP был создан для выполнения этих целей. SOAP обеспечивает связь между сервисами, запущенными на разных ОС с использованием разных технологий, реализации и написанных на разных языках, благодаря XMLной основе. SOAP SOAP — это стандарт для отсылки и получения сообщений по Интернет. Изначально этот протокол был предложен фирмой Microsoft в качестве средства для удаленного вызова процедур по протоколу HTTP. В большинстве случаев фаерволами предусмотрена работа по этому протоколу. Обычно коммуникация происходит с участием 80ого порта, а он по дефолту открыт. В SOAP спецификации также предусмотрены такие дополнительные процедуры, как авторизация и шифрование. Помимо этого широко используемого формата, также существуют и другие технологии, например REST. Эта технология, в принципе, включает те же возможности, что и SOAP, за исключением дополнительных возможностей, которые представляются тем же протоколом http, как авторизация и шифрование посредством https. Фирма IBM и ряд других компаний, в том числе Lotus, внесли определенный вклад в развитие этого протокола, и его спецификация была направлена на рассмотрение комитетом W3C. SOAP сообщение - это обычный XML-документ содержащий следующие элементы: Envelope определяет XML документ как SOAP сообщение; Header содержит специфическую информацию о приложении, например, требуется ли аутентификация; Body содержит информацию запроса и ответа; Также существует поле Fault, содержащее информацию об ошибках. UDDI IBM, Microsoft и компания Ariba создали проект Universal Description, Discovery and Integration (UDDI), который является общим каталогом всех web-сервисов. На рисунке показан процесс организации поиска web-сервиса в репозитории UDDI. Когда сервис создан, он помещается в UDDI, управляемый сервис-брокером. Система UDDI позволяет компаниям представить свой web-сервис общественности. Регистрация в каталоге UDDI осуществляется бесплатно и содержит описания всех сервисов по всей сети. У брокера есть специальный интерфейс для поиска сервисов по заданным пользователем критериям. Запросив сервис, заказчик получает wsdl файл с полным описанием сервиса (методы параметры адрес). Собственно и всё, этого вполне достаточно, чтобы можно было воспользоваться сервисом в полной мере.

Помогаете devby = помогаете ИТ-комьюнити.

Засапортить сейчас.