Распределенные системы на основе web технологий. Тема технологии веб-сервисов. Принципы построения распределенных веб-систем

16.03.2019

Флешка

Не так давно (век живи - век учись) я наткнулась на понятие "pairwise testing" (переведу в лоб как "попарное тестирование", но лучше буду использовать английский термин), заинтересовалась и решила разобраться, что это такое. Достаточно быстро поняв, как работает данная э… техника, у меня сразу возникли вопросы по поводу причин и смысла её использования, найти ответы на которые на днях у меня наконец дошли руки. Обо всём этом я и решила написать (длинно, но короче не вышло:().

Сразу скажу, что к своей радости, большую часть информации по данной теме я почерпнула из статей Майкла Болтона и Джеймса Баха в соавторстве с Патриком Шрёдером К радости - потому что с одной стороны, это небезызвестные и значительные для меня люди по теме исследовательского тестирования. С другой же стороны - в свойственной (как мне кажется) для этих авторов манере, статьи не безусловно восхваляют, но пытаются трезво оценить данную технику, что для скептичной меня и моих вопросов было именно тем, что нужно.

1. Что же это такое

Раз уж я взялась писать о pairwise testing, то, видимо, надо попытаться объяснять, в чём состоит суть данной техники. Не уверена, что у меня получится объяснить понятно и корректно, но я всё-таки попробую:)

Итак, pairwise testing - это техника формирования наборов тестовых данных. Сформулировать суть можно, например, вот так: формирование таких наборов данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. Выходит не слишком понятно (и не факт, что правильно), так что можно попробовать объяснять на примере:)

Допустим, какое-то значений (налог) для человека рассчитывается на основании его пола, возраста и наличия детей - получаем три входных параметра, для каждого из которых для тестов выбираем каким-то образом значения. Например: пол - мужской или женский; возраст - до 25, от 25 до 60, более 60; наличие детей - да или нет. Для проверки правильности расчётов можно, конечно, перебрать все комбинации значений всех параметров:

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	детей нет
3	мужчина	25-60	детей нет
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	детей нет
7	мужчина	до 25	дети есть
8	женщина	до 25	дети есть
9	мужчина	25-60	дети есть
10	женщина	25-60	дети есть
11	мужчина	старше 60	дети есть
12	женщина	старше 60	дети есть

А можно решить, что нам не нужны сочетания значений всех параметров со всеми, а мы хотим только убедиться, что мы проверим все уникальные пары значений параметров. Т.е., например, с точки зрения параметров пола и возраста мы хотим убедиться, что мы точно проверим мужчину до 25, мужчину между 25 и 60, мужчину после 60, а также женщину до 25, женщину между 25 и 60, ну и женщину после 60. И точно так же для всех остальных пар параметров. И таким образом, мы можем получить гораздо меньше наборов значений (в них есть все пары значений, правда некоторые дважды):

№	пол	возраст	дети
1	мужчина	до 25	детей нет
2	женщина	до 25	дети есть
3	мужчина	25-60	дети есть
4	женщина	25-60	детей нет
5	мужчина	старше 60	детей нет
6	женщина	старше 60	дети есть

Такой подход примерно и составляет суть техники pairwise testing - мы не проверяем все сочетания всех значений, но проверяем все пары значений.

2. Что в этом хорошего

Когда ведут речь о pairwise testing, чаще всего сравнивают его именно с перебором всех возможных комбинаций значений, и одно из главных достоинств pairwise testing в том, что с его использованием получается гораздо меньшее количество тестовых наборов данных, чем при полном переборе, который во многих случаях просто невозможен.

Наверное, по приведённому выше примеру может показаться, что разница между этой техникой и перебором всех значений не так и велика. Но это только при таком незначительном количестве параметров и их значений, а чем их больше - тем значительнее разница. Допустим, если есть 50 параметров, каждый из которых может принимать 2 значения, то для полного перебора потребуется количество комбинаций равное 2 в степени 50, т.е. 1 125 899 906 842 624:) А при использовании pairwise testing можно обойтись всего четырнадцатью комбинациями!

Кстати, составление нужных комбинаций данных - задачка часто не самая простая, но, к счастью, для её решения существует много инструментов , разного уровня качества и (бес)платности:)

3. Почему пары

Лично у меня при знакомстве с этой техникой сразу возник вопрос - а почему именно пары? Почему не тройки значений или не какое-либо "квартетное тестирование"? Есть ли у такого подхода, например, какое-либо математическое обоснование, либо это с потолка взято?

Мне удалось найти вот такое объяснение: когда-то, на основании кем-то выполненного анализа по каким-то реальным данным был сделан вывод о том, что причиной возникновения большинства ошибок являются либо отдельные значения, либо сочетания пар значений (источник ). Это соображение судя по всему и легло в основу развития pairwise testing.

В принципе, обоснование более ли менее разумное, ведь какие-то исследования были проведены. Однако из такого объяснения также понятно, что правило это не однозначно верное и что справедливо оно будет далеко не для всех случаев. К тому же стоит задуматься и о понятии "большинство ошибок" :)

4. Как же и когда это (не) применять

Разумеется, технику эту надо применять именно в тех случаях, в которых это целесообразно.

Вот если, например, у нас просто есть формочка с каким-то количеством разных полей, данные из которых просто сохраняются в базу данных, то применение этой техники практически не имеет смысла, ведь данные не взаимодействуют друг с другом (хотя и могут быть нюансы, как эти данные сохраняются в базу)! А pairwise testing - это та техника, применять которую стоит именно в случае взаимодействующих значений (для невзаимодействующих - чаще всего достаточно просто отдельной проверки каждого из параметров).

Под взаимодействующими параметрами я понимаю в первую очередь те, которые влияют на результат не просто своими собственными отдельными значениями, но именно комбинациями друг с другом. Кстати, вот хороший пример взаимодействия - определение вариантов тестовой среды, например, из нескольких операционных систем, браузеров и разрешений монитора.

Итак, если параметры задачи взаимодействуют, то, казалось бы, тут pairwise testing и станет тем чудесным решением, которое и силы сэкономит, и полное тестирование обеспечит. Но конечно, эта техника обеспечивает достаточно высокое покрытие, но далеко не полное - если вдруг ошибка возникает при сочетании трёх, четырёх или более параметров, то pairwise testing может и не помочь (это уж как повезёт). По-хорошему, применению pairwise testing должен предшествовать анализ тестируемого приложения на предмет того, насколько тестирование именно сочетаний пар параметров является для него целесообразным.

В любом случае, если не сравнивать pairwise testing с исчерпывающим тестированием (exhaustive testing), то понятно, что даже применение этой техники достаточно трудоёмко. И в иных случаях, возможно, лучше протестировать несколько наборов наиболее часто используемых реальными пользователями данных, чем затратить массу усилий и протестировать множество сгенерированных наборов, в которые действительно популярные комбинации могут и не попасть.

5. Так что же я хотела сказать

