ESTUDO COMPARATIVO SOBRE APS.NET WEB SERVICES E WCF

ESTUDO COMPARATIVO SOBRE APS.NET WEB SERVICES E WCF Daniel Strassburger <dstrassburger@gmail.com> Edemar Costa <edemar.costa@gmail.com> Orientador Universidade Luterana do Brasil (Ulbra) Curso de Ciência da Computação Câmpus Canoas Av. Farroupilha, 8001 Bairro São José CEP 92425-900 Canoas - RS RESUMO 17 de Abril de 2011 Este artigo propõe a comparação entre dois sistemas orientados a serviços, um deles utilizando o método de ASP.NET Web Services e o outro utilizando o Windows Communication Foundation (WCF). A comparação tratará quesitos fundamentais na comunicação SOA, são eles: transações, segurança, reuso, interoperabilidade, aplicabilidade. O objetivo é mostrar as vantagens da migração para a nova tecnologia WCF. Palavras-chave: Comparação, Web Services, WCF, SOA. ABSTRACT Title: Comparative between Web Services ASMX and WCF Web Services This paper proposes the comparison between two service oriented systems, one of them utilizing the Web Services method e another utilizing the Windows Communication Foundation (WCF). The comparison will treat fundamental questions in the SOA communication, they are: transactions, security, reuse, interoperability, applicability. The goal is show the advantages of migration to new WCF technology. Key-words: Comparison, Web Services, WCF, SOA. 1 INTRODUÇÃO A comunicação entre aplicações é um item que cada vez mais é discutido e implementado nos dias de hoje. Com a grande quantidade de tecnologias e métodos difundidos existe uma série de formas para realizar a comunicação entre sistemas. Com a evolução das linguagens podemos identificar alguns conceitos antigos sobre comunicação entre aplicações, como bibliotecas estáticas (.lib) ou dinâmicas (.dll), interoperação e intercâmbio de componentes binários utilizando o Modelo de Objetos Componentes (Component Object Model COM). Cada conceito com suas vantagens e defeitos, mas com a era da Internet e sistemas Web, ficou quase impossível continuar com estas alternativas. Sendo assim criou-se a orientação a serviços onde este método incorporou todos os benefícios das metodologias anteriores e aperfeiçoando suas deficiências. Claro a orientação a serviços também tem uma série de desafios a vencer, a engenharia de software moderna é o refinamento contínuo dos níveis sempre crescentes de independência (LÖWY, 2010). O problema é qual e por que escolher tal solução. Com base neste dilema este artigo abordará um comparativo entre duas soluções de interoperabilidade: uma utilizando clássicos Web Services e outra utilizando WCF Web Services utilizando a linguagem ASP.NET com o Visual Studio 10. No item 2 deste artigo teremos o enfoque teórico sobre as metodologias e formas como podemos resolver o problema, onde falaremos sobre serviços, serviços Web, WCF e arquitetura orientada a serviços. No item 3 teremos a definição de solução proposta e no item 4 o cronograma. O item 5 abordará alguns detalhes da implementação e sua validação e por fim no item 6 é apresentada a conclusão sobre os resultados. 2 REFERENCIAL TEÓRICO Tratando-se de exposição e consumo de serviços muitas soluções podem ser encontradas, como Computação na nuvem (Cloud Computing), Software como serviço (SaaS) e Serviços Web (Web Services). Cada uma destas soluções possuem suas peculiaridades, no caso de Computação na nuvem temos a 1

