1

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

29 de Novembro de 2011

RESUMO

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 (ASMX) e o outro utilizando o Windows Communication Foundation (WCF). A

comparação abordou quesitos fundamentais na comunicação orientada a serviços. São eles: transações, segurança,

reúso, interoperabilidade e aplicabilidade. O objetivo é mostrar as vantagens da migração para a nova tecnologia

WCF.

Palavras-chave: Comparação, Web Services, WCF, ASMX, SOA.

ABSTRACT

Title: “Comparative study between ASP.NET Web Services and WCF Web Services”

This paper proposes the comparison between two service oriented systems, one of them utilizing the ASP.NET

Web Services (ASMX) method and the other utilizing the Windows Communication Foundation (WCF). The

comparison treated fundamental questions in the oriented communication services: transactions, security, reuse,

interoperability, applicability. The goal is to show the advantages of migration to new WCF technology.

Key-words: Comparison, Web Services, WCF, ASMX, SOA.

1 INTRODUÇÃO

A comunicação entre aplicações é um item cada vez mais discutido e implementado. Devido à

quantidade de tecnologias e métodos difundidos nos dias de hoje, existe grande variedade de formas

destinadas a realizar a comunicação entre sistemas.

Com a evolução das linguagens, identifica-se 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 COM (Component Object Model). Cada conceito, com suas vantagens e defeitos. No

entanto, na era da internet e dos sistemas web, não há necessidade de continuar utilizando alternativas

legadas.

Sendo assim, criou-se a orientação a serviços, conceito ao qual este método incorporou os benefícios

das metodologias anteriores, aperfeiçoando seu desempenho. Claro, a orientação a serviços também

apresenta desafios. “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 com a linguagem ASP.NET e o Visual Studio 10.

O item 2 deste artigo terá enfoque teórico sobre as metodologias e formas de resolver o problema, ao

referir-se a serviços, serviços Web, WCF e arquitetura orientada a serviços. O item 3, apresentará a definição

da solução proposta, e o item 4 mostrará a validação dos dados. Por fim, no item 6, será feita a conclusão,

baseada nos 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 tem suas peculiaridades. No caso de computação na nuvem, o conceito é utilizar

2

recursos que estão fisicamente em outro lugar, longe do usuário. Já com SaaS, temos ferramentas prontas

para serem utilizadas e não é necessário 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 forma de comunicação mais adequada à empresa,

visando a maximizar seus resultados e a 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. Estima-se

que até 90% dos custos de TI (tecnologia da informação) são relativos à manutenção em sistemas legados

(PIGOSKI, 1996).

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.). Daí, 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 1920, na Polônia, quando foi construído o primeiro computador

eletromecânico, do tamanho de uma máquina de escrever. Na década de 1930, esse computador foi vendido

aos alemães, sendo utilizado para criptografar a comunicação. Hoje ele é conhecido 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 1940 e início dos anos 1950, quando os primeiros

computadores eletrônicos de propósitos gerais passaram a admitir o desenvolvimento de algoritmos. Agora

as máquinas podiam executar códigos dirigidos para qualquer problema e não apenas a um problema

especifico para diversos problemas. Durante a Segunda Guerra Mundial, foi usado com o objetivo de defesa.

Ainda assim, os códigos gerados nessa época eram ligados diretamente ao hardware, não podendo ser

executados em outros computadores. Mas isso não era problema, visto que existiam poucos computadores

úteis no mundo todo.

E, assim, as linguagens foram evoluindo. Na década de 1960 já existiam linguagens de mais alto

nível, como Cobol e Fortran, que introduziram o conceito de compiladores: o desenvolvedor escreveria o

programa de uma maneira, e o compilador geraria os códigos de que a máquina necessitava. O problema

agora era que a linguagem não era completamente estrutural, pois havia recursos de salto (jump) e ir para (go

to), que muitas vezes causavam efeitos desastrosos nos algoritmos que os usavam.

2.1.1 Linguagem estruturada

Nos anos 1970, nasceram as linguagens estruturadas, propriamente ditas, como C e Pascal. Uma

verdadeira revolução, no qual 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 à redução de custos. Empresas começaram a tratar do reúso em suas aplicações. Em C, o

reúso é feito através da utilização de funções. Mas, com variáveis globais, é comum ocorrerem alterações, o

que pode danificar uma ou mais funções. “O problema com o reúso baseado em função é que ele é

dependente dos dados que manipula” (LÖWY, 2007, p. 477).

2.1.2 Orientação a objetos

Na década de 1980, 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. As funções se tornaram métodos, nos

quais fica encapsulada a lógica da programação, enquanto os dados se tornaram atributos do objeto.

