Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Questa sezione illustra come definire e implementare contratti WCF. Un contratto di servizio specifica ciò che un endpoint comunica con l'esterno. A livello più concreto, si tratta di una dichiarazione su un insieme di messaggi specifici organizzati in schemi di scambio di messaggi di base (MEPs), come richiesta/risposta, unidirezionale e duplex. Se un contratto di servizio è un set logico di scambi di messaggi, un'operazione del servizio è un singolo scambio di messaggi. Ad esempio, un'operazione Hello deve ovviamente accettare un messaggio (in modo che il chiamante possa annunciare il saluto) e può o meno restituire un messaggio (a seconda della cortesia dell'operazione).
Per altre informazioni sui contratti e altri concetti principali di Windows Communication Foundation (WCF), vedere Concetti fondamentali di Windows Communication Foundation. Questo argomento è incentrato sulla comprensione dei contratti di servizio. Per altre informazioni su come creare client che usano contratti di servizio per connettersi ai servizi, vedere Cenni preliminari sul client WCF.
Informazioni generali
In questo argomento viene fornito un orientamento concettuale di alto livello per la progettazione e l'implementazione di servizi WCF. Gli argomenti secondari forniscono informazioni più dettagliate sulle specifiche della progettazione e dell'implementazione. Prima di progettare e implementare l'applicazione WCF, è consigliabile:
Comprendere che cos'è un contratto di servizio, come funziona e come crearne uno.
Comprendere che i contratti contengono requisiti minimi di stato che la configurazione di runtime o l'ambiente di hosting potrebbero non supportare.
Contratti di assistenza
Un contratto di servizio specifica quanto segue:
Le operazioni esposte da un contratto.
Firma delle operazioni in termini di messaggi scambiati.
Tipi di dati di questi messaggi.
Posizione delle operazioni.
Protocolli e formati di serializzazione specifici usati per supportare la corretta comunicazione con il servizio.
Ad esempio, un contratto ordine di acquisto potrebbe avere un'operazione CreateOrder che accetta un input di tipi di informazioni sugli ordini e restituisce informazioni sull'esito positivo o negativo, incluso un identificatore dell'ordine. Potrebbe anche essere disponibile un'operazione GetOrderStatus che accetta un identificatore di ordine e restituisce informazioni sullo stato dell'ordine. Un contratto di servizio di questo tipo specifica:
Il contratto di ordine di acquisto è costituito da operazioni
CreateOrdereGetOrderStatus.Che le operazioni hanno specificato messaggi di input e messaggi di output.
Dati che questi messaggi possono trasportare.
Istruzioni categoriche sull'infrastruttura di comunicazione necessaria per elaborare correttamente i messaggi. Ad esempio, questi dettagli includono se e quali forme di sicurezza sono necessarie per stabilire una comunicazione corretta.
Per trasmettere queste informazioni ad altre applicazioni su molte piattaforme (incluse le piattaforme non Microsoft), i contratti di servizio XML vengono espressi pubblicamente in formati XML standard, ad esempio WSDL (Web Services Description Language ) e XML Schema (XSD), tra gli altri. Gli sviluppatori per molte piattaforme possono usare queste informazioni sul contratto pubblico per creare applicazioni in grado di comunicare con il servizio, sia perché comprendono il linguaggio della specifica e perché tali linguaggi sono progettati per consentire l'interoperabilità descrivendo i moduli, i formati e i protocolli pubblici supportati dal servizio. Per altre informazioni su come WCF gestisce questo tipo di informazioni, vedere Metadati.
I contratti possono essere espressi in molti modi e, mentre WSDL e XSD sono linguaggi eccellenti per descrivere i servizi in modo accessibile, sono linguaggi difficili da usare direttamente e sono semplicemente descrizioni di un servizio, non implementazioni del contratto di servizio. Pertanto, le applicazioni WCF usano attributi, interfacce e classi gestiti sia per definire la struttura di un servizio che per implementarla.
Il contratto risultante definito nei tipi gestiti può essere esportato come metadati, WSDL e XSD, quando necessario dai client o da altri implementatori del servizio. Il risultato è un modello di programmazione semplice che può essere descritto (usando metadati pubblici) per qualsiasi applicazione client. I dettagli dei messaggi SOAP sottostanti, le informazioni relative al trasporto e alla sicurezza e così via possono essere lasciati a WCF, che esegue automaticamente le conversioni necessarie da e verso il sistema del tipo di contratto di servizio al sistema di tipi XML.
Per altre informazioni sulla progettazione di contratti, vedere Progettazione di contratti di servizio. Per altre informazioni sull'implementazione dei contratti, vedere Implementazione di contratti di servizio.
Messaggi in primo piano e al centro
L'uso di interfacce gestite, classi e metodi per modellare le operazioni dei servizi è diretto per chi è abituato alle firme di metodo in stile RPC (Remote Procedure Call), in cui il passaggio di parametri in un metodo e la ricezione di valori restituiti è la modalità normale di richiesta di funzionalità da un oggetto o da un tipo di codice diverso. Ad esempio, i programmatori che usano linguaggi gestiti come Visual Basic e C++ COM possono applicare la conoscenza dell'approccio in stile RPC (usando oggetti o interfacce) alla creazione di contratti di servizio WCF senza riscontrare i problemi intrinseci nei sistemi a oggetti distribuiti in stile RPC. L'orientamento del servizio offre i vantaggi della programmazione orientata ai messaggi e ad accoppiamento libero, mantenendo al tempo stesso la facilità e la familiarità dell'esperienza di programmazione RPC.
Molti programmatori sono più a proprio agio con le interfacce di programmazione delle applicazioni orientate ai messaggi, ad esempio code di messaggi come Microsoft MSMQ, System.Messaging gli spazi dei nomi in .NET Framework o l'invio di codice XML non strutturato nelle richieste HTTP, per citarne alcuni. Per altre informazioni sulla programmazione a livello di messaggio, vedere Uso di contratti messaggi, programmazione del servizio Channel-Level e interoperabilità con applicazioni POX.
Informazioni sulla gerarchia dei requisiti
Un contratto di servizio raggruppa le operazioni; specifica il modello di scambio di messaggi, i tipi di messaggio e i tipi di dati che tali messaggi contengono; e indica le categorie di comportamento di runtime che un'implementazione deve avere per supportare il contratto( ad esempio, potrebbe essere necessario che i messaggi siano crittografati e firmati). Il contratto di servizio stesso non specifica esattamente come vengono soddisfatti questi requisiti, ma solo che devono essere. Il tipo di crittografia o il modo in cui un messaggio è firmato dipende dall'implementazione e dalla configurazione di un servizio conforme.
Si noti come il contratto richieda aspetti specifici dell'implementazione del contratto di servizio e della configurazione di runtime per aggiungere un comportamento. Set di requisiti che devono essere soddisfatti per esporre un servizio per l'uso si basa sul set di requisiti precedente. Se un contratto rende i requisiti dell'implementazione, un'implementazione può richiedere ancora più configurazioni e associazioni che consentono l'esecuzione del servizio. Infine, l'applicazione host deve supportare anche tutti i requisiti aggiunti dalla configurazione e dalle associazioni del servizio.
Questo processo di requisiti additivi è importante da tenere presente durante la progettazione, l'implementazione, la configurazione e l'hosting di un'applicazione di servizio Windows Communication Foundation (WCF). Ad esempio, il contratto può specificare che deve supportare una sessione. In tal caso, è necessario configurare l'associazione per supportare tale requisito contrattuale oppure l'implementazione del servizio non funzionerà. In alternativa, se il servizio richiede l'autenticazione integrata di Windows ed è ospitato in Internet Information Services (IIS), l'applicazione Web in cui risiede il servizio deve avere l'autenticazione integrata di Windows attivata e il supporto anonimo è disattivato. Per altre informazioni sulle funzionalità e sull'impatto dei diversi tipi di applicazioni host del servizio, vedere Servizi di hosting.