Rodrigo Cristiano Silva

Apresentação em tema: "Rodrigo Cristiano Silva"— Transcrição da apresentação:

1 Rodrigo Cristiano Silva rodrigo@facens.br
Tecnologias Web Rodrigo Cristiano Silva

2 Agenda

3 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

4 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

5 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

6 Web Services Caracterí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

7 Web Site: HTML Cliente:
O Browser Exibe a informação para um usuário, que reage ou não a ela Web Service: XML Cliente: Sistemas Web Service O sistema que recebe a informação (Excel, ERP) processa a informação assim que a recebe

8 Padrões abertos utilizados pelos Web Services

9 Comunicação com um Web Service

10 Web Services Basics 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

11 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

12 Documentando o Web Service
É possível adicionar descrições nos atributos [WebMethod] e [WebService] Exemplos: [WebMethod(Description="Teste")] [WebService(Description="Teste",Namespace="

13 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

14 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

15 Proxy Class Existem duas maneiras para criar uma classe proxy:
WSDL.exe command line tool "Add Web Reference" do Visual Studio

16 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)]

17 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

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

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

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

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

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

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

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

25 O Atributo ScriptService
O atributo ScriptService indica que o serviço foi projetado para aceitar chamadas de proxies baseados em JavaScript.

26 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:

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

28 Propriedades do Atributo ScriptMethod

29 Registrando AJAX Web Services

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

31 Proxy Class

32 Executando Chamadas Remotas