Obviamente, a orientação de objetos não era perfeita. O reúso exercido por uma classe que ainda está

em formato fonte fica restrito a determinada linguagem. “Você não poderia ter um cliente de Smalltalk

consumindo uma classe de C++ ou derivando dela” (LÖWY, 2007, p. 477).

3

De acordo com Löwy (2007), a herança não é a melhor solução para o reúso, e em alguns casos

provê mais problemas do que soluções. O desenvolvedor tem que estar familiarizado com a classe base da

derivação, e isso produz uma dependência vertical devido à hierarquia de classe.

Outro problema ocorria quando os objetos eram distribuídos entre processos ou computadores. Por

exemplo, não era possível utilizar C++ comum para a invocação. A solução era criar processos host e utilizar

uma tecnologia alternativa para chamadas remotas, como soquetes TCP (Transmission Control Protocol)

para fazer chamadas a distância. Essas chamadas eram muito diferentes das chamadas originais da

linguagem, consequentemente, não era possível beneficiar-se delas.

Figura 1 – Linguagem estruturada e orientada a objetos (SANTOS)

1.

2.1.3 Orientação a componente

E mais uma vez a necessidade de evolução era iminente, exigindo melhor interoperabilidade entre

sistemas. Em 1994, após um longo período de utilização das bibliotecas estáticas (.lib) e dinâmicas (.dll), foi

criada, pela Microsoft, a tecnologia COM. “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

Com este breve histórico de engenharia de software, é possível notar um padrão: novas tecnologias e

métodos de desenvolvimento sempre incorporam os benefícios das antecessoras e aprimoram vários outros

quesitos não abordados antes. 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 na orientação a componente. A ideia

principal da orientação a serviço é a 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 vez, envia um metadado também padronizado, que descreve o que o serviço pode fazer e

como os clientes devem invocar as operações.

1 Figura obtida no site www.webfinal.com.br.

4

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

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. Esses sistemas

implementam os processos de negócio e a troca de informações com fornecedores, clientes e sócios. O

objetivo é sobreviver e obter sucesso no atual contexto da economia de mercado, que tem exigido que os

serviços sejam disponibilizados via web.

Foi neste contexto que surgiu a tecnologia de serviços web, 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 de 2000, ano do surgimento dos serviços web, as empresas Oracle, HP, Sun, IBM, BEA e

Microsoft (maiores fornecedoras de software para TI do mundo) anunciaram a intenção de utilizar esses

padrões 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. O objetivo é ter 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 XML (Extensible Markup Language) 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,

codificações e protocolos-padrão para troca de informações. “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 serviços web, pode-se trocar dados com acoplamento fraco na forma de mensagens XML

entre sistemas heterogêneos. O acesso remoto a dados e a lógica da aplicação são conceitos antigos, mas

atuando com baixo acoplamento tonaram-se inovadores. Tentativas anteriores – como o modelo de objetos

componentes distribuídos (DCOM - Distributed Component Object Model), Internet Inter-ORB Protocol

(IIOP) e Java Remote Method Invocation (RMI) – requeriam forte integração entre o cliente e o servidor. Ao

invés de usar o contrato baseado em XML, que é essencial para serviços da web, eles usavam os formatos de

dados binários, específicos do sistema operacional e de sua implementação.

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 mensagens, confirmando que

honraram o contrato através de um transporte especifico, como o Hypertext Transfer Protocol (HTTP).

Como resultado, temos programas escritos em qualquer linguagem e sendo executados em qualquer sistema

operacional – usando qualquer modelo componente – e podendo utilizar o serviço web. Além disso, a

flexibilidade de um formato de texto como XML permitirá a evolução da troca de mensagens de maneira

fracamente acoplada. Esse fraco acoplamento é obrigatório em ambientes em que não seja possível a

atualização simultânea de todas as partes na troca de mensagens.

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.

5

Especificações adicionais, conhecidas de modo geral como 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 características dos serviços web se devem, em grande parte, ao fato de basearem-se em normas

padrões, dentre as quais se destacam: XML, SOAP, WSDL e UDDI (Universal Description, Discovery and

Integration). O acesso a um serviço web é semelhante a qualquer requisição feita através de uma URL

(Uniform Resource Locator). A diferença está no conteúdo do que é enviado na requisição do cliente para o

servidor. Os clientes enviam um documento XML, formatado de maneira especial, de acordo com as regras

da especificação SOAP (CERAMI, 2002).

2.3 ASP.NET Web Services

Dentre várias definições para Web Services encontradas, uma delas é; o Web Service é a lógica da

aplicação disponível para outros programas, através de protocolos padrões da web e independente de

