Web Services Aluno: Fabiano Costa Teixeira

Apresentação em tema: "Web Services Aluno: Fabiano Costa Teixeira"— Transcrição da apresentação:

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

2 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; Web Services – Fabiano Costa Teixeira – /82

3 Como esse processo pode ser automatizado?
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? Web Services – Fabiano Costa Teixeira – /82

4 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; Web Services – Fabiano Costa Teixeira – /82

5 Qual a solução para isso?
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? Web Services – Fabiano Costa Teixeira – /82

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

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

8 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 Web Services – Fabiano Costa Teixeira – /82

9 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; Web Services – Fabiano Costa Teixeira – /82

10 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; Web Services – Fabiano Costa Teixeira – /82

11 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; Web Services – Fabiano Costa Teixeira – /82

12 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; Web Services – Fabiano Costa Teixeira – /82

13 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; Web Services – Fabiano Costa Teixeira – /82

14 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; Web Services – Fabiano Costa Teixeira – /82

15 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; Web Services – Fabiano Costa Teixeira – /82

16 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; Web Services – Fabiano Costa Teixeira – /82

17 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; Web Services – Fabiano Costa Teixeira – /82

18 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; Web Services – Fabiano Costa Teixeira – /82

19 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; Web Services – Fabiano Costa Teixeira – /82

20 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; Web Services – Fabiano Costa Teixeira – /82

21 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; Web Services – Fabiano Costa Teixeira – /82

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

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

24 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! Web Services – Fabiano Costa Teixeira – /82

25 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; Web Services – Fabiano Costa Teixeira – /82

26 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; Web Services – Fabiano Costa Teixeira – /82

27 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; Web Services – Fabiano Costa Teixeira – /82

28 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> Web Services – Fabiano Costa Teixeira – /82

29 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 Web Services – Fabiano Costa Teixeira – /82

30 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)> Web Services – Fabiano Costa Teixeira – /82

31 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)> Web Services – Fabiano Costa Teixeira – /82

32 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; Web Services – Fabiano Costa Teixeira – /82

33 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> </contrato> Web Services – Fabiano Costa Teixeira – /82

34 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”> Web Services – Fabiano Costa Teixeira – /82

35 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; Web Services – Fabiano Costa Teixeira – /82

36 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> Web Services – Fabiano Costa Teixeira – /82

37 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); <date type=”date”> </date> garantiria a comunicação pois o tipo date sempre é AAAA-MM-DD; Web Services – Fabiano Costa Teixeira – /82

38 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; Web Services – Fabiano Costa Teixeira – /82

39 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; Web Services – Fabiano Costa Teixeira – /82

40 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); Web Services – Fabiano Costa Teixeira – /82

41 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; Web Services – Fabiano Costa Teixeira – /82

42 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; Web Services – Fabiano Costa Teixeira – /82

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

44 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; Web Services – Fabiano Costa Teixeira – /82

45 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 ; Web Services – Fabiano Costa Teixeira – /82

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

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

48 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; Web Services – Fabiano Costa Teixeira – /82

49 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; Web Services – Fabiano Costa Teixeira – /82

50 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; Web Services – Fabiano Costa Teixeira – /82

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

52 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; Web Services – Fabiano Costa Teixeira – /82

53 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; Web Services – Fabiano Costa Teixeira – /82

54 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; Web Services – Fabiano Costa Teixeira – /82

55 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; Web Services – Fabiano Costa Teixeira – /82

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

57 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; Web Services – Fabiano Costa Teixeira – /82

58 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); Web Services – Fabiano Costa Teixeira – /82

59 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: <s:Header> <m:path xmlns:m=“ <m:to> <m:fwd> <m:via> <m:via> </m:fwd> <m:from> </m:path> </s:Header> Web Services – Fabiano Costa Teixeira – /82

60 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; Web Services – Fabiano Costa Teixeira – /82

61 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; Web Services – Fabiano Costa Teixeira – /82

62 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; Web Services – Fabiano Costa Teixeira – /82

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

64 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; Web Services – Fabiano Costa Teixeira – /82

65 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; Web Services – Fabiano Costa Teixeira – /82

66 WSDL: Estrutura (Parte Abstrata)
<definitions> <message name=“dadosLivro”> <part name=“isbn” type=“xs:string”/> </message> <message name=“estoqueAtual”> <part name=“estoque” type=“xs:integer”/> <portType name=“informacoesLivro”> <operation name=“requisitaEstoque“> <input message=“dadosLivro”/> <output message=“estoqueAtual”> </operation> </portType> ... Web Services – Fabiano Costa Teixeira – /82

67 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; A versão Apache utiliza o atributo namespace do elemento body; Web Services – Fabiano Costa Teixeira – /82

68 WSDL: Estrutura (Parte Concreta)
... <binding name=“livroBinding” type=“informacoesLivro”> <soap:binding style=“rpc” transporte=“ <operation name=“requisitaEstoque”> <soap:operation soapAction=“ <input> <soap:body use=“literal”> </input> <output> </output> </operation> </binding> <service name=“servicoEstoque”> <port name=“estoquePort” binding=“livroBinding”> <soap:address location=“ </port> </service> </definitions> Web Services – Fabiano Costa Teixeira – /82

69 WSDL: Stub’s A partir do WSDL um compilador gera as stub’s 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; Web Services – Fabiano Costa Teixeira – /82

70 WSDL: Stub’s WSDL Compilador WSDL (Lado do cliente) Compilador WSDL
(Lado do serv.) Aplicação Cliente Aplicação Servidora Stub Skeleton Web Services – Fabiano Costa Teixeira – /82

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

72 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; Web Services – Fabiano Costa Teixeira – /82

73 UDDI: Informações Páginas brancas: Páginas amarelas: Páginas verdes:
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; Web Services – Fabiano Costa Teixeira – /82

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

75 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; Web Services – Fabiano Costa Teixeira – /82

76 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; Web Services – Fabiano Costa Teixeira – /82

77 UDDI: API’s Registros UDDI possuem três tipos de usuários para os quais ele expõe suas API’s: 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; Web Services – Fabiano Costa Teixeira – /82

78 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; UBR’s 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; Web Services – Fabiano Costa Teixeira – /82

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

80 UDDI: Registros Públicos e Privados
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; Web Services – Fabiano Costa Teixeira – /82

81 Conclusão 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! Web Services – Fabiano Costa Teixeira – /82

82 Fabiano Costa Teixeira
Web Services – Fabiano Costa Teixeira – /82