• Artigo

Este artigo foi traduzido por máquina.

Serviços Web contract-first

Desenvolvimento baseado em esquema com o Windows Communication Foundation

Christian Weyer

"Se eu tivesse oito horas a fragmentação para baixo uma árvore, eu seria gasto seis nitidez o Machado" disse Abraham Lincoln. Isso é verdadeiro para diferentes fases em engenharia de software também. Ter um design bem-planejado-through é o segredo por trás da maioria das histórias de sucesso software. Isso é especialmente verdadeiro quando se trata a criação de sistemas de comunicação, como serviços da Web (WS). Atenção deve ser pago em direção a interface formal usada para comunicação. Essa interface determina a facilidade de uso e a interoperabilidade do sistema. Conseqüentemente, a criação desta interface--qual é também conhecido como o contrato--durante primeiras fases do ciclo de vida do é significativo. Neste artigo, mostraremos como criar e desenvolver primeiro contratos para os serviços com base em Windows Communication Foundation (WCF), enfocando a área de serviços da Web. Com WS contratos, duas metodologias principais existe-- de desenvolvimento contratar primeiro esquema primeiro e primeiro código desenvolvimento contratar primeiro. Nosso foco será principalmente no último.

O que é desenvolvimento contratar primeiro?

Contratar primeiro design e desenvolvimento não é algo novo. Ele foi introduzido por Bertrand Meyer formalmente como parte do seu design de linguagem de programação Eiffel e tem apareceram em várias publicações técnicas desde 1986 1, 2. Portanto, Noções básicas sobre contratos de uma perspectiva da escola antigo ferramenta/tecnologia podem ser útil para entender por que ele é útil.

Embora computadores hoje podem fazer muitas coisas de aritmética simples para controlar satélites orbiting nossa Terra, a idéia fundamental de uma máquina de entrada e saída não foi alterado desde a adição de máquinas inventadas no século 19. Conseqüentemente, os engenheiros de software ainda escrever funções que tomar alguma entrada e executarem alguns trabalho e algo de saída. Essas funções são então usadas de outros locais. Um contrato de uma função define as expectativas e compromissos dessa função. Em outras palavras, parâmetros de entrada para uma função podem ser considerados como suas expectativas e os valores de retorno podem ser considerados como seu compromisso. Os usuários da função apenas precisam saber sobre o contrato para usá-lo. Um exemplo clássico para isso é um arquivo de cabeçalho C++. Quando você deseja chamar uma função em outra biblioteca de C++, você não estiver interessado em observar a implementação--na verdade, na maioria das vezes, você poderia não tenha acesso à implementação. O arquivo de texto sem formatação de cabeçalho informa você e seu compilador suficiente sobre o que você precisa chamar essa função e o que você obterá na conclusão dele.

Arquivos de biblioteca de tipos COM e ActiveX e as interfaces translation from VPE for Csharp, normalmente são vistas como outras formas de contratos. Como um contrato é uma forma de definir especificações da interface formal, precisas, verificável com base nos dados abstrata tipos para componentes de software, há uma tendência natural para criar os contratos primeiro. É por isso que quase todos os programador C/C ++ inicia um programa escrevendo primeiro o arquivo de cabeçalho.

Contratos em WS não são exceção. Como desenvolvedor WS, sua intenção é compartilhar seu sistema de entrada/saída como um serviço da Web--potencialmente limites de plataforma. Estamos se que você já ouviu muitas vezes antes que os usuários do seu serviço da Web não devem ser preocupante sobre os detalhes de implementação. Ter acesso ao seu contrato deve ser suficiente para alguém para consumi-lo. Como serviços da Web são independentes de plataforma, usamos interoperáveis, baseada em padrões, construções como WSDL (Web Service Definition Language) e esquema XML (XSD) para definir contratos. Um contrato de modelagem envolve a modelagem de dados, mensagens e a interface do seu serviço da Web.

Primeiro, você modelar seus contratos de dados (ou seja, estruturas de dados) que são usados para passar dados entre os clientes e o serviço. Contratos de dados ou pode ser tipos primitivos ou simples, como de seqüência de caracteres , de número inteiro, de dupla de ou tipos complexos ou específicas de domínio, como de produto , de funcionário ou de itinerário.

