A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "IC-UNICAMP Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira."— Transcrição da apresentação:

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

2 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 Agenda Durante a apresentação serão abordados os seguintes assuntos: –W3C –XML –Web Services –SOAP –WSDL –UDDI

7 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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

9 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 W3C: Passos da Recomendação (1) Recebimento da submissão; (2) Publicação da nota; (3) Criação do grupo de trabalho; (4) Publicação do rascunho do trabalho; (5) Publicação da recomendação candidata; (6) Publicação da recomendação proposta; (7) Publicação da recomendação;

12 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 XML x HTML Trecho HTML: Fabiano Costa Teixeira Av. Albert Einstein, 1251 UNICAMP. Campinas – SP

23 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 XML x HTML Resultado voltado para seres humanos;

24 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 XML x HTML Trecho XML: Fabiano Costa Teixeira Albert Einstein 1251 UNICAMP Campinas SP Possível entendimento para máquinas!

25 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 DTD: Declaração Interna Fabiano Costa Teixeira Albert Einstein 1251 UNICAMP Campinas SP

29 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 DTD: Declaração Externa Fabiano Costa Teixeira Albert Einstein 1251 UNICAMP Campinas SP padrao.dtd

30 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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:

31 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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:

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

33 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 tags 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: Fabiano Costa Teixeira

34 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 XML Schemas: Atributos Elementos simples não possuem atributos; Se um elemento possui atributo ele é considerado um elemento complexo; Declaração de atributos:

35 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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: Outros tipos de restrições como enumeração e padrões são também aceitos;

36 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 XML Schemas: Elem. Complexos Elementos complexos podem ter outros elementos e/ou atributos; Exemplo de um elemento complexo: Fabiano Costa Teixeira IC Declaração:

37 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 pode ser interpretada de duas formas (mês sendo 01 ou 09); garantiria a comunicação pois o tipo date sempre é AAAA-MM-DD;

38 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 Web Services: Papéis

44 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Estrutura

47 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /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;

51 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Exemplo Método: –void myMethod(int x, int y); Invocação: –myObject.myMethod(5,10); Mensagem SOAP enviada: 5 10 Corpo Envelope

52 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Processamento O fato de um envelope SOAP separar os cabeçalhos do corpo da mensagem fornece uma forma para indicar como a mensagem deve ser processada pelos diferentes nós durante o caminho percorrido; Cada header possui atributo que descreve a qual tipo de nó ele está associado; Existem três tipos (roles) de nós pré-definidos: –Next; –UltimateReceiver; –None;

53 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Processamento Um header pode possuir um atributo denominado MustUnderstand: –Se seu valor for igual a true o nó que está processando a mensagem (desde que o nó esteja classificado no role para o qual o header está indicado) deverá, obrigatoriamente, processar o bloco. Se não for possível deve ser gerada uma mensagem de erro;

54 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Extensibilidade SOAP é um framework que tem uma preocupação com extensibilidade; Uma feature é uma extensão do SOAP framework; Uma feature pode incluir recursos como confiabilidade, segurança, roteamento, etc; O modelo de processamento do SOAP inclui um mecanismo necessário para implementar uma ou mais features através de um bloco header; A sintaxe de um header em conjunto com sua semântica cria o que é chamado de SOAP Module;

55 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Binding É necessária uma forma para transportar essa mensagem SOAP entre dois nós; O transporte da mensagem é tipicamente efetuado sobre o HTTP; Outros protocolos (como SMTP) também podem ser utilizados; A especificação de qual protocolo a ser utilizado no transporte é o que é chamado de Binding; A mensagem SOAP será encapsulada pelo protocolo selecionado para efetuar o transporte;

56 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: Binding Como exemplo, a primitiva POST do HTTP poderia ser utilizada em uma invocação RPC: Implementação do Cliente SOAP Engine HTTP Engine Requisitante do Serviço Implementação do Serviço HTTP Engine SOAP Engine Fornecedor do Serviço HTTP Post SOAP Envelope SOAP Header Soap Body Nome do Proc. Parâmetro 1 Contexto SOAP Envelope SOAP Header Soap Envelope Resposta Contexto HTTP POST /Exemplo HTTP/1.1 Host: Content-Type: text/xml; charset=utf-8 SOAPAction:Some-URI 5 10

