Ein typisches Szenario dafür wäre z.B. eine Azure Function, die einen bestehenden On-Premise Service aufrufen können soll. In diesem Artikel wird dies am Beispiel eines WCF Services erklärt und auf typische Probleme hingewiesen. In Azure wird dabei zunächst ein Relay-Namespace angelegt, z.B. myrelay.servicebus.windows.net. In diesem Namespace kann anschließend unter „WCF Relays“ ein neues Relay hinzugefügt werden. Dabei muss nur ein Name angegeben werden. Die Relay-Url setzt sich dann aus Namespace und Relay-Namen zusammen.
Beispiel-Url von Azure Relay: https://myrelay.servicebus.windows.net/myservice
Diese Url wird nun in der web.config des On-Premise Service als Service-Endpoint Adresse angegeben.
Authentifizierung gegenüber Azure Relay
Für die Authentifizierung gegenüber Azure mittels SharedAccessSignature wird das EndpointBehavior transportClientEndpointbehavior benötigt. In diesem Behavior wird der Key des Relays angegeben. In folgendem Beispiel ist dies der standardmäßig angelegte Key „RootManageSharedAccessKey“. Aus Sicherheitsgründen ist es aber empfehlenswert einen Key anzulegen, der ausschließlich „Listen“ Rechte hat.
<endpointBehaviors>
<behaviorname="sb">
<transportClientEndpointBehavior>
<tokenProvider>
<sharedAccessSignaturekeyName="RootManageSharedAccessKey"key="12345678…=" />
</tokenProvider>
</transportClientEndpointBehavior>
<webHttp />
</behavior>
</endpointBehaviors>
Das Behavior befindet sich in der Assembly Microsoft.ServiceBus.dll, die über das NuGet Paket „WindowsAzure.ServiceBus“ hinzugefügt werden kann. Das Behavior muss unter behaviorExtensions eintegragen werden:
<system.serviceModel>
<extensions>
<behaviorExtensions>
<addname="transportClientEndpointBehavior"type="Microsoft.ServiceBus.Configuration.TransportClientEndpointBehaviorElement, Microsoft.ServiceBus, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</behaviorExtensions>
…
</extensions>
…
</system.serviceModel>
Binding: webHttpRelayBinding
Als Binding muss das webHttpRelayBinding verwendet werden:
<webHttpRelayBinding>
<bindingname="RelayEndpointConfig"isDynamic="false"
maxReceivedMessageSize="2147483647">
<securityrelayClientAuthenticationType="RelayAccessToken"mode="Transport" />
<readerQuotasmaxDepth="2147483647"maxStringContentLength="2147483647"
maxArrayLength="2147483647"maxBytesPerRead="2147483647"
maxNameTableCharCount="2147483647" />
</binding>
</webHttpRelayBinding>
Die Service Adresse ist die Azure Relay-Adresse. Die vollständige Service-Definition sieht dann folgendermaßen aus:
<servicename="myService.Sample">
<endpointaddress="https://myrelay.servicebus.windows.net/myservice"
behaviorConfiguration="sb"binding="webHttpRelayBinding"
bindingConfiguration="RelayEndpointConfig"
contract="myService.Sample" />
</service>
Automatische Initialisierung
Damit sich der On-Premise nach einem Server- bzw. IIS-Neustart automatisch beim Azure Relay als Listener registriert, müssen die einzelnen Services (*.svc) für die applicationInitialization eingetragen werden:
<system.webServer>
…
<applicationInitializationdoAppInitAfterRestart="true">
<addinitializationPage="/MyService.svc" />
</applicationInitialization>
</system.webServer>
Hierbei ist wichtig, dass die Windows Server Komponente „“ installiert ist - was bei einer Standardinstallation von Windows Server nicht der Fall ist (Web Server (IIS) – Web Server – Application Development – Application Initializiation). Ohne diese Komponente wird die applicationInitialization-Konfiguration nicht berücksichtigt und auch keine Fehlermeldung im Eventlog ausgegeben.
Falls die Konfiguration korrekt durchgeführt wurde, müssten die Listener in Azure den Wert 1 haben (pro Service ein WCF Relay Listener):
Der On-Premise Service ist nun unter der Relay-Url erreichbar (aus Beispiel: https://myrelay.servicebus.windows.net/myservice) und kann z.B. aus Azure Functions heraus aufgerufen werden.
