Condividi tramite

Il presente articolo è stato tradotto automaticamente.

Contract-First Web Services

Sviluppo basato su schemi con Windows Communication Foundation

Christian Weyer & Buddhike de Silva

"Se dispone di otto ore per escludere verso il basso una struttura, È necessario dedicare sei aumento della nitidezza il axe" detto Abraham Lincoln. Questo vale per diverse fasi di progettazione del software nonché. Una struttura ben-progettati-tramite è il segreto dietro la maggior parte dei casi di successo software. Questo è vero soprattutto per quanto riguarda la progettazione di sistemi di comunicazione, ad esempio WS (Web Services). Attenzione deve essere pagato verso l'interfaccia formale utilizzata per la comunicazione. Questa interfaccia determina l'utilizzabilità e l'interoperabilità del sistema. Di conseguenza, la progettazione di questa interfaccia, che è anche detto il contratto--prime fasi del ciclo di vita di è significativo. In questo articolo verrà illustrato come progettare e sviluppare prima di contratti per i servizi basati su Windows Communication Foundation (WCF), che si occupa dell'area di servizi Web. Con i contratti di WS, due metodologie principali esistono--prima del codice di sviluppo contract-first e sviluppo Contract-First prima di schema di. L'attenzione verrà indicata principalmente da quest'ultimo.

Che cos'è Development prima del contratto?

Prima di contratto di progettazione e sviluppo non è qualcosa di nuovo. È stato introdotto da Bertrand Meyer formalmente come parte del suo progettazione del linguaggio di programmazione Eiffel pertanto è stato riportato in pubblicazioni tecniche diverse dall'198612. Di conseguenza, i contratti di comprensione da una prospettiva tecnologie scuola precedente e lo strumento possono essere utili per comprendere il motivo per cui si rivela utile.

Sebbene computer oggi eseguire tante cose da semplici operazioni aritmetiche per controllare i satelliti orbiting la terra, il concetto fondamentale di un computer di input / output non è modificato dopo l'aggiunta di computer inventato diciannovesimo secolo. Di conseguenza, gli ingegneri software ancora scrivere funzioni che accettano un input e di eseguono alcune funzionino e qualcosa di output. Queste funzioni vengono quindi utilizzate da altri punti. Un contratto di una funzione definisce le aspettative e gli impegni di tale funzione. In altre parole, parametri di input a una funzione possono considerare come le aspettative e i valori restituiti possono essere considerati come suo impegno. Solo gli utenti della funzione devono conoscere il contratto di utilizzarlo. Un esempio classico per questo è un file di intestazione c ++. Quando si desidera richiamare una funzione in un'altra libreria c ++, non sono interessati a esaminare l'implementazione, infatti, nella maggior parte dei casi, non si avrebbe accesso all'implementazione. Il file di testo intestazione indica a è e il compilatore sufficientemente su occorre richiamare tale funzione e che cosa verrà visualizzato al termine di tale.

File libreria dei tipi COM e ActiveX e interfacce in C#, sono solitamente come altri moduli di contratti. Poiché un contratto è un modo di definire le specifiche di interfaccia formale, accurata e verificabile in base ai dati astratto tipi dei componenti software, c'è una tendenza naturale a prima di creare i contratti. Ecco perché quasi ogni programmatore C/C ++ avvia un programma tramite la scrittura prima il file di intestazione.

Contratti di WS non sono alcuna eccezione. Lo sviluppatore di WS l'intento consiste nel condividere il sistema di input/output come un servizio Web--potenzialmente, limiti di piattaforma. Siamo che si è sentito parlare più volte prima che gli utenti del servizio Web devono non essere preoccupante sui dettagli di implementazione. Accesso al contratto dovrebbe essere sufficiente per qualcun altro di utilizzarlo. Poiché i servizi Web sono indipendenti dalla piattaforma, utilizziamo costrutti interoperabile e basato su standard come WSDL (Web Service Definition Language) e XML (XSD) per definire contratti. Modellazione di un contratto include la modellazione dati, i messaggi e l'interfaccia del servizio Web.

In primo luogo, è possibile modellare contratti di dati (vale a dire, strutture di dati) vengono utilizzati per passare dati tra i client e il servizio. I contratti di dati potrebbero essere tipi semplici o primitivi, ad esempio di stringa, numero intero di, doppie o tipi di complessi o specifiche per il dominio, ad esempio prodotti di, dipendente di o itinerario di.

