WCF: услуги Per-Call и Per-Session ... нужно убедить, что Per-Call стоит

Question

В настоящее время мы проводим обзор дизайна нашей службы WCF, и одна вещь, которая беспокоит меня, - это решение между услугами Per-Call и Per-Session. Я полагаю, что понимаю концепцию, лежащую в основе обоих, но на самом деле я не вижу преимущества услуг Per-Call. Я понимаю, что мотивация для использования услуг Per-Call заключается в том, что служба WCF удерживает объект сервера только в течение срока действия вызова, тем самым ограничивая время, в течение которого экземпляр службы удерживает дорогой ресурс, но для меня его гораздо проще использовать более OO-подобная модель Per-Session, где ваш экземпляр прокси-объекта всегда соответствует одному и тому же экземпляру объекта сервера и просто обрабатывает любые дорогостоящие ресурсы вручную.

Например, скажем, у меня есть служба CRUD с методами Добавить, Обновить, Удалить, Выбрать. Это может быть сделано как услуга Per-Call с подключением к базе данных («дорогой ресурс»), созданным в конструкторе объекта сервера. С другой стороны, это может быть служба Per-Session с созданием и закрытием соединения с базой данных в каждом из представленных методов CRUD.

Для меня это не отличается в плане ресурсов, и это делает модель программирования проще, поскольку клиент может быть уверен, что у него всегда один и тот же объект сервера для своих прокси: сохраняется любое дорогостоящее состояние, которое может быть между вызовами, и для методов не требуется никаких дополнительных параметров, чтобы определить, какие данные о состоянии должны быть извлечены службой, когда она снова создает новый объект сервера (как в случае Per-Call). Это похоже на использование классов и объектов, когда применяются те же проблемы управления ресурсами, но мы не создаем новые экземпляры объектов для каждого вызова метода, который мы имеем для объекта!

Так что же мне не хватает в модели Per-Call?

Спасибо

Answer 1

В терминах PerCall или PerSession нет ничего правильного или неправильного, только разные сильные и слабые стороны. Кажется, вы подходите с объектно-ориентированной точки зрения, где PerSession является естественным соответствием. Типичный подход SOA - это подход PerCall.

При прочих равных компромисс между производительностью и масштабируемостью. PerSession должен работать лучше, потому что объект не должен быть создан при последующих запросах. PerCall должен масштабироваться лучше, потому что единственные объекты, которые создаются на сервере, выполняют фактическую работу. Это не просто «дорогие» ресурсы, это все сессии, которые открыты на сервере. например в ситуации PerSession на сервере может быть создано 1000 объектов, но в настоящий момент только 100 находятся в состоянии вызова. Однако в ситуации PerCall для 100 вызовов создается только 100 объектов. Созданные объекты PerSession могут быть пустой тратой ресурсов и могут повлиять на способность обслуживать запросы под нагрузкой.

Если бы мой сервис был представлен публично, я бы также предпочел не доверять время жизни моего объекта капризам потребителей сервиса; Я бы беспокоился о том, что мой сервис может быть уничтожен вредоносным или ошибочным кодом.

Другим потенциальным преимуществом подхода PerCall является доступность системы. Возвращаясь к предыдущему примеру, в случае сбоя сервера PerSession все 1000 клиентов, у которых есть сеанс на этом сервере, потеряли бы свой сеанс и не смогли бы завершить свою работу. В ситуации PerCall единственные ошибки, которые могли бы произойти, были бы к 100 фактическим запросам, которые выполнялись (предполагая быстрое аварийное переключение). Остальные 900 клиентов могут быть перенаправлены на другой сервер при следующем вызове. Это может быть важно для SLA.

Answer 2

Короче говоря, ответом будет отсутствие состояния и масштабируемость.

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

Что касается дизайна, то хорошей практикой также является предоставление сервисного вызова независимым друг от друга. Таким образом, вы не полагаетесь на предыдущий вызов сервиса для настройки состояния объекта.