definição de utilizar recursos que estão fisicamente em outro lugar longe de nossa organização. Já com SaaS temos ferramentas prontas para serem utilizadas e não é necessário mais licenças de software e sim taxas diluídas mas vitalícias. A terceira tecnologia é a disponibilização e consumo de Web Services de forma que a comunicação entre sistemas seja mais rápida, ágil e segura. Os projetistas de software devem optar pela melhor escolha para a empresa visando maximizar seus resultados e atender seus requisitos. Principalmente buscar a redução de custos desnecessários ao negócio, como por exemplo, gastos com infraestrutura, aplicações comuns, etc. Estimasse que 80% dos custos de TI são sobre manutenção em sistemas. Com o uso de Web Services há a viabilidade de comunicação entre aquele que disponibiliza e o que consome o serviço, mas também auxilia a integração e interoperabilidade entre sistemas heterogêneos (tecnologias diferentes, plataformas distintas, sistemas legados, etc.). Por esta razão a importância de utilizar os princípios de arquiteturas orientadas a serviços. 2.1 Histórico Tudo começou pela década de 20 onde foi construído o primeiro computador moderno eletromecânico, do tamanho de uma máquina de escrever. Pela década de 30 foi vendido aos Alemães e utilizado para criptografar toda a comunicação. Conhecido hoje como a máquina Enigma. A Enigma não era um computador de propósitos gerais: ela apenas conseguia fazer o ciframento e decodificação (hoje chamamos isso de encriptação e decriptação) (LÖWY, 2007, p. 476). Todo o algoritmo e lógica eram representados por rotores e se o usuário quisesse mudar este algoritmo teria que alterar a estrutura mecânica da máquina, trocar rotores, ordem, posição inicial e cabos. Segundo Löwy (2010), o algoritmo era dependente do problema para o qual foi programado e do projeto de hardware da máquina. Isso começou a mudar no final dos anos 40 e início dos anos 50, pois os primeiros computadores eletrônicos de propósitos gerais para objetivo de defesa. Agora as máquinas podiam executar códigos dirigidos para qualquer problema e não apenas um problema especifico. Ainda assim os códigos gerados nesta época eram ligados diretamente ao hardware não podendo ser executados em outros computadores. Na época isso não era problema visto que existiam poucos computadores úteis no mundo. E assim as linguagens foram evoluindo, na década de 60 já existiam linguagens de mais alto nível, como COBOL e FORTRAN, e introduziram o conceito de compiladores, o desenvolvedor iria escrever o programa de uma maneira e o compilador iria gerar os códigos que a máquina precisa saber. O problema agora era que a linguagem não era completamente estrutural, pois havia recursos de salto (Jump) e ir para (go to) que por muitas vezes causavam efeitos desastrosos em algoritmos que os usavam. 2.1.1 Linguagem estruturada Nos anos 70 nasceu às linguagens estruturadas propriamente ditas, como C e Pascal, uma verdadeira revolução onde desassociaram o código gerado de seu formato e estrutura interna introduzindo o conceito de funções e estruturas. Iniciaram-se também as pesquisas sobre Engenharia de Software, visando a redução de custos em computadores empresas iniciaram a tratar do reuso em suas aplicações. Em C o reuso é feito através da utilização de funções, mas com variáveis globais normalmente ocorre o problema de alterar uma variável e danificar outra função. O problema com o reuso baseado em função é que ela é dependente dos dados que manipula (LÖWY, 2007, p. 477). 2.1.2 Orientação a objetos Na década de 80 a solução para estes problemas foi proposta pela criação das linguagens orientadas a objetos, como Smalltalk, C++ e logo em seguida o Java. Agora a função e os dados estão em um mesmo objeto resolvendo o problema da linguagem estruturada. Funções se tornaram métodos, onde fica encapsulada a lógica e os dados encapsulados no objeto. Mas obviamente a orientação de objetos não era perfeita. O reuso exercido por uma classe que ainda esta em formato fonte fica restrito a uma determinada linguagem. Você não poderia ter um cliente de Smalltalk consumindo uma classe de C++ ou derivando dela (JÖWY, 2007, p. 477). De acordo com Jöwy (2007), a herança não é a melhor solução para o reuso, e em alguns casos provê mais problemas do que soluções, o desenvolvedor tem que estar familiarizado com a classe base da derivação, isso produz uma dependência vertical pela hierarquia de classe. Outro problema ocorria quando os objetos eram distribuídos entre processos ou computadores, não 2

