web 2.0

WCF Parte III

Olá a todos!

Hoje vamos colocar em prática aquilo que aprendemos nos post´s anteriores, ou seja, vamos criar e hospedar nosso primeiro serviço WCF.

Como falei anteriormente, vamos criar nosso serviço sem a utilização de Templates, isso nos dará um bom entendimento sobre tudo que o WCF precisa para funcionar. Mas isso não impede de você criar seus serviços a partir dos Templates o que na verdade é muito mais simples e rápido, porém para estudo vamos ver em detalhes a criação completa do WCF.

Para nossos artigos, vamos criar um projeto que irá disponibilizar métodos para se trabalhar com Post´s, ou seja, iremos criar um Blog. Depois iremos consumí-lo de várias maneiras como WinForm, Console, Asp.Net etc.

Antes de iniciarmos, crie uma solução em branco e dê o nome de WCFPost. Feito isso vamos adicionar a ela dois projetos do tipo C# –> Class Library e dê o nome de WCFPost.Contract, e WCFPost.Data.

Para fins de estudo, não irei utilizar banco de dados pois nosso foco é WCF ok!

Voltando ao nosso projeto, adicione no projeto WCFPost.Data duas classes, Post e Author e decore as classes com o atributo DataContract e suas propriedades com o atributo DataMember, não esqueça de adicionar a referencia a System.Runtime.Serialization pois é neste assembly que estão contidos os atributos DataContract e DataMember. Estes atributos definem que nossas classes poderão ser expostas por um serviço WCF. Suas classes deverão ficar conforme a Listagem 01.

Listagem 01 – classes Post e Author

using System;
using System.Runtime.Serialization;

namespace WCFPost.Data
{
    [DataContract]
    public class Post
    {
        [DataMember]
        public int PostId { get; set; }

        [DataMember]
        public string Title { get; set; }

        [DataMember]
        public DateTime PostDate { get; set; }

        [DataMember]
        public bool IsActive { get; set; }

        [DataMember]
        public Author Author { get; set; }
    }
}

 

using System.Runtime.Serialization;

namespace WCFPost.Data
{
    [DataContract]
    public class Author
    {
        [DataMember]
        public int AuthorId { get; set; }

        [DataMember]
        public string Name { get; set; }
    }
}

Agora que temos a parte Data pronta, vamos começar criando nossa Interface.

Crie uma Interface no projeto WCFPost.Contract e dê o nome de IPost. Ela será o contrato e como todos já sabem, é o contrato quem determinará quais operações estarão expostas, quais informações essas operações necessitam para ser executadas e também qual será o tipo de retorno. O contrato nada mais é que uma Interface que, por sua vez, deverá possuir os métodos que serão expostos para o cliente. Como foi visto anteriormente, devemos decorar nosso contrato com o atributo ServiceContratactAttribute que está presente no assembly System.ServiceModel. Nossa interface deverá ficar como na listagem 02.

Listagem 02 – IPost contract

using System.ServiceModel;
using WCFPost.Data;

namespace WCFPost.Contract
{
    [ServiceContract]
    public interface IPost
    {
        [OperationContract]
        Post GetPostById(int postId);

        [OperationContract]
        void AddPost(Post post);

        [OperationContract]
        void DeletePost(Post post);
    }
}

 

Assim como decoramos a nossa Interface com o atributo ServiceContract, devemos também decorar nossos métodos com o atributo OperationContractAttribute, pois só assim eles estarão expostos para serem consumidos.

Para um melhor entendimento, seu projeto deverá estar como na figura 01.

wcf_p3_01

Figura 01 – Projeto WCFPost

Bem, agora iremos criar a classe que irá representar nosso serviço. Para isso, adicione mais um projeto do tipo C# Class Library e de o nome  de WCFPost.Service. Adicione a este projeto, as referencias às dlls dos projetos WCFPost.Contract e WCFPost.Data.

Precisamos agora implementar a interface do serviço em nossa classe. Seu código deverá ficar como na listagem 03. Fiz a implementação apenas no método GetPostById para tornar o artigo menos extenso ok!

Listagem 03 – implementação da interface IPost.

using System;
using WCFPost.Contract;
using WCFPost.Data;

namespace WCFPost.Service
{
    public class PostService : IPost
    {
        public Post GetPostById(int postId)
        {
            var post = new Post
                           {
                               Author = new Author{AuthorId = 1, Name = "Luciano"},
                               IsActive = true,
                               PostDate = DateTime.Today,
                               PostId = 1,
                               Title = "Trabalhando com WCF"
                           };

            return post;
        }