Конечно, я назвала только пару-тройку, но есть большое количество соображений, которые стоит принять во внимание, принимая решение о применении техники pairwise testing - стоит хотя бы обратиться к упомянутым выше статьям (их вообще стоит почитать при наличии интереса к данной теме). А pairwise testing - это просто инструмент, который, как и прочие инструменты, требует использования с умом.

Каждый тестировщик пишет тесты по определенному принципу. Даже тот, кто слыхом не слыхал ни о каких методиках, так или иначе руководствуется рядом принципов, которые, как правило, держит в голове, или в редких случаях на бумаге. Но скажите, какой бывалый тестировщик не представлял себе фантастическую ситуацию, когда эти принципы реализованы в коде: софт создает тест-кейсы. Конечно до такой радужной перспективы еще очень далеко, но первые шаги на этом поприще уже сделаны…

Описание метода

Представьте себе, что вам нужно протестировать систему с большим числом параметров, влияющих на её работу. Ярким примером такого рода может быть конфигурационное тестирование: например проверка работы системы под различными операционными системами или работа сайта в различных браузерах. Кто знает, какое сочетание параметров приведет к сбою? Каждый тестировщик знает, что все комбинации не проверить. К примеру, для проверки всех сочетаний 10 параметров с 10 значениями каждый, потребуется 10,000,000,000 тестов, в то время как метод перебора пар позволяет реализовать сравнимое по качеству тестирование (учитывая количество и критичность найденных в результате багов) используя всего 177 тестов.

Итак, в чем же трюк? Метод парного тестирования основан на довольно простой, но от того не менее эффективной идее, что подавляющее большинство багов выявляется тестом, проверяющим один параметр, либо сочетание двух. Ошибки, причиной которых явились комбинации трех и более параметров как правило значительно менее критичны, чем пары параметров и тем более одного, не говоря уже о том что никто не мешает дополнить свое тестовое покрытие кейсами на желаемые комбинации параметров.

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

Рассмотрим как происходит оптимизация. Возьмем для примера таблицу параметров и значений следующего вида:

Переберем значения первого параметра со вторым (строки №1-4), первого с третьим (строки №5-8) и второго с третьим (строки №9-12). Удалив повторяющиеся наборы параметров (выделены серым), получим следующую таблицу тестов:

Зеленым выделены уникальные пары всех параметров в таблице. Теперь начинается самое интересное, значения выделенные белым не являются необходимыми для перебора всех пар в таблице, поэтому могут быть заменены на любое другое значение. Поэтому заменив их, мы можем оптимизировать тесты, добавив проверку пар из 5, 6 и 7 строк во вторую и третью строки, получим:

Как видно из примера выше, оптимизация даже такого малого набора параметров не так проста как могло бы показаться. При этом сложность задачи возрастает пропорционально росту числа параметров. Однако эта задача решаема, в чем мы убедимся в последствии.

Применение

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

Поэтому метод следует использовать лишь на стабильном функционале, когда текущие тесты уже теряют свою эффективность.

Для того чтобы воспользоваться методом необходимо выполнить несколько простых шагов:

1. Определиться с функциональностью, которую будем проверять

Как говаривал Козьма Прутков "Нельзя объять необъятное", поэтому прежде всего необходимо разделить функциональность на части: компоненты, функции, сценарии. Функциональность небольшой программы, например по записи дисков, упрощенно можно представить в виде всего двух сценариев: запись диска, стирание диска. Выбираем запись диска и переходим к следующему шагу.

2. Исследовать выбранный сценарий и выявить его параметры и их значения

На данном этапе следуют спросить себя, какие параметры сценария могут повлиять на его выполнение? В качестве параметров могут выступать как настройки самой программы, так и внешние факторы.

Упрощенно, параметры и их значения при записи диска можно представить в виде:

Вы наверняка обратили внимание, что параметр «Скорость записи» имеет значения, недопустимые для “DVD”, как же быть?. У этой маленькой задачки, есть несколько вариантов решения, одно из которых – это разделить таблицу на две. Стоит учитывать, что на практике параметров в этом сценарии гораздо больше, и несостыковок, было бы значительно больше.

Итак, поделив таблицу по типу носителя получим:

При выборе параметров и значений помните, что негативные тесты не стоит включать в таблицу – в одном тесте может проверяться несколько пар, а в случае негативного теста будет выполнена проверка лишь одного параметра, в результате некоторые пары могут остаться непроверенными. По этой причине в нашем примере отсутствуют значения объёма данных, равные нулю и превышающие объем диска. Если мы их добавим, то в результате использования метода можем получить кейс в котором на нулевом объёме данных будет проверяться к примеру пара Файловой системы ISO и начала мультисесии. В результате, успешно убедившись в корректной обработке попытки записи пустого диска, мы упустим проверку пары ISO-начать мультисесию.

На этом этапе важно следовать поговорке: семь раз отмерь, один отрежь. Ведь если после создания тестов обнаружится что вы упустили какой-либо параметр или его значение, и вы захотите инкрементально дополнить тестовое покрытие – количество тестов увеличиться несопоставимо больше, доле упущенных параметров. Забегая вперед скажу, что для нашего примера с записью DVD методом перебора пар мы получим 17 тестов. Решив дополнить исходную таблицу всего одним значением, например скоростью записи DVD 32х, мы увеличим общее число тестов на 8, так как в стремление сохранить целостность метода будем вынуждены перебирать это значение со всеми значениями других параметров. Целесообразно дополнить тестовое покрытие одним-двумя тестами на проверку нового значения составленными вручную, либо заново создать таблицу, как это описано в следующем шаге.

3. Применить алгоритм, составляющий оптимальное число тестов с полным перебором пар.

Составлять тесты по методу парного тестирования без использования технических средств крайне сложно, поэтому чтобы упростить себе жизнь, следует воспользоваться программными решениями . Я использую «Allpairs» - свою задачу она выполняет отлично и к тому же бесплатна.

В результате, взяв таблицу с параметрами для DVD, получим перечень тестов:

«~» означает что вместо указанного значения может быть использовано любое, так как оно не составляет пары в данном тесте.

К слову, если бы мы перебирали все пары последовательно: все значения скорости записи со всеми файловыми системами, плюс все значения скорости записи со всеми значениями мультисессии, и так далее до полного перебора всех пар значений у нас получился бы 61 тест. Это наглядно демонстрирует возможности оптимизации

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

В приложении к статье вы найдете составлению мною инструкцию к программе.

Итого

В результате мы имеем достаточно специфичную методику с четко выраженной областью применения. Не слишком гибкую и слабо применимую при большом количестве зависимостей между параметрами, но в умелых руках весьма эффективную.

Остается только попробовать!

Инструкция по использованию Allpairs.

В качестве входных данных для программы используется.txt файл с таблицей параметров, столбцы которой разделены табуляцией. Для создания такого файла удобнее всего использовать MS Excel – там есть возможность сохранять “текстовые файлы с разделителями табуляции (*.txt)”.