Stile RPC/codificato utilizza i tipi definiti nello schema per definire le parti dei messaggi WSDL. Ciò rende difficile convalidare l'intero corpo SOAP a fronte dello schema, come solo una parte di tale rappresenta ciò che definita nello schema. Il resto proviene da WSDL. Consente inoltre di codificare il contenuto del corpo SOAP in base a regole di codifica sezione 5 definito dalla specifica SOAP 1.1. Anche se questo stile non è valido, non WS È conforme.

Stile RPC/Literal è simile a stile RPC/codificato. Tuttavia, a differenza di stile RPC/codificato, non codifica il corpo SOAP. Anche se questo stile è WS È conforme, è comunque difficile da convalidare.

Documento/letterale utilizza gli elementi per definire parti dei messaggi WSDL e non consente di codificare il contenuto del corpo. Questo Elimina entrambi i principali problemi negli stili illustrati in precedenza. Pertanto, questo è diventato lo stile WS È conforme ampiamente accettato.

Stile documento/letterale/Wrapped è stata introdotta da Microsoft. Lo stesso stile document/literal ’s, ma anche il wrapping del contenuto dell'elemento all'interno di un elemento autore il nome dell'operazione. Con il nome dell'operazione il corpo rende più semplice inviare i messaggi da un endpoint non HTTP. Ma soprattutto, è utile per essere conformi a WS-I-È standard che richiede un solo elemento figlio all'interno di elemento.

In genere, i servizi di Web interagire con i client tramite lo scambio di SOAP messaggi3. Modellazione di tali contratti di messaggio è il secondo passaggio dello sviluppo contract-first. Come a tale scopo varia a seconda che si preferisce utilizzare formato di messaggistica di SOAP:

  • RPC/codificato
  • RPC/Literal
  • Documento/letterale.
  • Documento/letterale/con

C'è anche un altro formato chiamato/documento codificato, ma è estremamente difficile individuare le implementazioni di utilizzarlo. Per questo articolo verranno lo stato attivo solo in un documento in un valore letterale/Wrapped poiché viene utilizzata più comunemente e si tratta inoltre di Web Services Interoperability Organization (WS-I-I) - compatibile con.

Definizione di un contratto di messaggio dispone di due aspetti. In primo luogo, è necessario definire la struttura del corpo SOAP. È possibile utilizzare XSD per eseguire questa operazione ed è inoltre possibile utilizzare contratti di dati definiti nel passaggio precedente. L'altri aspetti del contratto di messaggio sono definire la struttura di intestazioni soap. Le intestazioni per i messaggi sono definite in WSDL. Si tratta di una pratica comune utilizzare contratti di dati, configurati in passaggio 1, per definire ciò che va in tali intestazioni.

Dopo avere contratti di dati e il messaggio, è possibile modellare l'interfaccia definendo una o più operazioni disponibili nel servizio. Un contratto di operazione può utilizzare contratti di messaggio modellati nel secondo passaggio per la definire quali messaggi vengono scambiati durante tale operazione.

Oltre ai tre tipi di contratto primario--contratti dati, il messaggio e interfaccia--un contratto di servizio Web prevede inoltre un criterio, le associazioni e gli endpoint. Nella figura 1 vengono riepilogati per rappresentare gli elementi diversi in contratti di servizio Web vengono utilizzati i costrutti di WSDL/schema.


Nella figura 1 WSDL e XSD costrutti utilizzo

Vs prima del codice. Nome di schema

Come indicato nell'introduzione, vi sono due modi per modellare i contratti di-codice-prima di e prima di schema di. È importante comprendere entrambi allo scopo di scegliere quella adatta alle proprie esigenze.

Nell'approccio prima del codice, è possibile utilizzare costrutti di programmazione potenti contratto dichiarativo forniti da stack di servizio Web diverso (WCF, ASMX, JAX-WS e così via). In questo modo che è possibile modellare mediante il linguaggio di programmazione preferito in un editor. Pertanto, anziché l'apprendimento di costrutti di schemi WSDL e XML, è possibile utilizzare programmazione costrutti e tipi di dati che si ha già una sufficiente dimestichezza con. Lo stack WS sottostante si occupa del più pesanti per generare contratti WS nel relativo formato nativo (WSDL e XSD). Tali costrutti di programmazione dichiarativi rende molto più facili da realizzare un nuovo servizio Web da zero o esporre un'implementazione esistente come servizio.