        public void AddPost(Post post)
        {
            throw new NotImplementedException();
        }

        public void DeletePost(Post post)
        {
            throw new NotImplementedException();
        }
    }
}

 

Uma das maravilhas do WCF é a possibilidade de utilizar qualquer tipo de aplicação como host, ou seja, ele não tem uma dependência de algum software, como o IIS, como acontecia com os Web Services, pois o WCF pode expor serviços para serem consumidos através de diversos tipos de protocolos, como por exemplo: HTTP, TCP, IPC e MSMQ. 

Para nosso artigo, iremos utilizar um Console Application para hospedar nosso host. Então, inclua mais um projeto, mas agora do tipo C# –> Console Application. Adicione a referencia a System.ServiceModel e aos projetos WCFPost.Contract e WCFPost.Service.

Para que nosso serviço comece a funcionar, precisamos antes definir nosso ServiceHost, este precisa conhecer o ABC. Lembram do ABC do artigo anterior? A – Address, B – Binding, C – Contract, pois então iremos utilizá-lo agora.

Defina seu Address como http://localhost:1010, o Binding será do tipo basicHttpBinding e o Contract será o nosso serviço PostService.

Atente que estamos realizando tudo a base de código, isso faz com que nosso aplicativo fique engessado tornando-o praticamente “incustomizável”, palavrinha estranha!!.

Mas não se preocupem, existe outra forma de se realizar tais configurações, porem veremos esta em um outro post galera.

Seu código deve estar como na listagem 04.

Listagem 04 – criando o serviço

using System;
using System.ServiceModel;

namespace WCFPost.Host
{
    class Program
    {
        static void Main(string[] args)
        {
            var address = new Uri("http://localhost:1010");
            var type = typeof (Service.PostService);

            ServiceHost serviceHost = new ServiceHost(type, address);

            serviceHost.Open();
            Console.WriteLine("Service started...");
            Console.ReadLine();
        }
    }
}

Bem, nosso serviço ainda não está totalmente pronto pois, para que os clientes possam extrair as informações (metadados), precisamos expor a descrição do mesmo para que os desenvolvedores possam referenciá-lo nas aplicações clientes que irão consumí-lo.

Você pode expor essas informações através do protocolo HTTP - via método Get - ou utilizar um Endpoint exclusivo para o metadado.

Desta forma iremos utilizar o MEX (Metadata Exchange Endpoint), ele é extremamente necessário, já que o cliente necessita importar os metadados para ter localmente a representação do serviço.

Para configurarmos um serviço a ser exposto, iremos adicionar um EndPoint para o MEX, desta forma altere o código do seu host para o código conforme a listagem 05. Novamente venho frisar que iremos aprender a fazer todas essas configurações em um App.config e no Web.config para termos uma aplicação customizável.

Listagem 05 – criação do MEX

using System;
using System.ServiceModel;
using System.ServiceModel.Description;
using WCFPost.Contract;

namespace WCFPost.Host
{
    class Program
    {
        static void Main(string[] args)
        {
            var address = new Uri("http://localhost:1010");
            var type = typeof (Service.PostService);

            ServiceHost serviceHost = new ServiceHost(type, address);

            serviceHost.Description.Behaviors.Add(new ServiceMetadataBehavior {HttpGetEnabled = true});
            serviceHost.AddServiceEndpoint(typeof (IMetadataExchange), MetadataExchangeBindings.CreateMexHttpBinding(), "mex");
            serviceHost.AddServiceEndpoint(typeof (IPost), new BasicHttpBinding(), "ServicePost");

            serviceHost.Open();
            Console.WriteLine("Service started...");
            Console.ReadLine();
        }
    }
}

 

Vamos observar algumas mudanças em nosso host.

Criamos um ServiceMetadataBehavior com a propriedades HttpGetEnabled setada como true, isso faz com que os metadados sejam acessíveis através de HTTP-GET.

Criamos o EndPoint para o Mex, definindo a interface IMetadataExchange como sendo nosso Contract, deixamos que o método CreateMexHttpBinding() fique responsável por criado o Binding apropriado para nós e por fim definimos um Address para nosso mex.

Rode a aplicação, ela deve estar conforme as figuras 02 e 03.

wcf_p3_02

Figura 02 – serviço iniciado

wcf_p3_03

Figura 03 – acesso ao endereço da aplicação

 

Ufa, finalmente terminamos nosso serviço!! Mas espera ai, é só isso? Claro que não, ainda tem muito mais, mas vamos deixar para os próximos posts né galera!!

