Управляя сообщением
Более общий подход заключается в том, что ввести “посредника” между потребителем сервиса и и его провайдером. Перехват сообщения на уровне трафика для его обработки - не новая идея. Она уже используется в Web-мире на уровне как оборудования, так и софтвера для балансирования загрузки, ускорения, маршрутизации и кеширования (load balancing, acceleration, routing, and caching).
Как только вы поймете, что вы можете не только инспектировать и манипулировать контентом SOAP-сообщения, но и применяя WSDL, получить полное представление о формате этого сообщения, его операторов и конечных точек, возможности этого подхода становятся весьма интересными.
Например, рассмотрим простой случай использования сервиса с таблицей Employee salary из моей предыдущей статьи. Этот сервис на основе номера служащего (employee number) возвращает соответствующую информацию о зарплате. Представьте, что после нескольких месяцев применения, этот сервис начинает использоваться несколькими крупными подразделениями в компании, и многие люди просят, чтобы сервис предоставлял и информацию о комиссионных. Разработчики решают просить пользователей этого сервиса изменить входящее сообщение, которое ранее содержало только номер служащего, чтобы оно включало дополнительный параметр, <salary_type> (тип зарплаты), отмечая что именно: зарплата (salary), комиссионные или они оба должны быть возвращены. Таблица 1 показывает разницу между двумя этими форматами.
В идеальном мире, и провайдер, и пользователи этого Web-сервиса должны изменить свои среды одновременно, чтобы поддержать новый параметр, и вычислительная система должна быть модернизирована. В мире Web-сервисов, в котором у провайдеров и потребителей часто различные приоритеты, несвязанные расписания модернизаций и нередко трудно изменяемые инфраструктуры, такая (одновременная) реализация этих модернизаций часто затруднительна.
Решение? Есть немало возможностей на уровне управления, с которыми можно “понять” передаваемое сообщение. Одна из них заключается в том, чтобы “ловить” передаваемые сообщения со старой подписью и маршрутизировать их к старой реализации (old implementation) — простое решение на основе версий.
Другой подход заключается в том, чтобы преобразовать сообщения старого формата (old-style messages) без параметра <salary_type> в новый формат с включением значения по умолчанию для этого параметра. Такой тип абстракции реализации называется виртуализацией сервиса (service virtualization).
Результат этого подхода – провайдер сервиса может выполнять модернизацию по расписанию, независимому от потребителей сервиса. Еще лучше то, что процесс управления происходит на “лету” независимо от реализации, можно проводить модернизацию, даже если ваша внутренняя (back-end) среда состоит из разнородных реализаций Web-сервисов. Соответственно, потребители сервисов могут выбирать модернизацию или воспользоваться преимуществом новых функций по своему собственному расписанию.
Для такой инфраструктуры можно указать немало случаев применения. Что, если ваши клиенты требуют использования SOAP-сообщений, но вы не можете модернизировать вашу внутреннюю инфраструктуру для обработки двоичных данных? Вы можете использовать это подход для “посредничества” между протоколом входящего SOAP и двоичным протоколом в вашей внутренней инфраструктуре. Либо вы могли бы маршрутизировать сообщение к другим машинам на основе таких факторов, как тип клиента, посылающего сообщение, или необходимость учитывать расписания модернизаций этих машин.
И этот продуманный процесс, и появляющиеся прототипы реализаций вызвали ажиотаж в управлении Web-сервисами. Эта область является естественным дополнением для других появляющихся стандартов для Web-сервисов в областях надежности, безопасности, транзакций, grid-вычислений и даже управления бизнес-процессами. Но важно не забывать, что она не волшебная; эта область просто пользуется преимуществами и новациями характеристик присущих Web-сервисами.
