1 / 82

Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira

Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira. Cenário. Considere uma agência de viagens que quando vai vender um pacote precisa analisar: Empresas aéreas: Determinar a melhor opção entre os horários e preços dos vôos; Hotéis: Melhores condições e preços;

sunee
Download Presentation

Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira

  2. Web Services – Fabiano Costa Teixeira – 2005 2/82 Cenário • Considere uma agência de viagens que quando vai vender um pacote precisa analisar: • Empresas aéreas: Determinar a melhor opção entre os horários e preços dos vôos; • Hotéis: Melhores condições e preços; • Atualmente a negociação com o cliente é feita de forma “manual”. Ou seja, o cliente vai até à agência, informa o local de destino, a data de partida e retorno e o padrão de hotel e a classe de vôo desejados;

  3. Web Services – Fabiano Costa Teixeira – 2005 3/82 Cenário • Com a finalidade de propiciar uma maior comodidade aos clientes e agilizar o atendimento a agência deseja automatizar esse processo; • É desejado que o site da agência possua recursos de forma que o cliente informe os dados e valor da viagem seja calculado; Como esse processo pode ser automatizado?

  4. Web Services – Fabiano Costa Teixeira – 2005 4/82 Cenário • As empresas aéreas precisam disponibilizar formas para as agências consultarem suas tabelas de vôos e preços, • Os hotéis precisam disponibilizar formas para as agências consultarem suas tabelas de preços e reservas; • O sistema da agência precisa acessar os dados dos hotéis e das empresas aéreas para analisar a melhor condição e oferece-lá ao cliente;

  5. Web Services – Fabiano Costa Teixeira – 2005 5/82 Cenário • Diferentes hotéis e empresas aéreas possuem diferentes estruturas de informática; • Cada hotel e empresa aérea pode disponibilizar seus dados utilizando uma tecnologia e forma de acesso diferentes; • Essa heterogeneidade complica o desenvolvimento da solução; • A agência precisa saber quais as empresas aéreas e hotéis que oferecem tal recurso, de forma que ela possa incluí-los na consulta; Qual a solução para isso?

  6. Web Services – Fabiano Costa Teixeira – 2005 6/82 Agenda • Durante a apresentação serão abordados os seguintes assuntos: • W3C • XML • Web Services • SOAP • WSDL • UDDI

  7. Web Services – Fabiano Costa Teixeira – 2005 7/82 W3C: O que é? • Criado em 1994 como colaboração entre o Massachusetts Institute of Technology (MIT) e a European Organization for Nuclear Research (CERN) e com suporte da U.S. Defense Advanced Research Projects Agency (DARPA) e da Comissão Européia; • Tim Berners-Lee é o atual diretor do W3C;

  8. Web Services – Fabiano Costa Teixeira – 2005 8/82 W3C: O que é? • Funciona como um consórcio. Alguns membros bem conhecidos são: • IBM • Microsoft; • América Online • Apple • Adobe • Macromedia • Sun Microsystems; • Lista completa de membros em http://www.w3.org/Consortium/Member/List

  9. Web Services – Fabiano Costa Teixeira – 2005 9/82 W3C: O que é? • As operações do W3C são administradas, em conjunto, por: • MIT Computer Science and Artificial Intelligence Laboratory (CSAIL); • Europeam Reserarch Consortium for Informatics and Mathematics (ERCIM); • Keio University;

  10. Web Services – Fabiano Costa Teixeira – 2005 10/82 W3C: Recomendações • Um dos trabalhos mais importantes realizado pelo W3C é o desenvolvimento de especificações (também chamadas de recomendações); • Elas descrevem padrões como HTML, XML, etc; • Cada recomendação é realizada por um grupo de trabalho consistido de membros e “experts” convidados; • Empresas podem submeter recomendações ao W3C para uma recomendação formal;

  11. Web Services – Fabiano Costa Teixeira – 2005 11/82 W3C: Passos da Recomendação • Recebimento da submissão; • Publicação da nota; • Criação do grupo de trabalho; • Publicação do rascunho do trabalho; • Publicação da recomendação candidata; • Publicação da recomendação proposta; • Publicação da recomendação;

  12. Web Services – Fabiano Costa Teixeira – 2005 12/82 W3C: Submissão • Qualquer membro do W3C pode submeter uma sugestão de padronização; • A maioria das recomendações do W3C surgiram como uma sugestão de padronização; • Após receber uma sugestão de padronização o W3C irá decidir se iniciará um trabalho para refinar a sugestão;

  13. Web Services – Fabiano Costa Teixeira – 2005 13/82 W3C: Publicação da Nota • Muitas vezes uma submissão ao W3C torna-se uma nota; • A nota é uma descrição (editada pelo membro que efetuou a submissão) de uma sugestão refinada como um documento público; • Essa nota é publicada pela W3C somente para discussão; • A publicação de uma nota não indica aprovação por parte do W3C nem mesmo indica o início de qualquer trabalho por parte do W3C;

  14. Web Services – Fabiano Costa Teixeira – 2005 14/82 W3C: Grupo de Trabalho • Quando uma submissão é reconhecida pelo W3C é formado um grupo de trabalho consituído de membros e outras partes interessadas; • O grupo de trabalho irá definir um cronograma é um rascunho da padronização proposta;

  15. Web Services – Fabiano Costa Teixeira – 2005 15/82 W3C: Rascunhos de Trabalho • São normalmente postados no site do W3C; • Incluem “chamadas” para comentários do público; • Indicam que o trabalho está em progresso; • Não podem ser utilizados como material de referência; • O conteúdo pode ser substituído e/ou alterado a qualquer momento;

  16. Web Services – Fabiano Costa Teixeira – 2005 16/82 W3C: Recomendações Candidatas • Algumas recomendações são mais complexas; • Precisam de mais tempo e mais testes; • Essas recomendações são publicadas como Candidatas; • Possuem também um status de trabalho em progresso; • Pode ser atualizada e/ou substituída a qualquer momento; • Não devem ser utilizadas como documentos de referência;

  17. Web Services – Fabiano Costa Teixeira – 2005 17/82 W3C: Recomendação Proposta • Representa o estágio final do trabalho do grupo; • Continua sendo um trabalho em progresso; • Ainda pode ser atualizada e/ou substituída; • Na maioria das vezes se torna a recomendação propriamente dita;

  18. Web Services – Fabiano Costa Teixeira – 2005 18/82 W3C: Recomendação • Totalmente revisada pelo W3C; • Possui o “carimbo” de APROVADA concedido pelo diretor do W3C; • Considerado um documento estável e pode ser utilizado como material de referência;

  19. Web Services – Fabiano Costa Teixeira – 2005 19/82 XML • EXtensible Markup Language; • Tornou-se uma recomendação do W3C em 10 de fevereiro de 1998; • XML é uma “meta-linguagem” utilizada para descrever dados e é focada no que os dados são; • Criada para estruturar, armazenar e enviar informações; • “Linguagem independente de plataforma, hardware e software para transmissão de informações” (W3Schools); • Utilização de TAG`s;

  20. Web Services – Fabiano Costa Teixeira – 2005 20/82 XML • Está se tornando a principal forma para troca de informações entre empresas através da Internet; • Pelo fato de ser independente de plataforma, hardware e software, os dados descritos utilizando XML podem ser acessíveis por outros aplicativos além dos Browsers;

  21. Web Services – Fabiano Costa Teixeira – 2005 21/82 XML x HTML • XML não é uma substituta da HTML; • Enquanto HTML é focada para descrever como os dados devem ser “mostrados”, XML é focada para descrever informações; • HTML trabalha com TAGs pré-definidas; • XML nos permite a criação de nossas próprias TAGs;

  22. Web Services – Fabiano Costa Teixeira – 2005 22/82 XML x HTML • Trecho HTML: <p><b>Fabiano Costa Teixeira</b> <br> Av. Albert Einstein, 1251 <br> UNICAMP. Campinas – SP</p>

  23. Web Services – Fabiano Costa Teixeira – 2005 23/82 XML x HTML • Resultado voltado para seres humanos;

  24. Web Services – Fabiano Costa Teixeira – 2005 24/82 XML x HTML • Trecho XML: <endereco> <nome>Fabiano Costa Teixeira</nome> <rua>Albert Einstein</rua> <numero>1251</numero> <bairro>UNICAMP</bairro> <cidade>Campinas</cidade> <estado>SP</estado> </endereco> • Possível entendimento para máquinas!

  25. Web Services – Fabiano Costa Teixeira – 2005 25/82 Utilização da XML • Na realidade, sistemas de computação e sistemas de bancos de dados possuem dados em formatos incompatíveis; • Convertendo os dados para XML a troca de informações entre esses sistemas se simplifica; • Os dados convertidos para XML podem ser interpretados por diferentes tipos de aplicações; • Poder ser utilizada também para armazenamento de dados;

  26. Web Services – Fabiano Costa Teixeira – 2005 26/82 Regras para Documentos XML • Requer um parser para rejeitar qualquer documento inválido; • Possui regras básicas como: • O documento deve ter apenas um elemento raíz; • Toda elemento requer uma tag inicial e uma final; • Elementos são case sensitive; • Etc • Documento bem formado: Aquele que obedece às regras de sintaxe; • Documento válido: Aquele que obedece às regras de sintaxe e a um formato pré-definido;

  27. Web Services – Fabiano Costa Teixeira – 2005 27/82 DTD • Document Type Definition; • Um documento pode atender às regras básicas, no entanto sua estrutura pode ser inválida; • O DTD define a estrutura do documento como uma lista de elementos válidos; • Declaração interna do tipo do documento: O mesmo arquivo contém as regras DTD e o documetno XML; • Declaração externa do tipo do documento: O documento e a declaração do tipo estão em arquivos diferentes;

  28. Web Services – Fabiano Costa Teixeira – 2005 28/82 DTD: Declaração Interna <!DOCTYPE endereco [ <!ELEMENT endereco (nome,rua,numero,bairro,cidade,estado)> <!ELEMENT nome (#PCDATA)> <!ELEMENT rua (#PCDATA)> <!ELEMENT numero (#PCDATA)> <!ELEMENT bairro (#PCDATA)> <!ELEMENT cidade (#PCDATA)> <!ELEMENT estado (#PCDATA)> ]> <endereco> <nome>Fabiano Costa Teixeira</nome> <rua>Albert Einstein</rua> <numero>1251</numero> <bairro>UNICAMP</bairro> <cidade>Campinas</cidade> <estado>SP</estado> </endereco>

  29. Web Services – Fabiano Costa Teixeira – 2005 29/82 DTD: Declaração Externa <!DOCTYPE endereco SYSTEM “padrao.dtd”> <endereco> <nome>Fabiano Costa Teixeira</nome> <rua>Albert Einstein</rua> <numero>1251</numero> <bairro>UNICAMP</bairro> <cidade>Campinas</cidade> <estado>SP</estado> </endereco> <!ELEMENT endereco (nome,rua,numero,bairro,cidade,estado)> <!ELEMENT nome (#PCDATA)> <!ELEMENT rua (#PCDATA)> <!ELEMENT numero (#PCDATA)> <!ELEMENT bairro (#PCDATA)> <!ELEMENT cidade (#PCDATA)> <!ELEMENT estado (#PCDATA)> padrao.dtd

  30. Web Services – Fabiano Costa Teixeira – 2005 30/82 DTD: Ocorrência de Elementos • Define o número de vezes que um determinado elemento deve aparecer; • É representado por um símbolo que deve aparecer imediatamente após o elemento; • ?: Elemento opcional; • +: Elemento deve aparecer pelo menos uma vez; • *: Elemento pode aparecer zero ou mais vezes; • Exemplo: <element empregado (nome, departamento, dependente*)> <element nome (#PCDATA)> <element departamento (#PCDATA)> <element dependente (#PCDATA)>

  31. Web Services – Fabiano Costa Teixeira – 2005 31/82 DTD: Seleção de Elemento • Uma seqüência de elementos pode conter uma condição do tipo “um ou outro”; • Essa condição deve aparecer entre elementos: • |: Indica a escolha de um dos elementos; • Exemplo: <element empregado (nome, departamento, (filho|filha)*)> <element nome (#PCDATA)> <element departamento (#PCDATA)> <element filho (#PCDATA)> <element filha (#PCDATA)>

  32. Web Services – Fabiano Costa Teixeira – 2005 32/82 XML Schemas • Inicialmente proposta pela Microsoft; • Tornou uma recomendação da W3C em Maio de 2001; • Sucessora do DTD; • Escrita em XML: • <schema> deve ser o elemento root; • É possível utilizar o mesmo editor XML; • Suporta tipos de dados;

  33. Web Services – Fabiano Costa Teixeira – 2005 33/82 XML Schemas: Elemento Simples • Elemento que contêm somente texto; • Não contém outros elementos ou atributos; • Expressão “somente texto” quer dizer que entre as tag’s de início e fim do elemento não existe outros elementos. No entanto o elemento especificado por ser de um determinado tipo de dado (string, date, etc); • Exemplo: <xs:element name=“nome” type=“xs:string”> <xs:element name=“idade” type=“xs:integer”> <xs:element name=“contrato” type=“xs:date”> <nome>Fabiano Costa Teixeira</nome> <idade>18</idade> <contrato>2005-09-22</contrato>

  34. Web Services – Fabiano Costa Teixeira – 2005 34/82 XML Schemas: Atributos • Elementos simples não possuem atributos; • Se um elemento possui atributo ele é considerado um elemento complexo; • Declaração de atributos: <xs:atribute name=“sexo” type=“xs:string” • Um atributo pode ser opcional ou requerido: <xs:atribute name=“sexo” type=“xs:string” use=“optional”> <xs:atribute name=“sexo” type “xs:string” use=“required”>

  35. Web Services – Fabiano Costa Teixeira – 2005 35/82 XML Schemas: Restrições • Através de XML Schemas é possível definir para cada elemento as restrições quanto ao conteúdo do mesmo: <xs:element name=“idade”> <xs:simpleType> <xs:restriction base=“xs:integer”> <xs:minInclusive value”0”/> <xs:maxInclusive value=“100”/> </xs:restriction> </xs:simpleType> <xs:/element> • Outros tipos de restrições como enumeração e padrões são também aceitos;

  36. Web Services – Fabiano Costa Teixeira – 2005 36/82 XML Schemas: Elem. Complexos • Elementos complexos podem ter outros elementos e/ou atributos; • Exemplo de um elemento complexo: <aluno> <nome>Fabiano Costa Teixeira</nome> <instituto>IC</instituto> </aluno> • Declaração: <xs:element name=“aluno”> <xs:ComplexType> <xs:sequence> <xs:element name=“nome” type=“xs:string”> <xs:element name=“instituto” type=“xs:string” </xs:sequence> </xs:complexType> </xs:element>

  37. Web Services – Fabiano Costa Teixeira – 2005 37/82 XML Schemas: Tipos de Dados • Quando informações são trocadas é necessário que o emissor e o receptor tenham a mesma expectativa a respeito do conteúdo; • Com XML Schemas o emissor irá inserir dados de forma que o receptor possa entender; • Uma data do tipo 01-09-2005 pode ser interpretada de duas formas (mês sendo 01 ou 09); • <date type=”date”>2005-09-01</date> garantiria a comunicação pois o tipo date sempre é AAAA-MM-DD;

  38. Web Services – Fabiano Costa Teixeira – 2005 38/82 XML Schemas: Tipos de Dados • Os tipos de dados mais comuns no XML Schema são: • xs:string; • xs:decimal; • xs:integer; • xs:boolean; • xs:date; • xs:time;

  39. Web Services – Fabiano Costa Teixeira – 2005 39/82 Web Services • Implementam serviços que precisam ser compartilhados; • Podem ser desenvolvidos em qualquer plataforma utilizando qualquer ambiente de desenvolvimento; • Devem ser capazes de comunicar com outros Web Services utilizando protocolos padrões; • No cenário proposto (no início da apresentação) os hotéis e as empresas aéreas podem disponibilizar Web Services com operações para consulta de preços e condições;

  40. Web Services – Fabiano Costa Teixeira – 2005 40/82 Web Services • O sistema da agência invocaria o Web Service oferecido pelo hotel ou empresa aéra, efetuando a consulta desejada; • Middleware baseado em três padrões: • Simple Object Access Protocol (SOAP); • Web Services Description Language (WSDL); • UDDI (Universal Description, Discovery and Integration);

  41. Web Services – Fabiano Costa Teixeira – 2005 41/82 Web Services: Arquitetura • Camada de Transporte • HTTP; • SMTP; • Etc; • Camada de Mensagens: • SOAP; • Camada de Dados: • XML (RPC Style, Document Style); • Camada de descrição: • WSDL; • Camada de descoberta: • UDDI;

  42. Web Services – Fabiano Costa Teixeira – 2005 42/82 Web Services: Papéis • Provedor de Serviços:Disponibiliza um serviço Web para que esse possa ser invocado por um outro software; • Registro de Serviços: Repositório que mantém e fornece informações sobre Web Services; • Cliente de Serviços: Aplicação que localiza um serviço, implementa sua interface e invoca o serviço;

  43. Web Services – Fabiano Costa Teixeira – 2005 43/82 Web Services: Papéis

  44. Web Services – Fabiano Costa Teixeira – 2005 44/82 SOAP • Simple Object Access Protocol; • Versão 1.1 foi sugerida em maio de 2000 pela IBM, Microsoft, etc; • A especificação da versão 1.2 foi liberada em 24 de junho de 2003; • Protocolo padrão baseado em XML para trocar mensagens entre aplicações; • Não está vinculado a nenhuma plataforma específica, linguagem de programação e rede;

  45. Web Services – Fabiano Costa Teixeira – 2005 45/82 SOAP: Por quê? • Permite às aplicações a troca de informações; • A comunicação entre aplicações pode ser feita utilizando padrões já existentes como RPC, CORBA, etc; • Firewalls normalmente bloqueiam esse tipo de tráfico; • A melhor forma para efetuar a comunicação entre aplicações é através do HTTP, pois ele é suportado por todos os Web Servers ;

  46. Web Services – Fabiano Costa Teixeira – 2005 46/82 SOAP: Estrutura

  47. Web Services – Fabiano Costa Teixeira – 2005 47/82 SOAP: Estrutura • Header: • SOAP assume que toda mensagem possui um emissor, um receptor e um número qualquer de intermediários; • O header contém informações que podem ser processadas pelos intermediários; • Um envelope SOAP pode conter 0 ou n header's; • Podem ser utilizados para fornecer informações para: • Autenticação; • Transação; • Etc;

  48. Web Services – Fabiano Costa Teixeira – 2005 48/82 SOAP: Estrutura • Body: • Contém a mensagem que deve ser recebida pelo destinatário da mensagem; • Teoricamente pode conter qualquer informação; • Pode haver dois tipos de interação: Document-Style e RPC-Style;

  49. Web Services – Fabiano Costa Teixeira – 2005 49/82 SOAP: Document-Style • Nesse tipo de interação as duas aplicações trocam documentos que possuem uma estrutura pré-definida; • O SOAP é utilizado para transportar essas mensagens de uma aplicação até a outra; • Muito utilizado para comunicação assíncrona, onde o servidor ao receber a mensagem a insere em uma fila para processamento posterior;

  50. Web Services – Fabiano Costa Teixeira – 2005 50/82 SOAP: RPC-Style • Nesse estilo de interação uma mensagem SOAP encapsula uma requisição enquanto outra mensagem encapsula uma resposta; • O corpo da mensagem de requisição deve conter: • O nome do procedimento a ser invocado; • Os parâmetros de entrada; • O corpo da mensagem de resposta deve conter: • O resultado do processamento; • O formato do corpo de uma mensagem de requisição segue uma convenção;

More Related