Tuttavia, questa semplicità e praticità può causare problemi sottili di se utilizzata senza la consapevolezza dei costrutti di WSDL/XSD sottostanti utilizzato per rappresentare gli elementi che è modello. Sì, questo contraddicono le l'istruzione precedente informa che è in grado di sviluppare contratti di senza la conoscenza del WSDL e XSD. Ma, Sfortunatamente, la verità è le perdite di astrazione prima del codice. È opportuno tentare di comprendere il motivo da un punto di vista per .NET gli sviluppatori.

Quando si lavora con il codice, è ancora l'approccio mentale di modellazione di oggetti grafici utilizzando il sistema di tipo .NET. Ad esempio, l'approccio prima del codice non ostacolare è di utilizzare .NET idiosincrasie ad esempio System.Data.DataSet di o System.DateTimeOffset di . Questi tipi, infatti, in modo definito possono essere rappresentati in XML (e sono serializzabili XML). Ma un client non di .NET non dispone di accesso ai tipi stessi.

Un altro esempio è ciclici grafici. Come affermato in precedenza, prima del codice è necessario un approccio mentale orientato agli oggetti. Di conseguenza, tendono a modello di oggetti grafici e i grafici e potrebbero essere riferimenti ciclici. Si consideri la seguente struttura di dati con un riferimento circolare:

public class OrderItem
    {
        public Order Order { get; set; }
    }

    public class Order
    {
        public List<OrderItem> Items { get; set; }
    }

Un ordine di ha un elenco di OrderItems e ogni OrderItem ha un riferimento all'ordine padre. Se si tenta di rappresentare questo in XML, si colpisce un problema in quanto XML non dispone di una nozione di identità dell'oggetto e pertanto potrebbe essere necessario con qualcosa di simile al XML in figura 2, che verrebbero visualizzati sempre.

Nella figura 2 che rappresenta un grafico di oggetti con riferimenti ciclica in XML

<Order>
  <Items>
    <OrderItem>
      <Order>
        <Items>
          <OrderItem>
            ...
          </OrderItem>
        </Items>
      </Order>
    </OrderItem>
  </Items>
</Order>

Questo comportamento è dovuto alla differenza tra la natura gerarchica di documenti XML e il modello di grafico in oggetti grafici. Sfortunatamente, questo è qualcosa che non è facilmente rilevabili quando si segue un approccio prima del codice. Per risolvere il problema, è necessario attivare il riferimento tracciabilità in di DataContractSerializer mediante proprietà IsReference di DataContractAttribute. Ma, quindi si dovranno affrontare una serie di problemi diversa: in primo luogo, non sarebbe in grado di convalidare il documento XML rispetto a uno schema utilizzando una convalida dello schema standard API;in secondo luogo, il riferimento standard verifica meccanismo utilizzato dal serializzatore si basa su regole di codifica sezione 5 definite nella specifica SOAP 1.1. Queste regole sono obsolete in messaggi di stile document literal, che è lo standard specificato in WS-si specifiche.

Nonostante tali problemi nell'approccio prima del codice, si può comunque trovare è più semplice utilizzare costrutti invece di WSDL/XSD di programmazione di WCF crea purché si disponga di un po' conoscenza del modo in cui questi due mondi vengono mappati tra loro e funzionamento di serializzazione di WCF. Sebbene la discussione dei dettagli di quella Contract-First prima del codice esula dall'ambito di questo articolo, in quanto diagramma deve fornire una visualizzazione di 20.000 metri della relazione tra le più comunemente utilizzati costrutti di programmazione contratto WCF e costrutti di WSDL/XSD.

Nella figura 3 mapping tra comunemente utilizzati costrutti di programmazione dichiarativa in WCF e WSDL/schema costrutti

Il principale in alternativa alla progettazione prima di codice è Progettazione schema-primo, che utilizza WSDL e XSD direttamente per la modellazione. Questo è un modo più naturale di modellazione WS contratti come si utilizzano ora con costrutti nativi. Utilizzo di WSDL e XSD consente di modellare i contratti con un ulteriori contribuiva basato su XML, eliminando molti gli svantaggi nell'approccio prima del codice.

