Выезд
Я не совсем уверен, что вы ищете или что вас больше всего интересует - вы можете уточнить?
Вам необходимо принять во внимание две части: клиент и сервер.
Сервер - это класс, который предоставляет методы, и его необходимо разместить где-то - в IIS или в собственном приложении. В вашем сценарии самостоятельного размещения вы создаете ServiceHost, в котором размещается один класс обслуживания. В службе определены 1-n конечных точек, которые «открыты» и прослушивают входящие запросы.
Сервер имеет несколько опций, которые влияют на то, как будет создан экземпляр класса обслуживания и как будут обрабатываться входящие запросы.
Одним свойством в ServiceContract является InstanceContextMode , которое может быть:
PerCall: для каждого входящего запроса создается новый экземпляр класса обслуживания, который обрабатывает вызов и затем завершается; обычно это рекомендуемая настройка PerSession: клиент устанавливает сеанс со службой, и экземпляр службы будет оставаться там до тех пор, пока клиент не завершит работу, и покажет это, или пока не истечет время ожидания неактивности Single: существует только один экземпляр класса обслуживания, который обрабатывает все запросы (singleton). Если синглтон является однопоточным, это означает, что запросы сериализуются и обрабатываются один за другим. Чтобы разрешить одновременное обслуживание нескольких запросов, синглтон должен поддерживать многопоточность, а все внутренние переменные и т. Д. Должны быть защищены от одновременного доступа (все становится намного сложнее и грязнее при множественном одновременном доступе)
Другой связанный параметр: ConcurrencyMode , который может быть Single (только один класс обслуживания может обрабатывать только один запрос; это рекомендуемая настройка для активации по вызову; это самая простая модель), Reentrant (что в основном совпадает с Single, за исключением того, что дуплексные обратные вызовы разрешены обратно - когда-либо использовались, если у вас есть дуплексные каналы), и Multiple, что является лучшим выбором, если Синглтон-сервис и требует производительности - но модель программирования становится намного сложнее и требовательнее.
Клиент также должен знать (по конфигурации или по коду), куда обращаться за услугой.
Что клиент в основном делает (а сервер делает это в обратном направлении), это следующие шаги:
- принимает один или несколько параметров (int, string, ваши собственные типы)
- затем сериализует эти параметры в сообщение
- обычно он шифрует и подписывает сообщение (необязательно)
- затем он передаст это сообщение на сервер по проводам
Между ними есть несколько дополнительных шагов - клиент может добавлять заголовки к сообщению, он может делать с ним другие действия, но это большинство шагов.
На сервере после получения сообщения выполняются следующие шаги:
- сообщение получено в конечной точке
- сообщение проверено, расшифровано и т. Д.
- сообщение десериализуется в параметры и объекты
- диспетчер выясняет (на основе информации сообщения, например, действия SOP), какой объект и какой метод вызывать
- этот метод затем вызывается и параметры сообщения передаются в
Как только сообщение было обработано на сервере, теперь сервер создает ответное сообщение и в основном отправляет его обратно тем же способом (сериализация, шифрование и т. Д.), И клиент получает его и интерпретирует его.
Марк