Имея исходный файл, необходимо запустить консоль и набрать там строку вида:

C:\allpairs.exe C:\so.txt > C:\re.txt

C:\allpairs.exe - полный путь к приложению allpairs.exe
C:\so.txt – путь к исходному файлу с таблицей параметров
C:\re.txt - путь и имя файла, который будет создан в результате работы программы

Результирующий файл будет содержать в себе готовый перечень проверок вида:


SQL version	Use of Java	pairings





		appearances

Pairings – количество уникальных пар в тест-кейсе

Pairing details – перечень всех пар всех параметров

Appearances – количество раз, сколько та или иная пара фигурирует в кейcах

Cases – номера кейcов, где фигурирует данная пара

Хотя популярность buzzword «pairwise» уже не та, на собеседованиях до сих пор задают вопрос о том, что представляет собой эта техника тест-дизайна. Однако, далеко не все тестировщики (как те, кто приходят на собеседование, так и те, кто его проводят) могут четко сформулировать ответ на вопрос, зачем нужны комбинаторные техники в общем и pairwise в частности (подавляющее большинство ошибок, все же, находятся на атомарных значениях параметров и не зависят от других). Простой ответ на этот вопрос, на мой взгляд - для нахождения багов, возникающих вследствие явных и неявных зависимостей между параметрами. Для простых случаев техника вряд ли принесет серьезную пользу, поскольку их можно проверить вручную, а для большого числа параметров и сложных зависимостей между ними количество тестов, скорее всего, будет слишком велико для ручного тестирования. Потому основное применение комбинаторных техник (и соответственно, инструментов, осуществляющих генерацию комбинаций параметров) - автоматизированное составление наборов тестовых данных по определенным законам.

Большинство инструментов для генерации комбинаторных тестов умеют выдавать результат в виде файла с данными, который может быть передан на вход соответствующим автотестам. Такой пример (используется инструмент PICT) и будет рассмотрен ниже.

Пример 1. Серия и номер паспорта

При условии использования автоматизированного тестирования для серии и номера паспорта можно составить исчерпывающий набор позитивных тестов, поскольку требования к этому полю строги - ровно две заглавных буквы украинского алфавита (кроме Ґ, Ї, Ь) и шесть цифр от 0 до 9. Всего таких тестов будет (33-3) 2 *10 6 = 9*10 8 . Однако, редко встречаются случаи, когда требования к полю настолько строгие, да и вряд ли нужно проводить исчерпывающее тестирование. Скорее всего, достаточно проверить возможность ввода каждой отдельной буквы и каждой отдельной цифры на каждой позиции соответственно. Задачу составления таких тестов вполне может решить инструмент комбинаторного тестирования:
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 {SERIES_1, SERIES_2, NUMBER_1, NUMBER_2, NUMBER_3, NUMBER_4, NUMBER_5, NUMBER_6} @ 1 Модель 1
Щ З 4 6 3 1 1 5 І Є 8 3 8 9 9 3 А Н 3 0 5 8 6 2 М С 4 3 4 1 3 1 Є Я 4 6 7 3 1 4 Г Ц 0 2 4 5 2 0

Аналогично можно составить негативные тесты (PICT позволяет пометить их специальным символом "~").
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_2: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_3: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_4: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_5: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F NUMBER_6: 0,1,2,3,4,5,6,7,8,9,~A,~B,~C,~D,~E,~F Модель 2
З У 1 3 7 2 7 4 Л Ю ~B 7 3 2 7 9 А Є 8 8 2 0 ~A 8 Часть результатов моделирования

Пример 2. Увеличение тестового покрытия с помощью дополнительного параметра

Иногда баги, связанные с валидациями, зависят от того, каким образом пользователь вводит невалидные данные: с клавиатуры (физической или экранной), с помощью контекстного меню копирования-вставки, горячих клавиш, перетаскивания выделенного текста. Например, часто перетаскивание текста не обрабатывается клиентской валидацией, если таким образом вводятся некорректные данные. Способ ввода можно ввести в модель в качестве дополнительного параметра и учесть его при составлении автотестов.
SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 INPUT: keyboard, screen keys, context menu, copy paste, drag-n-drop Модель 3
М Л 0 8 0 8 5 9 keyboard Ю У 0 0 2 3 2 2 drag-n-drop С Ч 5 3 6 2 1 0 screen keys Я Д 3 9 4 1 6 7 context menu У Ш 9 9 0 7 4 4 copy paste Часть результатов моделирования

Пример 3. Тесты для систем принятия решений, валидация требований

Для систем принятия решений иногда составляются исчерпывающие тестовые наборы, которые потом можно использовать не только для тестирования, но и для валидации требований. Применяя последовательно правила системы к каждому тесту, можно посмотреть, не получаются ли противоречивые результаты.

Валидация требований - очень немаловажная часть тестирования в данном случае, поскольку можно обнаружить скрытые противоречия. Инструмент генерации комбинаторных тестов позволит не только составить тесты, но и задать условия, накладываемые на входные данные. Если эти условия делают какие-то из возможных данных недостижимыми, инструмент укажет на это, что может послужить сигналом тщательной проверки требований на непротиворечивость.
AGE: 0-17, 18-21, 22-65, >=66 CHILDREN: Y, N SMOKING: Y, N WORK: 0-5, 6-10, >=11 {AGE, CHILDREN, SMOKING, WORK} @ 4 IF = "0-17" THEN <> ">=11"; IF =">=11" THEN = "0-17"; Модель 4
Constraints Warning: Restrictive constraints. Output will not contain following values WORK: >=11 Реакция инструмента на противоречивые требования

В данной модели есть противоречивые требования, которые отсекают значение WORK: >=11, и оно не появляется ни в одном из тестов. К сожалению, инструмент не дает ответа на вопрос, какие именно условия вызывают противоречие, только показывает, какое значение исключено из тестов. Однако, этой информации может быть достаточно, чтобы выделить из всего массива ограничений те, что влияют на этот параметр, и проанализировать их на предмет противоречивости.

Исчерпывающий набор тестов в дальнейшем может быть использован для техники тест-дизайна «причина-следствие».

Пример 4. Формирование параметров окружений для конфигурационного тестирования

Инструменты для комбинаторного тестирования позволяют также составлять список возможных конфигураций, который потом можно отсортировать по популярности использования, вычеркнуть неподходящие и т.д. Если не обязательно проводить все тесты для каждой из конфигураций, можно поделить их равномерно между выбранными окружениями, добавив окружение в качестве еще одного параметра для генерации тестовых данных (так, как это делалось в примере со способом ввода данных).
BROWSER: IE, Firefox, Chrome, Opera LANG: en, ru, ua OS: win, linux, android {BROWSER, LANG, OS} @ 1 IF = "linux" THEN <> "IE"; Модель 5
IE ua win Firefox en win Opera ua linux Chrome ru android Результаты моделирования

