Как получить SOAP-XML сообщения прямого и callback вызова.

Ниже приведён код, на примере которого будет проводиться демонстрация. 

Примечания к коду:

1. Для прямого вызова будем выводить SOAP сообщение метода SayHello() контракта IMyService.
2. Для Callback вызова будем выводить SOAP сообщение метода Wellcome() контракта IMyCallback.
3. Используется привязка WSDualHttpBinding работающая с HTTP транспортом и передающая SOAP сообщения в текстовом виде с настройкой Security=None. Если у вас net.tcp привязка, тогда вам подойдёт только способ 1 и 2.

Сетевые шахматы (Network Chess). С исходным кодом на C# скачать бесплатно.

Все игры:

•  Симулятор игры "Жизнь" ("Game of life") на WPF
•  Классическая игра сапер (Minesweeper). Клон на С#,WPF
•  Сетевые шахматы (Network Chess)

Скачать проект.

Описание

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

Сразу скажу, что я не профессиональный игрок по шахматам и всех правил могу не знать. Дайте знать если я что то пропустил.

WCF System.Diagnostics логирование в реальном времени

Скачать проект.

Оглавление:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом. 

Введение

При разработке не раз была потребность понять, кто вызывает в конкретный момент мой сервис с клиента. Для этого (лично я) у сервиса в каждом методе добавлял Breakpoint и далее производил TestCase, выясняя из каких мест на клиенте производятся вызовы по Call Stack. Или представьте, когда происходит какая то проблема, не на вашем компьютере, влияющая на отзывчивость приложения и вам надо найти подозреваемого, а значит понять дело в сервере или клиенте путём анализа вызовов.
Для этого можно в приложении включить полную троссировку вызовов, воспользовавшись Trace Viewer (Using Service Trace Viewer for Viewing Correlated Traces and Troubleshooting) но он пишет все в лог файл, при этом требует каких то действий для настройки его на клиенте. Не спорю, его может быть достаточно, но там будет лог всех сообщений за время работы  клиента и в этой куче не сразу найдёшь что было вызвано в нужный интервал времени. Но хочется, что то на уровне - нажал - посмотрел вызовы, нашёл что надо - закрыл, отключил.

WCF Tracker в реальном времени.

Хочу представить альтернативный вариант, который, помимо возможности видеть все вызовы, имеет возможность ставить breakpoint.

Демонстрация работы:

WCF. Callback через BasicHttpBinding без дуплексной связи.

Оглавление:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом. 

В данной статье я хочу поделиться с вами примером того, как можно в WCF инициировать передачу данных с сервера на клиент используемые BasicHttpBinding в качестве привязки для взаимодействия.
Как вам должно быть известно, для того, что бы сервер выступа в качестве инициатора передачи данных на клиент используя WCF, ему надо использовать одну из схем ниже:

• Производить подключение к клиенту самостоятельно в ответ на вызов клиента (что выглядит глупо).
• Использовать Duplex связь, которая была создана специально для этого.
  

  [ServiceContract(CallbackContract = typeof(ICallback))]
  internal interface IMyContract
  {
  }

Duplex связь покрывает наши запросы, но есть одно "но" - привязка (Binding) должена поддерживать работу с использованием сессии. А BasicHttpBinding (на основе протокола HTTP) в силу своей природы не может поддерживать сессию (постоянное TCP соединение), так как работает по схеме "Запрос-ответ". Как же тогда поступить?

WSDualHttpBinding привязка.

Для работы через HTTP транспорт, с возможностью использования Duplex связи, специально был создан WSDualHttpBinding, который, для имитации сессии, используя HTTP заголовок, добавляя туда техническую информацию. А для обратного соединения сам создаёт подключение к клиенту. Замечу, что обратное соединение создаётся через WCF engine, и используется как при работе с любой другой привязкой, а не программистом, при первом подключении клиента. В качестве обратного соединения используются подключения на 80 (по умолчанию) порт клиента со стороны сервера, когда надо передать данные.
Все было бы хорошо, но в какой то момент, может возникнуть ситуация, когда клиент будет находиться за NAT, что приводит к невозможности подключиться к нему сервером. Почему? Читайте как работает NAT, он разрешает соединения из внутренней сети, но запрещает подключения из внешней (за маршрутизатором).  В это случае выходом может быть лишь привязки на основе протокола TCP (NetTcpBinding), в которые, для обратного и прямого соединения, используется одно TCP соединение. Но что, если нам нужно как то через HTTP производить обратный вызов клиента.

WCF service. С чего начать. Основные моменты создание службы.

Примеры, которые используются тут, можно скачать по ссылке:

Еще ссылки:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом.  

Оглавление статьи:

1. Что такое endpoint?
2.  Способы общения клиента с сервисом. 
3. Канал связи клиента и сервера.  
4. Надежные каналы связи (reliableSession).
5. Управление состоянием службы.
6. Управление созданием экземпляров службы.
7. Управление временем жизни экземпляра службы атрибутами контракта.
8. Режимы параллельной работы с экземплярами службы
9. Регулирование нагрузки.
10. Обработка исключений.  
11. Обработка исключений. Продолжение работы с посредником если используется HTTP транспорт.
12. Обработка исключений. Обертывание всех исключений в FaultException, используя IErrorHandler.
13. Закрытие канала посредника.
14. Использование общей сборки с контрактами.
15. Как убрать Web Reference. Использование общей сборки с контрактами.

Введение