Espero que estejam gostando.

Enjoy!!

Tags:

WCF

WCF–Parte II

Dando continuidade ao post anterior “Iniciando com WCF”, vamos ver hoje um pouco sobre a arquitetura WCF.

A figura 1 mostra a arquitetura principal do Windows Communication Foundation. Vamos ver cada item par que você possa começar a se familiarizar com o WCF.

 

wcf_02

Figura 1 – Arquitetura WCF

 

Contracts

O contrato expõe quais membros de uma classe serão visíveis. Através de interfaces podemos definir um contrato entre um serviço e as aplicações que irão consumí-lo, expondo somente os métodos desejados.

O WCF conta com os seguintes tipos de contratos:

  • Service Contract - Um contrato para um serviço. Define os detalhes do serviço, e será utilizado na interface de contrato.
  • Operational Contract - Define uma operação individual, e será aplicado na assinatura dos métodos da interface de contrato.
  • Data Contract - Define a serialização para objetos complexos. Esta propriedade necessita da inclusão do namespace System.Runtime.Serialization.
  • Message Contract - Este contrato descreve a mensagem SOAP completa.
  • Fault Contract - Utilizado para documentar erros no WCF.

Policies and Binding - Especifica as condições que serão requeridas para a comunicação, como exemplo podemos destacar os requisitos de segurança a serem utilizados na comunicação com o serviço.

Os contratos do WCF são utilizados como propriedades, podendo ser atribuído a classes e interfaces.

 

Service Runtime

Ele contém os comportamentos que ocorrem durante a execução do serviço.

- Throttling Behavior: controla quantas mensagens são processadas.
- Error Behavior: especifica um erro interno ocorrido no serviço.
- Metadata Behavior: informa como e se os metadados estarão disponíveis.
- Instance Behavior: especifica quantas instâncias do serviço deverão ser criadas durante a execução do serviço.
- Transaction Behavior: permite a reversão de operações caso uma falha venha a ocorrer.
- Dispatch Behavior: controla como uma mensagem é processada pela infra-estrutura do WCF

 

Messaging

A camada Message é composta de Canais. Canais são componentes que fazem o processamento das mensagens, por exemplo, autenticando uma mensagem.

Um conjunto de Canais é conhecido como Channel Stack. Os canais são o núcleo para o envio e recebimento de mensagens para um EndPoint.

Existem dois tipos de canais:

- Transport Channels: realiza o envio/ recebimento de mensagens pela rede. Ex.: HTTP, TCP e MSMQ.

- Protocol Channels: implementa o protocolo SOAP possibilitando a modificação da mensagem. Ex.: WS-Security e WS-Reliability.

 

Activation and Hosting

Para que um serviço possa ser consumido ele deve estar ativado e hospedado. No caso do WCF, este pode ser hospedado de diversas formas como:

  • IIS – Internet Information Service: provê várias vantagens como controle do serviço. Porém só pode ser utilizado o protocolo HTTP para o tráfego de informações.
  • Windows Activation Service  - (WAS)
    É uma forma mais atual de ser ativar um serviço, foi incorporado ao IIS 7. Trabalha com os seguinte protocolos: TCP e Named Pipes.
  • Self-Hosting

    WCF Service pode ser hospedado também em um aplicativo do tipo Console Application, Windows Form ou aplicações gráficas WPF.

  • Windows Service

    WCF também pode ser hospedado em um Serviço do Windows onde você pode ter o controle do aplicativo pelo Service Control  Manager (SCM).

Como podem ver o WCF nos dá uma flexibilidade muito grande quanto a forma de hospedagem o que nos abre um enorme leque de possibilidades.

 

Aguardo vocês no próximo post!!

 

Enjoy!

Tags:

WCF | Desenvolvimento

Iniciando com WCF

Fala pessoal, tudo na paz?

Bem, como ando recebendo e-mails da galera perguntando sobre WCF, resolvi escrever alguns artigos sobre ele.

Nessa primeira parte vamos ver o que é o WCF e o que o compõe. Será uma introdução básica, porém, espero colocar toda informação necessária para um primeiro contato.

Primeiramente, o que é o WCF?

Windows Communication Foundation ou WCF como é mais conhecido nada mais é do que um SDK para desenvolvimento de aplicações distribuídas e orientadas a serviço, também conhecidas como (SOA).