Estilo RPC/codificado usa tipos definidos no esquema para definir as partes de mensagens WSDL. Isso dificulta validar o corpo SOAP inteiro contra o esquema, como apenas uma parte de ele representa que definido no esquema. O restante é proveniente do WSDL. Ele também codifica o conteúdo do corpo SOAP de acordo com regras de codificação seção 5 definido pela especificação SOAP 1.1. Embora esse estilo seja legal, isso não é compatível WS-I-com.

Estilo RPC/literal é bastante semelhante ao estilo RPC/codificado. No entanto, ao contrário do estilo RPC/codificado, ele não codifica o corpo SOAP. Embora esse estilo for WS-I-compatível, é difícil ainda validar.

Documento/literal usa elementos para definir partes de mensagens do WSDL e não codifica o conteúdo do corpo. Isso elimina ambos os principais problemas em estilos discutidos anteriormente. Assim, isso tornou o estilo de WS eu-compatível amplamente aceito.

Estilo de documento/literal/Wrapped foi introduzido pela Microsoft. Ele ’s o mesmo estilo de documento/literal, mas ele também envolve o conteúdo do elemento dentro de um elemento criado pelo nome da operação. Com o nome de operação no corpo torna mais fácil distribuir mensagens de um ponto de extremidade não-HTTP. Mas o mais importante, ele ajuda a ser compatível com o WS-padrão, que exige apenas um elemento filho dentro do elemento.

Normalmente, serviços da Web interagem com seus clientes trocando SOAP mensagens 3. Esses contratos de mensagem de modelagem é a segunda etapa do desenvolvimento contratar primeiro. Como fazer isso depende de qual SOAP formato de mensagens que você prefere usar:

  • RPC/codificado
  • RPC/literal
  • Documento/literal
  • Documento/literal/quebrado

Também há outro formato, chamado documento/codificado, mas é extremamente difícil localizar implementações usá-lo. Neste artigo, vamos foco somente no documento/literal/Wrapped porque ele é o mais comumente usado e é também Web Services Interoperability Organization (WS-I) - compatível.

Definir um contrato de mensagem tem dois aspectos. Primeiro, ele deve definir a estrutura do corpo SOAP. Você pode usar o XSD para fazer isso e você também pode usar contratos de dados definidos na etapa anterior. Outro aspecto do contrato da mensagem é definir a estrutura de cabeçalhos soap. Cabeçalhos de suas mensagens são definidos no WSDL. É uma prática comum usar contratos de dados, modelados na etapa um, para definir o que acontece nesses cabeçalhos.

Depois de ter seus contratos de dados e a mensagem, você pode modelar sua interface, definindo uma ou mais operações disponíveis no serviço. Um contrato de operação pode usar contratos de mensagem modelados na segunda etapa para definir quais mensagens são trocadas durante essa operação.

Em adição aos três tipos de contrato principal--contratos de dados, a mensagem e interface--um contrato de serviço da Web também tem uma diretiva, as ligações e pontos de extremidade. A Figura 1 resume quais WSDL/esquema construções são usadas para representar diferentes artefatos em contratos de serviço da Web.


A Figura 1 WSDL e uso de construções XSD

Código primeiro vs. Nome de esquema

Como mencionado na introdução, há duas maneiras para modelar seus contratos - primeiro código de e de esquema primeiro. É importante compreender ambos para escolher o que atenda às suas necessidades.

Na abordagem de código primeiro, você tem a capacidade de usar construções de programação poderosa contrato declarativa fornecidas pelo diferentes pilhas de serviço da Web (WCF, ASMX, JAX WS e assim por diante). Dessa forma você pode modelá-los usando sua linguagem de programação favorita em seu editor de favorito. Portanto, em vez de aprendizado construções WSDL e esquema XML, você pode usar programação construções e tipos de dados que você já estiver familiarizado com. A pilha de WS subjacente cuida do processamento mais pesado para gerar contratos de WS em seu formato nativo (WSDL e XSD). Essas construções de programação declarativas torna muito mais fácil reunir um novo serviço da Web do zero ou expor uma implementação existente como um serviço.

