Web Services Aluno: Fabiano Costa Teixeira Professor: Dr. Edmundo R. M. Madeira Web Services – Fabiano Costa Teixeira – 2005 1/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; Web Services – Fabiano Costa Teixeira – 2005 2/82

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

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 – 2005 5/82

Agenda Durante a apresentação serão abordados os seguintes assuntos: W3C XML Web Services SOAP WSDL UDDI Web Services – Fabiano Costa Teixeira – 2005 6/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; Web Services – Fabiano Costa Teixeira – 2005 7/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 Web Services – Fabiano Costa Teixeira – 2005 8/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; Web Services – Fabiano Costa Teixeira – 2005 9/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; Web Services – Fabiano Costa Teixeira – 2005 10/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; Web Services – Fabiano Costa Teixeira – 2005 11/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; Web Services – Fabiano Costa Teixeira – 2005 12/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; Web Services – Fabiano Costa Teixeira – 2005 13/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; Web Services – Fabiano Costa Teixeira – 2005 14/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; Web Services – Fabiano Costa Teixeira – 2005 15/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; Web Services – Fabiano Costa Teixeira – 2005 16/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; Web Services – Fabiano Costa Teixeira – 2005 17/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; Web Services – Fabiano Costa Teixeira – 2005 18/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; Web Services – Fabiano Costa Teixeira – 2005 19/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; Web Services – Fabiano Costa Teixeira – 2005 20/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; Web Services – Fabiano Costa Teixeira – 2005 21/82

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 – 2005 22/82

XML x HTML Resultado voltado para seres humanos; Web Services – Fabiano Costa Teixeira – 2005 23/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! Web Services – Fabiano Costa Teixeira – 2005 24/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; Web Services – Fabiano Costa Teixeira – 2005 25/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; Web Services – Fabiano Costa Teixeira – 2005 26/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; Web Services – Fabiano Costa Teixeira – 2005 27/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> Web Services – Fabiano Costa Teixeira – 2005 28/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 Web Services – Fabiano Costa Teixeira – 2005 29/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)> Web Services – Fabiano Costa Teixeira – 2005 30/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)> Web Services – Fabiano Costa Teixeira – 2005 31/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; Web Services – Fabiano Costa Teixeira – 2005 32/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> Web Services – Fabiano Costa Teixeira – 2005 33/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”> Web Services – Fabiano Costa Teixeira – 2005 34/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; Web Services – Fabiano Costa Teixeira – 2005 35/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> Web Services – Fabiano Costa Teixeira – 2005 36/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; Web Services – Fabiano Costa Teixeira – 2005 37/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; Web Services – Fabiano Costa Teixeira – 2005 38/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; Web Services – Fabiano Costa Teixeira – 2005 39/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); Web Services – Fabiano Costa Teixeira – 2005 40/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; Web Services – Fabiano Costa Teixeira – 2005 41/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; Web Services – Fabiano Costa Teixeira – 2005 42/82

Web Services: Papéis Web Services – Fabiano Costa Teixeira – 2005 43/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; Web Services – Fabiano Costa Teixeira – 2005 44/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 ; Web Services – Fabiano Costa Teixeira – 2005 45/82

SOAP: Estrutura Web Services – Fabiano Costa Teixeira – 2005 46/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; Web Services – Fabiano Costa Teixeira – 2005 47/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; Web Services – Fabiano Costa Teixeira – 2005 48/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; Web Services – Fabiano Costa Teixeira – 2005 49/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; Web Services – Fabiano Costa Teixeira – 2005 50/82

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 – 2005 51/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; Web Services – Fabiano Costa Teixeira – 2005 52/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; Web Services – Fabiano Costa Teixeira – 2005 53/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; Web Services – Fabiano Costa Teixeira – 2005 54/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; Web Services – Fabiano Costa Teixeira – 2005 55/82

SOAP: Binding Como exemplo, a primitiva POST do HTTP poderia ser utilizada em uma invocação RPC: POST /Exemplo HTTP/1.1 Host: www.exemplo.com.br 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 – 2005 56/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; Web Services – Fabiano Costa Teixeira – 2005 57/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); Web Services – Fabiano Costa Teixeira – 2005 58/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: <s:Header> <m:path xmlns:m=“http://schemas.xmlsoap.org/rp/”> <m:to>http://d.com</m:to> <m:fwd> <m:via>http://.b.com</m:via> <m:via>http://c.com</m:via> </m:fwd> <m:from>http://a.com</m:from> </m:path> </s:Header> Web Services – Fabiano Costa Teixeira – 2005 59/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; Web Services – Fabiano Costa Teixeira – 2005 60/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; Web Services – Fabiano Costa Teixeira – 2005 61/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; Web Services – Fabiano Costa Teixeira – 2005 62/82

WSDL: Estrutura Parte Abstrata Parte Concreta Web Services – Fabiano Costa Teixeira – 2005 63/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; Web Services – Fabiano Costa Teixeira – 2005 64/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; Web Services – Fabiano Costa Teixeira – 2005 65/82

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

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

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 – 2005 69/82

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 – 2005 70/82

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

UDDI: Informações Páginas brancas: Páginas amarelas: Páginas verdes: Busca de organizações pelo nome; Informações sobre contato (e-mail, 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 – 2005 73/82

UDDI: Estrutura de Dados Web Services – Fabiano Costa Teixeira – 2005 74/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; Web Services – Fabiano Costa Teixeira – 2005 75/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; Web Services – Fabiano Costa Teixeira – 2005 76/82

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 – 2005 77/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; 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 – 2005 78/82

UDDI: Registros Públicos e Privados http://uddi.microsoft.com Web Services – Fabiano Costa Teixeira – 2005 79/82

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 – 2005 80/82

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 – 2005 81/82

Fabiano Costa Teixeira fabiano.teixeira@ic.unicamp.br Web Services – Fabiano Costa Teixeira – 2005 82/82