I ruoli che è possibile deployare sulla piattaforma Windows Azure sono di due tipi: web e worker. Il primo non è altro che un insieme di siti web che vengono automaticamente deployati e configurati su IIS della macchina virtuale. Il worker è invece adatto per attività da eseguire ad intervalli o per eseguire codice intensivo il cui lavoro non dipende da interazioni con l'utente attraverso un sito internet.
Quando si realizza un servizio WCF viene automatico pensare di ospitarlo attraverso il web role e il relativo file svc che rappresenta l'endpoint HTTP. Questo però non è necessariamente obbligatorio, perché anche un worker role può ospitare un servizio WCF o più in generale rispondere su HTTP/TCP. I motivi per cui non si voglia usare un web role per ospitare un servizio possono essere moltiplici: dalla necessità di interagire direttamente con il motore, alla necessità di voler "risparmiare" sul numero dei ruoli, aggregando attività e servizi sotto un unico ruolo.
Per poter raggiungere questo scopo occorre innanzitutto vedere lo script #286 dove si è visto come definire gli endpoint per un ruolo. In questo caso, siccome si vuole utilizzare il basicHttpBinding, l'endpoint dev'essere di tipo http, come nell'esempio seguente.
<?xml version="1.0" encoding="utf-8"?> <ServiceDefinition> <WorkerRole name="WCFWorkerRole" vmsize="Small"> <Endpoints> <InputEndpoint name="Service" protocol="http" port="80" /> </Endpoints> </WorkerRole> </ServiceDefinition>
A questo punto sul metodo Run del worker role si utilizza la classe ServiceHost per istanziare il motore che ascolta e processa le chiamate al servizio. Poiché le istanze dei ruoli possono essere molteplici e gli ip delle macchine virtuali sono assegnati dinamicamente, è necessario definire l'URI di ascolto del servizio, concatenando IP e al resto dell'URI.
public override void Run() { // Determino l'uri in base all'ip string address = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Service"].IPEndpoint.ToString(); Trace.WriteLine("Listening on " + address); // Avvio il servizio di ascolto ServiceHost host = new ServiceHost(typeof(ServiceTest), new Uri("http://" + address + "/TestService")); host.AddServiceEndpoint(typeof (ServiceTest), new BasicHttpBinding(), ""); host.Open(); }
Ora il servizio è pronto e si mette in ascolto all'avvio del worker role. E' necessario però fare un'ultima operazione. Per ascoltare sulla porta 80 il servizio necessita di diritti che il processo in cui gira il worker role normalmente non detiene, per cui è necessario utilizzare il tool netsh per darli e permettere al ServiceHost di mettersi in ascolto. Per questo scopo, siccome dobbiamo configurare questi permessi ad ogni avvio del ruolo, vengono in aiuto i task che possiamo eseguire automaticamente allo startup. Come visto nello script #284, occorre specificare l'exe da eseguire che nel caso specifico è una console application che occorre preparare.
<Startup> <Task commandLine="AzurePortDetector.exe" executionContext="elevated" taskType="background"> </Task> </Startup>
L'applicazione non fa altro che chiamare netsh creando l'uri di ascolto in base all'endpoint configurato nel worker role. Di seguito il codice che esegue tale configurazione.
static void Main(string[] args) { int port = RoleEnvironment.CurrentRoleInstance.InstanceEndpoints["Service"].IPEndpoint.Port; Process.Start("netsh", string.Format("http add urlacl url=http://+:{0}/TestService user=everyone listen=yes delegate=yes", port)); }
Una volta compilato occorre includere l'exe e il file .config come content all'interno del worker role. I passi sono molteplici, ma nell'allegato è possibile trovare un progetto completo di esempio dal quale è possibile partire. Occorre inoltre prestare attenzione al fatto che nel caso di molteplici istanze il balancer di Azure distribuirà le chiamate su tutti i servizi.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Creare un'applicazione React e configurare Tailwind CSS
Evitare (o ridurre) il repo-jacking sulle GitHub Actions
Supportare lo HierarchyID di Sql Server in Entity Framework 8
Potenziare Azure AI Search con la ricerca vettoriale
Utilizzare un service principal per accedere a Azure Container Registry
Utilizzare il nuovo modello GPT-4o con Azure OpenAI
Assegnare un valore di default a un parametro di una lambda in C#
Gestire domini wildcard in Azure Container Apps
Eseguire una query su SQL Azure tramite un workflow di GitHub
Modificare i metadati nell'head dell'HTML di una Blazor Web App
Eseguire operazioni sui blob con Azure Storage Actions
Eseguire query manipolando liste di tipi semplici con Entity Framework Core
I più letti di oggi
- Build 2016: segui con noi in live streaming!
- Build 2017: segui con noi tutte le novità mercoledì 10 e giovedì 11 maggio da Seattle!
- Microsoft Visual Studio Code: un nuovo editor gratuito per Windows, MacOSX e Linux per sviluppatori ASP.NET e Node.js
- Usare gRPC come infrastruttura per i nostri servizi web
- Utilizzare QuickGrid di Blazor con Entity Framework
- Realizzare una Progressive Web Application con Blazor e ASP.NET Core
- Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
- ASP.NET 4.5 e Visual Studio 2012 Live - Online
- Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
- Gestire la cancellazione di una richiesta in streaming da Blazor