No entanto, essa simplicidade e conveniência podem levar a problemas sutis se empregado sem o conhecimento das construções WSDL/XSD subjacentes usado para representar os artefatos que você modelar. Sim, isso contradiz a instrução acima sobre ser capaz de desenvolver seus contratos sem o conhecimento do WSDL e XSD. Mas, infelizmente, a verdade é os vazamentos de abstração de código primeiro. Vamos tentar entender o porquê de um ponto de vista do .NET desenvolvedor.

Quando você estiver trabalhando com o código, você ainda tem o hábito de gráficos de objeto usando o sistema de tipo .NET de modelagem. Por exemplo, a abordagem de código primeiro não prejudica você de usar Idiossincrasias do .NET como de System.Data.DataSet ou System.DateTimeOffset. Esses tipos definitivamente podem ser representados em XML (e eles são serializáveis de XML). Mas um cliente não-.NET não tem acesso aos mesmos tipos.

Outro bom exemplo é cíclicas gráficos. Como mencionado anteriormente, com código primeiro você ainda tem um pensamento orientado a objeto. Conseqüentemente, tendem a gráficos de objeto de modelo e esses gráficos também podem ter referências cíclicas. Considere a seguinte estrutura de dados com uma referência cíclica:

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

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

Um pedido tem uma lista de do OrderItems e cada ItemPedido tem uma referência ao pai do pedido. Se você tentar representar isso em XML, você acerta um problema em que o XML não tenha uma noção de identidade do objeto e para que você pode acabar com algo semelhante ao XML no Figura 2, que deve ir para sempre.

Figura 2 representando um gráfico de objeto com referências cíclico no XML

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

Esse comportamento é devido à diferença entre a natureza hierárquica de documentos XML e o modelo de gráfico em gráficos de objeto. Infelizmente, isso é algo que não é facilmente podem ser detectados quando você estiver seguindo um método de código primeiro. Para corrigir isso, você precisa ativar o acompanhamento no DataContractSerializerIsReference propriedade do DataContractAttribute por meio de referência. Mas, em seguida, você enfrentará um conjunto diferente de problemas: primeiro, você não poderá validar o documento XML com base em um esquema usando uma validação de esquema padrão API;em segundo lugar, a referência padrão usado pelo serializador de mecanismo de controle é baseada em regras de codificação seção 5 definidas na especificação SOAP 1.1. Essas regras são preteridas no documento/literal estilo mensagens, que é o padrão especificado no WS-I especificações.

Apesar desses problemas na abordagem de código primeiro, você pode encontrar ainda mais fácil de usar construções em vez de WSDL/XSD de programação WCF ele constrói, contanto que você tenha um pouco conhecimento de como esses dois mundos são mapeados para si e como funciona a serialização do WCF. Embora discutindo os detalhes da abordagem de contratar primeiro código primeiro está além do escopo deste artigo, o seguinte diagrama deve fornecer a você uma exibição de 20.000 pé da relação entre as mais comumente usadas construções de programação WCF contrato e constrói WSDL/XSD.

Figura 3 mapeamento entre mais usados construções de programação declarativa no WCF e WSDL/esquema construção

A alternativa principal para o código primeiro design é design primeiro esquema, que usa o WSDL e XSD diretamente para a modelagem. Isso é uma forma mais natural de WS contratos de modelagem como você está lidando com construções nativas agora. Uso de WSDL e XSD permite modelar seus contratos com um pensamento centrado em XML mais, eliminando muitas das limitações na abordagem de código primeiro.

