Создание маршрутизатора WCF - Перенаправление в соответствии с заголовком Action
ОГЛАВЛЕНИЕ
Перенаправление в соответствии с заголовком Action
Сообщения, принимаемые на маршрутизаторе, имеют два адресных заголовка, которые удобно использовать при пересылке сообщений в надлежащую службу.
To Этот заголовок указывает имя конечной точки. Если заголовок соответствует целевой службе, а не маршрутизатору, он указывает адрес URL конечной точки службы, которой предназначено это сообщение.
Action Этот заголовок указывает операцию службы, которой предназначено данное сообщение, но он может не представлять допустимый адрес URL per se.
Однако, во многих случаях заголовок To соответствует адресу маршрутизатора, а не службе, оставляя заголовку Action роль более надежного источника информации о правильном пункте назначения этого сообщения. Вспомним, что заголовок Action строится на основе пространства имен контракта службы, имени контракта службы и имени операции. В предположении, что контракты не используются совместно разными типами служб, маршрутизатору достаточно этой информации для однозначного определения целевой службы. Рассмотрим следующие контракты служб, каждый из которых реализован на разных типах служб.
[ServiceContract(Namespace =
"http://www.thatindigogirl.com/samples/2008/01")]
public interface IServiceA {
[OperationContract]
string SendMessage(string msg);
}
[ServiceContract(Namespace =
"http://www.thatindigogirl.com/samples/2008/01")]
public interface IServiceB {
[OperationContract]
string SendMessage(string msg);
}
public class ServiceA : IServiceA {...}
public class ServiceB : IServiceB{...}
Из рис. 1 видно, что маршрутизатор может опираться на соответствие между пространствами имен контрактов для всех контрактов служб и конечными точками служб, которым должны быть направлены сообщения.
Рис. 1 Сопоставление пространства имен контракта конечной точке службы
Далее показано, как словарь, инициализированный таким образом, что каждая запись пространства имен контракта сопоставляется элементу конфигурации, указывающему, какие параметры конфигурации канала надлежит использовать.
static public IDictionary<string, string> RegistrationList =
new Dictionary<string, string>();
RegistrationList.Add(
"http://www.thatindigogirl.com/samples/2008/01/IServiceA",
"ServiceA");
RegistrationList.Add(
"http://www.thatindigogirl.com/samples/2008/01/IServiceB",
"ServiceB");
В таком случае код для инициализации канала будет выглядеть следующим образом.
static public IDictionary<string, string> RegistrationList =
new Dictionary<string, string>();
RegistrationList.Add(
"http://www.thatindigogirl.com/samples/2008/01/IServiceA",
"ServiceA");
RegistrationList.Add(
"http://www.thatindigogirl.com/samples/2008/01/IServiceB",
"ServiceB");
В этой ситуации имеется несколько важных зависимостей проекта, на которые следует обратить внимание.
- Для упрощения конфигурации и поддержки нескольких экземпляров маршрутизатора сопоставление контрактов службам будет находиться, скорее всего, в базе данных.
- Контракт службы может быть реализован на службах нескольких типов, только если сообщения можно обрабатывать любой службой, реализующей контракт.
- Если на ферме серверов имеется несколько экземпляров службы, конфигурация каждой конечной точки должна сопоставляться виртуальному адресу, который физический балансировщик нагрузки сможет затем распределить соответствующим образом.
- Не существует поддержки для сообщений, содержащих заголовок action, кроме поддержки сообщений для служб приложений.
Последний факт важен, поскольку если для служб приложений активированы безопасные или надежные сеансы, до отправки сообщений службы приложений осуществляется отправка дополнительных сообщений для установления этих сеансов. Эти сообщения используют заголовок Action для соответствующих протоколов и совершенно не зависят ни от какой службы приложений. Это означает, что для перенаправления сообщений необходимо использовать некоторую альтернативу заголовку Action.