qualquer plataforma. Sobre a lógica da aplicação, pode-se afirmar que o Web Service expõe alguma lógica ou

código da aplicação, que podem ser cálculos ou operações ao banco de dados, por exemplo. Levando em

conta que a maioria dos sites, hoje, são acessados via navegador, 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, que serão mostrados em detalhes, mais adiante, neste artigo. Um Web Service pode

ser implementado por qualquer plataforma. 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 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 é 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:

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 a 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 bottomup (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 pode consistir em 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. Existem algumas diferenças entre a versão WSDL 1.1 e a 2.0, mas não é o objetivo abordar com

detalhes cada diferença, e sim mostrar a evolução do protocolo. No WSDL 1.1, os parâmetros dos serviços

são definidos nas sessões “<message>”, enquanto na versão WSDL 2.0 são definidos como qualquer outro

tipo na seçã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 define a localização física (endereço,

URL) onde o Web Service está disponível. A figura 2 mostra as duas estruturas de WSDL 1.1 e WSDL 1.2.

6

Figura 2 – Estrutura do WSDL 1.1 e WSDL 2.0.

2.3.2 SOAP

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>”. O elemento Body (corpo) contém o

payload (carga útil), que pode ser uma requisição, uma 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 3 – Exemplo de requisição SOAP.

A mensagem de resposta a esta requisição deve conter o formato mostrado na Figura 4.

Figura 4 – Exemplo de resposta a requisição SOAP.

2.3.3 UDDI

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

7

introduzir as três funções de um mercado de trabalho: fornecedores que oferecem serviços, consumidores

que precisam de serviços e corretores que agrupam esses serviços para publicá-los (JOSUTTIS, 2007).

Figura 5 – 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, esse desenvolvimento 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 à estrutura bem formada, aos padrões de mercado empregados, aos gerenciamentos de

estados, às métricas de desempenho e à fácil implementação.

De fato, o WCF foi construído com os aspectos de SOA (Service Oriented Architecture) em mente.

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 eles quando ocorre 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 a 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 em ambientes corporativos.

Resumindo, serviços são orientados a mensagens, possuem contratos de serviços e de dados, são

multiprotocolos e multihosts, 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 = Address + Binding + Contract) é possível uma

grande flexibilidade na implantação e configuração de serviços em diversos ambientes de TI.

Desde a versão 1.0 do .NET Framework é possível implementar serviços web como os encontrados

no mercado, com a diferença de que o desenvolvedor pode utilizar os recursos nativos do framework em 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

8

sistemas distribuídos em um único modelo, visando a arquitetura orientada a serviços (SOA). Uma das

principais características desta nova API (Application Programming Interface) é o fato do WCF ser

totalmente desacoplado das regras de negócio que serão expostas pelo serviço. A tecnologia WCF tem

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 será feito e apresenta uma ou mais interfaces para implementar esse 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, EUA, 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, conforme é visto na figura 8.

Figura 6 - Arquitetura de Referência SOA proposta pela Microsoft.

Cambiucci (2009) descreve as principais camadas da arquitetura de referência SOA.

Primeiro, percebe-se uma camada de aplicações compostas, que é destinada às interfaces de

composição de serviços da solução. Aqui, as 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, aparece a camada 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 (Internet Information Services) são exemplos para essa camada.

Apoiando os serviços acima, encontramos os componentes de serviços, que podem ser

componentes legados, exportando funcionalidades existentes de nossa infraestrutura.

9

Por último, a camada de integração ou legado (LoB - Line of Business Application), em que se

encontram sistemas nativos, bancos de dados e soluções que podem ser exportadas, para outras

áreas da empresa, por exemplo.

Atendendo a 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, existe formas diferentes de obter resultados que resulta em uma

aplicação SOA. Sendo 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 à sua execução. Cada uma

das seções a seguir irá analisar e discutir essas mudanças, mostrando também alguns detalhes importantes

que poderão apresentar um comportamento “estranho” durante a execução, caso não sejam identificados a

tempo.

3 METODOLOGIA

Com base nestas diferenças entre WCF e ASP.NET Web Services (ASMX), uma comparação de

desempenho entre estes serviços é vital para a análise de custo-benefício em sua implementação. Isto ajudará

muito em uma migração ou aquisição de investimentos para começar a utilizar tais tecnologias. Mas não

apenas a performance foi comparada neste artigo. Foram realizados testes, abordando as principais

características de cada tecnologia, como segurança, aplicabilidade, reúso e expansibilidade.

Foi criado um ambiente de testes em que foram executados testes pontuais, analisando desempenho,

segurança, escalabilidade e aplicabilidade. Além disso, foi realizada a análise de migração em um ambiente

