Hosting nel servizio di attivazione dei processi di Windows
Il servizio di attivazione dei processi di Windows (WAS, Windows Process Activation Service) gestisce l'attivazione e la durata dei processi di lavoro che contengono applicazioni che ospitano servizi Windows Communication Foundation (WCF). Il modello di processo WAS generalizza il modello di processo IIS 6.0 per il server HTTP rimuovendo la dipendenza da HTTP. Questo consente ai servizi WCF di utilizzare protocolli HTTP e non HTTP, ad esempio Net.TCP, in un ambiente host che supporta l'attivazione basata su messaggi e offre la possibilità di ospitare un gran numero di applicazioni in un determinato computer.
Per ulteriori informazioni su generazione di un servizio WCF eseguito nell'ambiente host WAS, vedere Procedura: ospitare un servizio WCF in WAS.
Il modello di processo WAS prevede diverse funzionalità che consentono una modalità di hosting delle applicazioni più efficace e gestibile e in cui le risorse vengono utilizzate in maniera efficiente:
L'attivazione basata su messaggi di applicazioni e applicazioni del processo di lavoro viene avviata e interrotta dinamicamente in risposta a elementi di lavoro in ingresso tramite protocolli di rete HTTP e non HTTP.
Efficace riciclo di applicazioni e processi di lavoro per mantenere l'integrità delle applicazioni in esecuzione.
Configurazione e gestione centralizzate delle applicazioni.
Consente alle applicazioni di sfruttare il modello di processo IIS senza richiedere il footprint di distribuzione di un'installazione IIS completa.
Per ulteriori informazioni su funzionalità WAS, vedere Hosting nel servizio di attivazione dei processi di Windows.
Windows Server AppFabric utilizza IIS 7.0 e il servizio Attivazione processo Windows (WAS, Windows Process Activation Service) per fornire un ambiente di hosting completo per i servizi NET4 WCF e WF. Tali vantaggi includono la gestione del ciclo di vita del processo, il riciclo del processo, l'hosting condiviso, una rapida protezione dall'errore, la gestione dell'opzione orfano processo, l'attivazione su richiesta e il monitoraggio dello stato. Per informazioni dettagliate, vedere Funzionalità di hosting di AppFabric e Concetti di hosting.
Elementi del modello di indirizzamento WAS
Le applicazioni hanno indirizzi URI (Uniform Resource Identifier), che sono le unità di codice la cui durata e il cui ambiente di esecuzione vengono gestiti dal server. Una singola istanza server WAS può accogliere numerose applicazioni diverse. I server organizzano le applicazioni in gruppi denominati siti. All'interno di un sito, le applicazioni vengono disposte in un ordine gerarchico che riflette la struttura degli URI che fungono da indirizzi esterni.
Gli indirizzi delle applicazioni sono composti di due parti: un prefisso URI di base e un indirizzo relativo specifico dell'applicazione (percorso), che, se uniti insieme, forniscono l'indirizzo esterno di un'applicazione. Il prefisso URI di base viene creato dall'associazione di sito e utilizzato per tutte le applicazioni presenti nel sito. Gli indirizzi delle applicazioni vengono quindi creati aggiungendo frammenti del percorso specifico dell'applicazione (ad esempio "/applicationOne") al prefisso URI di base (ad esempio "net.tcp://localhost"), per formare l'URI dell'applicazione completo.
Nella tabella seguente vengono illustrati diversi possibili scenari di indirizzamento per siti WAS con associazioni di sito HTTP e non HTTP.
| Scenario | Associazioni di sito | Percorso dell'applicazione | URI dell'applicazione di base |
|---|---|---|---|
Solo HTTP |
http: *:80:* |
/appTwo |
https://localhost/appTwo/ |
HTTP e non HTTP |
http: *:80:* net.tcp: 808:* |
/appTwo |
https://localhost/appTwo/ |
Solo non HTTP |
net.pipe: * |
/appThree |
net.pipe://appThree/ |
Possono essere indirizzati anche servizi e risorse all'interno di un'applicazione. All'interno di un'applicazione, le risorse dell'applicazione vengono indirizzate in relazione al percorso dell'applicazione di base. Ad esempio, si presupponga che un sito in un computer contoso.com abbia associazioni di sito per entrambi i protocolli HTTP e Net.TCP. Si presupponga inoltre che il sito contenga un'applicazione ubicata in /Billing, che espone un servizio in GetOrders.svc. Quindi, se il servizio GetOrders.svc espone un endpoint con un indirizzo relativo di SecureEndpoint, l'endpoint del servizio viene esposto nei due URI seguenti:
https://contoso.com/Billing/GetOrders.svc/SecureEndpoint
net.tcp://contoso.com/Billing/GetOrders.svc/SecureEndpoint
Runtime WAS
Le applicazioni vengono organizzate in siti a scopo di indirizzamento e gestione. In fase di esecuzione, le applicazioni vengono inoltre raggruppate in pool. Un pool di applicazioni può contenere molte applicazioni diverse di molti siti diversi. Tutte le applicazioni in un pool di applicazioni condividono una serie comune di caratteristiche runtime. Ad esempio, vengono eseguite tutte nella stessa versione di Common Language Runtime (CLR) e tutte condividono un'identità di processo comune. Ogni pool di applicazioni corrisponde a un'istanza di un processo di lavoro (w3wp.exe). Ogni applicazione gestita in esecuzione in un pool di applicazioni condiviso è isolata dalle altre applicazioni da un AppDomain CLR.
Vedere anche
Attività
Procedura: installare e configurare componenti di attivazione WCF
Procedura: ospitare un servizio WCF in WAS
Concetti
Architettura di attivazione WAS
Configurazione del servizio di attivazione dei processi di Windows da utilizzare con Windows Communication Foundation