57 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: WS-Routing Usando o modelo de extensibilidade SOAP, especificações baseadas em SOAP são projetadas para fornecer ambientes de troca de mensagens mais ricos; WS-Routing é um protocolo baseado no SOAP para efetuar o roteamento de mensagens SOAP; O caminho completo de uma mensagem é estabelecido; O caminho de volta da mensagem também pode ser definido;

58 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: WS-Routing Define um novo header (path) e o associa ao modelo de processamento; Considerando que um determinado nó A deseja enviar uma mensagem para D através de B e C: Para expressar rotas o path contém os seguintes elementos: –from: Contém o emissor original da mensagem; –to: Contém o destino final da mensagem; –fwd: Contém o caminho de encaminhamento; –rev: Contém o caminho reverso (volta);

59 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: WS-Routing O elemento rev é definido para possibilitar troca de mensagens two-way; Os elementos fwd e rev possuem elementos via para descrever cada intermediário; Exemplo:

60 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: WS-Routing Quando um intermediário recebe uma mensagem SOAP ele analisa o cabeçalho e verifica a necessidade de encaminhamento; Se existe elementos via dentro de fwd então ele remove o primeiro da lista; Se não existe elementos via dentro de fwd então esse nó é o destino final da mensagem; Se após a remoção restou algum elemento via dentro de fwd então a mensagem deve ser encaminhada para o intermediário indicado no topo da lista;

61 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 SOAP: WS-Routing Se após a remoção não sobrou nenhum elemento via dentro de fwd: –Se não houver elemento to então o intermediário atual é o destino final da mensagem; –Se houver um elemento to então o intermediário deve encaminhar a mensagem para o destino final; Se o elemento rev existir, o caminho reverso é montado automaticamente quando a mensagem passa pelo intermediário: –O elemento via é retirado do topo da lista fwd e inserido no topo da lista rev;

62 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL Web Services Definition Language; Originalmente criada pela Microsoft, IBM e Ariba; Documento escrito em XML utilizado para descrever Web Services; WSDL está para Web Services assim como IDL está para Corba; Além de especificar as operações oferecidas por um determinado serviço a WSDL também descreve como acessar tal serviço;

63 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura Parte Abstrata Parte Concreta

64 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura (Parte Abstrata) types: –Definem os tipos de dados que serão utilizados pelo Web Service; –Para obter a máxima neutralidade de plataforma WSDL utiliza a mesma sintaxe do XML Schema para definir tipos de dados; messages: –Unidade de comunicação entre os Web Services; –Representam a troca de informações entre eles; –Composta por parts, cada qual representa um parâmetro a ser enviado;