de produção que anteriormente utilizava ASP.NET Web Services e passou a utilizar o WCF. Foram

reestruturadas as camadas da arquitetura com base em SOA.

Neste ambiente foram apresentadas três aplicações de uma empresa de venda de computadores.

Essas aplicações são: sistema de vendas, sistema de suporte e sistema financeiro. Inicialmente, o problema

de comunicação entre esses sistemas era resolvido através do uso de ASP.NET Web Services e troca de

arquivos.

Foi desenvolvida uma camada para comunicação entre estas aplicações, utilizando o WCF e, assim,

efetuados 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 foi utilizado o mesmo ambiente. Um servidor com processador Intel® Xeon®

X5680 (12M Cache, 3.33 GHz, 6.4), 12 GB de memória RAM, placa de rede 1 Gbps e o sistema operacional

Windows Server 2008 R2. Os clientes serão quatro 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 7. O servidor web

responsável pela exposição dos serviços será o IIS 7.0.

10

Servidor

Switch

1GB Ethernet

Cliente 1 Cliente 2 Cliente 3 Cliente 4

Figura 7 – Infraestrutura para realização dos testes.

3.2 Performance de operações

Inicialmente, foram desenvolvidas duas soluções em cada uma das tecnologias, WCF e ASP.NET

Web Services. Estas soluções não terão nenhuma boa prática inclusa, apenas os requisitos mínimos para que

se possa efetuar uma transação com sucesso.

Cada uma das aplicações será formada por um processo de requisição e resposta, padrão das duas

tecnologias. A requisição enviará um número inteiro e terá como resposta uma coleção de objetos criados no

servidor. Esta coleção de objetos será padrão nas duas aplicações e pode ser conferida na Figura 8.

Ordem[] GetOrdens(int NumOrderns);