O WCF surgiu no .Net Framework 3.0. Ele veio para  unificar tecnologias como COM+, .Net Remoting, Web Services e MSMQ (Microsoft Message Queue), isso porque, antes do WCF, era necessário que o desenvolvedor utilizasse tecnologias distintas para cada tipo de aplicação, um exemplo seria a criação de Web Services para disponibilizar na Internet algum serviço. Caso este serviço fosse disponibilizado na intranet, deveria ser criada uma aplicação utilizando .Net Remoting, isso porque .Net Remoting utilizava o protocolo TCP enviado arquivos binários pela rede o que tornava a aplicação muito mais rápida do que com Web Service (Http/XML). Com a criação do WCF isso deixa de existir, ele torna a vida do programador muito mais simples.

Para que possamos criar, projetar e implantar serviços WCF, devemos nos ater a alguns conceitos básicos que são os EndPoints e seus componentes ( Address, Binding e Contract).

Toda comunicação com o serviço se dá através dos EndPoints, são eles os responsáveis por fornecer aos clientes o acesso às funcionalidades do serviço.

Calma pessoal não se assustem, vamos ver em detalhes cada pedacinho que compõe um EndPoint. Vamos lá?

Address

Nada mais é do que o local ou endereço onde o serviço reside. O Address possui dois pontos importantes que são a localização e o protocolo de transporte. Um Address possui o seguinte formato:

[base address]/[optional URI]

Já o base address segue o seguinte formato:

[transport]://[machine or domain][:optional port]

Como transport, o WCF nos oferece os seguintes canais de comunicação:

http, https, net.tcp, net.pipe, net.msmq e net.p2p

Para ilustrar melhor abaixo temos alguns exemplos de Address:

http://localhost:8080
http://localhost:8080/MeuWCFService
net.tcp://localhost:123/MeuWCFService
net.pipe://localhost/MeuWCFService
net.msmq://localhost/private/MeuWCFService
net.msmq://localhost/MeuWCFQueue

 

Binding

É o responsável por definir como será a comunicação com o serviço (tcp, ipc, http, msmq, etc).
O WCF nos oferece seis tipos de binding que são:

-  BasicHttpBinding
-  NetTcpBinding
-  NetNamedPipeBinding
-  WSHttpBinding
-  WSDualHttpBinding
-  NetMsmqBinding

Para saber mais sobre Binding, deem uma olhada no post  WCF Bindings.

 

Contract

No contrato é onde definimos quais funcionalidades um serviço irá expor para os clientes.
Existem quatro tipos de contrato que são:

Service Contracts:
- define quais operações estarão disponíveis no serviço para o cliente, ou seja, mapeia tipos CLR para WSDL

Data Contracts:
– define a estrutura de dados usada no serviço, ou seja, ele mapeia tipos CLR para XSD

Fault Contracts:
- define os tipos de erros que serão lançados pelo serviço e como eles irão propagar para o cliente.

Message Contracts:
- define a estrutura de mensagens usadas no serviço, ou seja, mapeia tipos CLR para SOAP


Então, para que tenhamos um EndPoint precisamos ter um Address, um Binding e um Contract, estes itens são conhecidos como ABC´s EndPoint.

Bem pessoal, por hoje é só!

Em nossos próximos posts iremos nos aprofundar um pouco mais no WCF.

Espero que tenham gostado desta primeira parte.

 

Enjoy!!

Tags:

WCF

De volta aos posts

Fala galera, desculpem por ter deixado de postar mas estas três ultimas semanas foram cruciais para que eu ficasse por conta de estudar e tirar mais algumas certificações e graças a Deus deu tudo certo.

Recebi o resultado das duas provas Betas do .NET 4.0 que fiz

TS: Web Applicaions Development w/Microsoft .NET Frmwk 4 – Failed
Pro: Designing & Developing Web Apps Using MS .NET Frmwk 4 – Passed

 

Já para a certificação MCPD Enterprise Application Developer 3.5 na qual passei as semanas estudando a coisa foi bem melhor, como faltavam apenas mais três provas resolvi fazer todas de uma vez, não foi fácil, mas também não foi impossível e ta ai o resultado, até fiquei surpreso com a pontuação alcançada nas provas mas isso prova que estudando a gente consegue!

PRO: Design & Develop Enterprise App Using MS .NET Frmwrk 3.5 – Passed - 916pts
TS: MS .NET Framework 3.5, ADO.NET Application Development – Passed - 895pts
TS: MS .NET Framework 3.5, Windows Forms App Dev – Passed  1000pts

Bem para aqueles que estão interessados em tirar uma certificação seja 3.5 ou 4.0 a dica é estude muito, faça bastante exercício e principalmente faça os simulados que vem junto aos livros pois eles ajudam bastante e principalmente eles contêm explanação sobre o porquê da resposta dada que é muito válido.

