Конечные точки службы WCF и Windows Server

Question

Мне нужно разработать тему темы службы Windows Server Service Bus (да, Windows Server, а не Azure), и чтобы абстрагироваться от чтения, начать рабочий поток, ..., цикл и воспользоваться возможностями управления AppFabric, я имел следующую идею:

• Develop службы WCF
• определить конечную точку службы Windows Server Bus

и вопросы:

1. Издатель должен использовать Сервисный договор для отправки сообщений по этой теме?
2. Каким должен быть файл конфигурации?

Заранее спасибо.

Answer 1

Чтобы помочь будущим связанных с этим проблем здесь является необходимой конфигурацией

расширения, необходимые как в издателя и конфигурации абонентского:

<extensions> 
    <behaviorExtensions> 
    <add name="transportClientEndpointBehavior" type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Version=1.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> 
    </behaviorExtensions> 

    <bindingExtensions> 
    <add name="netMessagingBinding" type="Microsoft.ServiceBus.Messaging.Configuration.NetMessagingBindingCollectionElement, Microsoft.ServiceBus, Version=1.8.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> 
    </bindingExtensions> 
</extensions> 

Примечание: требуется сборка Microsoft.ServiceBus как в издателе, так и в подписчике. Пакет доступен в Nuget.

конфигурации на стороне подписчика:

<bindings> 
    <netMessagingBinding> 
    <binding name="messagingBinding" closeTimeout="00:03:00" openTimeout="00:03:00" receiveTimeout="00:03:00" sendTimeout="00:03:00" sessionIdleTimeout="00:01:00" prefetchCount="-1"> 
     <transportSettings batchFlushInterval="00:00:01" /> 
    </binding> 
    </netMessagingBinding> 
</bindings> 

<behaviors> 
    <endpointBehaviors> 
    <behavior name="securityBehavior"> 
     <messageInterceptorBehavior/> 
     <transportClientEndpointBehavior> 
     <tokenProvider> 
      <windowsAuthentication> 
      <stsUris> 
       <stsUri value="https://[SERVER]:9355/[NAMESPACE]" /> 
      </stsUris> 
      </windowsAuthentication> 
     </tokenProvider> 
     </transportClientEndpointBehavior> 
</behavior> 

<endpoint listenUri="sb://[SERVER]/[NAMESPACE]/[TOPIC]/Subscriptions/[SUBSCRIPTIONNAME]" 
       address="sb://[SERVER]/[NAMESPACE]/[TOPIC]" 
       behaviorConfiguration="securityBehavior" binding="netMessagingBinding" 
       bindingConfiguration="messagingBinding" name="InsuranceService" 
       contract="[WCF_CONTRACT_NAME]" /> 

конфигурации Издательство:

<bindings> 
    <netMessagingBinding> 
    <binding name="InsuranceService" closeTimeout="00:03:00" openTimeout="00:03:00" 
     receiveTimeout="00:03:00" sendTimeout="00:03:00" prefetchCount="-1" 
     sessionIdleTimeout="00:01:00"> 
     <transportSettings batchFlushInterval="00:00:01" /> 
    </binding> 
    </netMessagingBinding> 
</bindings> 

<behaviors> 
    <endpointBehaviors> 
    <behavior name="securityBehavior"> 
     <messageInterceptorBehavior/> 
     <transportClientEndpointBehavior> 
     <tokenProvider> 
      <windowsAuthentication> 
      <stsUris> 
       <stsUri value="https://[SERVER]:9355/[NAMESPACE]" /> 
      </stsUris> 
      </windowsAuthentication> 
     </tokenProvider> 
     </transportClientEndpointBehavior> 
    </behavior> 
    </endpointBehaviors> 
</behaviors> 

<client> 
    <endpoint address="sb://[SERVER]/[NAMESPACE]/[TOPIC]" 
    behaviorConfiguration="securityBehavior" binding="netMessagingBinding" 
    bindingConfiguration="InsuranceService" contract="PushVoucherService.ISubscriber" 
    name="InsuranceService" /> 
</client> 

Answer 2

Основная механика подключения WCF и служебной шины одинакова между версиями Azure и Server. You can use this post as a good starting point:

Главное отличие между этими двумя адресами заключается в адресах конечных точек и способах проверки подлинности (поскольку на сервере нет ACS). This post has some useful information on it.

Теперь, чтобы ответить на ваши вопросы конкретно:

• издатель мог технически толкать непосредственно к очередям автобусных услуг, но это лучше, если вы используете контракт. Проблема здесь заключается не в том, как нажимать, а в том, как создавать сообщение таким образом, чтобы служба могла его понять. Наличие контракта WCF позволит вам абстрагировать сериализацию/десериализацию.

• Для конфигурации типичным сценарием будет использование службы WCF, которая использует netMessagingBinding. Первое сообщение, о котором я упоминал, содержит информацию о конфигурации. Просто убедитесь, что вы обновили фрагменты адреса авторизации и конечной точки, чтобы соответствовать серверу служебной шины.