SERIES_1: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я SERIES_2: А,Б,В,Г,Д,Е,Є,Ж,З,І,Й,К,Л,М,Н,О,П,Р,С,Т,У,Ф,Х,Ц,Ч,Ш,Щ,Ю,Я NUMBER_1: 0,1,2,3,4,5,6,7,8,9 NUMBER_2: 0,1,2,3,4,5,6,7,8,9 NUMBER_3: 0,1,2,3,4,5,6,7,8,9 NUMBER_4: 0,1,2,3,4,5,6,7,8,9 NUMBER_5: 0,1,2,3,4,5,6,7,8,9 NUMBER_6: 0,1,2,3,4,5,6,7,8,9 ENVIRONMENT: IE ua win, Firefox en win, Opera ua linux, Chrome ru android Модель 6

Пример 5. Составление нескольких тестов с учетом большого количества ограничений

Безусловно, комбинаторное тестирование можно применять и для генерации тестов, которые выполняются вручную, но как мне кажется, это стоит делать, только если есть очень большое количество ограничений, которые трудно удержать в голове. Из-за наличия условий количество тестов может быть ограничено, так сказать, естественным образом, и инструмент позволит получить все возможные тестовые данные, подходящие под все накладываемые на них условия. При этом тесты можно выполнить и вручную.
AGE: 0-17, 18-21, 22-65, >=66 CHILDREN: 0, 1, 2, 3, 4, 5 SMOKING: Y, N WORK: 0-5, 6-10, >=11 IF = "0-17" THEN <> ">=11"; IF = "0-17" THEN = 0; IF = "18-21" THEN < 2; IF > 0 THEN = "N"; IF = ">=66" THEN <> "0-5"; IF = "0-17" OR = "18-21" THEN = "0-5"; Модель 6
22-65 2 N 0-5 18-21 1 N 0-5 >=66 2 N 6-10 22-65 4 N 6-10 22-65 5 N 6-10 22-65 3 N 6-10 >=66 4 N >=11 22-65 5 N >=11 0-17 0 Y 0-5 >=66 3 N >=11 22-65 4 N 0-5 22-65 2 N >=11 18-21 0 Y 0-5 22-65 0 Y >=11 22-65 1 N 6-10 22-65 3 N 0-5 >=66 1 N >=11 0-17 0 N 0-5 >=66 0 Y 6-10 >=66 5 N >=11 22-65 5 N 0-5 Результаты моделирования - 21 тест

01.06.2006 Майкл Папазоглоу, Виллем-Ян ван ден Хьювел

Решения на базе сервис-ориентированной архитектуры позволяют использовать преимущества распространенных сервисов и обеспечивают взаимодействие бизнес-процессов разных организаций. Однако приложения на основе Web-сервисов могут охватывать несколько компьютеров, операционных систем, языков и предприятий

, а потому довольно сложно контролировать и измерять Web-сервисы, управлять их готовностью и производительностью.

Рассмотрим связи между управлением Web-сервисами и традиционными распределенными системами, а также подходы к управлению Web-сервисами и их основообразующие архитектурные концепции.

Сегодня Web-сервисы - самая популярная парадигма распределенных вычислений. Принимая на вооружение сервис-ориентированные архитектуры (service-oriented architecture, SOA) на базе Web-сервисов, предприятия могут гибко решать внутри- и межкорпоративные проблемы интеграции. Web-сервисы начинают играть все более важную роль в жизни предприятий, и контроль над ними становится насущной необходимостью. Направляя развитие Web-сервисов, можно получать ясное представление об их работе, обоснованно принимать управленческие решения и осуществлять управляющие воздействия для адаптации поведения приложений на их базе. Для всего этого нужны распределенные средства управления Web-сервисами.

При управлении распределенными системами наборы инструментов и утилиты контролируют их действия, что облегчает принятие управленческих решений и внесение изменений в поведение систем. По традиции основное внимание до сих пор уделялось управлению последовательными уровнями новых технологий, которые вводились в эксплуатацию в распределенных средах. Однако такие методы не отвечают корпоративным требованиям, поскольку не соответствуют бизнес-функциям. Кроме того, многие инфраструктуры системного управления не обеспечивают контроля над соглашениями об уровне обслуживания (service level agreement, SLA) или получения от приложений на базе Web-сервисов информации об обслуживании, необходимой для устранения ошибок.

Эксплуатируя решения на базе SOA, ИТ-администраторы должны непрерывно анализировать модели использования сервисов, критерии и метрики SLA, данные об отказах. Без такой информации довольно трудно понимать причины проблем с производительностью и стабильностью приложений SOA. В частности, предприятия должны контролировать и измерять уровни обслуживания распределенных и консолидированных процессов. Наблюдая за бизнес-процессами, ИТ-администраторы могут выявлять благоприятные возможности и диагностировать проблемы по мере их возникновения. Благодаря этому Web-сервисы, поддерживающие конкретную бизнес-задачу, выполняются в соответствии с требованиями SLA.

Поставщики средств управления предлагают измерительные инструменты только для конечных точек и узлов-посредников SOAP или серверов UDDI. Обеспечиваемое данными инструментами представление об использовании Web-сервисов приложениями страдает неполнотой: ему не хватает жизненно важной информации о состоянии и характеристиках Web-сервисов. Для получения таких сведений Web-сервисы должны стать измеримыми и более управляемыми. Этого можно достичь только путем стандартизации, которая обеспечит сквозную управляемость всех частей долгоживущей многошаговой транзакции, охватывающей несколько приложений, предприятий и действующих лиц.

Ожидается, что в ближайшем будущем управление Web-сервисами станет жизненно важным компонентом распределенных приложений. Мы обсудим распределенные Web-сервисы и проблемы управления ими, исследуем концепции SOA и их связь с ключевыми требованиями.

Управление распределенными сервисами

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

Управление распределенной вычислительной средой требует надежных эффективных процессов как для администрирования системы, так и для управления сетью. Такие процессы обеспечиваются программами, инструментами и утилитами, которые дают администраторам представление о состоянии систем и сетей, приложений и моделей поведения. Хотя в традиционных распределенных средах наборы инструментов и утилиты действуют уже много лет, придется разработать эквивалентные технологии для сложного мира слабосвязанных приложений на базе Web-сервисов.

Использование Web-сервисов для организации доступа к унаследованным приложениям и их расширения дает предприятиям явные технологические преимущества. Объединение сервисов в дискретные логические компоненты, непосредственно увязанные с бизнес-функциями, помогает получить еще более существенные плюсы. Компании могут «оркестровать» такие сервисы во многих конфигурациях для поддержки нескольких бизнес-процессов. Оркестрованная реализация сервисов формирует логическую сеть услуг, наложенную поверх инфраструктуры (в том числе программной среды, серверов, унаследованных приложений, внутренних систем) и физической сети связи. По мере разрастания такой сети Web-сервисов ее работа и производительность становятся жизненно важными для ключевых бизнес-операций.

Требования к качеству