Tuttavia, se si desidera passare a questa traccia, è necessario conoscere piuttosto bene WSDL e XSD. Inoltre, poiché questi due mondi sono connessi, è impossibile concentrarsi completamente su WSDL e XSD o. Ad esempio, in caso di prima di schema a un certo punto sarà necessario generare codice da uno schema per modificare a livello di programmazione le strutture di dati. Oggi, diversi stack WS disponibili forniscono strumenti per questo (verrà illustrato gli strumenti disponibili per WCF più avanti in questo articolo). Tuttavia, a causa di enormity della specifica dello schema XML, questi strumenti supportano spesso solo un sottoinsieme di costrutti di schema. Di conseguenza, se si utilizzano questi costrutti non supportati nello schema, è possibile ancora eseguire dei problemi in termini di interoperabilità. Inoltre, determinati eventi modello di come restrizioni XSD non presente alcun equivalente dichiarativo molti Toolkit e potrebbero scomparire durante la generazione di codice.

Nell'approccio prima del codice, scrivere codice e consentire il toolkit di generare il WSDL/XSD. Di conseguenza, se si modifica un elemento nel codice, verrà riportata automaticamente negli schemi generati. Nell'approccio prima di schema, WSDL e XSD possono diventare non aggiornati senza un processo di modifica appropriate e disciplined gli sviluppatori del team. Inoltre, potrebbe essere necessario anche gli strumenti per modellare il WSDLs in quanto l'IDE potrebbe non dispone di tali funzionalità pronte per il.

In genere, sia prima del codice e prima di schema hanno vantaggi e svantaggi. Il metodo prima di schema dei vantaggi è soprattutto in scenari in cui si desidera utilizzare gli schemi esistenti, come che può avere state modellate durante molto prime fasi di ciclo di vita di sviluppo allo scopo di a un contratto con i cointeressati. Si tratta di una situazione comune in governo e ambienti di transazioni bancarie. Sarà inoltre necessario utilizzare gli schemi esistenti, se si siano creando applicazioni conformi con standard esistente, ad esempio Apri cronologia Alliance (OTA). La scelta tra i due approcci per la definizione del contratto deve essere basata inoltre dello scenario, risorse e le competenze disponibili in team. Ad esempio, se si sta creando un servizio WCF che non è necessario supportare client in esecuzione su altre piattaforme, probabilmente non si desidera prendere in considerazione un approccio prima di schema. Inoltre, se si ha familiarità piuttosto con contratto i costrutti di programmazione in WCF, conoscere bene il processo di serializzazione e hanno la possibilità di concentrarsi sulle strutture gerarchiche anziché oggetti grafici, è possibile seguire il codice di primo approccio e ottenere gli stessi risultati.

Viene così se si è deciso di passare con schema-primo approccio, ora, il resto di questo articolo illustrato come eseguire questa operazione per i servizi WCF.

Schema-primo approccio descrizione

L'approccio del primo schema dispone di cinque passaggi discreti come illustrato nella figura 4.


Nella figura 4 prima di schema processo di sviluppo prima di contratto

Vengono trattati i primi tre passaggi all'inizio di questo articolo. Di conseguenza, è opportuno solo riportarli e spostarsi sul successivo alcuni punti chiave.

Dati di modello del passaggio 1: Modello di strutture di dati utilizzate per trasferire dati tra il servizio e client che utilizzano uno schema XML. È possibile utilizzare l'editor di Visual Studio XSD o uno strumento simile come Altova XmlSpy o Studio XML liquidi.

Messaggi di modello del passaggio 2: Come è illustrato in precedenza, modello la struttura del corpo del messaggio utilizzando schema XML in questo passaggio. Si utilizzerà probabilmente le strutture di dati modellata nel passaggio 1 di seguito.

Interfaccia di modello del passaggio 3: In questo passaggio, è possibile modellare il contratto di interfaccia definendo le operazioni. Tuttavia, a differenza di questa procedura, qui è necessario utilizzare WSDL invece dello schema XML. Modifica WSDL non è disponibile in Visual Studio, ma è disponibile in alcuni prodotti come Altova XmlSpy.

Passaggio 4 genera il codice: Una volta che si è modellata i dati, il messaggi e le operazioni, è giunto il momento per generare il codice per rappresentare tali elementi di linguaggio di programmazione preferito. Le due sezioni successive verranno elaborare questa operazione con strumenti oggi disponibili per gli sviluppatori WCF.

Passaggio 5 iterazione contratto progettazione e codice la generazione: È difficile estremamente raggiungere la perfezione nel tentativo di uno. Una volta che si progetta il contratto, sarà necessario refactoring più volte fino a individuare le strutture ottimale che è necessario.

Utilizzando strumenti WCF fuori della casella per sviluppo contratto-prima del nome di schema