No entanto, se você deseja ir para baixo esta faixa, você precisa saber muito bem WSDL e XSD. Além disso, como esses dois mundos estão conectados, você não é possível focalizar completamente WSDL e XSD ou. Por exemplo, na abordagem do primeiro esquema, em algum momento você terá que gerar código do seu esquema para manipular programaticamente as estruturas de dados. Pilhas de WS diferentes disponíveis hoje fornecem ferramentas para isso (abordaremos as ferramentas disponíveis para o WCF neste artigo). Entretanto, oferecem devido a enormidade da especificação de esquema XML, essas ferramentas geralmente somente suporte um subconjunto das construções de esquema. Conseqüentemente, se você usar essas construções sem suporte no seu esquema, você ainda pode executar em problemas em termos de interoperabilidade. Além disso, certas coisas modelo como restrições de XSD não têm nenhum declarativa equivalente no vários kits de ferramentas e assim pode desaparecer durante a geração de código.

A abordagem de código primeiro, você escrever código e permitir que o Toolkit gerar WSDL/XSD para você. Conseqüentemente, se você alterar algo em seu código, ele serão automaticamente refletido em esquemas gerados. Abordagem primeiro esquema, WSDL e XSD podem se tornar obsoleto sem um processo de alteração adequado e disciplined os desenvolvedores a equipe. Além disso, talvez também seja necessário as ferramentas para modelar seus WSDLs como o IDE não pode ter esses recursos fora da caixa.

Geralmente, código primeiro e o primeiro esquema têm prós e contras. O método primeiro esquema beneficia você especialmente em cenários em que você precisará usar esquemas existentes, como eles podem ter sido estabelecidos durante muito primeiros estágios do ciclo de vida do desenvolvimento para chegar em um contrato com os interessados. Isso é uma situação comum no governo e transações bancárias ambientes. Talvez também seja necessário usar esquemas existentes se você estiver criando aplicativos compatíveis com padrões de indústria existentes como OTA (Open Travel Alliance). A escolha entre as duas abordagens para definição de contrato também deve se basear seu cenário, recursos e as habilidades disponíveis em sua equipe. Por exemplo, se você estiver criando um serviço WCF que não precise oferecer suporte a clientes que executam em outras plataformas, você provavelmente não quer considere uma abordagem de esquema primeiro. Além disso, se você estiver bem familiarizado com o contrato construções de programação em WCF, ter uma boa compreensão do processo de serialização e têm a capacidade de se concentrar em estruturas hierárquicas em vez de gráficos de objeto, você poderá siga a primeira abordagem código e obter os mesmos resultados.

Portanto, se você tiver decidido ir com abordagem primeiro esquema agora, o restante deste artigo mostra como fazê-lo para os serviços WCF.

Abordagem de primeiro esquema explicação

A abordagem do primeiro esquema tem cinco etapas separadas como descrito em Figura 4.


Figura 4 esquema primeiro processo de desenvolvimento contratar primeiro

Já que discutimos as três primeiras etapas no início deste artigo. Portanto, vamos apenas resumi-los e passar para os próximo alguns pontos chaves.

Etapa 1 modelo de dados: Modelar as estruturas de dados usadas para transferir dados entre o serviço e os clientes usando o esquema XML. Você pode usar o editor do Visual Studio XSD ou uma ferramenta semelhante como Altova XmlSpy ou Liquid Studio XML.

Etapa 2 modelo mensagens: Como explicamos anteriormente, nesta etapa você modelar a estrutura do seu corpo da mensagem usando o esquema XML. Você provavelmente usará as estruturas de dados modelados na etapa 1 aqui.

Interface de modelo da etapa 3: Nesta etapa, você pode modelar seu contrato de interface definindo suas operações. No entanto, ao contrário das etapas anteriores, aqui você precisará usar WSDL em vez de esquema XML. Edição de WSDL não está disponível no Visual Studio mas está disponível em determinados produtos como Altova XmlSpy.

Etapa 4 gerar código: Depois de você ter modelado seus dados, mensagens e operações, é hora de gerar o código para representar os artefatos em sua linguagem de programação favorita. As próximas duas seções serão elaborar como fazer isso com as ferramentas disponíveis atualmente para desenvolvedores do WCF.

Etapa 5 Iterate contrato design e código de geração: É extremamente difícil alcançar perfeição em uma tentativa. Quando você cria seu contrato, talvez queira refatorá-la várias vezes até encontrar as estruturas ideais, que você precisa.