Поставщик и покупатель должны договориться об особенностях сервиса. В приложениях, объединяющих географически распределенные Web-сервисы, такой договор составляет суть корпоративного соглашения SLA. Цель состоит в том, чтобы улучшить фактическое качество услуг (quality of experience, QoE) для внутренних или внешних клиентов. QoE создает единую основу для измерения качества продукта или услуги, в том числе производительности, пред- и послепродажного обслуживания, степени удовлетворенности клиента. Поставщик часто должен заключить и контролировать выполнение несколько внутренних (для бизнеса или конечных пользователей) либо внешних (для поставщиков услуг, партнеров, аутсорсеров и т.д.) соглашений SLA. Вообще говоря, бизнес-процесс предполагает несколько соглашений SLA, управляющих взаимосвязанными услугами в интересах конечного пользователя. Для каждого уровня SLA одну из сторон можно считать поставщиком, а другую - потребителем.

Обеспечение качественного сервис-ориентированного управления требует измерения ключевых показателей эффективности (Key Performance Indicator, KPI) приложений и услуг. Поставщик услуг может рассмотреть общие KPI перед их применением к конкретным приложениям. К общим KPI бизнес-приложений относятся доступность и производительность сервиса, время отклика и скорость выполнения транзакций, время простоя и безопасность. Поставщик должен знать, соответствуют ли его услуги установленным показателям KPI, и бить тревогу в случае «накладок». Ему необходимо установить для сервиса целевые показатели KPI, научиться их измерять и анализировать, а также отчитываться о KPI, отличающихся от целевых.

Web-сервисы не могут самостоятельно выполнять эти сервис-ориентированные функции управления. Поэтому есть острая необходимость в инструментах контроля над Web-сервисами и управления ими.

Концептуальная архитектура управления

Циклическое, замкнутое управление и мониторинг состояния ресурсов реализуется с помощью технологий системного управления, позволяющих реагировать на ситуации, непрерывно возникающие в объекте управления. Мы можем рассматривать инфраструктуру управления как концептуальную архитектуру, которая объединяет разные компоненты, в том числе ресурсы, менеджеров ресурсов и консоль управления (рис. 1 ).

Консоль управления отображает информацию через интерфейс, позволяющий администраторам контролировать ресурсы и изменять их поведение. Интерфейс управления использует такие механизмы, как журналы, события, команды, интерфейсы API и файлы конфигурации . Как показано в левой нижней части рис. 1, интерфейс также применяет метаданные о свойствах ресурса:

идентификация - обозначает экземпляр управляемого ресурса;
метрика - обеспечивает информацию и действия для измерения показателей функционирования ресурса, таких как производительность, эффективность использования и т.д.;
конфигурация - предоставляет информацию и действия для конфигурируемых атрибутов управляемого ресурса.

Интерфейсы управления также требуют сведений о взаимосвязях ресурса с окружающей средой, в том числе пользователями и компьютерами. Наконец, интерфейс получает информацию о текущем состоянии управляемого ресурса и событиях управления (уведомлениях), которые могут произойти, если ресурс подвергнется существенным изменениям состояния.

Платформы распределенного управления

Широко применяются несколько стандартных платформ распределенного управления. Среди наиболее известных следует упомянуть SNMP (Simple Network Management Protocol - «простой протокол управления сетью», www.ietf.org/rfc/rfc1157.txt ), CIM (Common Information Model - «общая информационная модель», www.dmtf.org/standards/cim/ ), WBEM (Web-Based Enterprise Management - «технология корпоративного управления на базе Web», www.dmtf.org/standards/wbem/ ) и OMI (Open Management Interface - «открытый интерфейс управления», www.openview.hp.com/ downloads/try_omi_0001.html ).

SNMP, предложенный IETF, - это протокол прикладного уровня, который облегчает обмен управляющей информацией между сетевыми устройствами . Элементами сети SNMP являются устройства (такие, как хосты, шлюзы и терминальные серверы), снабженные агентами. Последние исполняют функции, запрашиваемые станциями управления сетью. Платформа SNMP позволяет сетевым администраторам управлять пропускной способностью сети, находить и устранять неисправности, планировать наращивание сети. Фактически SNMP является отраслевым стандартом сетевого управления.

Модель CIM, разработанная рабочей группой по управлению распределенными системами DMTF (Distributed Management Task Force), описывает все управляемые элементы предприятия, в том числе системы, сети и приложения. CIM не зависит от реализации и позволяет управляющим приложениям собирать необходимые данные из разных источников. Группа разработала также WBEM - набор стандартов управления и технологий Internet, нацеленных на унификацию управления корпоративной вычислительной средой. Опираясь на WBEM, можно построить интегрированный набор инструментов на базе стандартов, использующих преимущества развивающихся Web-технологий.

Интерфейс OMI, совместно разработанный компаниями Hewlett-Packard и webMethods , предоставляет поставщикам систем управления и другим заинтересованным сторонам легкий открытый доступ к управлению ресурсами, связанными с платформой интеграции и к относящимся к ней бизнес-процессам. OMI позволяет управляющим инфраструктурам с помощью программного интерфейса получить доступ к управлению интегрированной платформой бизнес-процессов. Через этот интерфейс пользователи могут управлять набором объектов OMI, представляющих доступные ресурсы.

Управление Web-сервисами

Когда традиционные централизованные управляющие приложения переходят к распределенным динамическим архитектурам SOA, они могут более гибко выполнять основные функции управления. В рамках SOA платформа управления Web-сервисами WSMF (Web Services Management Framework) обеспечивает поддержку обнаружения, анализа, защиты и обращения к ресурсам, а также выполнение функций управления и поддержку инфраструктурных управляющих сервисов и наборов инструментов. Те же технологии, определяющие бизнес-процессы и высокоуровневые процессы управления ИТ, теперь могут согласовываться с технологиями менеджеров ресурсов, инфраструктурных сервисов и управления ресурсами.

Методы управления сервисами

Все коммуникации между поставщиками и потребителями услуг осуществляются с помощью стандартизированных сообщений SOAP, которые облегчают управление Web-сервисами. Разработчики могут использовать сообщения SOAP для пометки начальных и конечных точек сервисных транзакций. Кроме того, источник и получатель сообщения SOAP легко идентифицируются, поэтому достаточно получить детальные критерии качества работы приложений, охватывающих платформы и предприятия.

Управлять инфраструктурой Web-сервисов удается не всегда, но организации могут контролировать поток сообщений SOAP, которыми обмениваются приложения. Действительно, анализ трафика и изменение сообщений SOAP (которые могут быть перехвачены во многих точках сети приложений, связанных через Web-сервисы) являются основными принципами управления Web-сервисами. Контейнеры для сервисов облегчают построение среды потока сообщений типа «запрос-ответ». Подобно контейнерам J2EE, контейнеры для Web-сервисов подразумевают физическое проявление конечной точки абстрактного сервиса и обеспечивают реализацию сервисного интерфейса.