A meta agora é MCITP: Database Developer 2008, já tenho material de estudos o que falta é coragem pra começar..hehehehe, mas vamos em frente.

É isso ai pessoal, obrigado àqueles que acompanham o blog, fico feliz que estejam gostando e caso tenham dúvidas não hesitem em perguntar estou sempre à disposição!

Tags:

Asp .Net | Desenvolvimento Web | JavaScript | WCF

WCF Data Service – Parte 2

Na primeira parte de nosso post sobre WCF Data Service vimos como criar nosso serviço e executar algumas pesquisas utilizando URI. Hoje veremos como consumir nosso serviço além de conhecermos um pouco mais sobre a liberação de acesso às entidades.

Abram o projeto anterior, vamos começar dando uma olhada nas permissões de acesso de nossas entidades.

No trecho de código da listagem 01 definimos que todas as entidades receberão livre acesso, ou seja, o chamador do serviço terá total acesso a elas tanto para leitura quanto para escrita.

Listagem 01

config.SetEntitySetAccessRule("*", EntitySetRights.All);

 

O método SetEntityAcessRule recebe dois parâmetros, no primeiro deles nós informamos qual será a entidade e no segundo qual o tipo de permissão que iremos liberar. Abaixo podemos ver cada item da enum de permissões.

EntitySetRights Enumerator

All – permite total acesso à entidade (escrita/leitura)
AllRead – permite somente leitura
AllWrite – permite somente escrita
None – nega qualquer tipo de acesso
ReadMultiple – leitura de várias linhas é permitida
ReadSingle – permite que apenas uma linha da tabela seja lida
WriteAppend – permite a criação de novos dados na tabela
WriteDelete – permite a exclusão de dados
WriteMerge – permite que se faça um merge com atualização dos dados
WriteReplace – permite que se faça uma atualização de troca de dados

Agora que já conhecemos um pouco sobre o acesso às entidades, vamos criar nosso aplicativo.

Adicione um novo projeto do tipo Console Application, dê o nome dele de AppWCFDataService, agora adicione uma referencia ao serviço, Add Service Reference, clique em Discover que o Visual Studio irá procurar nosso serviço dentro da solução.

wcf_p02_01

Figura 01 – adição do serviço ao projeto

 

Abra a class Program.cs, antes de utilizamos nosso serviço devemos criar duas instancias que são DataServiceContext que faz parte do namespace System.Data.Services.Client e NorthwindEntities que é no nome da classe que contem nosso mapeamento, lembra? Criamos ele em nosso primeiro post. Caso não recorde acesse o post aqui.

Listagem 02 – Classe Program

using System;
using System.Data.Services.Client;
using AppWCFDataService.WCFDataService;

namespace AppWCFDataService
{
    class Program
    {
        static void Main( string[] args )
        {
            var context = new DataServiceContext( new Uri( "http://localhost:26482/WcfDataService1.svc" ) );
            var db = new NorthwindEntities( new Uri( "http://localhost:26482/WcfDataService1.svc" ) );
        }
    }
}

Observem que informamos a mesma URI para as duas instâncias, isso porque ambas compartilham do mesmo serviço. Esta URI foi obtida executando o serviço, este é o endereço que acesso o serviço em minha maquina, atente para passar a url correta de sua maquina.

Para testar nosso aplicativo vamos criar os métodos: ListaClientes(), InserirClienteContext(Custormer customer), InserirClienteDB(Customer customer), AtualizarCliente(Customer customer) e ApagarCliente(Customer customer).

Crie os métodos conforme o código da listagem 03.

Listagem 03

/// <summary>
/// Lista todos os clientes
/// </summary>
/// <returns></returns>
static IEnumerable<Customer> ListaClientes()
{
    var result = from customers in _db.Customers select customers;
    return result.ToList();
}

/// <summary>
/// Insere um novo cliente
/// Utiliza o context para inserir o objeto
/// </summary>
/// <param name="customer"></param>
static void InserirClienteContext(Customer customer)
{
    _context.AddObject("Customers", customer);
    _context.SaveChanges();
}

/// <summary>
/// Insere um novo cliente
/// Utiliza o mapeamento para inserir o objeto
/// </summary>
/// <param name="customer"></param>
static void InserirClienteDB( Customer customer )
{
    _db.AddToCustomers(customer);
    _db.SaveChanges();
}