era possível utilizar C++ comum para a invocação por exemplo, a alternativa era criar processos host e utilizar uma tecnologia alternativa para chamadas remotas, como soquetes TCP para fazer chamadas à distância, estas chamadas eram muito diferentes das chamadas originais da linguagem, consequentemente não era possível se beneficiar da mesma. 2.1.3 Orientação a componente E mais uma vez a necessidade de evolução era eminente, era necessário uma interoperabilidade entre sistemas. Após as bibliotecas estáticas (.lib) e dinâmicas (.dll) em 1994 foi criada pela Microsoft a tecnologia COM (Component Object Model Modelo de Objetos Componentes). A orientação a componente permite interoperação e intercâmbio de componentes binários (LÖWY, 2007, p. 477). Apesar de ser uma tecnologia inovadora, o COM não foi muito bem sucedido, pois a maioria dos desenvolvedores tinha problemas graves com sua implementação. Ela era feia sem necessidade porque era construída sobre um sistema operacional que não sabia de sua existência, e as linguagens usadas para escrever componentes COM eram orientadas a objeto mas não a componentes (LÖWY, 2007, p. 478). 2.1.4 Orientação a serviços Se analisarmos este breve histórico de engenharia de software podemos notar um padrão: novas tecnologias e métodos de desenvolvimento sempre incorporam os benefícios das antecessoras e aprimoram vários outros quesitos antes não abordados. Com outras palavras, dependência é ruim, mas é necessária. Um aplicativo absolutamente independente é inútil porque não adiciona nenhum valor. (LÖWY, 2007, p. 479). Ciente das dificuldades das tecnologias antecessoras, a orientação a serviço surgiu como uma alternativa para os problemas encontrados na orientação a objeto e da orientação a componente. A ideia principal da orientação a serviço é de que os desenvolvedores devem se preocupar com as regras de negócio e deixar que os quesitos segurança, escalabilidade e interoperabilidade a linguagem faça por si. Toda a sequência de comunicação entre serviço e cliente é feita através de mensagens padronizadas, o serviço por sua envia algum tipo metadados também padronizado, assim descreve o que pode fazer e como os clientes devem invocar as operações. 2.2 O que são Serviços Web? A criação, a popularização e a evolução da Internet trouxeram muita facilidade e comodidade aos seus usuários. No entanto, à medida que a rede foi crescendo, novas necessidades foram surgindo. Como por exemplo, a necessidade de integração dos sistemas computacionais de uma empresa, os quais implementam os processos de negócio da mesma, bem como a troca de informações com seus fornecedores, clientes e sócios, a fim de que a mesma consiga sobreviver e obter sucesso no contexto da economia de mercado atual que tem exigido que serviços sejam disponibilizados via Web. Foi neste contexto que surgiu a tecnologia Web Services, a qual visa à integração de sistemas computacionais e de serviços de forma que esta integração seja independente da localização geográfica destes sistemas e serviços, da plataforma sobre a qual os mesmos são executados, da linguagem de programação em que foram implementados, etc. No final do ano 2000, ano do seu surgimento, as empresas Oracle, HP, Sun, IBM, BEA e Microsoft (maiores fornecedoras de software para TI do mundo), anunciaram as suas intenções de utilizar os padrões Web Services (SOAP, WSDL e UDDI) em seus produtos. Desde então esta tecnologia tem sido alvo de muitas pesquisas e investimentos a fim de que se possa especificar e padronizar protocolos para solucionar alguns dos problemas ainda existentes em sua arquitetura, para que se tenha uma infraestrutura confiável para o seu desenvolvimento e implantação de modo que ela seja adotada de forma mais efetiva comercialmente. Nos últimos anos, a necessidade de conectar pessoas, informações e processos mudou a forma como o software vem sendo desenvolvido. Sistemas bem-sucedidos de TI exigem cada vez mais interoperabilidade entre plataformas e serviços flexíveis que possam evoluir facilmente com o tempo. Isso tem levado ao domínio de Extensible Markup Language (XML) como a linguagem universal para representar e transmitir dados estruturados que sejam independentes de linguagem de programação, plataforma de software e hardware. Criado sob a ampla aceitação de XML, os serviços da Web são aplicativos que usam transportes, 3