ИТ-администраторы могут вводить средства управления сервисами в конвейер SOAP, используя агентов либо посредников. Управление сервисами с помощью агентов соответствует контейнерному стилю управления. В данном случае «родной» для платформы контейнер Web-сервиса имеет возможности управления. С архитектурной точки зрения выгода этой модели состоит в следующем. Агент способен использовать преимущества конфигурации конкретной инфраструктуры контейнера бизнес-приложений (сервера приложений), который администраторы могут кластеризовать и защищать для достижения требуемого уровня обслуживания.

В отличие от подхода с использованием агентов, который непосредственно связывает управляющие серверы Web-сервисов с контейнерами, посредник (или брокер) действует как клиентская конечная точка, а затем передает запрос фактической конечной точке сервиса (рис. 2 ). Администраторы развертывают средства управления на уровне посредника, что позволяет осуществлять управление и контроль. Посредническая модель полностью отделена от узлов Web-сервисов и может использоваться в любой среде. Через узел-посредник допускается направлять сервисы с нескольких платформ, что также облегчает централизованное конфигурирование и управление.

Посредническая модель упрощает администрирование и техническую поддержку, она не подразумевает установки агента на каждом отдельном узле Web-сервисов. Однако посредники требуют реконфигурации сетевого адреса. Кроме того, при отсутствии инфраструктуры кластеризации посредников Web-сервисов они могут стать отдельными точками неисправности и таким образом создать проблемы в средах, требующих высокой надежности.

Управление инфраструктурными сервисами

Для управления услугами платформа WSMF использует свойства управляемости архитектурных ресурсов. Они определяют стандартные схемы, метаданные и интерфейсы языка описания Web-сервисов WSDL (Web Services Description Language), описывающие поведение ресурсов, с помощью которого последние обеспечивают доступ к информации об управляемости . Как правило, ресурсы реализуют только применимые, а не все свои стандартные свойства управляемости, которые включают в себя эксплуатационный статус, метрику и отношения.

Свойства управляемости реализуются через информационную модель управляемости, которая представляет управляемость ресурса и сопутствующую информацию, такую как состояние, конфигурация и отношения . Платформа управления сервисами использует информацию из этой модели, которая может, например, указывать, что заголовок сообщения SOAP содержит цифровое удостоверение личности клиента. WSMF извлекает эти сведения и задействует для идентификации клиента (например, при подсчете сообщений SOAP определенного клиента для конкретного Web-сервиса).

WSMF применяет инфраструктурные сервисы управления для определения стандартных интерфейсов к общедоступным функциям инфраструктуры . К числу таких сервисов относятся измерение, посреднические функции при обработке метрик и событий, мониторинг, сканирование системы, реализация политик и мосты между моделями. Стандартные интерфейсы управления позволяют выполнять утилиты, процессы и приложения более высокого уровня, такие как управление готовностью и производительностью, оптимизация, планирование загрузки, формирование счетов, управление конфигурацией, защита ресурсов, выявление проблем, бизнес-анализ.

Системы управления сервисами управляют ресурсами, используя их интерфейсы, сервисы инфраструктуры и другие доступные инструменты. Эти механизмы поддерживают ряд функций, в том числе простой мониторинг, контроль, автоматическую настройку и восстановление, управление качеством, сквозное управление бизнес-процессами, предоставление системных ресурсов и услуг на основе политик. Они также обеспечивают интерфейсы и контент для консолей управления.

Web-сервис является управляемым, если его свойства управляемости доступны через стандартные интерфейсы управления, подобные функциональным интерфейсам . Интерфейсы управления отличаются лишь тем, что имеют семантику, связанную с управлением, и их использует система управления Web-сервисами, а не клиент. На рис. 3 показаны интерфейсы управления Web-сервиса, доступные для платформы WSMF. Документ WSDL описывает интерфейсы управления и конечные точки, которым WSMF может посылать сообщения, связанные с управлением. WSMF логически играет роль связующего звена между поставщиками и потребителями Web-сервисов.

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

Как показано на рис. 3, наряду с распределенным мониторингом и реализацией политики WSMF предлагает централизованную платформу управления и политик. Она работает совместно с каталогами сервисов и средствами идентификации как при получении информации (такой, как статистика производительности сервисов, сведения о взаимозависимости сервисов), так и при ее отсылке. Политика в виде наборов правил направляется компонентам управления сервисами. Эти правила определяют поведение компонента управления сервисами - когда и куда посылать оповещения, как обрабатывать транзитный трафик сообщений, соблюдать политику защиты и соглашения SLA и т.д.

Управление сервисами и приложениями

В дополнение к традиционным средствам разработки прикладных сервисов для эффективного управления системами и приложениями архитектура SOA на базе Web-сервисов требует двух ключевых функций:

единой платформы управления для гетерогенного набора составляющих систем;
поддержки комплексных, межкомпонентных сценариев управления, таких как соблюдение соглашений SLA и динамическое предоставление ресурсов.

На рис. 4 представлены концептуальные компоненты архитектуры, которые объединяют каналы управления сервисами и прикладные каналы, разработанные в соответствии с принципами SOA. Эта архитектура обеспечивает постоянную связь между прикладным каналом Web-сервисов и каналом управления. К числу управляющих приложений, которые она может обслуживать, относятся управление готовностью, производительностью, конфигурацией, заданиями, планирование загрузки, защита ресурсов и поиск неисправностей.

В этой архитектуре управление сервисами подразумевает подбор сервисов, взаимодействующих друг с другом при передаче данных или координации определенных операций, что облегчает оказание одной или нескольких бизнес-услуг. Вместо того чтобы предписывать конкретный протокол управления или технологию измерений, архитектура обеспечивает работу с протоколом SOAP, расширениями JMX (Java Management Extensions), технологией WBEM и другими (в том числе будущими) технологиями и стандартами.

На рис. 4 к управляемым ресурсам относятся физические и логические программные и аппаратные средства. Эти ресурсы публикуют свои свойства управляемости в виде Web-сервисов, которые реализуют разные интерфейсы, например определенные в спецификации распределенного управления Web-сервисами WSDM (Web Services Distributed Management). Интерфейс управления ресурсом описывается документом WSDL, схемой свойств ресурса, документами метаданных и, возможно, набором политик, связанных с управлением.

В процессе управления или в бизнес-процессе менеджеры ресурсов могут непосредственно обращаться к ресурсам. Как показано на рис. 4, на двух взаимодействующих предприятиях бизнес-процесс основан на базовых сервисах, таких как проверка кредитоспособности, отгрузка, обработка заказа и управление складскими запасами. Управляющие приложения архитектуры контролируют ресурсы через их интерфейсы или сервисы инфраструктуры . Эти менеджеры обеспечивают ряд функций, в том числе простой мониторинг, контроль, автономную настройку и восстановление, управление качеством, сквозное управление бизнес-процессами, предоставление системных ресурсов и услуг на основе политик. Обычно они поддерживают интерфейсы и контент для консолей управления и отображают информацию, связанную с управлением. Менеджеры взаимодействуют с ресурсами и сервисами инфраструктуры, применяя интерфейсы Web-сервисов. Кроме того, менеджеры сервисов используют язык WS-BPEL (Web Services Business Process Execution Language) для описания и выполнения процессов управления, которые обеспечивают исполнение заданных сценарием функций управления.