{

Ordem[] ordens = new Ordem[numOrdens];

for (int i = 0; i < numOrdens; i++)

{

Ordem ordem = new Ordem();

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 8 – Código que irá criar processamento no serviço.

Com este cenário foi 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. Nos testes executados, tanto no ASP.NET Web

Services quanto no WCF, o servidor trabalhou com o processamento próximo a 100% de utilização.

Este teste mostrou o poder de desempenho do WCF e do APS.NET Web Services. Contudo, uma

11

aplicação SOA requer análises em diversas variáveis, e isso será abordado nas próximas subseções.

3.3 Segurança

Foi desenvolvido um estudo sobre segurança em que foram abordados quesitos básicos do ASP.NET

Web Services e do WCF. Apesar de as duas formas poderem utilizar o protocolo HTTPS (Hypertext Transfer

Protocol Secure), o WCF consegue ter mais recursos de segurança nativamente e, quando é desenvolvida

uma aplicação SOA, é fundamental que este quesito seja relacionado.

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, serão explanadas na

validação de segurança.

O ASP.NET Web Services provê a segurança apenas no nível do 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 os principais requisitos de segurança.

O ASMX pode confiar somente na segurança baseada no transporte, ou seja, ele somente será seguro

se o serviço for exposto através de HTTPS. Só se pode abrir mão do HTTPS se for utilizada a segurança

baseada na mensagem, que está disponível no ASMX, através do Web Services Enhancements (WSE).

Muitas vezes se utiliza um “SoapHeader” com usuário e senha. Isso somente terá alguma segurança se

utilizar HTTPS ou segurança em nível de mensagem. Do contrário, qualquer um que intercepte a requisição,

conseguirá extrair o conteúdo da mensagem e seus respectivos headers.

Como já era de se esperar, o WCF fornece ambos os níveis de segurança nativamente. São

configurações que se realizam (de forma imperativa ou declarativa), e que o serviço utilizará para efetuar a

autenticação e a autorização do cliente. Uma das grandes dificuldades encontradas ao utilizar-se o WCF é

que, mesmo se ele for configurado para autenticar o cliente, será necessário utilizar um certificado para

garantir a segurança.

3.4 Representação dos dados

Foi 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.

A análise detalhou algumas diferenças nas classes utilizadas por cada uma das tecnologias,

identificando assim 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

arquivos de importação, muito tempo e confiabilidade se perdem. Até mesmo o desenvolvimento de novas

aplicações fica comprometido nesta estrutura.

Foi 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 é completamente independente das aplicações, e adequações foram feitas nas

antigas aplicações para que as trocas de informações sejam suportadas.

3.5.1 Reuso

Foi realizada uma análise na estrutura do código, visando o reúso: quanto é possível reutilizar os

Web Services desenvolvidos em ASP.NET e quanto é possível reusar os serviços WCF. Esta análise exige

um pouco mais de cuidado devido ao tempo necessário para confirmações.

3.5.2 Migração

Com o desenvolvimento desta nova plataforma, analisamos quesitos importantes, como tempo de

desenvolvimento, dificuldade da estrutura e compatibilidade. O objetivo é determinar a ocasião mais propícia

para realizar uma migração de plataforma ou quando será necessário desenvolver novamente toda a estrutura

de comunicação.

12

4 VALIDAÇÃO

Os resultados obtidos com este trabalho serão abordados nas subseções a seguir.

4.1 Desempenho

Com os testes de desempenho, foi identificada uma melhora de 12%, 13% e 52% para requisições de

1, 10 e 100 objetos respectivamente.

Nesta seção, a comparação feita tem o objetivo de mensurar o desempenho dos serviços e nenhuma

segurança foi utilizada. O WCF binding utilizado foi o “BasicHttpBinding”. Esta ligação padrão utiliza

HTTP como protocolo de transporte.

A hospedagem dos serviços foi feita no IIS 7.0, deixando exposto apenas um serviço. O binding

utilizado foi o “BasicHttpBinding”, para o WCF Service e o protocolo HTTP para o ASP.NET Web Service.

A figura abaixo ilustra as camadas de um serviço que utiliza este protocolo.

Figura 9 – Camadas utilizando o BasicHttpBinding.

Todos os testes executados empregaram a mesma configuração de hardware apresentada na sessão

3.1. O número de processos-cliente usados no sistema cliente foi suficiente para assegurar que o processador

do servidor fosse completamente saturado, ou seja, próximo a 100% de utilização. Os dados coletados e aqui

apresentados refletem uma média de várias execuções convergentes, e todos os cuidados foram tomados para

garantir sua sustentabilidade.

Para criar uma quantidade significativa de requisições aos serviços, foi utilizada a ferramenta

WCFStorm (www.wcfstorm.com).

13

Figura 10 – WCFStorm.

Também foi aplicado um projeto open source para executar estes testes de carga. O projeto utilizado

foi o WCF Load Test (http://wcfloadtest.codeplex.com/), Foram levados em consideração os resultados das

duas ferramentas.

Testes unitários e, posteriormente, testes de carga foram criados para verificar a capacidade de

resposta de cada uma das tecnologias. Os testes unitários realizam uma chamada simples ao serviço, que

retornou uma coleção de objetos. Nos testes de carga foi criado um cenário onde foi simulado o aumento

crescente de usuários até 200, aumentado 10 usuários a cada 10 segundos.

4.1.1 Throughput

Nas comparações de taxa de transferência, quanto maior o valor alcançado, melhor será o resultado.

Também será demostrado os resultados de tempo de resposta, neste caso, quanto menor o valor, mais rápido

o serviço responde as chamadas. Foram utilizados gráficos de barras para exemplificar os resultados.

Como é mostrado na figura 11, o WCF melhorou o desempenho sobre ASMX. No gráfico, três

diferentes assinaturas foram utilizadas. Em cada caso, um inteiro é passado do cliente para o servidor, e uma

coleção de objetos (1,10 ou 100) é retornado para o cliente. O WCF supera em 12%, 13% e 52% para 1, 10

ou 100 objetos em uma mensagem, respectivamente.

Figura 11 – Gráfico de throughput.

0

50

100

150

200

250

300

Mensagem com 1 obj Mensagem com 10 obj Mensagem com 100 obj

Op

era

çõe

s p

or

segu

nd

o

Throughput

WCF

ASMX

14

4.1.2 Tempo de resposta

Cada operação leva um determinado tempo para obter o retorno. Como visto na figura 12, o WCF

consegue responder a mais transações por segundo, consequentemente, sua taxa de tempo de resposta é mais

rápida também.

É possível verificar o tempo de resposta no gráfico abaixo.

Figura 12 – Gráfico de tempo de resposta.

Desta maneira, o WCF mostra larga vantagem no tempo de resposta de seus serviços expostos. Com

estas duas vantagens extremamente importantes comprovadas nos testes, a comunicação através do WCF é

uma forma segura, eficaz e rápida para transmitir os dados entre aplicações e clientes.

4.1.3 Memória

Foi analisada a memória do servidor no momento dos testes de carga. Notou-se que a utilização de

memória é mais elevada com o WCF. Isso se deve ao nível de complexidade das informações por ele

processadas.

A ferramenta utilizada para mensurar este recurso foi o “Perfmon.exe” nativo no Windows

Server 2008 R2.

Tabela 1 – Utilização de memória em %.

WCF ASMX Teste 1 58 55 Teste 2 58 55 Teste 3 60 57

Verifica-se que, com aplicações WCF, a memória do servidor deve ser mais elevada para suportar

melhor a tecnologia.

4.2 Camada de serviços

O problema de comunicação entre aplicações consome boa parte no tempo de desenvolvimento de

uma solução. Foi analisado um projeto em produção no qual aplicações comunicavam-se entre si através de

Web Services e de exportação e importação de arquivos.

A figura abaixo mostra como estava o ambiente originalmente.

0.00000

0.00500

0.01000

0.01500

0.02000

0.02500

Mensagem com 1 obj Mensagem com 10 obj Mensagem com 100 obj

Segu

nd

os

Tempo de resposta

WCF

ASMX

15

Figura 13 – Camada de serviços

Foi implementada uma camada de serviços, interligando as aplicações envolvidas, proporcionando

desta maneira uma forma centralizada de comunicação.

Figura 14 – Camada de serviços

Assim, obteve-se uma padronização na comunicação entre as aplicações, provendo melhor controle e

facilidade para o desenvolvimento, testes e correções, entre outros. O ganho de desempenho é notório, mas

difícil de comparar, visto que nem todas as comunicações feitas anteriormente ocorriam através de serviços

web e sim por transferência de arquivos ou até mesmo de forma manual.

Todas as vantagens explicadas na seção anterior ficaram visíveis nesta implementação, mas não foi

possível efetuar testes exatamente iguais, pois a lógica do sistema também mudou.

4.2.1 Reúso

O reúso é um item difícil de mensurar, devido ao tempo que se leva para comprovar sua eficácia.

Pelo fato do WCF prover uma interface com o contrato de seus serviços, os serviços ficam mais simples de

interpretar, modificar e reutilizar.

4.3 Migração

Os ASP.NET Web Services já existem há algum tempo e há muitas aplicações que ainda o utilizam.

Esta seção ajudará a entender melhor as diferenças entre ASMX e o WCF, desde a sua estrutura de projeto

até detalhes relacionados a sua execução.

4.3.1 Contratos

O ASMX irá se basear nos métodos decorados com o atributo “WebMethodAttribute” para gerar o

16

documento WSDL. Para controlar a visibilidade dos métodos, é necessário adicionar ou remover este

atributo. Qualquer tipo complexo referenciado nos métodos será automaticamente inserido na descrição do

serviço sem nenhuma configuração extra.

Já o WCF trabalha de forma bem diferente. Ele utiliza interfaces para determinar os contratos que o

serviço apresenta. Essas interfaces são aquelas tradicionais, já utilizadas no dia a dia, mas decorada com um

atributo chamado “ServiceContractAttribute”. Os métodos são descritos dentro das interfaces e expostos

através do atributo “OperationContractAttribute”.

4.3.2 Serialização e Desserialização

A serialização e a desserialização estão condicionadas ao serializador que cada tecnologia utiliza. O

ASMX utiliza o “XmlSerializer” para transformar os objetos em XML e vice-versa. O “XmlSerializer”

serializa todos os membros públicos (propriedades e campos), sem a necessidade de definir qualquer

atributo. É possível controlar a forma como essa serialização será realizada utilizando vários atributos que

existem neste mesmo namespace.

O WCF, por outro lado, utiliza o serializador “DataContractSerializer” por padrão. Este serializador

trabalha de forma semelhante ao “XmlSerializer”, com poucas diferenças. Entre essas diferenças está o

tratamento do atributo “SerializableAttribute”, utilizado para manter a compatibilidade com objetos .NET

Remoting. Outra diferença é a capacidade que este serializador tem de manter membros definidos como

private e protected. Este serializador ainda gera um XML mais simplificado, melhorando a

interoperabilidade entre as plataformas. Se desejar utilizar o “XmlSerializer”, basta adicionar ao contrato o

atributo “XmlSerializerFormatAttribute”.

4.3.3 Protocolo e hospedagem

O ASMX só pode ser hospedado no IIS, utilizando o protocolo HTTP/HTTPS. O WCF tem uma

arquitetura mais flexível e independente do protocolo, ou seja, ele pode ser executado em HTTP, HTTPS,

TCP, MSMQ etc.

O WCF também pode utilizar o IIS como host. Mas, além dele, é possível fazer uso de outras

aplicações para expor um serviço, como um Windows Service, ou ainda, uma simples aplicação

Windows/Console.

4.3.4 Implantação

Assim como em qualquer aplicativo .NET, basta mover os serviços para o IIS remoto e tudo já

funciona. É necessário certificar-se de que tenha a mesma versão do .NET Framework (isso inclui o service

pack) instalada no servidor. É importante dizer que ambas tecnologias necessitam de um diretório virtual

devidamente criado no IIS, com as permissões também configuradas.

4.3.5 Cliente

Dentro do Visual Studio .NET você tem duas opções para referenciar um serviço: “Add Web

Reference” e “Add Service Reference”. A primeira opção é utilizada para referenciar um serviço ASMX. A

segunda é utilizada para referenciar um serviço WCF. Ao serem acionadas, essa opções criarão

automaticamente o proxy, utilizando a API da tecnologia correspondente.

4.4 Segurança

A segurança entre ASP.NET Web Services e WCF é fundamental em um ambiente orientado a

serviços. Nesta sessão, são apresentadas duas soluções, ambas abordando as funcionalidades de cada uma

das tecnologias.

Por ser uma tecnologia recente, o WCF provê nativamente muitos recursos para trazer segurança a

um serviço.

4.4.1 ASP.NET Web Service

Web services criados com o ASP.NET podem dispor de segurança de autenticação e autorização

oferecida por esta estrutura ou customizada. O ASP.NET opera em conjunto com o IIS para prover várias

opções de autenticação e autorização. Também é possível criar opções de autenticação com o uso de SOAP

Headers. Para isso, é necessário que o serviço tenha uma classe responsável pela verificação das credenciais.

17

A figura 15 apresenta um exemplo de utilização do SOAP Header com a instância “Authentication”. Esta

classe irá coletar os dados para autenticação.

Figura 15 – Exemplo SOAP Header.

O atributo “Authentication” é uma instância da classe “AuthHeader”, responsável por armazenar e

decripitar os dados de autenticação, pois serão enviados criptografados por questões de segurança no

transporte.

Figura 16 – Classe “AuthHeader” derivando a classe “SoapHeader”.

O cliente irá enviar as credenciais criptografadas e invocar o serviço web. Veja a codificação.

Figura 17 – Cliente fazendo chamada ao serviço web.

O serviço irá decripitar os dados de autenticação e verificar se o usuário possui direitos de acesso. O

código abaixo mostra esta sequência.

Figura 18 – Serviços verificando credenciais e atendendo ao cliente.

4.4.2 WCF

Apesar de serviços WCF não fugirem muito do padrão de segurança de aplicações convencionais, há

algumas exceções, e uma delas é a forma de segurança que será aplicada à mensagem. Essa forma de

segurança influencia na forma que a autenticação será realizada e como a mensagem será protegida durante a

viagem. É importante dizer que – se a transferência da mensagem entre o cliente e o serviço, ou entre o

18

serviço e o cliente não fosse protegida – a autenticação e a autorização estariam completamente vulneráveis,

permitindo vários tipos de ataque.

Assim como outras configurações, a segurança também é uma característica do binding, podendo

efetuar a configuração de forma declarativa ou imperativa. O WCF fornece cinco formas diferentes para

tornar segura a transferência da mensagem. Cada uma dessas formas tem suas particularidades e influenciam

em como a mensagem será protegida e em como a autenticação será realizada. Abaixo são detalhadas essas

formas de segurança.

None – Como o próprio nome indica, nenhuma espécie de segurança é fornecida e toda a

mensagem será trafegada sem criptografia.

Transport – Esta opção informa ao WCF que o transporte (TCP, IPC, MSMQ ou HTTPS)

garantirá a segurança da mensagem, criptografando toda a comunicação. Além disso, fornece

integridade, privacidade e autenticação mútua. Um dos pontos negativos deste modo é que a

segurança só será garantida se for ponto a ponto. Ou seja, se houver intermediários entre o cliente

e o serviço, não há garantia de que a mensagem chegará segura até o destino final.

Message – Com esta opção, toda a mensagem será criptografada, garantindo a autenticação e a

proteção da mensagem (confidencialidade e integridade). Ao contrário da segurança baseada no

transporte, a segurança em nível de mensagem garante a segurança end-to-end,

independentemente do número de intermediários entre o cliente e o serviço. Isso permite,

inclusive, que o serviço seja exposto sob um protocolo não seguro, como é o caso do HTTP.

Outro grande benefício é que a segurança se baseia em padrões existentes no mercado, o que

garantirá a interoperabilidade. Já um ponto negativo desta opção é a sobrecarga, pois todas as

mensagens serão criptografadas e assinadas.

Both – Como o próprio nome diz, esta opção utiliza a segurança em nível de transporte e em nível

de mensagem, ou seja, a mensagem será protegida e, além disso, será transferida por um

transporte seguro. Apesar de maximizar a segurança, isso pode causar uma grande perda de

performance. Além disso, esse nível de segurança só é permitido em protocolos específicos, como

é o caso do MessageQueue, no qual a latência não é sentida.

TransportWithMessageCredential – Esta opção é uma mistura das duas anteriores. Ou seja, a

autenticação do cliente será fornecida em nível de mensagem, enquanto a proteção da mensagem

(confidencialidade e integridade) e a autenticação do serviço serão fornecidas pela segurança do

transporte.

TransportCredentialOnly – Apenas a autenticação mútua é fornecida em nível de transporte, não

havendo a proteção da mensagem. Esta opção somente está disponível para o ligação

“basicHttpBinding”.

5 CONCLUSÃO

Com este estudo, foram identificadas as principais vantagens do WCF e os benefícios alcançados

com sua utilização. Ganhos de desempenho e escalabilidade, fundamentais para as organizações, são

possíveis com a utilização de comunicação WCF. Como o assunto é relativamente novo, a documentação

sobre tais testes ainda deixa a desejar, e este estudo poderá ser uma base de conhecimento e poderá trazer

resultados significativos para o desenvolvimento da integração de aplicações comerciais.

O WCF fornece uma grande quantidade de funcionalidades que facilmente podem ser adicionadas

em serviços. Além disso, grande parte dessas funcionalidades pode ser configurada de forma declarativa,

através de arquivos de configuração que, na maioria dos casos, trazem enorme flexibilidade.

Apesar de ser uma tecnologia com muito mais recursos, o WCF não é complicado, pelo contrário, é

bem simples. Ainda há algum receio em sua utilização, pois sistemas legados de intercomunicação de

aplicações são extremamente caros e vitais nas empresas. Não é simples conseguir mudar o fluxo de dados

de uma hora para outra. Mas, as vantagens obtidas com a programação orientada a serviços trazem

benefícios (a curto e a longo prazos) aos quais arquitetos e desenvolvedores de software deveriam estar

atentos.

Conclui-se que o WCF é uma excelente evolução para os antigos ASP.NET Web Services, e que, na

medida do possível, as aplicações legadas (ASMX) deveriam ser substituídas, levando em conta o

treinamento de desenvolvedores no WCF para melhor aproveitamento. Apesar de o desenvolvimento ser

19

feito em uma plataforma orientada a objetos, o resultado é extremamente satisfatório. Tudo indica que, em

um futuro próximo, será criada uma plataforma especifica para desenvolvimento orientado a serviços.

5.1 Trabalhos futuros

A orientação a serviços é uma forma de desenvolvimento muito rica, mas pode ser melhor em

diversos pontos. Algumas das oportunidades para novos trabalhos são:

WCF na nuvem.

Ambiente de Desenvolvimento Integrado (Integrated Development Environment – IDE) para

orientação a serviços.

AGRADECIMENTOS

Gostaria de agradecer especialmente ao professor Edemar Costa, por acompanhar e auxiliar o

desenvolvimento deste trabalho, assim como a todos os professores que fizeram parte de minha formação

acadêmica.

Um agradecimento especial a minha mãe, Alzira Ferreira Gomes, cujo apoio tornou possível a

conclusão da minha graduação nesta universidade. Muito obrigado.

REFERÊNCIAS

BASIURA, Russ et al. Professional ASP.NET Web Services. Birmingham: Ed. Wrox Press Ltd, 2001.

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.

CAMBIUCCI, Waldemir. Cenários de implementação de serviços com WCF - Parte 1: Aspectos de

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.

CERAMI , Ethan. Web Services Essentials. 1 ed. Sebastopol: Ed. O’Reilly Media, Inc., 2002.

HAAS, Hugo; BROWN, Allen. W3C Working Group Note. [S. l], W3C Glossary, fevereiro 2004.

Disponível em: <http://www.w3.org/TR/ws-gloss/>. Acesso em: 17 abr. 2011.

JOSUTTIS, Nicloai. SOA in Practice. Sebastopol: Ed. O’Reilly Media, Inc., ago. 2007.

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.

LIBERTY, Jesse; HOROVITZ, Alex. Programming .NET 3.5. Sebastopol: Ed. O’Reilly Media, Inc., jul.

2010.

LÖWY, Juval. Programando Serviços WCF. 1 ed. Sebastopol: Ed. O’Reilly Media, Inc., 2007.

LÖWY, Juval. Programming WCF Services. 3 ed. Sebastopol: Ed. O’Reilly Media, Inc., 2010.

PIGOSKI, Thomas M., Practical Software Maintenance. [S. l], John Wiley & Sons, Inc., 1996.

SANTOS, Victor. Orientação a Objeto – Parte I. [S. l], Web Final, julho 2010. Disponível em:

<http://www.webfinal.com.br/blog/2010/07/03/sexta-net-aula-5-orientacao-a-objeto-parte-i/>. Acesso em:

17 abr. 2011.

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.