Из журнала IBM WebSphere Developer Technical Journal.

Введение

Когда я не занят написанием колонки в журнал IBM WebSphere®Developer Technical Journal, я провожу много времени в дискуссиях с архитекторами и разработчиками, обсуждая проблемы, с которыми они сталкиваются при проектировании и реализации решений, основанных на Web-сервисах и SОА. Существует целый ряд проблем, вопросов и тем (вызывающих горячие споры), всплывающих снова и снова, и я решил поделиться с вами собственным списком десяти самых популярных вопросов, связанных с Web-сервисами.

Заметьте, я не называю свои ответы на эти вопросы лучшими и единственными, просто потому, что на многие из них нет однозначного ответа. Напротив, для тех вопросов, на которые отвечали уже много раз, я лишь указываю на мои любимые источники, где та или иная проблема рассматривается наиболее подробно (в основном это, конечно, статьи на developerWorks). Я прекрасно понимаю, что эти темы очень актуальны, и вы вольны полностью разделять моё мнение или иметь совершенно противоположную точку зрения; вы также можете предлагать новые темы и вопросы для обсуждения. Осознавая, что тем самым могу открыть ворота потоку, я приглашаю вас скинуть мне по строчке ваших комментариев.

В начало

1. Что же такое в действительности документальный/литеральный Web-сервис?

Это, бесспорно, самый распространённый вопрос, который мне приходилось слышать. Его постоянно задают нам вот уже несколько лет, поэтому удивительно, что он до сих пор задаётся так часто, и что по нему всё еще имеется неправильное представление. Вы, вероятно, знаете, что можно задать стиль, как вызова так и кодирования Web-сервиса с помощью WSDL-определения (язык описания Web-сервиса). И до тех пор, пока это влияет на то, как в точности строится сообщение протокола SOAP, это почти не влияет на ваше решение в целом, стиль взаимодействия или модель программирования. Итак, я всегда советую следующее:

• Не стремитесь к использованию повсюду одного какого-либо стиля. Есть свои причины для существования различных стилей, и вы, скорее всего, со всеми ними столкнётесь.
• Относитесь к этому, как к детали реализации и не позволяйте этому управлять или влиять на дизайн вашей системы.
• Прочтите замечательную статью Какой стиль WSDL (языка описания Web-сервиса) мне следует использовать? Русса Бутека (Russ Butek), которая предлагает лучшее, на мой взгляд, объяснение разницы.

В начало

2. Web-сервисы медленно работают. Так ли это?

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

Этому способствуют несколько вещей; например, интеллектуальная технология синтаксического разбора XML (которая значительно оптимизирована для работы с элементами протокола SOAP и XML) или появление таких специализированных XML-устройств, как IBM DataPower® (которое поддерживает обработку XML на аппаратном уровне). Я бы даже добавил сюда поддержку кэширования Web-сервисов в сервере приложений WebSphere Application Server, как ещё один пример, который может помочь значительно улучшить производительность. На самом деле, в некоторых ситуациях вызовы SOAP через HTTP в последней версии runtime-библиотеки WebSphere Application Server выполняются быстрее, чем вызовы той же функции в RMI через IIOP.

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

В начало

3. Моя XML-схема не работает с вашими продуктами!

Когда вы преодолеете этап разработки тестовых приложений а-ля Hello World, вы можете обнаружить, что некоторые более продвинутые элементы схемы XML не поддерживаются или плохо поддерживаются вашими вспомогательными программами. Например, отсутствует отображение для элемента <xsd:choice> (который очень часто используется в схемах) в инструментарии WebSphere. То же самое относится и к <xsd:group>. В этих случаях можно либо поменять схему, либо создать собственный код для обработки XML, основанного на такой схеме. Имейте в виду, что может потребоваться ручное вмешательство, чтобы преобразовать вашу схему к реализации ваших Web-сервисов. Я рекомендую две статьи:

• Использование полиморфизма как альтернатива xsd:choice
• Как выбрать свою технологию преобразования для Web-сервисов

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

В начало

4. А как насчёт UDDI? Пользуется ли им кто-нибудь?

Когда Web-сервисы только стали популярными, всегда подчёркивалось, что в любой среде SОА существуют три основные роли:

• инициатор запросов сервиса
• поставщик сервиса
• сервисный брокер (посредник).

Роль брокера сводилась обычно к следованию стандартам UDDI в реестре. Вам предоставлялись публичные реестры для создания ваших собственных записей и повторного использования других. Сервер приложений WebSphere Application Server также включает частный реестр UDDI.