Решения на базе SOA, предназначенные для разработки приложений и управления ими, поощряют применение методов множественного связывания, а также следующие общедоступные сервисы управления:

управление SLA и фактическим качеством услуг, в том числе измерение производительности и готовности, сервисы оповещения;
обеспечение видимости и управляемости, в том числе интерактивный мониторинг, администрирование и создание отчетов;
поддержка адаптируемости сервисов, в том числе контроль над версиями, маршрутизация, дифференцированные услуги и преобразование сообщений;
поддержка Web-сервисов и механизмов безопасности на основе XML.

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

Литература

An Architectural Blueprint for Autonomic Computing. White paper, IBM, Oct. 2004; www-3.ibm.com/autonomic/ pdfs/AC wpFinal.pdf .
J.D. Case et al., Introduction to Version 3 of the Internet-Standard Network Management Framework, IETF RFC 2570. Apr. 1999; www.rfc-editor.org/rfc/rfc2570.txt .
G. Bullen et al., Open Management Interface Specification, v. 1.0, revision 1, Organization for the Advancement of Structured Information Standards. 2001; www1.webmethods.com/PDF/OMI_Spec.pdf .
H. Kreger et al., Management Using Web Services: A Proposed Architecture and Roadmap, tech report, IBM, Hewlitt-Packard and Computer Assoc. June 2005; www-128.ibm.com/developerworks/library/ specification/ws-mroadmap .
M. Potts, I. Sedukhin, H. Kreger, Web Services Manageability - Concepts (WS-Manageability), tech. report, IBM, Computer Assoc. and Talking Blocks. Sept. 2003; www3.ca.com/Files/SupportingPieces/ web_service_manageability_concepts.pdf .
W. Vambenepe, ed. Web Services Distributed Management:Management Using Web Services (MUWS 1.0) Part 1 and 2, Organization for the Advancement of Structured Information Standards. Mar. 2005; www.oasis-open.org/committees/download.php/11819/ wsdm-muws-part1-1.0.pdf .

Майкл Папазоглоу ([email protected]) - профессор Университета Тилбурга (Голландия). В сферу его научных интересов входят распределенные системы, сервис-ориентированные архитектуры и Web-сервисы, интеграция корпоративных приложений, технологии и приложения электронного бизнеса. Виллем-Ян ван ден Хьювел ([email protected]) - доцент Университета Тилбурга. К его научным интересам относятся сервис-ориентированные архитектуры, эволюция систем и увязка новых корпоративных информационных систем с унаследованными.

Стандарт управления Web-сервисами

Согласованное сквозное управление Web-сервисами невозможно без разработки общеотраслевых стандартов. С этой целью организация OASIS (Organization for the Advancement of Structured Information Standards) активно развивает спецификацию распределенного управления Web-сервисами WSDM (Web Services Distributed Management; www.oasis-open.org ). Она определяет протокол обмена управляющей информацией через Web-сервисы. При решении проблем управления распределенными системами WSDM подразумевает две задачи: управление с использованием Web-сервисов (management using Web services, MUWS) и управление Web-сервисами (management of Web services, MOWS).

MUWS устанавливает использование технологий Web-сервисов как основы современной платформы управления распределенными системами, в том числе применение Web-сервисов для упрощения взаимодействия управляемых ресурсов и управляющих приложений. Так, MUWS определяет, как описывать свойства управляемости ресурсов с помощью документов WSDL. Описание этих свойств способствует более эффективному выявлению и анализу ресурсов. Поскольку ИТ-менеджеры обычно фокусируются на конкретной задаче или области управления, они должны иметь возможность эффективно выявлять подходящие свойства управляемого ресурса.

MOWS определяет требования к управляющим Web-сервисам. В соответствии со спецификацией WSDM, Web-сервисы являются основой распределенных вычислений, интероперабельности, слабого связывания и независимости от реализации. Спецификация MOWS базируется на концепциях и определениях MUWS. Как и в MUWS, при определении модели управления Web-сервисами в MOWS прослеживается стремление оставаться в рамках существующих модельных структур, а не заново изобретать обобщенную объектную модель управляемых ресурсов.

Michael Papazoglou, Willem-Jan van den Heuvel, Web Services Management: A Survey, IEEE Internet Computing, Nov/Dec 2005. IEEE Computer Society, 2005, All rights reserved. Reprinted with permission.

5.1.1 Основы Web-сервисов

Web-сервисы - это новая перспективная архитектура, которая обеспечивает новый уровень распределенности. Вместо разработки или приобретения компонентов и их встраивания в ИС предлагается покупать время их работы и формировать программную систему, которая осуществляет вызовы методов из компонентов, которые принадлежат и поддерживаются независимыми провайдерами. Благодаря Web-сервисам функции любой программы в сети могут стать доступными через Интернет. Самый простой пример Web-сервиса - система Passport на Hotmail, которая позволяет создать аутентификацию пользователей на собственном сайте.

В основе Web-сервисов лежат следующие универсальные технологии:

TCP/IP – универсальный протокол, понимаемый всеми сетевыми устройствами, от мэйнфреймов до мобильных телефонов и PDA;

HTML – универсальный язык разметки, применяемый для отображения информации устройствами пользователей;

XML (Extensible Markup Language)– универсальный язык для работы с любыми типами данных.

Универсальность этих технологий – основа для понимания веб-сервисов. Они основаны только на общепринятых, открытых и формально независимых от поставщиков технологиях. Только посредством этого достигается главное преимущество веб-сервисов как концепции построения распределенных ИС – их универсальность, т. е. возможность применения для любых операционных систем, языков программирования, серверов приложений и т. д. Таким образом, веб-сервисы решают исходную задачу – задачу интеграции приложений различной природы и построения распределенных ИС. В этом и заключается основное принципиальное отличие веб-сервисов от предшественников.

Веб-сервисы - это XML-приложения, осуществляющие связывание данных с программами, объектами, базами данных либо с деловыми операциями целиком. Между веб-сервисом и программой осуществляется обмен XML-документами, оформленными в виде сообщений. Стандарты веб-сервисов определяют формат таких сообщений, интерфейс, которому передается сообщение, правила привязки содержания сообщения к реализующему сервис приложению и обратно, а также механизмы публикации и поиска интерфейсов.