/// <summary>
/// Atualiza um cliente
/// </summary>
/// <param name="customer"></param>
static void AtualizarCliente( Customer customer )
{
    var customerToUpdate = (from cus in _db.Customers where cus.CustomerID == customer.CustomerID select cus).First();
    customerToUpdate.CompanyName = customer.CompanyName;
    
    _db.UpdateObject( customerToUpdate );
    _db.SaveChanges();
}

/// <summary>
/// Exclui um cliente
/// </summary>
/// <param name="customer"></param>
static void ApagarCliente( Customer customer )
{
    var customerToDelete = ( from cus in _db.Customers where cus.CustomerID == customer.CustomerID select cus ).First();

    _db.DeleteObject( customerToDelete );
    _db.SaveChanges();
}

Agora só precisamos criar um cliente e testar nossos métodos. O código da listagem 04 mostra como isso pode ser feito.

Listagem 04

static DataServiceContext _context = new DataServiceContext( new Uri( "http://localhost:26482/WcfDataService1.svc" ) );
static NorthwindEntities _db = new NorthwindEntities( new Uri( "http://localhost:26482/WcfDataService1.svc" ) );

    static void Main( string[] args )
    {
        //
        // Lista os clientes
        //
        foreach (Customer customer in ListaClientes())
        {
            Console.WriteLine(customer.ContactName + " - " + customer.Country);
        }

        //
        // Cliente a ser inserido
        //
        var newCustomer = new Customer
                           {
                                CustomerID = "LUCLI",
                                Address = "Rua Teste",
                                City = "Belo Horizonte",
                                CompanyName = "Tabajara S/A",
                                ContactName = "Luciano Lima",
                                ContactTitle = "Sr",
                                Country = "Brasil",
                                Fax = "31 1234-5678",
                                Phone = "31 1234-5678",
                                PostalCode = "12330-123",
                                Region = "MG"
                           };

            //Inserir - Context
            InserirClienteContext(newCustomer);

            //Inserir - Entity
            InserirClienteDB(newCustomer);

            //Atualizar
            AtualizarCliente(newCustomer);

            //Excluir
            ApagarCliente(newCustomer);

            Console.ReadLine();
    }

 

Bem pessoal, vimos aqui como o trabalho com serviços está ficando cada vez mais fácil, como viram com pouco código conseguimos montar um serviço e criar uma aplicação simples para consumí-lo.

Tags:

C# | WCF

WCF Data Service

Antes de iniciarmos com WCF Data Service vamos dar uma passada rápida no conceito de Web Service e WCF para que possamos entender melhor o WCF Data Service.

Web Service é uma solução utilizada na integração de sistemas e na comunicação entre aplicações diferentes. Com esta tecnologia é possível que novas aplicações possam interagir com aquelas que já existem e que sistemas desenvolvidos em plataformas diferentes sejam compatíveis. Os Web services são componentes que permitem às aplicações enviar e receber dados em formato XML. Cada aplicação pode ter a sua própria "linguagem", que é traduzida para uma linguagem universal, o formato XML.

Essencialmente, o Web Service faz com que os recursos da aplicação do software estejam disponíveis sobre a rede de uma forma normalizada. Outras tecnologias fazem a mesma coisa, como por exemplo, os browsers da Internet acedem às páginas Web disponíveis usando por norma as tecnologias da Internet, HTTP e HTML. No entanto, estas tecnologias não são bem sucedidas na comunicação e integração de aplicações. Existe uma grande motivação sobre a tecnologia Web Service pois possibilita que diferentes aplicações comuniquem entre si e utilizem recursos diferentes.

Utilizando a tecnologia Web Service, uma aplicação pode invocar outra para efetuar tarefas simples ou complexas mesmo que as duas aplicações estejam em diferentes sistemas e escritas em linguagens diferentes. Em outras palavras, os Web Services fazem com que os seus recursos estejam disponíveis para que qualquer aplicação cliente possa operar e extrair os recursos fornecidos pelo Web Service.

Windows Communication Foundation (WCF) é um modelo de programação unificado e ambiente de execução (Framework) criado pela Microsoft que visam a construção de aplicações orientadas a serviços (Service Oriented Architecture).

O objetivo principal do WCF é permitir que analistas e desenvolvedores criem aplicações voltadas para computação distribuída.

O WCF possui ainda um conjunto de bibliotecas (classes) que permitem aos desenvolvedores criar estas aplicações para funcionarem sob o sistema operacional Windows. Ele é, na verdade,  uma evolução ao Web Service, isso porque ele agrupa várias tecnologias para resolver o problema na comunicação dos dados.