Однако, я все-таки считаю UDDI практически бесполезным в реальных жизненных ситуациях. Большинство IT-организаций по-своему осуществляют получение описаний сервисов и оконечных точек (например, используют LDAP), или вовсе предпочитают не иметь с этим дело, ожидая появления нового подхода де-факто к реестру сервисов. Некоторые добавляют собственные расширения к UDDI. Поддержка публичных реестров UDDI, осуществляемая IBM и другими фирмами, была прекращена.

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

В начало

5. Синхронизм Web-сервисов

Еще один предмет частых споров и разногласий – является ли сервис синхронным или асинхронным, а также какую роль играет использованный протокол обмена по сравнению с моделью программирования. Например, предположим, что Web-сервис предлагается с привязанным протоколом SOAP через канал службы сообщений Java (JMS). Складывается впечатление, что работа со службой сообщений JMS, которая поддерживает асинхронные интеракции, подразумевает, что это асинхронный Web-сервис. Однако, если вы пользуетесь поддержкой JAX-RPC (механизм вызова удалённых процедур) на сервере приложений WebSphere Application Server, потребителю придётся ждать возвращения ответа до возвращения управления. Это происходит потому, что JAX-RPC 1.1 активизирует синхронную интеракцию между инициатором запроса и провайдером, независимо от используемого протокола. Другими словами, модель программирования, которую вы применяете для вызова Web-сервиса, обычно определяет синхронизм запроса, а не сетевой протокол.

Существует 2 способа создания действительно асинхронных интеракций. Вы можете создать последовательность односторонних сервисов, которые обмениваются информацией, используя, например, поддержку адресации WS-Addressing на сервере приложений WebSphere Application Server V6.1. Подробнее об этом можно прочесть в статье на сайте developerWorks: Скрытое воздействие WS-Addressing на SOAP (The hidden impact of WS-Addressing on SOAP).

Второй способ – использовать поддержку сервисно-компонентной архитектуры (Service Component Architecture (SCA)) для асинхронных вызовов. SCA предлагает клиетский интерфейс API, который позволяет отделить отправку запроса от получения ответа. В будущем подобную поддержку обеспечит новый стандарт JAX-WS 2.0.

В начало

6. Корпоративная сервисная шина ESB: быть или не быть?

Существует ряд вопросов, связанных с корпоративной сервисной шиной (ESB):

1. Что же такое ESB? Это программа или шаблон? Или и то и другое?
2. Требуется ESB при каждой реализации SOA?
3. Действительно ли ESB представляет собой потенциальное "узкое место" в системе, выдаваемое за центр?
4. Что в корпоративной сервисной шине ESB и что на ESB?

Прежде, чем я попытаюсь ответить на эти вопросы, позвольте представить основной ресурс, который очень хорошо объясняет точку зрения IBM на ESB в контексте модели программирования SOA: Введение в корпоративную сервисную шину IBM.

Ответы на заданные вопросы могут составить целый ряд статей, но здесь я постараюсь кратко охватить лишь самое основное соответственно:

1. Корпоративная сервисная шина является архитектурным шаблоном. Продукты могут способствовать созданию отдельных экземпляров этого шаблона.
2. Ключевая характеристика ESB - разделение задач. Различия протоколов связи, маршрутизация и ревизия интеракций, безопасность и т.д. могут управляться вне фактического инициатора запроса и провайдера сервиса. Если вы можете запустить процесс без такого разделения, сейчас вам не нужна шина ESB. В большинстве случаев она вам все-таки потребуется.
3. Шина ESB - концептуальное ядро, которое в большинстве экземпляров будет физически размещена распределённым способом.
4. Хоть это иногда и трудно сказать (а часто, зависит от продукта(ов), который вы используете), следует начать с рассмотрения логики инфраструктуры в сравнении с бизнес-логикой. В шине случаются вещи, относящиеся к логике инфраструктуры, но не к бизнес-логике.

Опять же я не утверждаю, что эти ответы - исчерпывающие, но они, возможно, помогли осветить основные моменты.

В начало

7. Заголовки и контекстные данные

Основа строения Web-сервисов – определение сообщений, входящих в сервисы и исходящих из них. Сообщения всегда содержат две основные части: фактическую полезную нагрузку, относящуюся к бизнес-функции сообщения и контекстные данные (как, например, идентификация сообщения, транзакционные и сессионные ID, информация о безопасности и т.д.). Каждый протокол обмена сообщениями предоставляет место для контекстной информации: заголовков протокола SOAP и сервера сообщений JMS, "рабочей области" WebSphere и т.д. Проблема заключается в том, что не существует ни одного согласованного подхода или интерфейса API для этих отличающихся механизмов, и в большинстве реальных сред SOA вы столкнётесь больше, чем с одним протоколом обмена сообщениями.