Per illustrare questo scenario, è ora creare un semplice servizio Web che dispone di un'operazione per recuperare un elenco di processi attivi nel computer host. Iniziando con il contratto dati, è un modello due tipi complessi.

  1. Di tipo complesso processo rappresenta un processo nel computer host.
  2. Di tipo complesso processList rappresenta un elenco di processi definiti dal tipo di processo.

Quindi abbiamo due elementi del modello esplorare e input/output di exploreResponse astrarre il corpo di messaggi. Come menzionato prima, sia compatibile con WS-si è necessario assicurarsi che il corpo del messaggio disponga di un solo elemento figlio all'interno dell'elemento di soap: body. Sia WCF che ASMX gestire questo eseguendo la creazione di un elemento wrapper con il nome di operazione. Se la convenzione di denominazione utilizzata per i messaggi di modello è diversa da di WCF standard, strumenti di generazione di codice genera classi di MessageContract per la richiesta e la risposta. È stata utilizzata la convenzione di denominazione WCF per nome gli elementi del messaggio e quindi dispone di un semplice modello di oggetto quando si genera il codice più avanti in questo processo.

Infine, si modello il file WSDL utilizzando uno strumento esterno. In questo caso, è stato utilizzato Altova XML Spy per Aiutaci con.

Figura 4, 5 e 6 contiene le definizioni di contratto dati, il messaggio e interfaccia citati in precedenza rispettivamente.

Nella figura 4 Data.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
           xmlns:ns1="http://schemas.thinktecture.com/contractfirst/2009/07/data" 
           targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/data" 
           elementFormDefault="qualified" 
           attributeFormDefault="unqualified"
           >
    <xs:complexType name="process">
        <xs:sequence>
            <xs:element name="pid" type="xs:int"/>
            <xs:element name="name" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>
    <xs:complexType name="processList">
        <xs:sequence>
            <xs:element name="process" type="ns1:process" maxOccurs="unbounded"/>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

Nella figura 5 Messages.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
           xmlns:data="http://schemas.thinktecture.com/contractfirst/2009/07/data"
           xmlns:ns1="http://schemas.thinktecture.com/contractfirst/2009/07/"
           targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/"
           elementFormDefault="qualified">
  <xs:import namespace="http://schemas.thinktecture.com/contractfirst/2009/07/data"
             schemaLocation="data.xsd"/>
  <xs:element name="explore">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="hostname" type="xs:string" nillable="true"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
  <xs:element name="exploreResponse">
    <xs:complexType>
      <xs:sequence>
        <xs:element name="processes" type="data:processList" nillable="true"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>  
</xs:schema>

Nella figura 6 ProcessExplorerService.wsdl

<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="https://schemas.xmlsoap.org/wsdl/" 
                  xmlns:soap="https://schemas.xmlsoap.org/wsdl/soap/" 
                  xmlns:http="https://schemas.xmlsoap.org/wsdl/http/" 
                  xmlns:xs="http://www.w3.org/2001/XMLSchema" 
                  xmlns:soapenc="https://schemas.xmlsoap.org/soap/encoding/" 
                  xmlns:mime="https://schemas.xmlsoap.org/wsdl/mime/" 
                  xmlns:tns="http://schemas.thinktecture.com/contractfirst/2009/07/" 
                  xmlns:soap12="https://schemas.xmlsoap.org/wsdl/soap12/" 
                  xmlns:msg="http://schemas.thinktecture.com/contractfirst/2009/07/" 
                  xmlns:ns="http://schemas.thinktecture.com/contractfirst/2009/07/data"
                  xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
                  targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/">
    <wsdl:types>
        <xs:schema targetNamespace="http://schemas.thinktecture.com/contractfirst/2009/07/" 
               elementFormDefault="qualified">
            <xs:import schemaLocation="messages.xsd"/>
        </xs:schema>
    </wsdl:types>
    <wsdl:message name="exploreRequestMessage">
        <wsdl:part name="parameters" element="msg:explore"/>    
    </wsdl:message>
    <wsdl:message name="exploreResponseMessage">
        <wsdl:part name="parameters" element="msg:exploreResponse"/>
    </wsdl:message>
    <wsdl:portType name="processExplorer">
        <wsdl:operation name="explore">      
            <wsdl:input wsaw:Action="http://schemas.thinktecture.com/contractfirst/2009/07/explore" 
                  message="tns:exploreRequestMessage"/>
            <wsdl:output wsaw:Action="http://schemas.thinktecture.com/contractfirst/2009/07/exploreResponse" 
                   message="tns:exploreResponseMessage"/>
        </wsdl:operation>
    </wsdl:portType>
    <wsdl:binding name="processExplorerHttpBinding" type="tns:processExplorer">
        <soap12:binding style="document" transport="https://schemas.xmlsoap.org/soap/http"/>
        <wsdl:operation name="explore">
            <soap12:operation 
        soapAction="http://schemas.thinktecture.com/contractfirst/2009/07/explore" 
        soapActionRequired="true"/>
            <wsdl:input>        
        <soap12:body use="literal"/>
            </wsdl:input>
            <wsdl:output>
                <soap12:body use="literal"/>
            </wsdl:output>
        </wsdl:operation>
    </wsdl:binding>
    <wsdl:service name="ProcessExplorerService">
        <wsdl:port name="processExplorerPort" binding="tns:processExplorerHttpBinding">
            <soap12:address location="http://localhost/processexplorer"/>
        </wsdl:port>
    </wsdl:service>