WCF Data Services é uma forma de expormos um modelo de dados do Entity Framework através de uma interface REST. O DS é uma extensão do WCF (isto é, pode ser hospedado como qualquer serviço WCF). É uma tecnologia que visa facilitar o acesso a dados tanto de aplicações Web comuns como AJAX, como Silverlight e .NET.

Para expor os dados via WCF Data Services, é preciso que se tenha uma fonte de dados que suporte consultas utilizando LINQ, isto é, que implemente IQueryable/IUpdatable. Resumidamente, a aplicação pede um endereço para o serviço, e este endereço é traduzido como uma consulta LINQ para que então, o provedor de dados retorne os dados de interesse.

Parece meio confuso mas na verdade o WCF Data Service nos dá as seguintes possibilidades:

  • fornece uma API que nos permite criar e consumir dados através de HTTP utilizando serviços RESTful. 
  • suporta todas as operações de banco de dados através de URI. 
  • é capaz de expor um Modelo de Entidade através de uma URI. 
  • suporta CRUD. 
  • pode ser consumido por qualquer aplicação em diferentes tipos de clientes como Windows, SilverLight, Web, AJAX e Console.

Mas vamos deixar de conversa e vermos na prática como isso funciona!

Crie um projeto do tipo Asp .Net Web Application, dê o nome de “WebAppWCFDataService”.

Feito isso, precisamos adicionar nosso WCF Data Service, para isto, clique com o botão direito na solução e adicione um item do tipo “WCF Data Service”.

wcfdata01

Figura 01 – inclusão de novo item

 

wcfdata02

Figura 02 – item do tipo WCF Data Service

 

Seu projeto deverá estar como na figura 03.

wcfdata03

Figura 03 – Solução

 

Precisamos agora de nossa fonte de dados. Estou utilizando o NorthWind para este exemplo, caso não possua um banco de dados, você pode baixá-lo aqui.

Não irei entrar em detalhes de como instalar o banco pois está fora do escopo deste post.

Vamos criar nosso mapeamento relacional, para isso adicione um item do tipo ADO .Net Entity Data Model. Ele irá apresentar várias telas para que você escolha o banco, as tabelas, o nome da conexão e o contexto, basta seguir conformes as figuras 04, 05, 06 e 07.

wcfdata04

Figura 04 – inclusão do entity data model

 

wcfdata05

Figura 05 – Seleção do tipo de Modelo

 

wcfdata06

Figura 06 – String de conexão e Context

 

wcfdata07

Figura 07 – Escolha das tabelas

 

Pronto, agora que já temos nosso mapeamento precisamos informar ao data service qual é nosso contexto e o que ele deverá disponibilizar.

Abra o arquivo WcfDataService1.svc.cs, ele deve estar como o código da listagem 1

Listagem 01

using System;
using System.Collections.Generic;
using System.Data.Services;
using System.Data.Services.Common;
using System.Linq;
using System.ServiceModel.Web;
using System.Web;

namespace WebAppWCFDataSerevice
{
    public class WcfDataService1 : DataService< /* TODO: put your data source class name here */ >
    {
        // This method is called only once to initialize service-wide policies.
        public static void InitializeService(DataServiceConfiguration config)
        {
            // TODO: set rules to indicate which entity sets and service operations are visible, updatable, etc.
            // Examples:
            // config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);
            // config.SetServiceOperationAccessRule("MyServiceOperation", ServiceOperationRights.All);
            config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V2;
        }
    }
}

Altere a linha

public class WcfDataService1 : DataService< /* TODO: put your data source class name here */ >

Para

public class WcfDataService1 : DataService<NorthwindEntities>

 

Remova as duas barras da linha

// config.SetEntitySetAccessRule("MyEntityset", EntitySetRights.AllRead);


Altere para

config.SetEntitySetAccessRule("*", EntitySetRights.All);


O que fizemos foi dizer ao nosso Data Service qual é a classe que contem o mapeamento para nossas entidades e definir as permissões para elas, no caso, definimos que todas as entidades não irão possuir qualquer restrição “EntitySetRights.All”

Compile o aplicativo, se tudo estiver correto ele deverá apresentar a tela como na figura 08.

wcfdata08

Figura 08 – aplicativo sendo executado


Bem, a princípio nada demais ok? Errado! Percebam que nosso serviço expos nossas entidades, assim podemos realizar pesquisas sem a necessidade de criarmos métodos para isso. Mas como isso é possível? Simples, como havia falado, o WCF Data Service nos fornece maneiras de realizarmos consultas em banco através de URI´s.

Vejam os exemplos abaixo.