Наиболее подходящее место для работы с такими разными механизмами и, в сущносности, позволяющее вам отображать одну структуру заголовка в другой, – это корпоративная сервисная шина ESB (это ещё одно преимущество шины ESB; ниже будет приведено по крайней мере ещё одно её достоинство). Возможно, это отображение нужно будет произвести вручную.

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

В начало

8. На скольких Web-сервисах мне остановиться?

Моя первая реакция на этот вопрос – посоветовать использовать методику, помогающую в процессе идентификации ваших сервисов. Это может быть подход SOMA (Сервисно-Ориентированное Моделирование и Архитектура), разработанный IBM Global Business Services. Вместе с IBM Rational®Unified Process (RUP) (унифицированный процесс IBM Rational) он, в целом, приблизит ваш подход к SOA.

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

И опять же, никто не скажет, как это сделать! Определение и разработка адекватных сервисов и степени их структурированности – это тяжелая работа аналитиков и IT-архитекторов.

В начало

9. Унаследованные приложения как потребители Web-сервисов

Большое внимание уделяется запуску существующей функциональной возможности в качестве сервиса. Реже обсуждается не менее важная проблема – способность существующих приложений использовать новые сервисы. Представим, что компания следует новым тенденциям SOA, создавая новые сервисы в течение долгого времени, и интегрируя их в существующее окружение. Одно из существующих приложений написано в RPG и запускается на системе IBM System i. Теперь, чтобы вызвать один из новых сервисов, этому приложению требуются изменения. Но разработчики, отвечающие за эту систему, не компетентны в работе с SOAP или XML, и они не имеют пакет Web-сервисов, основанных на RPG.

Самое простое решение этой проблемы – передача обработки SOAP и XML на ESB. Приложения, написанные, например, в COBOL или RPG могут обмениваться форматированными сообщениями со списками очередей WebSphere MQ. Такая поддержка легко устанавливается и используется сейчас достаточно часто. Продукт ESB, как, например, WebSphere ESB или WebSphere Message Broker могут получать информацию от MQ, преобразовывать её в XML, и, затем, работать с вызовом нового Web-сервиса.

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

В начало

10. Вся суть в деталях

Недавно я побывал в центре IBM Industry Solutions Center во Франции. Этот центр представляет решения IBM для разных областей, как, например, розничной торговли, здравоохранения, банковского дела. В презентациях не назывались конкретные IT-продукты, вместо этого были особо подчеркнуты конкретные коммерческие функции того или иного решения. Но в определённый момент, как бы мимоходом, было сказано:"Конечно, всё, что вы здесь видите, основано на SOA." Я не думаю, однако, что его каким-то образом беспокоил вопрос о том, как поддерживать заголовки WS-Addressing через многочисленные протоколы для асинхронных интеракций...

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

Итак, в следующий раз, когда ваш менеджер появится в вашем кабинете и предложит вам "создать одно из тех решений SOA, с которыми так легко работать", вы можете ответить, как отвечает мой коллега Грег Фларри в таких ситуациях: "Вся суть в деталях!"

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи Comment lines: Andre Tost: My top 10 Web services issues
  
  
• Какой стиль WSDL мне следует использовать? (Which style of WSDL should I use?)
  
  
• Web-совет: Использование полиморфизма как альтернатива xsd:choice (Web services tip: Use polymorphism as an alternative to xsd:choice)
  
  
• Привязка специализированных данных Web-сервисов, Часть 1: Как выбрать специализированную технологию отображения для Web-сервисов (Web Services Custom Data Binding, Part 1: How to choose a custom mapping technology for Web services)
  
  
• Скрытое воздействие WS-Addressing на SOAP (The hidden impact of WS-Addressing on SOAP)
  
  
• Модель программирования SOA для реализации Web-сервисов, Часть 4: Введение к Корпоративной Сервисной Шиной IBM (SOA programming model for implementing Web services, Part 4: An introduction to the IBM Enterprise Service Bus)
  
  

Об авторе

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• 1. Что же такое в действительности документальный/литеральный Web-сервис?
• 2. Web-сервисы медленно работают. Так ли это?
• 3. Моя XML-схема не работает с вашими продуктами!
• 4. А как насчёт UDDI? Пользуется ли им кто-нибудь?
• 5. Синхронизм Web-сервисов
• 6. Корпоративная сервисная шина ESB: быть или не быть?
• 7. Заголовки и контекстные данные
• 8. На скольких Web-сервисах мне остановиться?
• 9. Унаследованные приложения как потребители Web-сервисов
• 10. Вся суть в деталях
• Ресурсы
• Об авторе
• Комментарии