</wsdl:definitions>

Una volta pronti i contratti, si può avviare un prompt dei comandi di Visual Studio 2008 e generare codice C# per WCF tramite svcutil.exe, come illustrato nel codice riportato di seguito:

svcutil -noconfig -serializer:datacontractserializer -d:../ -
namespace:*,Thinktecture.Samples.ProcessExplorerService
ProcessExplorerService.wsdl Messages.xsd Data.xsd

Svcutil.exe viene utilizzato principalmente per generare il codice per il lato client. A differenza di wsdl.exe relativo predecessore, non è un'opzione per generare lo scheletro del lato del servizio. Di conseguenza, si noterà che il codice generato contiene il codice per il proxy sul lato client, che non è necessaria per l'implementazione del lato del servizio. Per l'implementazione di servizio, sarà necessario rimuovere questi tipi non rilevanti dal codice generato. Nel nostro caso di esempio, si tale scopo, rimozione di processExplorerClient e classi di processExplorerChannel dal codice generato. Una volta eseguita che operazione, è possibile implementare l'interfaccia generata tipo processExplorer semplicemente come illustrato nel progetto di ProcessExplorerService1 nella soluzione di esempio relativo.

Infine, prima di host è il servizio, è necessario regolare ServiceMetadataBehavior per disattivare la generazione automatica di WSDL e di runtime di generazione di WCF punto metadati al file WSDL statico. Di seguito specifica un percorso di metadati esterna nella configurazione della WCF:

<serviceMetadata httpGetEnabled="true"                            
externalMetadataLocation="..\contracts\processexplorerservice.wsdl"/>

Come si sarà notato, eseguendo lo sviluppo di prima di schema con questo approccio potrebbe essere un po' complessa in applicazioni reali.WSCF.Blue, il successore dello strumento di contratto prima (WSCF) di servizio Web gratuito, è stato creato per chiudere le lacune.

Un'analisi WSCF.blue

WSCF.Blue è un componente aggiuntivo gratuito di Visual Studio 2008.Sua funzione principale è l'attivazione di sviluppo di Contract-First prima di schema all'interno dell'IDE preferito.Modello di contratti di dati e il messaggio nell'editor schema XML di Visual Studio oppure in uno strumento disponibile gratuitamente come editor XML di liquido.È preferibile quest'ultimo poiché l'editor di schema disponibile in Visual studio 2008 fornisce il meno supporto modellazione rispetto a quella disponibile in Visual Studio 2005.Una volta pronti gli schemi è possibile utilizzare Creazione guidata di generazione WSDL del WSCF.blue per modellare l'interfaccia di servizio.Viene presenta un modo descrittivo per le operazioni dell'interfaccia del modello e nasconde i dettagli di costruzione WSDL effettivo.Questa procedura guidata può essere avviata dal clic con il pulsante destro del mouse sul file XSD contenente contratti di messaggio e selezionare Descrizione di interfaccia WSDL crea menu elemento dal menu di scelta rapida, come illustrato in di figura 7.


Nella figura 7 avvio il WSDL generazione guidata

Questa procedura guidata è costituito da alcuni passaggi di raccogliere informazioni sui contratti di operazione, che vengono si desidera che nell'interfaccia di servizio.La maggior parte delle operazioni è piuttosto semplice.Tuttavia, esistono alcune cose che potrebbero richiedere particolare attenzione nella procedura 2, 3 e 4.