codificações e protocolos padrão para troca de informações. Uma definição objetiva um serviço Web é um sistema de software projetado para suportar interação máquina-máquina interoperáveis sobre uma rede (BOOTH et al, 2004). Com amplo suporte entre fornecedores e empresas, os serviços da Web permitem que sistemas de computação em qualquer plataforma se comuniquem pelas intranets e extranets da empresa e na Internet com suporte para segurança de ponta a ponta, serviços de mensagens confiáveis, transações distribuídas e muito mais. Utilizando Web Services, você pode trocar dados com acoplamento fraco na forma de mensagens XML entre sistemas heterogêneos. Apesar de o acesso remoto de dados e lógica de aplicação não é um conceito novo, fazendo isso com baixo acoplamento foi inovador. Tentativas anteriores, como o DCOM, IIOP e Java / RMI, requeria uma forte integração entre o cliente e o servidor. Ao invés de usar o contrato baseado em XML que é a base para serviços da Web, eles usavam os formatos de dados binários que são específicos do sistema operacional e implementação específica. Enquanto DCOM, IIOP e Java / RMI exigem uma tecnologia de determinado componente ou convenção no chamado de objetos, os serviços da Web não. A única suposição feita entre o cliente e o servidor é que os destinatários vão entender as mensagens que recebem. Em outras palavras, o cliente e o servidor concordam com um contrato, neste caso, um contrato que é definido usando WSDL e XSL Schema Definition (XSD). Em seguida, o cliente e o servidor comunicam-se por geração de mensagens que honraram o contrato através de um transporte especifico como o HTTP. Como resultado, programas escritos em qualquer linguagem - usando qualquer modelo componente - e executando em qualquer sistema operacional pode acessar Web Services. Além disso, a flexibilidade de um formato de texto como XML permitirá a troca de mensagens evoluírem com o tempo de maneira fracamente acoplada. Esse fraco acoplamento é obrigatório em ambientes onde a atualização simultânea de todas as partes na troca de mensagens não é possível. Os serviços da Web baseiam-se em um conjunto central de padrões que descrevem a sintaxe e a semântica da comunicação por software: o XML fornece a sintaxe comum para a representação de dados; o protocolo Simple Object Access Protocol (SOAP) fornece a semântica para a troca de dados; o Web Services Description Language (WSDL) fornece um mecanismo para descrever as capacidades de um serviço da Web. Especificações adicionais, conhecidas de um modo geral como a arquitetura WS-*, definem a funcionalidade de detecção, os sistemas de eventos, os anexos, a segurança, os serviços de mensagens confiáveis, as transações e o gerenciamento dos serviços da Web. Estas suas características devem-se em grande parte ao fato de se basearem em normas standard, de entre as quais se destacam: XML, SOAP, WSDL e UDDI. Um Web Service é semelhante na medida que é acessado através de uma URL. A diferença esta no conteúdo do que é enviado na requisição do cliente para o servidor. Os clientes de Web Service enviam um documento XML, formatado de uma maneira especial, de acordo com as regras da especificação SOAP (CERAMI, 2002). 2.3 ASP.NET Web Services É possível encontrar várias definições para Web Services como, Web Service é a lógica da aplicação disponível para outros programas através de protocolos padrões da Web independente de qualquer plataforma. Sobre a lógica da aplicação podemos definir que o Web Service expõe alguma lógica ou código da aplicação, isto pode ser cálculos ou operações ao banco de dados, por exemplo. Levando em conta que a maioria dos Web Sites hoje são acessados via Web Browser, logo Web Services serão acessados por programas. Todo o conceito de Web Service é baseado em protocolos padrões da Web como HTTP, XML, SOAP, WSDL e UDDI, será mostrado detalhes mais adiante neste artigo. Um Web Service pode ser implementado por qualquer plataforma pois os padrões citados anteriormente não são proprietários e são suportados pela maioria dos fabricantes e desenvolvedores de plataformas (BASIURA, 2001). Segundo Josuttis (2007), existem cinco padrões fundamentais para Web Services. Dois deles são padrões gerais que já existiam e foram usados no desenvolvimento dos Web Services: XML é usado como formato para descrever modelos, formatos e tipos de dados, ou seja, é a linguagem sobre a qual são construídas todas as linguagens de Web Services. HTTP (incluindo HTTPS) é o protocolo que irá transportar as mensagens geradas pelos Web Services. Os outros três padrões fundamentais são específicos para Web Services: 4

WSDL é usado para definir interfaces de serviço. Ele irá descrever dois diferentes aspectos de um serviço: sua assinatura (nome e parâmetros) e detalhes de protocolo e localização. Este padrão descreve exatamente o que o Web Service faz e como invocá-lo. SOAP é o padrão que define o protocolo do Web Service. Enquanto HTTP é o protocolo usado pela Internet, SOAP é o formato específico para troca de dados via Web Service. UDDI é o padrão para gerenciamento do Web Service, ou seja, registra e encontra serviços. 2.3.1 WSDL O WSDL descreve o serviço na forma bottom up (de baixo para cima). Inicia com os tipos usados e termina com a localização (ou endereço) do serviço. Com isso são formadas três camadas: A primeira camada descreve a interface do serviço. Esta interface (chamada de tipo de porta no WSDL 1.1) pode consistir de uma ou mais operações com entrada ou saída de parâmetros que usam tipos específicos na primeira sessão do arquivo WSDL. Existe algumas diferenças entre a versão WSDL 1.1 e a 2.0, não é o objetivo abordar com detalhes cada diferença mas sim mostrar a evolução do protocolo. No WSDL 1.1 os parâmetros do serviços são definidos nas sessões <message>, enquanto na versão WSDL 2.0 são definidos como qualquer outro tipo na sessão <types> (JOSUTTIS, 2007). A segunda camada define o binding (ligação) do Web Service. Isto é, o protocolo e formato para o qual as operações do Web Service são fornecidas. A terceira camada defina a localização física (endereço, URL) onde o Web Service está disponível. A imagem abaixo mostra as duas estruturas de WSDL 1.1 e WSDL 1.2 2.3.2 SOAP Figura 1 Estrutura do WSDL 1.1 e WSDL 2.0 As mensagens SOAP contêm um formato XML e o elemento root chamado <Envelope>. Ele pode conter um opcional <Header> e um elemento obrigatório <Body>. No elemento Body (corpo) contém o payload (carga útil), que são requisição, resposta ou dados de falha. O elemento Header (cabeçalho) pode conter informações adicionais para ajudar a lidar com a infraestrutura de mensagens (como por exemplo, dicas de roteamento e dicas de segurança) (JOSUTTIS, 2007). Abaixo é exemplificada uma requisição SOAP. Figura 2 Exemplo de requisição SOAP. 5

