tecnologias web rodrigo cristiano silva [email protected]
TRANSCRIPT
Agenda
A era das aplicações monolíticas Hoje em dia, a maioria das aplicações Internet que usamos
podem ser consideradas monolíticas, ou seja, não são capazes de compartilhar funcionalidades com outras aplicações
Modelo de desenvolvimento de sucesso, mas que apresenta as seguintes fraquezas: Aplicações amarradas a plataformas ou tecnologias específicas
Dificilmente podem ser estendidas Para fazer a integração de aplicações é necessário um novo
projeto Compartilhar código entre aplicações não é uma tarefa fácil
Linguagens de programação diferentes Às vezes, queremos uma simples informação como a nota de
uma prova, entretanto, na maioria dos casos, a única forma que temos para conseguir essa informação é através de uma interface gráfica que pode ser inviável para conexões lentas ou dispositivos móveis
Revolução dos Componentes Desenvolvedores gastavam grande parte do seu
tempo resolvendo problemas que já tinham resolvido
Desenvolvedores precisavam organizar as aplicações cuidadosamente para ter a chance de reutilizar código
Tudo mudou dramáticamente quando surgiram as tecnologias de componentes como o COM da Microsoft
A tecnologia COM permitia empacotar funcionalidades em componentes reutilizáveis com interfaces bem definidas
A tecnologia COM ajudou a acabar com a era das aplicações monolíticas
Web Services Web services são unidades lógicas de programação
individuais que existem em um servidor web Podem ser facilmente integrados com todos os tipos
de aplicação, desde uma aplicação web até uma aplicação console
Os web services são ainda melhores que a tecnologia COM, uma vez que foram construídos sobre uma fundação de padrões abertos como XML, SOAP, WSDL, etc.
O padrão mais importante para os web services é o XML. Como ele é baseado em texto simples, chamadas a web services podem usar o protocolo HTTP. Outras tecnologias de objetos distribuídos, tais como DCOM, são muito mais complexas
Web ServicesCaracterísticas Interfaces para transações e regras de negócios Baseado em protocolos e padrões como: XML,
WSDL, SOAP, HTTP e UDDI Tecnologia de padrão aberto definida pelo W3C,
utilizada por empresas como a SUN, Microsoft, IBM e HP
Residem em um servidor Web, como as páginas de Internet e têm um endereço URL
Podem ser utilizados em ambientes com firewalls São chamados por outros programas, e recebem
seus parâmetros em formato XML Respondem às chamadas com dados formatados
em XML
Web Site: HTML Cliente:Web Site: HTML Cliente:
Web Service: XML Cliente:Web Service: XML Cliente:
O BrowserO Browser
WebWebServiceService
SistemasSistemas
Exibe a informação Exibe a informação para um usuário, para um usuário, que reage ou não a que reage ou não a elaela
O sistema que recebe O sistema que recebe a informação (Excel, a informação (Excel, ERP) processa a ERP) processa a informação assim que informação assim que a recebea recebe
Padrões abertos utilizados pelos Web Services
Comunicação com um Web Service
Web ServicesBasics Todo Web Service (WS) é uma classe
Um cliente pode criar uma instância de um WS e usar seus métodos como se fosse qualquer outra classe definida localmente
Namespace: System.Web.Services Um WS consiste em:
Um arquivo .asmx: arquivo através do qual são feitas as requisições ao serviço (análogo ao .aspx dos web forms)
Classe do WS: contém as funcionalidades do serviço (código). Herda System.Web.Services.WebService
Um ou mais métodos: métodos do WS marcados com o atributo [WebMethod]. Este atributo torna o método disponível para ser acessado pelas aplicações que usam o WS
ASP.NET gerencia detalhes de nível mais baixo Por exemplo, não é necessário criar um documento WSDL ou
uma mensagem SOAP
Criando um Web Service
WS´s podem ser adicionados a qualquer aplicação web
Não devemos usar o ASP.NET Development Server para hospedar WS´s, uma vez que o Visual Studio escolhe uma nova porta cada vez que ele é iniciado
IIS para hospedar o WS: Criar pasta abaixo do "home directory" do IIS Criar diretório virtual Criar novo web site escolhendo HTTP no "Location box" Adicionar um WS ao projeto
Documentando o Web Service
É possível adicionar descrições nos atributos [WebMethod] e [WebService]
Exemplos: [WebMethod(Description="Teste")] [WebService(Description="Teste",Namespace="w
ww.facens.br/ws")]
Tipos de retorno de um Web Service
Básicos: int, float, bool, string e DateTime
Enumerations Tipos definidos com a palavra chave enum
DataSet e DataTable Útil para a troca de informações recuperadas de um BD
XML Nodes (System.XML.XMLNode) Representam porções de um documento XML
Arrays e Collections Arrays de qualquer tipo suportado pela framework ou
collections como o ArrayList
Proxy Class
A proxy class atua entre o código da aplicação cliente e o WS
Quando o cliente quer invocar um web method, ele chama o método correspondente do objeto proxy
A classe proxy de forma transparente envia e recebe dados usando chamadas SOAP
Poderíamos criar e receber mensagens SOAP, mas isso exigiria um bom conhecimento de SOAP e seria muito mais complexo
Proxy Class
Existem duas maneiras para criar uma classe proxy: WSDL.exe command line tool "Add Web Reference" do Visual Studio
Gerenciamento de Estado
Um WS usualmente é desenvolvido como uma stateless class
Métodos são independentes e não retêm quaisquer informações entre requisições
Desabilitado por padrão Podemos habilitar para um método
específico: [WebMethod(EnableSession=true)]
Segurança nos Web Services
Transmitem texto puro (clear text), o que significa facilidade de espionagem dos dados ou modificação dos mesmos Solução: SSL
WS´s podem precisar autenticar e autorizar usuários, para isso temos duas opções: Windows Authentication (IIS + ASP.NET) Código customizado
Um dos métodos do WS é responsável pela autenticação
AJAX-Enabled Web Services
Existem situações nas quais o modelo de carregamento parcial não é apropriado e outras situações em que ele é simplesmente perfeito.
Quando o cliente necessita que uma operação específica seja executada no servidor de forma puramente stateless, devemos considerar outras opções que não o carregamento parcial.
Entra em cena as chamadas remotas a métodos do servidor.
Arquitetura do Servidor Orientada a Serviços Como o título do slide já descreve, a arquitetura do servidor deve
ser constituída de serviços. Para ser invocado a partir de uma página ASP.NET AJAX, o serviço
remoto deve atender a alguns requerimentos, os mais rigorosos estão relacionados à localização do endpoint e à plataforma utilizada. Serviços AJAX-Enabled devem ser hospedados no mesmo domínio a partir do
qual a chamada é feita. Isso significa que o serviço deve ser um ASP.NET XML Web Service (um endpoint .asmx) e deve ser hospedado na mesma aplicação IIS do mesmo servidor Web que a aplicação ASP.NET.
Resumidamente, existem três maneiras de definir serviços para uma aplicação ASP.NET AJAX: ASP.NET XML Web Services com um endpoint .asmx; WCF Services com um endpoint .svc; Métodos da mesma página que executa as chamadas com um endpoint .aspx.
Serialização de Dados
O formato de serialização comum a ambos pontos é a JavaScript Object Notation (JSON).
JSON é um formato baseado em texto especificamente projetado para mover o estado de um objeto através de camadas.
A JSON descreve o estado de um objeto como mostrado a seguir: {“ID”=“ALFKI”, “Company”:”Alfred Futterkiste”}
A string acima denota um objeto com duas propriedades (ID e Company) e seus respectivos valores serializados.
Web Services para Aplicações ASP.NET AJAX O ASP.NET não permite que sejam feitas chamadas a qualquer Web
Service baseado em SOAP a partir do JavaScript. Quando usamos o AJAX Extensions, podemos usar o JavaScript para fazer
chamadas a algum código de servidor dentro das fronteiras da aplicação. De alguma forma, o código de servidor da aplicação deve ser exposto ao
cliente: No ASP.NET 2.0 com AJAX Extensions instalado, podemos contar somente com ASP.NET
XML Web Services (modificados para retornar dados no formato JSON); No ASP.NET 3.5, podemos também utilizar serviços WCF.
Por padrão, os Web Services ASP.NET trabalham enviando e recebendo pacotes SOAP ao invés de pacotes JSON e expõem seus contratos usando WSDL.
O arquivo web.config de uma aplicação ASP.NET AJAX pode modificar o HTTP handler que recebe requisições a arquivos .asmx e redirecionar tais chamadas a um handler que entenda a JSON.
Definindo a API Remota
Um contrato é usado para especificar o que o endpoint no servidor oferece aos clientes.
Um ASP.NET Web Service não requer um contrato explícito, ao contrário de um WCF Service onde um contrato é exigido.
Utilizar uma interface no projeto da API produz um código mais limpo e é uma boa prática de programação.
Uma vez definido o contrato (interface), cria-se uma classe que implementa a interface.
Finalmente, publica-se a API e permite-se que o ASP.NET AJAX runtime faça chamadas a partir do cliente.
Publicando o Contrato
A publicação do contrato significa tornar a API visível ao JavaScript de uma página cliente e, conseqüentemente, habilitar o JavaScript da página a invocar métodos da API.
A publicação de um contrato significa gerar uma JavaScript proxy class que possa ser usada pelos scripts embutidos na página.
Quando a API é implementada através de um Web Service, registra-se o serviço através do controle script manager da página ASP.NET AJAX.
Também é necessário adicionar um HTTP handler especial para requisições a arquivos .asmx no arquivo web.config da aplicação.
Criando um Web Service AJAX
Existem duas principais diferenças entre ASP.NET AJAX Web Services e ASP.NET XML Web Services: Quando trabalhamos com ASP.NET AJAX Web Services, usamos
o contrato para atender aos requisitos de uma aplicação específica ao invés de configurar o comportamento de um serviço público.
Precisamos usar um novo atributo junto a classe do Web Service que não é permitido em ASP.NET XML Web Service tradicional.
No final, um ASP.NET AJAX Web Service deve ter duas interfaces publicas: a interface baseada em JSON e a interface clássica baseada em SOAP exposta a qualquer cliente de qualquer plataforma.
O Atributo ScriptService O atributo ScriptService indica que o serviço foi projetado para
aceitar chamadas de proxies baseados em JavaScript.
Bloqueando Clientes SOAP Podemos optar por inibir clientes SOAP de realizar chamadas ao
serviço. Para isso, basta inserir as configurações abaixo no arquivo web.config da aplicação ASP.NET que hospeda o serviço:
Definindo Métodos para um Web Service Métodos públicos da classe do Web Service que recebem o atributo
WebMethod podem ser invocados a partir da página cliente. Qualquer método é invocado usando o verbo POST do HTTP e
retorna seus valores como um objeto JSON. Podemos mudar essas configurações padrões para cada método
usando um atributo opcional chamado ScriptMethod.
Propriedades do Atributo ScriptMethod
Registrando AJAX Web Services
Configurando Aplicações ASP.NET para Hospedar AJAX Web Services
Para permitir que a aplicação ASP.NET AJAX faça chamadas ao Web Service, precisamos adicionar as configurações a seguir ao arquivo web.config da aplicação.
Essas configurações são incluídas por padrão no arquivo web.config gerado pelo Visual Studio quando criamos um projeto Web AJAX-enabled.
Proxy Class
Executando Chamadas Remotas