Отсутствие состояния службы - это принцип проектирования, который применяется в парадигме проектирования, ориентированной на службы , для разработки масштабируемых служб, по возможности отделяя их от данных состояния . [1] Это приводит к сокращению ресурсов, потребляемых службой, поскольку фактическое управление данными о состоянии делегируется внешнему компоненту или архитектурному расширению. За счет снижения потребления ресурсов служба может надежно обрабатывать больше запросов. [2]
Цель
Взаимодействие любых двух программ включает отслеживание данных, специфичных для взаимодействия, поскольку каждое последующее взаимодействие может зависеть от результата предыдущего взаимодействия. Это становится более важным в распределенных архитектурах, где клиент и сервер не существуют физически на одном компьютере. В двухуровневых архитектурах ответственность за отслеживание этих специфичных для взаимодействия данных возлагалась на полнофункциональных клиентов, что не было проблемой, поскольку каждый клиент обычно находился на отдельном компьютере. [3] Однако в n-уровневых архитектурах ответственность за управление состоянием перешла от клиента к приложению или веб-серверу . Это привело к необходимости некоторых расширений управления состоянием промежуточного программного обеспечения, чтобы сервер мог обрабатывать несколько одновременных клиентских запросов, передавая фактические данные о состоянии конкретного действия таким расширениям, например, сохраняя данные сеанса в базе данных в приложениях ASP .NET . Это помогает освободить ресурсы памяти в пользу увеличения скорости отклика сервера и возможности обрабатывать больше клиентских запросов.
В составе службы службе может потребоваться сохранить данные, относящиеся к конкретным действиям, в памяти, пока она ожидает завершения обработки другой службой. Следовательно, в случае сервис-ориентированности эффективное управление данными, связанными с сервисной деятельностью, становится более важным, поскольку сервис-ориентация делает большой упор на повторное использование сервисов. Служба должна иметь дело не только с управлением данными состояния, которые создаются в результате взаимодействия с программой-потребителем в контексте конкретного бизнес-процесса, но также и в отношении взаимодействия с другими типами потребительских программ, которые являются частью несколько бизнес-процессов. По мере увеличения возможности повторного использования увеличиваются и накладные расходы на управление данными состояния. Принцип безгражданства службы предоставляет рекомендации в пользу того, чтобы сделать службу без сохранения состояния, перенеся накладные расходы на управление состоянием с служб на какой-либо другой внешний архитектурный компонент. Это дополнительно способствует общей масштабируемости сервис-ориентированного решения.
Заявление
Правильное применение безгражданства службы требует понимания различных типов информации о состоянии, которыми необходимо управлять.
Данные контекста
В составе службы может потребоваться, чтобы служба отслеживала данные, относящиеся к выполнению конкретной деятельности службы, которая обычно связана с координацией сообщений, например, с рабочими процессами , и соответствующими правилами, которые регулируют то, как правила должны интерпретироваться.
Бизнес-данные
Это данные, которые относятся к фактическому бизнес-процессу, выполняемому текущей деятельностью по обслуживанию, например, записи клиентов и т. Д., В некоторых случаях этот тип данных может потребоваться временно сохранить, особенно если он действует в качестве входных данных для следующего этапа в рамках сервисная деятельность.
Данные сеанса
Это относится к информации о соединении между службами, например, когда клиентские программы и службы обмениваются данными взад и вперед, может потребоваться некоторая корреляция, чтобы запустить последующий запрос только к конкретному экземпляру службы, поскольку только этот экземпляр знает о предыдущее сервисное взаимодействие.
Безгражданство и типы услуг
Принцип безгражданства службы может применяться в различной степени в зависимости от типа логики решения, заключенной в службе.
Службы задач
Сервисы задач содержат логику решения, специфичную для конкретного бизнес-процесса, и, следовательно, уровень их повторного использования низкий. Однако эти службы содержат контекстные данные (правила рабочего процесса) об активности службы, которые прямо пропорциональны размеру композиции службы, которая администрируется службой задач. В результате разработка таких сервисов с опциями отсрочки состояния сокращает объем используемой ими памяти и делает их более отзывчивыми.
Коммунальные услуги
Эти виды служб могут нуждаться в отслеживании состояния, чтобы обеспечить безгражданство для служб задач и сущностей. [4] С другой стороны, служебная служба с высокой степенью многократного использования, например служебная служба, которая действует как оболочка для унаследованной системы , должна быть умеренно без сохранения состояния, чтобы она могла обрабатывать несколько одновременных запросов.
Юридические услуги
Поскольку эти услуги не зависят от какого-либо конкретного бизнес-процесса, они считаются наиболее часто используемыми. Другим важным фактором является то, что они обрабатывают данные, относящиеся к бизнес-объектам, и поэтому требуют более высоких уровней безгражданства, чтобы они не были обременены отслеживанием бизнес-данных, которые им, возможно, потребуется сохранить для обеспечения требуемой функциональности.
Отсутствие состояния может быть достигнуто либо путем делегирования управления состоянием некоторому совместно используемому расширению архитектуры, например промежуточному продукту, который существует за пределами границы реализации службы, либо выделенному механизму, который существует внутри границы службы, например, выделенной базе данных. [5]
Соображения
Не всегда возможно предоставить специальный вариант отсрочки для каждой услуги, поскольку это явно требует дополнительных инвестиций . С другой стороны, использование опции отсрочки общего состояния может создать зависимость для сервиса, которая может препятствовать развитию сервиса.
Хранение и извлечение информации о состоянии могут непреднамеренно повлиять на время отклика службы, поскольку обе эти задачи могут оказаться вычислительно интенсивными, поскольку сначала данные необходимо преобразовать в собственный формат расширения хранилища, и наоборот, когда дело доходит до извлечения та же информация.
Разработка служб без сохранения состояния требует дополнительных усилий и времени, поскольку служба должна содержать логику, которая взаимодействует с расширениями отсрочки состояния. Это, в свою очередь, потребует дополнительного кода и тестирования.
Рекомендации
- ^ Войцех Cellary, Sergiusz Strykowski Электронное правительство Based на облачных вычислений и сервис-ориентированной архитектуры [Интернет] .Date доступ: 19 апреля 2010.
- ^ IBM Red Books Power Systems и SOA Synergy [Online]. Дата обращения: 21 апреля 2010 г.
- ^ «Тонкий клиент против архитектуры толстого клиента» . RichHewlett.com. 2 декабря 2008 . Проверено 10 марта 2019 .
- ^ «Шаблон проектирования служб с отслеживанием состояния» . Архивировано из оригинала 1 марта 2010 года . Проверено 28 февраля 2010 года .
- ^ Редди. и другие. Оценка устаревших активов в контексте перехода на SOA [Online] .pp 58. Дата обращения: 19 апреля 2010 г.
дальнейшее чтение
- Майкл Пулен. Эволюция принципов сервисной ориентации: безгражданство сервиса, часть 6 [Online]. Дата обращения: 19 апреля 2010 г.
- Мауро. и другие. Сервисно-ориентированная интеграция устройств - анализ шаблонов проектирования SOA. [Online], pp. 1–10, 2010 43-я Гавайская международная конференция по системным наукам, 2010 г. Дата обращения: 8 апреля 2010 г.