A mensagem de resposta a esta requisição deve conter o seguinte formato, mostrado na figura 3. 2.3.3 UDDI Figura 3 Exemplo de resposta a requisição SOAP. Inicialmente a UDDI era um termo mais amplo, Universal Description, Discovery, and Integration Business Registry (resumindo UDDI Business Registry ou ainda mais curto UBR). A ideia original era introduzir todas as três funções de um mercado de trabalho: fornecedores que oferecem serviços, consumidores que precisam de serviços, e corretores que reúnem por publicidade e localização de serviços (JOSUTTIS, 2007). Figura 4 UDDI - Fornecedores, consumidores e corretores. 2.4 O que é o WCF? Segundo Löwy (2010) o Windows Communication Foundation é um kit de Desenvolvimento de Software (SDK) para desenvolvimento e distribuição no Windows. O WCF fornece um ambiente de execução dinâmico para seus serviços, isto é, efetua a compilação e interpreta os códigos dos aplicativos. Embora seja possível o desenvolvimento de serviços sem o WCF, na prática fica significativamente mais fácil com ele. Esta ferramenta além de facilitar o desenvolvimento traz vários benefícios como mais segurança nos códigos devido sua estrutura bem formada e os padrões de mercado empregados, gerenciamentos de estados, métricas de desempenho e fácil implementação. De fato, o WCF foi construído com os aspectos de Service Oriented Architecture (SOA) em mente. 6

Cambiucci (2008) cita alguns: O design e a implementação de serviços são naturalmente desacoplados da lógica de negócios da aplicação. Essa característica é que permite a migração das aplicações atuais para um modelo de serviços; Serviços expõem funcionalidades para clientes remotos através de contratos explícitos de serviços e de dados; Serviços são executados de forma autônoma, não havendo impacto entre serviços quando da ocorrência de uma falha, ou seja, o isolamento é uma condição obrigatória entre serviços, assim como as fronteiras de segurança; Serviços podem ser distribuídos através de diferentes protocolos, o que atende uma série de cenários presentes no ambiente corporativo. A interoperabilidade é uma exigência; Serviços são agnósticos ao transporte, ou seja, podem ser expostos diretamente na web, via intranet, ou usado como um backend no enterprise; Resumindo, serviços são orientados a mensagens, possuem contratos de serviços e de dados, são multi-protocolos e multi-hosts, com aspectos de segurança, isolamento, políticas, monitoração, comportamentos, etc. Todos esses aspectos são atendidos pelo modelo de programação do WCF. Ainda, através do ABC do WCF (onde Endpoint = Addess + Binding + Contract) é possível uma grande flexibilidade na implantação e configuração de serviços em diversos ambientes de TI. Desde as versões 1.0 do.net Framework é possível implementar serviços Web como os encontrados no mercado, com a diferença do desenvolvedor poder utilizar os recursos nativos do framework na sua construção. Entre estes recursos estão: autenticação, cache e gerenciamento de estado. A partir do.net Framework 3.0 a Microsoft unificou as várias tecnologias de programação para sistemas distribuídos em um único modelo visando a arquitetura orientada à serviços (SOA). Uma das principais características desta nova API é o fato do WCF ser totalmente desacoplado das regras de negócio que serão expostos pelo serviço. A tecnologia WCF possui muitas funcionalidades que visam performance, segurança, disponibilidade, transações, sincronizações e tratamento de erros. (LÖWY, 2007) 2.5 Arquitetura orientada a serviços Uma Arquitetura Orientada a Serviços (SOA) é baseada em quatro abstrações principais: um frontend de aplicação, um serviço, um repositório de serviços e um barramento de serviços. O W3C conceitua SOA como um conjunto de componentes que podem ser invocados e ter suas descrições de interface publicadas e descobertas. As tecnologias RMI, DCOM, CORBA e DCE são exemplos de sistemas SOA. (HAAS, BROWN, 2004). O frontend da aplicação é desacoplado dos serviços. Cada serviço tem um contrato que define o que você irá fazer e uma ou mais interfaces para implementar o contrato. O repositório de serviços fornece um lar para os serviços, e o barramento de serviços fornece um mecanismo de padrão industrial para a conexão e interação com os serviços. Os arquitetos das empresas veem a SOA como um meio de ajudar os negócios a responder mais rapidamente e com melhor relação custo-benefício às condições do mercado, que estão em constate mudança. Durante o evento SOA & Business Processes Conference 2007, realizado em Redmond, USA, a Microsoft apresentou para o mercado uma arquitetura de referência para projetos de SOA, como uma proposta para a organização de camadas e serviços, como vemos na figura abaixo: 7