Usando ferramentas WCF out of Box para o desenvolvimento contratar primeiro nome de esquema

Para demonstrar esse cenário, vamos criar um serviço da Web simples que tem uma operação para recuperar uma lista de processos ativos na máquina host. Começando com o contrato de dados, usamos modelos de dois tipos complexos.

  1. Tipo complexo do processo representa um processo na máquina host.
  2. Tipo complexo do processList representa uma lista de processos definidos por processo tipo.

Em seguida, usamos modelos de dois elementos explorar e, exploreResponse para abstrair o corpo de entrada/saída mensagens. Como mencionado anteriormente, para ser compatível com o WS-que você precisa garantir que o corpo da mensagem tem apenas um elemento filho dentro do elemento de soap: body. WCF e ASMX lidam com isso criando um elemento wrapper com o nome da operação. Se a convenção de nomenclatura usada para mensagens do modelo for diferente do padrão do WCF, ferramentas de geração de código irão gerar MessageContract classes para a solicitação e resposta. Nós usamos a convenção de nomenclatura do WCF para nomear elementos mensagem e, assim, ter um modelo de objeto mais simples quando geramos o código mais tarde no processo.

Finalmente, usamos modelos de WSDL usando uma ferramenta externa. Nesse caso, nós usamos Altova XML Spy para nos ajudar com isso.

Figuras 4, 5 e 6 contém as definições de contrato de dados, mensagem e interface mencionados anteriormente respectivamente.

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>

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>

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>

Depois que os contratos estiverem prontos, podemos iniciar um prompt de comando do Visual Studio 2008 e gerar código translation from VPE for Csharp para WCF usando svcutil.exe, conforme mostrado no código a seguir:

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

Svcutil.exe é usado principalmente para gerar código para o lado cliente. Ao contrário wsdl.exe seu predecessor, ele não tem uma opção para gerar o esqueleto de no lado do serviço. Conseqüentemente, você irá notar que o código gerado contém código de proxy do lado do cliente, que não é necessário para a implementação no lado do serviço. Para a implementação de serviço, você precisará remover esses tipos não relevantes do código gerado. No nosso caso exemplo, fazemos isso com a remoção de processExplorerClient e processExplorerChannel classes do código gerado. Após você ter feito que, você pode simplesmente implementar a interface gerado tipo processExplorer conforme o projeto de ProcessExplorerService1 na solução de exemplo que acompanha.

Finalmente, antes de você hospedar o serviço, você precisará ajustar a ServiceMetadataBehavior para desativar a geração automática de WSDL e metadados geração runtime do ponto de WCF para o arquivo WSDL estático. A seguir especifica um local externo metadados na configuração do WCF:

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

Como você deve ter observado, fazer o primeiro esquema desenvolvimento usando essa abordagem pode ser um pouco difícil em aplicativos do mundo real. WSCF.blue, a sucessora da ferramenta de livre Web serviço Contract First (WSCF), foi criado para fechar as lacunas.

Uma análise WSCF.blue

WSCF.blue é um suplemento gratuito do Visual Studio 2008. Sua função principal está ativando o primeiro esquema primeiro contrato desenvolvimento dentro do IDE favorito. Modelar seus contratos de dados e a mensagem no editor do Visual Studio XSD ou em uma ferramenta disponível gratuitamente como editor de XML líquido. Você pode preferir o último porque o editor de esquema disponível no Visual studio 2008 fornece menos suporte de modelagem que a que estava disponível no Visual Studio 2005. Depois que os esquemas prontos você pode usar Assistente de geração de WSDL do WSCF.blue para modelar a interface de serviço. Ele apresenta uma forma amigável para modelar as operações da sua interface e oculta os detalhes de construção WSDL real. Este assistente pode ser iniciado clicando no arquivo XSD que contém seus contratos de mensagem e selecionando criar descrição de interface WSDL menu item no menu de contexto, como mostrado no do Figura 7.


Figura 7 iniciando o Assistente de geração WSDL

