СМ-Консалт
 

Работа с Web-сервисами в корпоративных SOA: Часть 11. Соединение web-сервисов на основе XOP с внешними сервисами при помощи WebSphere Business Modeler и Rational Web Developer для WebSphere

Статьи Технологии разработки ПО SOA и Web-сервисы

Введение

В части 7 вы познакомитесь с тем, как приложения web-сервисов на основе XML могут сильно увеличиваться в объеме. Эти web-сервисы, используемые в больших количествах, могут привести к перегрузкам системы, вследствие чего сетевой трафик может застопориться. Чтобы разобраться с этой проблемой, вы пользовались спецификацией XOP (XML-binary Optimized Packaging) для повышения скорости web-сервисов.

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

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


Разработка моста web-сервисов

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

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


Рисунок 1. Простая очередь
Простая очередь

Далее вам необходимо определить поведение каждого файла после его поступления в очередь. Задайте себе следующие вопросы:

  • Во время нахождения в очереди сможет ли файл справиться с задержкой сервиса?
  • Или файл не будет ждать и захочет поступить в другую очередь с более быстрым сервисом?
  • Насколько длинной должна быть очередь?
  • Какой объем очереди должен быть продублирован?
  • Когда очередь достигнет своего порога, каким образом web-сервис должен оповестить отсылающий внешний web-сервис о том, что ему необходимо подождать, прежде чем отправлять файл в очередь в мост web-сервиса?
  • Если файл не может ждать, должен ли он быть послан в другую очередь того же самого или другого моста web-сервиса?

Определение пороговой величины размера файла

Каким же образом в очереди моста web-сервиса рассчитывается, файл какого размера является оптимальным? Вам необходимо задать механизм, устанавливающий пороговую величину размера, и создать его на таком уровне, чтобы он оценивал, является ли размер внешнего файла оптимальным. Если файл соответствует пороговому значению или ниже его, то мост web-сервиса выпускает его из очереди для дальнейшей обработки запрашивающей SOA (Service-Oriented Architecture). Если файл превышает размер пороговой величины, web-сервис маркирует его, как слишком большой. Такой файл затем передается в оптимизатор файлов web-сервиса

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


Создание многоканальной системы обслуживания с несколькими очередями

Проблема при работе только с одной очередью моста web-сервиса заключается в том, что каждый файл должен терпеливо ожидать своего часа. Он не может обойти другой файл впереди него, также как и машина не может обогнать другую, которая едет очень медленно, если дорога состоит из одной полосы. Что же можно сделать в таком случае, спросите вы?

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


Понимание взаимозависимостей внешних файлов

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

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

Очередь в оптимизаторе файлов web-сервиса одиночная, то есть невозможность файла ждать, пока его оптимизируют, не принимается в ней во внимание. Файл должен линейно дожидаться своей очереди. К моменту его оптимизации производительность запрашивающего web-сервиса снижается.


Создание нелинейных очередей

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

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

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


Использование нелинейных выборок

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

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


Рисунок 2. Нелинейная очередь с высоким уровнем приоритета
Нелинейная очередь с высоким уровнем приоритета

Установка оптимальной пороговой величины размера

Каким же образом вам следует определять пороговую величину размера тех файлов, которые необходимо оптимизировать? Вы можете воспользоваться WebSphere Business Modeler для того, чтобы помочь и разработчикам, и бизнес-аналитикам в установлении единых временных рамок, который будут способствовать динамическим изменениям в очередях. Определение границ таких рамок зависит от того, насколько интенсивным или менее загруженным является сетевой трафик, каков максимальный период работоспособности и какова полоса пропускания в периоды пиковой нагрузки. Это также зависит от того, каким образом web-сервисы оркестрируются в определенный момент их деятельности, каковы установки внутренней защиты, насколько быстро осуществляется доступ и выполнение, каковы проблемы, связанные со временем задержки, и сколько делается web-запросов за заданный промежуток времени.

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

  • Очередь с высоким уровнем приоритета и низким значением пороговой величины размера
  • Очередь с высоким уровнем приоритета и средним значением пороговой величины размера
  • Очередь с высоким уровнем приоритета и высоким значением пороговой величины размера

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


Заключение

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

Чтобы облегчить себе задачу, используйте IBM Rational Web Developer для создания web-сервисов, основанных на бизнес-процессах, которые вы моделируете с помощью IBM WebSphere Business Modeler. Эти продукты могут помочь и упростить вашу работу при соединении web-сервисов на основе XOP с внешними web-сервисами.

23.02.2008

Добавить комментарий (анонимные комментарии не публикуются!!!)

ФИО: 
E-mail: 
Тема: 
Комментарий: 
Оценка:   
 
 
 
 
 
Код подтверждения:
   

Новости СМ-Консалт

Вышла версия BIPULSE 6.2

Мастер-класс для тренеров и руководителей "Работа в аудитории". 1 ступень уже в марте

Обновлено расписание тренингов до марта 2017 года

Новые статьи в библиотеке

Мифы про ГОСТ 34

Примеры отраслевых решений на основе BIPULSE

Практика реализации модуля интеграции для Rational Software Architect, позволяющего преобразовывать низкоуровневое представление процесса из IBM Rational ClearQuest в UML

Что удивляет в русских менеджерах иностранцев

Разработка ПО с использованием лучших мировых практик и инструментов на Иркутском авиационном заводе

Презентация доклада для IT Global Meetup Санкт-Петербург: "Почему Agile так популярен? Взгляд циника и психолога"

Заказчики и истории успеха

Наши тренинги, семинары, курсы

Дружите с нами на FaceBook

Проверить настройки
Компания
Сделано в СМ-Консалт
Услуги 
Компетенция
  • CMC-TotalTest (скоро)
    уникальная разработка автоматизации функционального тестирования. Альтернатива HP UFT, IBM RFT и Microsoft!
  • CMC-Bisquiter
    автоматизированное тестирование АБС "Бисквит"
  • CMC-Formater
    тестирование печатных и экранных форм
  • CMC-TerminalTest
    тестирование терминальных приложений
  • ProjectTracker
    интеграция ALM и MS Project
  • GanttChart
    модуль управления проектами для IBM Rational ClearQuest и TeamConcert
    Все разработки СМ-Консалт >
  • ИТ-консалтинг
  • Автоматизированное тестирование
  • Ручное тестирование
  • Аутсорсинг тестирования
  • Оптимизация бизнес-процессов
  • Внедрение методологии и инструментов ALM
  • Обучение и коучинг
  • Разработка ПО
  • Интеграция
ООО СМ-Консалт (СМК), 2004-2017.
Карта сайта