Figura 5 - Arquitetura de Referência SOA proposta pela Microsoft. Cambiucci (2009) descreve as principais camadas da arquitetura de referência SOA: Primeiro, notamos uma camada de aplicações compostas ou consumidores, que é destinada para as interfaces de composição de serviços da solução. Aqui, temos nossas interfaces e aplicações combinam serviços e chamadas de processos da infraestrutura; Logo abaixo, temos a camada de composição de negócios ou processos, onde orquestrações e workflows podem consumir serviços ou tratar regras de negócio, de acordo com as necessidades da solução; Na sequência, temos acamada de serviços atômicos ou de composição, que implementam as interfaces de serviços propriamente ditas. Baterias de Web Services ou serviços hospedados em servidores IIS são exemplos para essa camada; Suportando os serviços acima, encontramos os componentes de serviços que podem ser componentes legados, exportando funcionalidades existentes de nossa infraestrutura; Por último, a camada de integração ou legado (LoB Line of Business Application), onde encontramos nossos sistemas nativos, bancos de dados e soluções existentes que pretendemos exportar para outras áreas da empresa, por exemplo; Atendendo todas as camadas encontramos as bibliotecas comuns, necessárias para a manutenção, administração e operação da solução. Assim, vemos as camadas verticais do desenho, que implementam monitoração, autorização, segurança, controle de acesso, auditoria, etc. São bibliotecas básicas, construídas ao longo do projeto ou fornecidas por alguma ferramenta de operação de serviços. Em muitos casos, barramentos de serviços oferecem essas funcionalidades de forma nativa, economizando algum tempo de desenvolvimento para o projeto. Um fator de sucesso em muitos projetos de SOA tem sido a adoção de uma arquitetura de referência, que posiciona corretamente as camadas e componentes da solução. Em muitos casos, essa estruturação garante o respeito de interfaces de forma padronizada, assim como a coesão e responsabilidades previstas para cada camada, fornecendo o mínimo de organização e facilidade de manutenção futura. 2.6 Justificativa Como visto nos itens acima temos formas diferentes de obter resultados que nos levam a ter uma aplicação em SOA. Como o conceito de Web Services é mais antigo muitas aplicações já foram construídas neste modelo. Este artigo irá abordar vantagens e auxiliará em uma possível migração de Web Services para WCF. Objetivando entender desde a sua estrutura de projeto até detalhes relacionados à execução do mesmo. Cada uma das seções a seguir irá analisar e discutir essas mudanças, falando também sobre alguns detalhes importantes que, se não se atentar, poderá ter um comportamento estranho durante a execução. 8