I tipi definiti nello schema di file selezionato in Esplora risorse per avviare la procedura guidata è disponibile per la modellazione di WSDL.Tuttavia, in caso di altri tipi in altri file XSD, nel passaggio 2, è possibile importare tali, nonché come figura 8 Mostra.


Nella figura 8 importazione schema ulteriori documenti per la creazione guidata

Nel passaggio 3 è possibile modellare le operazioni.La procedura guidata include inoltre una funzionalità in grado di scorrere gli elementi del contratto di messaggio e di dedurre le operazioni.Questa funzionalità, tuttavia, funziona solo per i messaggi utilizzando le convenzioni di denominazione utilizzate nelle regole inferring della procedura guidata, come illustrato in di figura 9.


Nella figura 9 aggiungere o rimuovere operazioni per l' interfaccia

Durante il passaggio 4, è possibile associare i messaggi modellata in richieste e risposte delle operazioni.Se la funzionalità inferring di passaggio 3 è stata utilizzata, è possibile che questo mapping verrà eseguito automaticamente dalla procedura guidata.È inoltre possibile definire le intestazioni dei messaggi nei messaggi di richiesta e risposta durante questo passaggio (Figure 10).


Nella figura 10 definire messaggi di input/output in operazioni.

Infine, quando si completa la procedura guidata, il file WSDL generato verrà aggiunto al progetto.
Ora che il contratto viene modellato, è possibile utilizzare lo strumento di generazione del codice WSCF.blue per generare codice WCF in linguaggio del progetto.A destra fare clic sul file WSDL in Esplora soluzioni e selezionare la voce di menu Genera codice di servizio Web nella finestra di menu di scelta rapida per avviare lo strumento di generazione di codice (figura 11).


Nella figura 11. avvio l' utilità di generazione di codice

Finestra di dialogo generazione di codice consente di varie opzioni di generazione di codice.Ad esempio contiene massimo per le opzioni disponibili in svcutil.exe, come pure alcuni quelle aggiuntive: Stub sul lato server per generare codice lato server;Modificare la combinazione di maiuscole e minuscole per convertire i nomi di casi camel utilizzati nello schema per i nomi di casi Pascal senza influenzare la serializzazione;e separare i file per generare un file di codice per ogni tipo CLR generato per rappresentare gli elementi dello schema corrispondente (figura 12).Nella figura 13contiene un elenco completo delle opzioni disponibili nello strumento di generazione del codice.


Nella figura 12 di opzioni di generazione di codice

Nella figura 13 di opzioni di generazione di codice WSCF.blue

Opzione Descrizione
Proxy sul lato clientGenera il proxy del lato client per i consumer del servizio. Stub lato servizioGenera il codice sul lato servizio per gli implementatori di servizio.
Proprietà pubblicheEspone generato i membri della classe come proprietà pubbliche. Classi serializzabiliClassi generate verranno essere decorate con SerializableAttribute.
CollectionsUtilizza insieme <T> tipo per rappresentare tipi di insieme. Exposes generated class members as public properties.
Elenco <T> Utilizza elenco <T> tipo per rappresentare tipi di insieme. Generated classes will be decorated with SerializableAttribute.
Associazione datiGenera il codice necessario per associare le classi generate a componenti associabili a dati. Uses Identificatori di ordineGenera proprietà Order per ogni DataMemberAttribute utilizzato.
Identificatori di ordineGenera proprietà Order per ogni DataMemberAttribute utilizzato.
File separatiOgni classe generata viene inserito nel proprio file. Uses Metodi asincroniGenera la versione dell'operazione asincrona e OperationContextAttribute.AsyncPattern proprietà su true per indicare a WCF che presenti.
File separatiOgni classe generata viene inserito nel proprio file. Modificare la combinazione di maiuscole e minuscoleUtilizza Pascal quando le classi generate e le relative proprietà di denominazione senza alterare il processo di serializzazione.
Modalità di concorrenzaSpecifica il valore generato per ServiceBehaviorAttribute.ConcurrencyMode proprietà. Modalità del contesto di istanzaSpecifica il valore generato per ServiceBehaviorAttribute.InstanceContextMode proprietà.
Utilizzare il contesto di sincronizzazioneSpecifica il valore generato per ServiceBehaviorAttribute.UseSyncrhronizationContext proprietà. Generates the asynchronous version of the operation and sets the OperationContextAttribute.AsyncPatternproperty to Attivare l'endpoint in WSDLAggiunge un endpoint al servizio per esporre i file di metadati statici.Questa operazione è fondamentale quando si desidera esporre statico i documenti in servizi di hosting automatico dei metadati.
Nome del file di destinazioneNome del file di output.Se è attivato opzione file separato, questo parametro viene ignorato e i nomi di classe vengono utilizzati come nomi di file. Spazio dei nomi di destinazioneSpazio dei nomi CLR da utilizzare per i tipi generati.
Memorizza le impostazioniVengono memorizzate le opzioni di generazione di codice utilizzate più di recente.
Sovrascrivere i file esistentiSpecifica che è necessario consentire WSCF.blue sovrascrivere i file esistenti invece di creare nomi di file univoco per risolvere i conflitti.’S importante tenere presente che eventuali personalizzazioni apportate al codice generato verranno sovrascritto.Pertanto si consiglia di eseguire tali modifiche tramite classi parziali. La versione di WSCF.blue descritto in questo articolo (Beta 1, di 2009 25 luglio) non supporta ancora i file di configurazione l'unione.Di conseguenza, la configurazione necessaria per host il servizio viene creato in un file di output.config.Per spostare il contenuto del file del file Web.config o file app.config esigenze, è necessario un passaggio manuale.

