 | Уровень сложности: средний Кайл Браун, почетный инженер, IBM
10.11.2009 
Исследование трех типичных антишаблонов, или "худших методик", которые могут значительно усложнить внедрение Web-сервисов и SOA.
Из журнала IBM WebSphere Developer Technical Journal.
Три простых способа испортить себе жизнь
Как консультант IBM® Software Services and Support, я встречал множество клиентов, использующих XML и Web-сервисы самыми разными способами. Среди них было много тех, кто успешно внедрил Web-сервисы, снизив затраты и повысив степень повторного использования активов. Но было также много таких, кто попал в ловушку, неправильно используя Web-сервисы и XML. Основываясь на своем опыте, я определил три типичные ситуации использования XML и Web-сервисов, приносящие разработчикам большую головную боль. Здесь я рассмотрю эти ситуации, объясню их причины и исследую некоторые альтернативные подходы, которые могут помочь решить возникающие проблемы. Итак, приступим.
"Сообщения съели мой сервер!"
Проблема
Отправка слишком больших сообщений, или, что еще хуже, слишком больших "непрозрачных" (двоичных) сообщений по транспортным каналам Web-сервисов.
Почему так происходит?
Я встречал эту проблему много раз, и всегда она имела один и тот же набор симптомов. Все начиналось либо со звонков пользователей в службу поддержки одного из продуктов IBM по поводу ошибок нехватки памяти, либо с привлечения одного из наших консультантов с целью оказания помощи в решении "проблемы производительности" архитектуры Web-сервисов. Обнаруживается, что серверная обработка XML создает очень высокую нагрузку, а коэффициент использования процессора приближается к 100%. Также обращают на себя внимание низкая пропускная способность и высокая сетевая латентность.
Начав исследование структуры сообщений Web-сервисов, мы выясняем, что причиной проблем являются слишком большие сообщения - зачастую 50 мегабайт и более. После более детального изучения сервисов обычно обнаруживается общая тенденция: сообщения часто содержат очень большой объем двоичной информации (закодированной с использованием алгоритма base-64), встроенной в основное тело XML-сообщения.
Почему так происходит? Подобная ситуация часто возникает, когда разработчик рассматривает Web-сервисы как однозначную замену EDI или FTP. Основная проблема состоит в том, что разработчик не понимает ограничений технологии: XML-обработка очень полезна для большинства задач, но необходимо понимать, что сообщения проходят синтаксический анализ, а для большинства продуктов WebSphere это означает, что основная часть сообщения (или полностью все сообщение) будет храниться в оперативной памяти.
Как исправить ситуацию?
Есть два способа, применив которые, можно попытаться исправить данную ситуацию:
-
Не пересылайте лишнюю информацию. При отправке двоичных данных во многих случаях можно обнаружить, что сообщения очень часто повторяются. Если это так, можно рассмотреть вариант сжатия на HTTP-уровне для снижения задержек в сети. Хотя это и не поможет снизить нагрузку на обработку, но может помочь в смягчении одной из проблем.
-
Вообще не встраивайте двоичную информацию в тело XML-сообщения. Это наилучший выход, и есть несколько способов, которые можно попробовать. Например, можно было бы использовать механизм SOAP with Attachments или Message Transmission Optimization Mechanism (MTOM) для устранения накладных расходов на синтаксический анализ, хотя это не поможет снизить сетевые задержки.
Еще лучшим вариантом может быть полный отказ от отправки с использованием SOAP больших двоичных данных (blob). Вместо этого используйте сторонний механизм передачи через управляемую систему обмена файлами (например, IBM WebSphere MQ File Transfer Edition или шаблон Claim Check), чтобы исключить отправку больших двоичных файлов как по SOAP, так и по HTTP.
"Извините, у вас видны данные!"
Проблема
При обеспечении доступа к низкоуровневым данным Web-сервисы используются не в том месте архитектуры.
Почему так происходит?
Иногда мы сталкиваемся с неопределенными "проблемами производительности" в архитектуре SOA или с архитектурой Web-сервисов, которая не обеспечивает обещанных в SOA преимуществ повторного использования и простоты обслуживания. После детального изучения часто обнаруживается, что архитектура Web-сервисов хотя и используется, но уровень Web-сервисов является очень, очень низким - иногда каждый Web-сервис соответствует одному SQL-выражению. В наихудших ситуациях сам Web-сервис даже не переформатирует данные в осмысленную доменную схему; вместо этого он представляет данные в "сыром" виде, в котором они были получены из базы данных. Почему это происходит? По моему мнению, причиной является недопонимание архитектурных принципов SOA.
Один из ключевых принципов хорошей архитектуры SOA: сервисы должны быть достаточно высокого уровня, чтобы можно было воспользоваться преимуществами повторного использования. Метод SOMA определяет так называемый тест Services Litmus Test, который можно применить для оценки каждого сервиса в соответствии со следующими критериями:
- Согласованность с бизнес-деятельностью.
- Компонуемость.
- Экспортируемое описание сервиса.
- Устранение избыточности.
Такие низкоуровневые сервисы данных часто не проходят тест по первым двум критериям. Если сервис соответствует единичному запросу, он обычно не согласован с определенной бизнес-функцией; он просто слишком уточнен для представления бизнес-функции в целом. Аналогично, такие низкоуровневые сервисы часто не проходят тест на компонуемость (composability), поскольку они кодируют низкоуровневые детали реализации (например, структуру базы данных) в описании сервиса.
Как исправить ситуацию?
Сервисы такого типа обычно появляются в проектах, в которых они порождаются "снизу вверх" из существующего кода; часто разработчики смотрят на существующие архитектурные диаграммы и решают преобразовать каждый уровень архитектуры, включая уровень персистенции, в набор сервисов.
Вместо этого правильнее было бы применять крупномодульные Web-сервисы в нужном месте архитектуры SOA, опять же, анализируя стандартную модель уровней архитектуры. Часто в ней присутствуют четко определенные места, которые уже инкапсулируют бизнес-логику системы. Такие сервисы могут быть инкапсулированы в шаблон Remote Facade Pattern для отображения приемлемым способом основанных на модели сервисов.
После идентификации крупномодульных Web-сервисов можно приступить к разработке WSDL сверху вниз, чтобы избежать просачивания специфики данных и языка программирования в схему. В реальной ситуации скорее всего понадобится некое отображение между повторно используемой "хорошей" WSDL/схемой и интерфейсом сервиса.
"Схема? Не нужны нам никакие ужасные схемы!"
Проблема
Произвольный недокументированный XML помещается в SOAP-конверт, и все это именуется Web-сервисом.
Почему так происходит?
Данная ситуация возникает у разработчиков, внедряющих Web-сервисы снизу вверх. Симптомы данной проблемы: отсутствие обещанных преимуществ SOA и кажущееся усложнение обслуживания решений по сравнению с существовавшим до внедрения Web-сервисов. Здесь обычно мы видим приложение, первоначально созданное с использованием методики RESTful, взаимодействующее с внешним миром либо через XML over HTTP, либо просто передающее XML-документы по другому протоколу (например, JMS). Проблема не в том, как передаются XML-данные; проблема в небрежном отношении к документированию самой структуры XML.
Данная проблема обычно возникает при попытке повторно использовать существующий код, который уже был реализован для генерирования и синтаксического анализа XML; в таких случаях обычно используется JAXP-совместимый XML-анализатор и прямой доступ к Java HTTP-классам, требующимся для отправки и получения XML-документов. Проблема возникает при попытке внедрения всего этого в Web-сервисы. Часто применяется подход с созданием WSDL-документа, использующего элемент схемы <xml:Any> для разрешения беспрепятственного прохождения XML-документов, которые затем анализируются существующим кодом.
Если XML не имеет внешней схемы, корректность XML невозможно проверить ни в самой программе, ни, что еще важнее, в промежуточных модулях (например, ESB), которые могут существовать между клиентом и провайдером Web-сервиса. Одной из особенностей Web-сервисов является то, что XML не только читабелен для человека, но и воспринимаем машиной. Если используемая XML-схема не документирована, становится трудно (или невозможно) написать промежуточные модули, способные эффективно работать с такими XML-документами.
Более того, клиенты Web-сервиса могут предпочесть использовать строго типизированную информацию описания отдельно от WDSL. Например, если предоставленный им WSDL содержит <xml:Any>, невозможно автоматически создать специфичные для языка программирования объекты, соответствующие XML. Наличие недетерминированного WSDL существенно уменьшает ценность Web-сервисов для потребителя.
Как исправить ситуацию?
Простое решение - при написании Web-сервисов (используя либо стандарты WS-*, либо методику REST) необходимо всегда создавать полную и точную XML-схему для представления структуры документа. Опять же, возвращаясь к SOMA, экспортируемое описание сервисов является важной частью четко определенного сервиса.
При создании WS-* Web-сервисов этот XML должен быть включен в WSDL-описание Web-сервисов. Даже при использовании методики REST наличие легко доступной XML-схемы будет способствовать повторному использованию сервисов. Я рекомендую сохранять и обслуживать эту схему в репозитории (например, в IBM WebSphere Services Registry and Repository), позволяющем поддерживать различные версии схемы и предоставляющем механизм для извлечения схемы как из клиентских приложений, так и из промежуточных модулей.
Резюме
В этой короткой статье я исследовал некоторые типичные, часто встречающиеся на практике подходы, которые могут существенно усложнить нашу жизнь. Надеюсь, что данная информация поможет вам обойти эти проблемы и получить максимальный выигрыш от использования XML и Web-сервисов. Если же вы находитесь в подобной ситуаций, представленные здесь советы, возможно, облегчат ваши страдания.
Благодарности
Выражаю огромную благодарность Рэйчел Рейнитц (Rachel Reinitz) за многочисленные полезные предложения по улучшению данной статьи.
Ресурсы
Об авторе | 
| | Кайл Браун (Kyle Brown) - почетный инженер в IBM Software Services for WebSphere, специализирующийся на SOA и перспективных технологиях. Кайл занимается предоставлением консультаций и обучением технологиям SOA, J2EE и объектно-ориентированным технологиям клиентов, входящих в список Fortune 500. Является также соавтором книг "Корпоративное программирование на Java с использованием IBM WebSphere" (EN) и "Персистентность на предприятии" (EN). Часто выступает на конференциях по SOA, Enterprise Java, объектно-ориентированному проектированию и шаблонам проектирования. |
Выскажите мнение об этой странице
| |