3 METODOLOGIA Com base nestas diferenças entre WCF e ASP.NET Web Services (ASMX) uma comparação de performance entre estes serviços é vital para uma análise de custo-benefício em sua implementação. Isto ajudará muito em uma analise de migração ou investimentos para começar a utilizar tais tecnologias. Mas não apenas a performance será comparada neste artigo. Serão realizados testes abordando as principais características de cada tecnologia, como segurança, aplicabilidade, reuso e expansibilidade. Será criado um ambiente de testes onde serão executados testes pontuais analisando desempenho, segurança, escalabilidade e aplicabilidade. Será implementado em um ambiente de produção que atualmente utiliza ASP.NET Web Services e será migrado para utilizar o WCF. Serão reestruturadas as camadas da arquitetura com base em SOA. Neste ambiente serão apresentadas três aplicações de uma empresa de venda de computadores. Estes sistemas são: sistema de vendas, suporte e financeiro. Inicialmente o problema de comunicação entre estes sistemas é resolvido através do uso de ASP.NET Web Services e troca de arquivos de importação. Será desenvolvida uma camada para comunicação entre estas aplicações utilizando o WCF e assim efetuar os testes nas duas formas de solução. O Objetivo é mostrar todos os benefícios e detalhes de uma solução robusta e evolutiva, aplicando o WCF em um ambiente real de produção. 3.1 Ambiente Em todos os testes que serão efetuados utilizaremos o mesmo ambiente. Um servidor com processador Intel Xeon Processor X5680 (12M Cache, 3.33 GHz, 6.4), 12 GB de memória RAM e placa de rede 1 Gbps o sistema operacional é Windows Server 2008 R2. Os clientes serão 4 computadores com processadores Core 2 Duo 3.0 GHz, 2GB de memória RAM e placa de rede de 1 Gbps. A infraestrutura é detalhada na Figura 2, logo abaixo. Servidor Cliente 1 Cliente 2 Cliente 3 Cliente 4 Switch 3.2 Performance de Transações 1GB Ethernet Figura 6 Infraestrutura para realização dos testes. Inicialmente será desenvolvida duas soluções em cada uma das tecnologias, WCF e ASP.NET Web Services, estas soluções não irão ter nenhuma boa prática inclusa apenas os requisitos mínimos para que se posa efetuar uma transação com sucesso. Cada uma das aplicações será formada de um processo de requisição e resposta, padrão das duas tecnologias. A requisição enviará um número inteiro e será retornada uma coleção de objetos criados no servidor. Esta coleção de objetos será padrão nas duas aplicações, podemos conferir a criação desta carga na figura 3. Ordem[] GetOrdens(int NumOrderns); { Ordem[] ordens = new Ordem[numOrdens]; for (int i = 0; i < numordens; i++) { Ordem ordem = new Ordem(); 9

} OrdemLinha[] linhas = new OrdemLine[2]; linhas[0] = new OrdemLine(); linhas[0].itemid = 1; linhas[0].quantidade = 10; linhas[1] = new OrdemLine(); linhas[1].itemid = 2; linhas[1].quantitidade = 5; ordem.ordemitens = lines; ordem.clienteid = 100; ordem.endereco1 = "012345678901234567890123456789"; ordem.endereco2 = "012345678901234567890123456789"; ordem.cidade = "0123456789"; ordem.estado = "0123456789012345"; ordem.cep = "12345-1234"; ordem.pais = "United States"; ordem.tipoenvio = "Courier"; ordem.cartaocreditotipo = "XYZ"; ordem.numerocartao = "0123456789012345"; ordem.validadecartao = DateTime.UtcNow; ordem.nomecartao = "01234567890123456789"; ordens[i] = ordem; } return ordens; Figura 7 Código que irá criar processamento no serviço. Com este cenário será possível simular um ambiente de produção e realizar a contagem de transações que cada uma das aplicações pode oferecer por segundo. No teste é será deixado o servidor trabalhando próximo de 100% de processamento em ambos os testes. Faremos testes com um Core e 4 Cores para analisarmos as diferenças. Este teste mostrará o poder de performance do WCF e do APS.NET Web Services, claro que uma aplicação SOA temos muitos mais para avaliar do que transações simples e isso veremos nos próximos itens. Assim o resultado esperado é que o WCF forneça mais transações do que o ASP.NET Web Services. O resultado será apresentado em gráficos mostrando a superioridade do WCF em performance. 3.3 Segurança A proposta consiste também em realizar um estudo sobre segurança onde será abordado quesitos básicos de segurança do ASP.NET Web Services e do WCF. Apesar das duas formas poderem utilizar o protocolo HTTPS o WCF consegue ter mais recursos de segurança nativamente e quando é desenvolvida uma aplicação SOA é fundamental relacionarmos este quesito. Serão abordadas as principais funcionalidades fornecidas pelo WCF para o gerenciamento de autenticação e autorização de serviços, abordando as vantagens e desvantagens de cada modo. É de comum conhecimento que o ASP.NET Web Services provê a segurança apenas no nível do Internet Information Services (IIS) e o WCF já consegue embutir várias funcionalidades em seu código visto que não é necessariamente publicado pelo IIS. O resultado esperado é um detalhamento dos quesitos de segurança de cada uma das tecnologias, tendo um pouco mais de segurança os serviços em WCF. E será validado na implementação da solução, acionando todos os requisitos de segurança. 3.4 Representação dos dados Será feita uma análise das diferenças na representação de dados entre ASP.NET Web Services e WCF. Neste item será abordada a maneira como é padronizado o código. Análise irá detalhar algumas diferenças nas Classes utilizadas por cada uma das tecnologias, assim identificando suas vantagens e desvantagens. 3.5 Camada de serviços Neste ambiente de aplicações utilizando a comunicação através de alguns ASP.NET Web Services e 10