Este assistente consiste em algumas etapas para reunir informações sobre os contratos de operação que você deseja ter na interface do serviço. A maioria das etapas são bem simples. No entanto, existem algumas coisas que talvez exijam sua atenção em etapas 2, 3 e 4.

Os tipos definidos no esquema do arquivo selecionado no Solution Explorer para iniciar o assistente estarão disponível para a modelagem de WSDL. No entanto, se você tiver tipos adicionais em outros arquivos XSD, na etapa 2, você pode importá-las além disso, como Figura 8 mostra.


Figura 8 Importando esquema adicionais documentos para o assistente

Na etapa 3, você modelar suas operações. O assistente também possui um recurso que pode percorrer os elementos do contrato de mensagem e inferir as operações. Este recurso, no entanto, só funciona para mensagens usando as convenções de nome usadas em regras inferring do assistente, como mostrado na do Figura 9.


Figura 9 adicionar ou remover operações para a interface

Durante a etapa 4, você pode mapear as mensagens modelado em solicitações e respostas de suas operações. Se o recurso inferring na etapa 3 tiver sido usado, esse mapeamento será feito automaticamente pelo assistente. Você também pode definir cabeçalhos de mensagens em suas mensagens de solicitação e resposta durante esta etapa (do Figura 10).


Figura 10 define mensagens de entrada/saída em operações.

Finalmente, quando você concluir o assistente, o arquivo WSDL gerado será adicionado ao seu projeto.
Agora que o contrato é modelado, você pode usar a ferramenta de geração de código WSCF.blue para gerar código WCF no idioma do seu projeto. Botão direito do mouse clique no arquivo WSDL no Solution Explorer e selecione o item de menu gerar código de serviço da Web no menu de contexto para iniciar a ferramenta de geração de código (do Figura 11).


Figura 11 iniciando a ferramenta de geração de código

A caixa de diálogo geração de código oferece várias opções de geração de código. Contém a maioria das opções disponíveis no svcutil.exe, bem como alguns outros adicionais como: Stub do lado do servidor para gerar código de servidor;Ajustar maiúsculas e minúsculas para converter camel casos nomes usados no esquema para nomes de maiúsculas e minúsculas de Pascal sem afetar a serialização;e separar arquivos para gerar um arquivo de código para cada tipo CLR gerado para representar os artefatos de esquema correspondente (do Figura 12). Figura 13 contém uma lista completa das opções disponíveis na ferramenta de geração de código.


Figura 12 do opções de geração de código

Figura 13 opções de geração de código WSCF.blue

Opção Descrição

Proxy do lado do cliente Gera o proxy do lado do cliente para os consumidores de serviço.

Stub do lado do serviço Gera o código no lado do serviço para implementadores de serviço.

Propriedades públicas Expõe gerado membros de classe como propriedades públicas.

Classes serializáveis Classes geradas irão ser decoradas com o SerializableAttribute.

Coleções Usa a coleção < T >tipo para representar tipos de coleção.

Lista < T > Usa List < T >tipo para representar tipos de coleção.

Ligação de dados Gera o código necessário para vincular classes geradas a componentes de dados vinculáveis.

Identificadores de ordem Gera propriedade Order para cada DataMemberAttribute usado.

Métodos assíncronos Gera versão da operação assíncrona e define o OperationContextAttribute.AsyncPattern propriedade como true para informar ao WCF que eles existem.

Arquivos separados Cada classe gerada é colocado no seu próprio arquivo.

Ajustar maiúsculas e minúsculas Usa Pascal caso ao nomear as classes geradas e suas propriedades sem afetar o processo de serialização.

Modo de concorrência Especifica o valor gerado para o propriedade do ServiceBehaviorAttribute.ConcurrencyMode.

Modo de contexto de instância Especifica o valor gerado para o propriedade do ServiceBehaviorAttribute.InstanceContextMode.

Usar o contexto de sincronização Especifica o valor gerado para o propriedade do ServiceBehaviorAttribute.UseSyncrhronizationContext.

Habilitar ponto de extremidade WSDL Adiciona um ponto de extremidade ao serviço para expor metadados estático arquivos. Isso é essencial quando você deseja expor metadados estático documentos no auto-serviços hospedados.