Listar todos os Clientes
http://localhost:26482/WcfDataService1.svc/Customers

Listar todos os Clientes de São Paulo
http://localhost:26482/WcfDataService1.svc/Customers?$filter=Region eq 'SP'

Listar os 10 primeiros Produtos
http://localhost:26482/WcfDataService1.svc/Products?$top=10

Mas você deve estar se perguntando. De onde você tirou estas URI´s? É simples existe uma tabela com parâmetros de pesquisa para as URI´s conforme abaixo. Não estão todos ai, mas os mais importantes.


Operações

orderby - realiza a ordenação por um parâmetro qualquer
top - seleciona a quantidade de registros informada
filter - realiza a pesquisa com base em algum filtro

 

Operadores

eq - igual
ne - não igual
gt - maior que
ge - maior ou igual
lt - menor que
le - menor ou igual
and - AND lógico
or - OR lógico
not - NOT lógico

 

Como puderam ver, o WCF Data Service é uma nova maneira de expormos nossas entidades sem a necessidade de criarmos métodos para realizar as diversas pesquisa e operações necessárias tornando assim nossa produtividade muito maior.

Num próximo post veremos como consumir nossos Data Services, além de darmos uma passada nas permissões de acesso às entidades e segurança na troca de informações.

E lembrem-se “Informação só tem sentido se for compartilhada!”

Enjoy!!

Tags:

WCF | Desenvolvimento Web | C# | Asp .Net | Data Service

WCF Bindings - Dicas

Bem, como todos sabem existem vários tipos de Bindings que podemos utilizar quando criamos nossos projetos do tipo WCF Server Application. Mas o problema maior é saber quando e qual utilizar para que possamos criar aplicações eficientes e seguras.

Bem aqui vão algumas dicas de quando utilizá-los. Coloquei apenas os mais conhecidos:

1ª – se você precisa suportar requisições de clientes na internet.

wsHttpBinding é uma boa opção para cenários de Internet onde você não precisa dar suporte a clientes legados, ou seja, que utilizem Web ASMX. Se você precisa de suporte a clientes legados,
considere utilizar basicHttpBinding. além disso, wsHttpBinding pode ser hospedado em servidores com IIS 5.0 ou IIS 6.0.

2ª – se você precisar expor seu WCF para sistemas legados, como antigos web services (*.asmx)

basicHttpBinding é uma boa opção para cenários onde você precisa dar suporte a clientes legados, ou seja, que utilizem Web ASMX. Por padrão basicHttpBinding não implementa segurança, caso você necessite terá que explicitar esta configuração. Assim como wsHttpBinding, basicHttpBinding pode ser hospedado em servidores com IIS 5.0 ou IIS 6.0.

3ª – se você esta utilizando seu WCF numa intranet.

netTcpBinding é uma boa opção para intranet principalmente se performance for um ponto a ser levando em consideração além de poder ser hospedado em um Windows Service ao invés de utilizar o IIS. netTcpBinding utiliza o protocolo TCP com isso possui suporte completo a SOA Security e a transações. Não é possível hospedar serviços utilizando o netTcpBinding no IIS 5.0 ou 6.0, somente no IIS 7.0.

4ª – se estiver testando seu WCF na mesma máquina, Server/Client.

netNamedPipeBinding provê um ambiente seguro e confiável para “cross-process” numa mesma máquina. Utilizado quando você deseja utilizar o protocolo Named-Pipe e ainda quer aproveitar o suporte a SOA Security e transações. Não é possível hospedar serviços utilizando o netNamedPipeBinding no IIS 5.0 ou 6.0, somente no IIS 7.0.

5ª – se for preciso dar suporte a chamadas desconectadas.

netMsmqBinding provê um ambiente onde é possível utilizar chamadas desconectadas utilizando MSMQ – Microsoft Message Queuing. Normalmente utilizamos este tipo de binding quando não temos o cliente nem a aplicação online ao mesmo tempo, assim o MSMQ pode receber várias chamadas sem parar ou perder o processamento de outras mensagens. Não é possível hospedar serviços utilizando o netMsmqBinding no IIS 5.0 ou 6.0, somente no IIS 7.0.

6ª – se seu serviço provê suporte bidirecional entre WCF´s.

wsDualHttpBinding provê serviço bidirecional (duplex) na qual é possível utilizar chamadas via CallBack. wsDualHttpBinding também suporta comunicação via SOA. Não é possível hospedar serviços utilizando o netMsmqBinding no IIS 5.0 ou 6.0, somente no IIS 7.0.

Tags:

WCF