arquivos de importação, muito tempo e confiabilidade se perdem. Até mesmo o desenvolvimento de novas aplicações fica comprometido nesta estrutura. Será criada uma camada de serviços WCF para esta organização de vendas de computadores, inicialmente para ligar apenas os três sistemas informados, vendas, suporte e financeiro. A camada de serviços será completamente independente das aplicações e adequações serão feitas nas antigas aplicações para que as sejam suportadas as trocas de informações. 3.5.1 Reuso Será realizada uma analise na estrutura do código visando o reuso. Quanto que é possível reutilizar os Web Services desenvolvidos em ASP.NET e quanto é possível reusar os serviços WCF. Esta analise é um pouco mais cuidadosa devido ao tempo que deve se levar para termos confirmações. 3.5.2 Migração Com o desenvolvimento desta nova plataforma analisaremos quesitos importantes como o tempo de desenvolvimento, dificuldade da estrutura, compatibilidade. Com o objetivo de definir o cenário de quando é vantajoso realizar uma migração de plataforma, ou quando é interessante desenvolver novamente toda a estrutura de comunicação entre sistemas de uma corporação. 4 CRONOGRAMA Abaixo é demostrado o cronograma proposta para este trabalho. Atividade Início Fim Dias Analise dos requisitos iniciais 01/08/2011 15/08/2011 15 dias Revisão de métodos e comunicação 15/08/2011 30/08/2011 15 dias Revisão dos requisitos 01/09/2011 05/09/2011 5 dias Ajustes de ambiente 05/09/2011 10/09/2011 15 dias Programação 10/09/2011 10/10/2011 30 dias Métodos de sincronização 10/10/2011 20/10/2011 10 dias Testes e validação dos usuários ambiente teste 20/10/2011 30/10/2011 10 dias Implementação e testes em ambiente de produção 01/11/2011 15/11/2011 15 dias Conclusões e encerramento do projeto 15/10/2011 30/11/2011 15 dias 5 CONCLUSÃO Com este estudo será mostrada todas as vantagens do WCF e benefícios com sua utilização. Ganhos de performance e escalabilidade, fundamentais para as organizações hoje em dia. Como o assunto é relativamente novo a documentação sobre tais testes ainda deixam a desejar, este estudo irá ajudar poderá ser uma base de conhecimento e resultados significativos para desenvolvimento de aplicações comerciais. REFERÊNCIAS LÖWY, Juval. Programming WCF Services. 3 ed. Sebastopol: Ed. O Reilly Media, Inc., 2010. LÖWY, Juval. Programando Serviços WCF. 1 ed. Sebastopol: Ed. O Reilly Media, Inc., 2007. SHODJAI, Payam. Serviços da Web e a plataforma Microsoft. [S. l], MSDN, 28 ago 2006. 47 f. Disponível em: <http://msdn.microsoft.com/pt-br/library/aa480728.aspx>. Acesso em: 17 abr. 2011. KHAN, Iqbal. Address Scalability Bottlenecks with Distributed Caching. [S. l], MSDN Magazine, jun. 2010. 12 f. Disponível em: <http://msdn.microsoft.com/pt-br/magazine/ff714590.aspx#>. Acesso em: 17 abr. 2011. CAMBIUCCI, Waldemir. Cenários de implementação de serviços com WCF - Parte 1 : Aspectos de 11

SOA. [S. l], MSDN Blogs, jun. 2008. 3f. Disponível em: <http://blogs.msdn.com/b/wcamb/archive/2008/06/25/cen-rios-de-implementa-o-de-servi-os-com-wcf-parte- 1-aspectos-de-soa.aspx>. Acesso em: 17 abr. 2011. CAMBIUCCI, Waldemir. Uma introdução ao Software + Serviços, SaaS e SOA. [S. l], MSDN Library, maio 2009. 23f. Disponível em: <http://msdn.microsoft.com/pt-br/library/dd875466.aspx>. Acesso em: 17 abr. 2011. LIBERTY, Jesse; HOROVITZ, Alex. Programming.NET 3.5. Sebastopol: Ed. O Reilly Media, Inc., jul. 2010. BOOTH, David et al. Web Services Architecture. [S. l], W3C, fev. 2004. 98f. Disponível em: <http://www.w3.org/tr/ws-arch/>. Acesso em: 24 abr. 2011. CERAMI, Ethan. Web Services Essentials. 1 ed. Sebastopol: Ed. O Reilly Media, Inc., 2002. BASIURA, Russ et al. Professional ASP.NET Web Services. Birmingham: Ed. Wrox Press Ltd, 2001. JOSUTTIS, Nicloai. SOA in Practice. Sebastopol: Ed. O Reilly Media, Inc., ago. 2007. 12