Принцип безгражданства услуги - Service statelessness principle

Безгражданство услуги это принцип конструкции который применяется в сервис-ориентированность парадигма дизайна, чтобы спроектировать масштабируемый Сервисы отделив их от их государственный данные по возможности.[1] Это приводит к сокращению ресурсов, потребляемых службой, как фактическое состояние. управление данными делегируется внешнему компоненту или архитектурному расширению. За счет снижения потребления ресурсов служба может надежно обрабатывать больше запросов.[2]

Цель

Взаимодействие любых двух программное обеспечение включает в себя отслеживание данных, связанных с взаимодействием, поскольку каждое последующее взаимодействие может зависеть от результата предыдущего взаимодействия. Это становится более важным в распределенных архитектурах, где клиент и сервер не существуют физически на одной машине. В двухуровневые архитектуры ответственность за отслеживание этих специфичных для взаимодействия данных возлагалась на полнофункциональных клиентов, что не было проблемой, поскольку каждый клиент обычно находился на отдельном компьютере.[3] Однако внутри n-уровневые архитектуры ответственность за управление государством перешла от клиента к приложению или веб сервер. Это привело к необходимости некоторых промежуточное ПО расширения управления состоянием, чтобы сервер мог обрабатывать несколько одновременных клиентских запросов, передавая фактические данные о состоянии конкретных действий таким расширениям, например хранение данных сеанса в базе данных в ASP .NET Приложения. Это помогает высвободить ресурсы памяти в пользу увеличения скорости отклика сервера и возможности обрабатывать больше клиентских запросов.

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

Заявление

Правильное применение безгражданства службы требует понимания различных типов информации о состоянии, которыми необходимо управлять.

Данные контекста

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

Бизнес-данные

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

Данные сеанса

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

Безгражданство и типы услуг

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

Службы задач

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

Коммунальные услуги

Эти виды услуг могут нуждаться в отслеживании состояния, чтобы обеспечить безгражданство для служб задач и сущностей.[4] С другой стороны, служебные услуги многократного использования, например служебная служба, которая действует как оболочка для устаревшая система, должен быть умеренно апатридом, чтобы он мог обрабатывать несколько одновременных запросов.

Юридические услуги

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

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

Соображения

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

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

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

Рекомендации

  1. ^ Погреб Войцеха, Сергиуш Стрыковский Электронное правительство на основе облачных вычислений и сервис-ориентированной архитектуры [Online]. Дата обращения: 19 апреля 2010 г.
  2. ^ Красные книги IBM Power Systems и SOA Synergy [Online]. Дата обращения: 21 апреля 2010 г.
  3. ^ «Тонкий клиент против архитектуры толстого клиента». RichHewlett.com. 2 декабря 2008 г.. Получено 10 марта 2019.
  4. ^ "Шаблон проектирования служб с отслеживанием состояния". Архивировано из оригинал 1 марта 2010 г.. Получено 28 февраля 2010.
  5. ^ Редди. и другие.Оценка устаревших активов в контексте перехода на SOA [Online] .pp 58. Дата обращения: 19 апреля 2010 г.

дальнейшее чтение