Nome do arquivo de destino Nome do arquivo de saída. Se a opção separar arquivos estiver ativada no, este parâmetro é descartado e nomes de classe são usados como nomes de arquivos.

Namespace de destino Espaço para nome CLR a ser usado para os tipos gerados.

Lembre-se de configurações Memoriza as opções de geração de código usadas mais recentemente.

Substituir arquivos existentes Especifica que você permita WSCF.blue substituir arquivos existentes em vez de criar nomes de arquivo exclusivo para resolver os conflitos. ’S Importante Lembre-se de que todas as personalizações que ’ve ser feito para o código gerado serão substituídas. Portanto, recomendamos fazer essas modificações por meio de classes parciais.

O lançamento do WSCF.blue discutidos neste artigo (Beta 1, como de 2009 25 de julho) não dá suporte ainda mesclar arquivos de configuração. Conseqüentemente, a configuração necessária para hospedar seu serviço é emitida para um arquivo de output.config. Uma etapa manual é necessária para mover o conteúdo desse arquivo para o web.config ou o arquivo app.config conforme apropriado.

Depois que o arquivo de configuração estiver pronto, você pode continuar a adicionar a implementação necessária à classe de serviço gerado.

Finalmente, você pode modificar seus esquemas no Visual Studio e use WSDL round-tripping recursos no Assistente de geração WSDL para alterar seus contratos e gerar novamente o código.

O que ’s Avançar

WSCF.blue é lançada como um projeto de código-fonte aberto e disponível em wscfblue.codeplex.com. A versão beta atual tem algumas limitações que você podem restringir para as implementações de serviço da Web básicas, mas mais comuns. Por exemplo, o Assistente de geração WSDL atualmente oferece suporte à ligação http básica somente. Além disso, a geração de código atual em WSCF.blue apenas gera XmlSerializable classes em vez de DataContractSerializable classes para oferecer suporte a mais ampla gama de construções de esquema. Uma lista completa dos problemas conhecidos e um mapa da estrada da ferramenta está disponível no site da CodePlex.

Uma explicação detalhada de como usar WSCF está disponível em thinktecture.com/resourcearchive/tools-and-software/wscf/wscf-walkthrough. Embora o documento se baseia em WSCF 0,6, as etapas explicadas aplicam ao igualmente

Conclusão

Esquema com base primeiro contrato modelagem serviços da Web permite modelar seus contratos com uma mentalidade centrada em XML. Esse processo mantém seu foco em tipos universalmente aceitáveis e nas estruturas de dados hierárquicas que podem ser representadas em XML. Ferramentas de suporte é essencial para fazer uma plataforma de serviços da Web bem-sucedida. WSCF.blue estende o limite das ferramentas de caixa fornecido pelo WCF para facilitar baseada em esquema desenvolvimento contratar primeiro para desenvolvedores do WCF.

Christian Weyer é um dos fundadores e o principal arquiteto da thinktecture, dedicado à e foi modelagem e implementar aplicativos distribuídos com Java, COM, DCOM, COM +, Web Services, WCF e outras tecnologias por muitos anos. Christian é o inventor original da ferramenta Web Services contrato primeiro clássica para. NET. Entre em contato com ele pelo thinktecture.com/staff/christian de.

Buddhike de Silva um fellow engenharia é baseado na Austrália. Antes de mover a Austrália, ele era o engenheiro de cliente potencial da thinktecture. Buddhike foi criação e implementação de aplicativos distribuídos por muitos anos e ele também é um colaborador tempo WSCF/WSCF.blue projetos. Você pode obter em contato com ele em de https://msdn.microsoft.com/pt-br/.

1 Design por contrato, técnico relatório TR-EI-12/CO, interativo engenharia de Software Inc., 1986.

2 http://se.ethz.ch/~Meyer/Publications/Computer/Contract.pdf

3 rESTful serviços Entretanto se comunicar com seus clientes trocando mensagens HTTP padrão e siga um paradigma totalmente diferente.