 |
Понятие состояния сервисов и сервисы без состояний
|
|
|
|
Одними из ключевых понятий в теории слабосвязанных сервисов являются понятия «состояния сервиса» и «сервис без состояний». Дело в том, что преимущества слабой связи вытекают из факта, что клиент может использовать любой сервис, который способен выполнить его запрос. Если выбор клиента ограничен единственным сервисом, тогда преимущества слабой связи существенно уменьшаются. В простом случае калькулятора или сервиса отслеживания курса акций является очевидным, что, как только клиент запросил и получил информацию, транзакция закончена, и у клиента нет никакой особой нужды при последующих запросах на аналогичные услуги обращаться к тому же самому сервису. С этой точки зрения, клиент и сервис связаны слабо.
Однако, для более сложных запросов, которые требуют нескольких шагов, дизайн сервиса мог бы быть таким, что сервис сохраняет в своей локальной памяти некоторую информацию ("состояние") о первом шаге, предполагая использовать ее, когда клиент входит с ним в контакт на следующем шаге. В этом случае, сервис обладает состоянием (stateful service), и клиент должен возвратиться к тому же самому сервису при следующем шаге. Это может привести к задержкам, если много клиентов используют один и тот же сервис или даже к отказу в обслуживании, если узел, являющийся главным сервисом, аварийно прекращает работу между шагами.
Более правильный подход при разработке сервисов основан на «сервисах без состояний» (stateless). Это подразумевает что при многошаговой обработке запросов:
В конце каждого промежуточного шага сервис должно возвратить клиенту достаточную информацию о состоянии, чтобы дать возможность любому сервису с соответствующими свойствами идентифицировать и продолжить обслуживание.
|
|
|
Клиент должен передавать информацию о состоянии любому сервису на следующем шаге обработки запроса.
Выбранный сервис должен быть в состоянии принимать и обрабатывать информацию о состоянии, поставляемую клиентом, независимо от того обрабатывал ли он сам запрос на предыдущем шаге, или это делал другой сервис.
Рис. 4 показывает клиента, делающего запрос, для обработки которого требуется три шага и несколько сервисов, каждый из которого может быть способен к обработке любой части или всего запроса.
Рис. 4 Мношаговое взаимодействие клиента и сервисов
Сервис, который обрабатывает шаг 1, сохраняет детали обработки текущего запроса в базе данных, и возвращает запрашиваемую информацию клиенту, наряду с идентификатором запроса. Клиент может запросить подтверждение со стороны пользователя перед передачей этого идентификатора другому сервису, который использует его, чтобы отыскать информацию о состоянии в базе данных и инициализирует шаг 2. Этот сервис затем обновляет базу данных и возвращает дополнительную информацию клиенту. Наконец, клиент передает операционный идентификатор третьему сервису вместе с запросом на окончание всей обработки.
Большинство нетривиальных приложений требует доступа к некоторому количеству информации о состоянии, и вопрос не о том, должны ли состояния существовать, а о том, где они должны храниться. В подходе, описанном выше, состояние обработки запроса отделено от сервиса, который эту обработку осуществляет – обеспечивая, тем самым, слабую связь сервисов и клиента. Для того чтобы максимально уменьшить объем информации о состояниях, которой обмениваются клиент и сервисы, существенные детали об обработке запроса сохраняются в базе данных. При все участвующие сервисы должны быть в состоянии обратиться к базе данных и получить требуемую информации на основе идентификационного номера клиента/запроса, который можно легко передать от клиента сервисам.
|
|
|
Архитектура
Как показано на рисунке, можно выделить три инстанции, взаимодействующие в рамках веб-службы. Переведём их названия как
● заказчик (service requester);
● исполнитель (service provider);
● каталог (service broker).
Когда служба разработана, исполнитель регистрирует её в каталоге, где её могут найти потенциальные заказчики. Заказчик, найдя в каталоге подходящую службу, импортирует оттуда её WSDL-спецификацию и разрабатывает в соответствии с ней своё программное обеспечение. WSDL описывает формат запросов и ответов, которыми обмениваются заказчик и исполнитель в процессе работы. Для обеспечения взаимодействия используются следующие стандарты:
● XML: Расширяемый язык разметки, предназначенный для хранения и передачи структурированных данных;
● SOAP: Протокол обмена сообщениями на базе XML;
● WSDL: Язык описания внешних интерфейсов веб-службы на базе XML;
● UDDI: Универсальный интерфейс распознавания, описания и интеграции (Universal Discovery, Description and Integration). Каталог веб-служб и сведений о компаниях, предоставляющих веб-службы во всеобщее пользование или конкретным компаниям. Пока UDDI существуют, однако, только в небольших фирменных сетях и ещё не нашли широкого распространения в открытом интернете.
SOAP
SOAP (от англ. Simple Object Access Protocol — простой протокол доступа к объектам; вплоть до спецификации 1.2) — протокол обмена структурированными сообщениями в распределённой вычислительной среде. Первоначально SOAP предназначался в основном для реализации удалённого вызова процедур (RPC). Сейчас протокол используется для обмена произвольными сообщениями в формате XML, а не только для вызова процедур. Официальная спецификация последней версии 1.2 протокола никак не расшифровывает название SOAP. SOAP является расширением протокола XML-RPC.
SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTP, HTTPS и др. Однако его взаимодействие с каждым из этих протоколов имеет свои особенности, которые должны быть определены отдельно. Чаще всего SOAP используется поверх HTTP. SOAP является одним из стандартов, на которых базируются технологии веб-служб.
|
|
|