65 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura (Parte Abstrata) portType: –O elemento muito importante do WSDL; –Ele define o Web Service (quais operações são oferecidas e as mensagens envolvidas; –Pode ser comparado a uma classe; operation: –Define uma operação que é disponibilizada pelo Web Service; –Pode ser comparado a um método;

66 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura (Parte Abstrata)...

67 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura (Parte Concreta) binding: –Especifica o mecanismo utilizado por um serviço para se comunicar com um cliente; –Define o tipo de interação RPC-Style ou Document-Style; –Define o serviço exato a ser invocado; port: –EndPoint; –Combina um binding com um endereço de rede; –O endereço de rede refere-se ao local onde o a implementação pode ser acessada;

68 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Estrutura (Parte Concreta)...

69 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Stubs A partir do WSDL um compilador gera as stubs para os aplicativos cliente e servidor; A stub oferece a ligação entre o aplicativo e o módulo SOAP; No aplicativo cliente, a stub fornece uma interface de forma que a chamada fica semelhante a uma local; No aplicativo servidor, a stub ou (skeleton) recebe uma chamada e invoca o método desejado;

70 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 WSDL: Stubs WSDL Compilador WSDL (Lado do cliente) Compilador WSDL (Lado do serv.) Aplicação Cliente Aplicação Servidora SkeletonStub

71 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 Web Services: Arquitetura Implementação do Cliente SOAP Engine HTTP Engine Requisitante do Serviço HTTP Engine SOAP Engine Fornecedor do Serviço HTTP Post SOAP Envelope SOAP Header Soap Body Nome do Proc. Parâmetro 1 Contexto SOAP Envelope SOAP Header Soap Envelope Resposta Contexto HTTP Stub Implementação do Servidor Skeleton

72 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI Os clientes precisam de uma forma para encontrar Web Services que atendem a uma determinada necessidade; Exemplo: –A agência de turismo precisa descobrir quais hotéis oferecem consultas através de Web Services; É necessário obter informações sobre o serviço oferecido; UDDI (Universal Description, Discovery and Integration) oferece a solução para tais questões;

73 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Informações Páginas brancas: –Busca de organizações pelo nome; –Informações sobre contato ( , telefone, etc); –Informações sobre os serviços oferecidos Páginas amarelas: –Busca de organizações ou serviços por categoria; –Categorias poder ser padronizadas ou definidas pelo usuário; Páginas verdes: –Busca de serviços com base em características técnicas;

74 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Estrutura de Dados

75 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Estrutura de Dados businessEntity: –Descreve uma organização que fornece Web Services; –Armazena nome da empresa, descrição, contato,etc; businessService: –Descreve um grupo de serviços oferecidos pela empresa; –Incluem informações de classificação; –Cada serviço pode estar disponível em múltiplos endereços, bindings diferentes, etc;

76 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Estrutura de Dados bindingTemplate: –Fornece as informações técnicas necessárias para acessar um determinado serviço; –Endereço no qual o Web Service se encontra disponível; –Referência para informações detalhadas (tModels); tModels: –Container genérico para qualquer tipo de especificação; –Pode ser referenciado por várias entidades; –Aponta para um overviewDoc o qual contém a descrição de uma interface (WSDL); –Possibilidade de Binding dinâmico;

77 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: APIs Registros UDDI possuem três tipos de usuários para os quais ele expõe suas APIs: –Provedores: Para publicarem os serviços oferecidos; –Consumidores: Para procurarem por serviços desejados; –Outros registros UDDI: Para trocarem informações; UDDI Inquiry API; UDDI Publishers API; etc;

78 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Registros Públicos e Privados Quando o UDDI foi lançado era esperado que ele funcionasse como um UBR (Universal Business Registry); Essa perspectiva foi suportada por poucas empresas. Ex: IBM e Microsoft; UBRs precisam seguir regras definidas pela especificação UDDI e são supervisionados pela OASIS; O conteúdo de um UBR precisa ser consistente com o conteúdo dos demais e alterações de conteúdos devem ser propagados a eles;

79 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Registros Públicos e Privados

80 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 UDDI: Registros Públicos e Privados Registros públicos: –Provê acesso público ao registro; –Pode ser disponibilizado como um Web Site bem conhecido; –Não precisa ser necessariamente um UBR; Registros privados: –Registro interno isolado dentro de uma intranet; Registros compartilhados: –É administrado por ambiente controlado; –Pode ser compartilhado com uma rede de parceiros;

81 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 Pelo fato de serem baseados em XML os Web Services se tornam uma tecnologia bastante atrativa para ambientes heterogêneos; Processos B2B ganharam um forte aliado a fim de prover soluções sólidas; O movimento de grandes empresas demonstram uma forte aposta na tecnologia; ComputerWorld de julho/2003 previu um investimento em Web Services de U$ 34 Bilhões para 2007! Conclusão

82 IC-UNICAMP Web Services – Fabiano Costa Teixeira – /82 Fabiano Costa Teixeira


Carregar ppt "IC-UNICAMP Web Services – Fabiano Costa Teixeira – 2005 1/82 Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira."

Apresentações semelhantes


Anúncios Google