1.4.3.2.6 Веб-сервисы и виртуализация
Легкость, с которой веб-сервисы могут быть реализованы и возможность обращаться к ним локально или удаленно и независимо от платформы на которой работает клиент, привела к тому, что они были широко приняты администраторами систем как «агенты виртуализации», которые обеспечивают общие интерфейсы управления к различным ресурсам. Например, веб-сервиса может быть спроектирована так, чтобы "представлять" специфическое устройство или обычное приложение, принимая запросы управления и контроля через стандартизированные интерфейсы, с ресурсом общаясь посредством его «родного» интерфейса, и возвращая результат запрашивающей стороне опять в стандартном формате. Рис. 5 иллюстрирует, каким образом единая консоль может управлять совокупностью разнообразных ресурсов посредством уровня виртуализации на основе веб-сервис, каждая из которых предоставляет консоли стандартизированные интерфейсы для взаимодействия со связанным с ней ресурсом.
Рис.5 Виртуализация ресурсов с помощью Веб-сервисов
1.4.3.2.3 Понятие состояния сервисов и сервисы без состояний
Одними из ключевых понятий в теории слабосвязанных сервисов являются понятия «состояния сервиса» и «сервис без состояний». Дело в том, что преимущества слабой связи вытекают из факта, что клиент может использовать любой сервис, который способен выполнить его запрос. Если выбор клиента ограничен единственным сервисом, тогда преимущества слабой связи существенно уменьшаются. В простом случае калькулятора или сервиса отслеживания курса акций является очевидным, что, как только клиент запросил и получил информацию, транзакция закончена, и у клиента нет никакой особой нужды при последующих запросах на аналогичные услуги обращаться к тому же самому сервису. С этой точки зрения, клиент и сервис связаны слабо.
Однако, для более сложных запросов, которые требуют нескольких шагов, дизайн сервиса мог бы быть таким, что сервис сохраняет в своей локальной памяти некоторую информацию ("состояние") о первом шаге, предполагая использовать ее, когда клиент входит с ним в контакт на следующем шаге. В этом случае, сервис обладает состоянием (stateful service), и клиент должен возвратиться к тому же самому сервису при следующем шаге. Это может привести к задержкам, если много клиентов используют один и тот же сервис или даже к отказу в обслуживании, если узел, являющийся главным сервисом, аварийно прекращает работу между шагами.
Более правильный подход при разработке сервисов основан на «сервисах без состояний» (stateless). Это подразумевает что при многошаговой обработке запросов:
В конце каждого промежуточного шага сервис должно возвратить клиенту достаточную информацию о состоянии, чтобы дать возможность любому сервису с соответствующими свойствами идентифицировать и продолжить обслуживание.
Клиент должен передавать информацию о состоянии любому сервису на следующем шаге обработки запроса.
Выбранный сервис должен быть в состоянии принимать и обрабатывать информацию о состоянии, поставляемую клиентом, независимо от того обрабатывал ли он сам запрос на предыдущем шаге, или это делал другой сервис.
Рис. 4 показывает клиента, делающего запрос, для обработки которого требуется три шага и несколько сервисов, каждый из которого может быть способен к обработке любой части или всего запроса.
Рис. 4 Мношаговое взаимодействие клиента и сервисов
Сервис, который обрабатывает шаг 1, сохраняет детали обработки текущего запроса в базе данных, и возвращает запрашиваемую информацию клиенту, наряду с идентификатором запроса. Клиент может запросить подтверждение со стороны пользователя перед передачей этого идентификатора другому сервису, который использует его, чтобы отыскать информацию о состоянии в базе данных и инициализирует шаг 2. Этот сервис затем обновляет базу данных и возвращает дополнительную информацию клиенту. Наконец, клиент передает операционный идентификатор третьему сервису вместе с запросом на окончание всей обработки.
Большинство нетривиальных приложений требует доступа к некоторому количеству информации о состоянии, и вопрос не о том, должны ли состояния существовать, а о том, где они должны храниться. В подходе, описанном выше, состояние обработки запроса отделено от сервиса, который эту обработку осуществляет – обеспечивая, тем самым, слабую связь сервисов и клиента. Для того чтобы максимально уменьшить объем информации о состояниях, которой обмениваются клиент и сервисы, существенные детали об обработке запроса сохраняются в базе данных. При все участвующие сервисы должны быть в состоянии обратиться к базе данных и получить требуемую информации на основе идентификационного номера клиента/запроса, который можно легко передать от клиента сервисам.