Веб-сервисы могут использоваться во многих приложениях. Независимо от того, откуда запускаются веб-сервисы, с настольных компьютеров клиентов или с переносных, они могут использоваться для обращения к таким интернет-приложениям, как система предварительных заказов или контроля выполнения заказов. Веб-сервисы пригодны для В2В-интеграции (business-to-business), замыкая приложения, выполняемые различными организациями, в один производственный процесс. Веб-сервисы также могут решать более широкую проблему интеграции приложений предприятия (Enterprise Application Integration, EAI), осуществляя связь нескольких приложений одного предприятия с несколькими другими приложениями. Во всех перечисленных случаях технологии веб-сервисов являются "связующим звеном", объединяющим различные части программного обеспечения.

Как видно из рис. 5.1, веб-сервисы представляют собой оболочку, обеспечивающую стандартный способ взаимодействия с прикладными программными средами, такими как системы управления базами данных (СУБД), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), посредники пакетов планирования ресурсов предприятия (Enterprise Resource Planning, ERP), брокеров интеграции и пр.

Рис.5.1. Веб-сервисы взаимодействуют с прикладными системами

Интерфейсы веб-сервисов получают из сетевой среды стандартные XML-сообщения, преобразуют XML-данные в формат, "понимаемый" конкретной прикладной программной системой, и отправляют ответное сообщение (последнее - не обязательно). Программная реализация веб-сервисов (базовое программное обеспечение, нижний уровень) может быть создана на любом языке программирования с использованием любой операционной системы и любого связующего программного обеспечения (middleware).

Простой пример: поиск информации

В настоящее время большинство сервисов вызываются по Сети посредством ввода данных в HTML-формы и отправки этих данных сервису путем добавления их в строку унифицированного указателя информационного ресурса (Uniform Resource Locator, URL):

http://www.google.com/search?q=Skate+boots&btnG=Google+Search

Этот пример иллюстрирует простоту веб-взаимодействия (например, поиска, покупки акций или запроса маршрута движения), где параметры и ключевые слова внедряются непосредственно в URL. В данном случае представлен простой запрос поиска skate boots (ботинки с коньками) в строке обращения к поисковой машине Google. Ключевое слово search (искать) представляет сервис, к которому будет осуществлено обращение, а параметр Skate+boots является строкой поиска, которая была введена в HTML-форме на странице веб-сайта Google. Сервис поиска Google передаст этот запрос к различным поисковым машинам, которые вернут список URL для страниц, на которых имеется соответствие параметру поиска Skate+boots. Данный малоэффективный способ поиска в Сети полностью основан на установлении соответствия указанной текстовой строки и индексированных HTML-страниц.

XML - лучший способ отправки данных. XML предоставляет значительные преимущества при передаче данных через Интернет. Теперь предыдущий запрос можно представить в виде XML-документа:

xmlns:s="www.xmlbus.com/SearchService">

Skate

boots

size 7.5

Отправка запроса в виде XML-документа имеет следующие преимущества: возможность определения типов данных и структур, большую гибкость и расширяемость. XML может представлять структурированные данные или данные определенного типа (например, допустимо указывать значение поля size (размер) как в виде строки цифр, так и в форме числа с плавающей точкой) и содержать больший объем информации, чем это допускает URL.

Данный пример представлен в форме SOAP-сообщения (Simple Object Access Protocol) - стандартной формы обмена XML-сообщениями - одной из технологий, лежащих в основе веб-сервисов. В SOAP-сообщении имя запрашиваемого сервиса и входные параметры представлены в виде отдельных XML-элементов. Рассматриваемый пример также иллюстрирует использование пространства имен XML (xmlns:), еще одного важного элемента веб-сервисов. Благодаря тому, что XML-документы поддерживают разные типы данных, сложные структуры и объединение схем, современные технологии веб-сервисов обеспечивают значительное преимущество над существующими возможностями обращения к программным приложениям посредством HTML и URL.

Следующее поколение Сети

Следующее поколение Сети будет основано на программно-ориентированных взаимодействиях. Веб-сервисы предполагают использовать созданные для взаимодействия людей глобальные сети совершенно в иных целях.

Использование веб-сервисов очень выгодно с коммерческой точки зрения. За счет повсеместного распространения веб-сервисов Интернет становится более эффективным, особенно при осуществлении коммерческих сделок. Сочетая прямой доступ к программным приложениям и коммерческим документам, веб-сервисы следующего поколения Сети обеспечат полностью автоматическое взаимодействие, что позволит обращаться непосредственно к данным программ, игнорируя знакомые веб-страницы. Более того, основные компоненты веб-сервисов, скорее всего, будут предоставляться и публиковаться множеством различных компаний, специализирующихся на отдельных функциональных элементах (проверка полномочий, координация сделок, ведение счетов). Это обеспечит непосредственное взаимодействие "приложение-приложение" - принцип, лежащий в основе веб-сервисов и определяющий их суть и реализацию.

ОБЩЕЕ ВЗАИМОПОНИМАНИЕ

Технология веб-сервисов существует на очень высоком уровне абстракции, позволяя поддерживать множество одновременных определений, которые иногда бывают противоречивы. На простейшем уровне веб-сервисы могут восприниматься как интернет-ориентированные текстовые брокеры интеграции. Любые данные могут преобразовываться в ASCII-текст и обратно, и этот подход в течение долгого времени был общим знаменателем для систем графического вывода и систем управления базами данных. Ориентированные на использование текста системы также лежат в основе успешного развития Интернета, на котором базируется дополнительная абстракция веб-сервисов. Любой компьютер или операционная система может поддерживать HTML, браузеры и веб-сервисы; и при получении по сети файлов им совершенно безразлично и даже неизвестно, с каким типом прикладной системы они взаимодействуют.

Преимущества и недостатки веб-сервисов.

К преимуществам веб-сервисов можно отнести следующее:

Веб-сервисы позволяют компании интегрировать свои бизнес-процессы с бизнес-процессами бизнес-партнеров и клиентов при меньшей стоимости, чем с использованием других интеграционных технологий. Стоимость подобных решений на основе веб-сервисов доступна даже для 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);

Добавление к функциям сервера приложений функциональности провайдера веб-сервисов в силу новизны технологий может представлять определенную трудность;

Вопросы безопасности функционирования ИС на основе веб-сервисов пока не урегулированы до конца. Спецификация 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.

Таким образом, преимущества представляют собой стратегические бизнес-преимущества компаний, а недостатки имеют технологический характер и обусловлены новизной технологий, решение этих проблем лишь вопрос времени.

Определение веб-сервиса

Назовем сервисом (service) ресурс, реализующий бизнес-функцию, обладающий следующими свойствами:

является повторно используемым;

определяется одним или несколькими явными технологически-независимыми интерфейсами;

слабо связан с другими подобными ресурсами и может быть вызван посредством коммуникационных протоколов, обеспечивающих возможность взаимодействия ресурсов между собой.

Веб-сервисом (см. документ W3C “Web-services architecture requirements”) называется программная система, идентифицируемая строкой URI, чьи интерфейсы и привязки определены и описаны посредством XML. Описание этой программной системы может быть найдено другими программными системами, которые могут взаимодействовать с ней согласно этому описанию посредством сообщений, основанных на XML, и передаваемых с помощью Интернет-протоколов.