В данной статье хочу описать настройки, которые разработчику следует знать  перед началом создания сервиса и клиента к нему. Я исхожу из того, что читатель уже имеет представление о WCF, пользовался какими то наработками, но не углублялся в настройки Binding и сервиса.

• Если вы являетесь новичком и хотели бы увидеть примеры служб и работу с ними, перед прочтением советую скачать и посмотреть примеры Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) Samples for .NET Framework 4/ созданные Microsoft.
• Из книг советую читать "Создание служб WCF (Джувел Леве)", на основе которой, а так же собственном опыте будет писаться данная статья.
• Для демонстрации можно использовать мои примеры из проекта, ссылка на который в начале статьи. 

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

Основные понятия и настройки.

Что такое endpoint?

Конечной точкой называется совокупность трех элементов:

1. Адрес сервиса. Подразумевается, что это URL, по которому располагается сам сервис.
2. Контракт сервиса.
3. Binding - содержит настройки работы с сервисом, протокол взаимодействия, Timeouts операций и т.д.

Способы общения клиента с сервисом.

В WCF существует три способа общения, которые обязательно надо знать:

1. Request-reply (запрос-ответ) - это когда с клиента делает вызов метода контракта Method(), текущий поток останавливается и ждет, пока сервер обработает ваш вызов и вернет ответ и управление. При этом все происходит в синхронном режиме, вы не сможете продолжить выполнение пока не получите ответа. Если происходит исключение на стороне сервера, то оно прилетит на клиента.
2. OneWay (или datagram) - данный способ отличается тем, что вызываемая метод контракта сторона (это может быть клиент, или сервер при дуплексной связи), не останавливается при вызове, а продолжает выполнение. Как если бы вызов практически сразу вернул результат. Иными словами мы в любом случае ожидаем доставки SOAP сообщения на противоположную сторону, но не ожидаем получения результата в ответ.
   Возможны ситуации, когда и при таком взаимодействии тоже произойдет блокировка потока на вызываемой стороне:
   
   • Когда при вызове, на сервере мы упираемся в какой то нагрузочный maxConcurrent* придел сервиса и наше сообщение с вызовом помещается в очередь на обслуживание. В этом случае мы будем ожидать пока вызов не встанет в обработку либо отвалимся по Timeout.
3. Duplex - это взаимодействие в обе стороны, когда клиент может вызывать методы сервера, а сервер, используя callback контракт, может вызывать методы клиента. Что бы это понять представьте чат, вы можете напечатать сообщение и отослать его на сервер, но что делать, если сообщение напишут вам? В этом случае сервер должен инициировать передачу на ваш компьютер. Как раз таки для этого он будет вызывать callback контракта, который задается отдельно, что бы уведомить вас.

Как реализуются данные схемы общения.

1. Request-reply. Данное поведение является "по умолчанию".
   
   

   [ServiceContract]
   internal interface IMyContract 

   {
       [OperationContract]
       void Method();
   }
   

2. OneWay. Для того, что бы метод контракта или callback контракта стал односторонним, достаточно указать IsOneWay = true.

   [ServiceContract]
   internal interface IMyContract
   {
       [OperationContract(IsOneWay = true)]
       void Method();
   }
   

3. Duplex. Для реализации используется свойство атрибута под названием CallbackContract.

   [ServiceContract(CallbackContract = typeof(ICallback))]
   internal interface IMyContract
   {
       [OperationContract]
       void Method1();
    
       [OperationContract(IsOneWay = true)]
       void MethodOneWay1();
   }
    
   [ServiceContract]
   internal interface ICallback
   {
       [OperationContract]
       void Method2();
    
       [OperationContract(IsOneWay = true)]
       void MethodOneWay2();
   }

Как отключить публикацию метаданных mex WCF сервисом.

Оглавление:

1. WCF service. С чего начать. Основные моменты создание службы. 
2. WCF. Callback через BasicHttpBinding без дуплексной связи.
3. Realtime WCF Tracker вызовов клиентского приложения.
4. Как отключить публикацию метаданных mex WCF сервисом. 

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

• Через HTTP-GET .
• И через специально подготовленную Endpoint для MEX, используя IMetadataExchange.

На MSDN есть две статьи, описывающие наоборот, оба процесса настройки. Поэтому можно опираться и на них:

• Publish Metadata for a Service Using a Configuration File
• Publish Metadata for a Service Using Code

1. Проверяем файл конфигурации сервера.
1.1 Ищем HTTP-GET

Открываем файл конфигурации, в котором хранятся настройки для ваших сервисов. И ищем раздел  <serviceBehaviors> 

<system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior name="SERVICEMETADATANAME">
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Если таковой имеется, тогда ищем tag <behavior/>, у которого внутри есть <serviceMetadata />. Значения атрибутов http(s)GetEnabled="True" говорят о том, что все <services />, у которых задано <service behaviorConfiguration="SERVICEMETADATANAME"  />, будут публиковать свои метаданные. Поэтому для того, что бы отключить публикацию достаточно задать:<serviceMetadata httpGetEnabled="false" httpsGetEnabled="false" />

ВНИМАНИЕ! Если используется пустое значение name <behavior name="">, это говорит о том, что данное поведение будет применено ко ВСЕМ Endpoint вне зависимости от того, где происходит инициализация ServiceHost. Ещё одно замечание, Endpoint не может работать одновременно в режиме httpEnabled="false" и httpsEnabled="true" поэтому надо менять оба параметра.

 Запускаем Web сервер. Если при обращении к сервисам получаете сообщение
"Metadata publishing for this service is currently disabled", значит все сделано правильно.