Общие параметры WCF ClientMessageInspector, DispatchMessageInspector или альтернатива?
Я использую WCF только для служб данных (т. Е. Внутренних по отношению к приложению и очень скудных без состояния сеанса и т. Д.), Чтобы поддерживать масштабируемость нашего веб-приложения.
Нам нужно предоставить некоторые общие свойства для каждого вызова службы, который мы в настоящее время передаем все время. Наличие одного объекта запроса для каждого вызова не является идеальным, поскольку помимо этих общих свойств, остальные очень разнообразны и изменяются довольно часто в процессе разработки.
В данный момент я рассматриваю возможность использования пользовательских заголовков и clientmessageinspector для установки значений. Это самый простой рекомендуемый подход для этого сценария или есть лучший подход?
Более детально..
Красные точки ниже, где я не уверен, правильный подход (или как это сделать).
Что отправляется
Отправляемые данные представляют собой простой набор идентификаторов (3 или 4 для идентификатора пользователя, клиента и т. Д.) - все эти идентификаторы влияют на безопасность и производительность (в некоторых случаях он определяет, к какой базе данных обращаться).
Мы также расширим это, чтобы иметь более сложные разрешения - не требующиеся для работников Windows.
Вызывающей стороной будет либо веб-приложение, в котором они исходят из объекта сеанса, либо работник службы Windows, где они заполняются вручную.
Текущее мышление
В идеале, getinstance в рабочем процессе вызывающей стороны должен либо автоматически заполнять эти свойства объектом сеанса, либо в большей степени вручную вызовами службы Windows (разные конструкторы?).
Затем мы должны гарантировать, что эти параметры всегда доступны без какого-либо обдумывания или без постоянных ссылок в коде, чтобы составить контракт для каждой функции, которая его вызывает. В настоящее время у нас много сервисных вызовов (из-за масштаба / сложности приложения, а не из-за плохой инженерии:)), поэтому, поскольку это распространяется на сложные разрешения, становится немного трудно применять правила самодокументируемым способом.
Концептуально, сессия - это то, где вы должны позаботиться об этом в приложении, но сервисы на самом деле представляют собой просто слой доступа к данным (с отображением представления, просмотром страниц и защитой последнего вызова от вызовов репозитория), поэтому нам не нужно такого рода повторение или сложность, только ключевые поля идентификации и разрешения для включения в запросы.
Эта проблема
Это очень похоже на то, что мы должны делать с заголовками в вызовах, так как нам всегда нужны эти поля, но я немного не уверен в том, где set и get должны находиться в жизненном цикле конечной точки и клиентского интерфейса. Я также счастлив быть неправым об этом.
3 ответа
Я применил подобную архитектуру; в основном каждый клиентский вызов должен нести некоторую информацию о том, какую БД следует выбрать, идентификатор и т. д. И на стороне сервера эти параметры должны обрабатываться автоматически и храниться в словаре.
Я создал универсальный прокси-класс, чтобы обернуть клиентские прокси, чтобы добавить связанные заголовки к каждому вызову службы. Каждый разработчик, которому необходимо вызвать службу, использовал этот универсальный прокси-класс в своих вызовах.
В сфере обслуживания я реализовал DispatchMessageInspector как поведение конечной точки, где данные извлекаются из заголовков запроса и сохраняются в словаре. Словарь инициализируется внутри расширения OperationContext (IExtension<OperationContext>) и доступен во время обработки запроса.
Обратите внимание, что контекстный режим служб PerCall,
Из моего опыта использования инспекторов сообщений может быть довольно сложно изначально настроить и настроить, и в моем исследовании не было ни одного сайта, который охватывал бы все, мне приходилось выбирать фрагменты из нескольких разных мест и собирать их все вместе.
Вы должны подвергнуть сомнению то, что вы помещаете в заголовки. Это информация, которая должна быть доступна для вызываемого метода? Если это так, то вставка в заголовки - неправильная опция, так как каждый метод должен анализировать информацию обратно.
Тип информации, которая идеально подходит для этого, - это пользовательская аутентификация и / или пользовательские метаданные, связанные с вызовом WCF. В моем случае у меня был вызов WCF, инициированный автоматизированной службой, которая была ретранслирована на другие конечные точки WCF, это был идеальный сценарий для использования инспекторов сообщений, поскольку я смог добавить метаданные в заголовки в точках ретрансляции для последующего использования. конечная точка
Если вы просто хотите упаковать некоторые данные, которые являются общими для каждого вызова, я бы включил создание базового объекта данных, который имеет соответствующие свойства, а затем просто расширил бы его для более специализированных вызовов (конечная точка может гарантировать, что общие данные либо присутствует, либо принимает некоторые значения по умолчанию, если его нет). Для общих данных, требуемых каждой конечной точкой, использование инспекторов сообщений является излишним и потенциально нежизнеспособным.
Это может быть старый подход, но вы можете легко использовать CallContext из System.Runtime.Remoting.Messaging, Клиент может использовать реализацию IClientMessageInspector установить контекст вызова на вызов операции и реализацию IMessageInspector на сервере, чтобы получить общие данные из CallContext,