La versione di WSCF.blue descritto in questo articolo (Beta 1, di 2009 25 luglio) non supporta ancora i file di configurazione l'unione.Di conseguenza, la configurazione necessaria per host il servizio viene creato in un file di output.config.Per spostare il contenuto del file del file Web.config o file app.config esigenze, è necessario un passaggio manuale.

Una volta che il file di configurazione è pronto, è possibile continuare aggiungere l'implementazione necessaria la classe di servizio generata.

Infine, è possibile modificare gli schemi in Visual Studio e utilizzare le funzionalità WSDL trip nella procedura guidata di generazione WSDL per modificare i contratti e rigenerare il codice.

Che cosa ’s Avanti

WSCF.Blue è rilasciato come un progetto open source e disponibile all'indirizzo wscfblue.codeplex.com.La versione beta corrente presenta alcune limitazioni che possano limitare le implementazioni di servizio Web di base ma più comuni.Ad esempio, la procedura di generazione WSDL guidata supporta attualmente associazione di base solo http.Inoltre, la generazione di codice corrente in WSCF.blue genera solo classi di XmlSerializable anziché classi di DataContractSerializable per supportare più ampia gamma di costrutti di schema.Il sito CodePlex è disponibile un elenco completo dei problemi noti e una mappa di strada dello strumento.

Una procedura dettagliata di come utilizzare WSCF è disponibile al thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough.Il documento è basato sul WSCF 0,6, i passaggi illustrati applicano a ugualmente

Conclusioni

Modellazione Contract-First basati su schema di servizi Web consente di modellare i contratti con un approccio mentale basato su XML.Tale processo pone l'accento sui tipi accettabili a livello universale e sulle strutture di dati gerarchici che possono essere rappresentate in formato XML.Strumento di supporto è essenziale per la creazione corretta di una piattaforma di servizi Web.WSCF.Blue estende la fuori la strumentazione di casella forniti da WCF per facilitare lo sviluppo prima del contratto di basata su schema per gli sviluppatori WCF.

Christian Weyer  è cofondatore e progettista principale di thinktecture ed è stato modellazione e l'implementazione di applicazioni distribuite con Java, COM, DCOM, COM +, servizi Web, WCF e altre tecnologie per molti anni.Christian è il suo inventore originale dello strumento Web Services contratto prima classico per. NET.Visualizzare in contatto con lui thinktecture.com/staff/christian di.

Buddhike de Silva  un progettazione fellow è basato in Australia.Prima di passare a Australia, era il tecnico responsabile in thinktecture.Buddhike è stato progettazione e implementazione di applicazioni distribuite per molti anni e ha inoltre è un collaboratore di tempo per i progetti WSCF/WSCF.blue.È possibile ottenere in contatto con lui in http://blogs.thinktecture.com/buddhike di.

1* Progettazione di Inc contratto*, Technical Report TR-EI-12/CO, Interactive Software Engineering., 1986.

2 http://se.ethz.ch/~Meyer/publications/computer/Contract.PDF

3 servizi REST tuttavia comunicano con i client tramite lo scambio di messaggi HTTP standard e seguono un paradigma completamente diverso.