III - Arquitetura. A arquitetura básica inclui tecnologias Web services capazes de:

Transcrição

1 III - Arquitetura Uma arquitetura de Web services ocupa, dentro de uma relação, vários componentes e tecnologias que compreendem uma pilha de Web services ou implementações completamente funcionais. Componentes e tecnologias que estendem a arquitetura básica são representadas dentro da arquitetura estendida. A arquitetura básica inclui tecnologias Web services capazes de: trocar mensagens; descrever Web services; publicar e descobrir descrições Web services. O fundamento da arquitetura Web services define uma interação entre agentes de software como um trocador de mensagens entre serviços requisitados e provedores de serviço. Os requisitantes são softwares agentes que requisitam a execução do serviço. Provedores são agentes de software que provêem um serviço. Agentes podem ser ambos, requisitantes e provedores. Provedores são responsáveis por publicar a descrição do serviço que ele esta disponibilizando / provendo. Requisitantes devem ser capazes de encontrar as descrições dos serviços. O fundamento dos modelos de arquitetura do Web service interagem entre agentes realizando qualquer das três funções: provedor de serviço, agência de serviço de publicação e requisição do serviço. A interação envolve a publicação, localização e operação de união. Num cenário típico um provedor de serviço hospeda um exemplo de uma rede acessível através de agente de software. O provedor do serviço define a descrição do serviço para o Web service e publica isso para um requisitante ou para um agente de publicação. O requisitante do serviço usa uma função de procura para recuperar a localização do serviço

2 localmente ou para descobrir uma agência de publicação (ex: registro ou repositório) e usa o serviço de descrição para ligar o Web service com o provedor e invocar ou interagir com a implementação do Web service. O provedor de serviço e a função de requisitante são desenvolvidas e um serviço deve exibir características de ambas. O uso de Web services na Internet esta se expandindo rapidamente como uma necessidade por comunicação de aplicativo pra aplicativo e crescente interoperabilidade. A excitação encima do Web service é baseada no potencial para uma combinação de especificações de XML, a Internet, o SOAP e o WSDL, e na definição de protocolos de endereçamento de tarefas, muitos dos problemas dessas tecnologias foram encontradas. As populares tecnologias Web service SOAP 1.1 e WSDL 1.1 foram originariamente desenvolvidas fora do W3C, porem, seus sucessores estão agora sendo desenvolvidos dentro das atividades do Web service W3C. Estas especificações estão sendo usadas como a base para a criação de uma arquitetura de mensagens extensível (SOAP 1.2) e a definição de uma interface de linguagem (WSDL 1.2). A figura acima ilustra a arquitetura básica do Web service, na qual um requisitante de serviço e um provedor interagem baseados no serviço descrição da informação publicada pelo provedor e descoberta pelo requisitante através de algumas formas de descobrimento da agencia. O serviço é requisitado e os provedores interagem trocando mensagens, as quais devem ser agregadas para o formulário MEP s message Exchange patterns (padrões de troca de mensagens).

3 No desenho acima, os nós do triângulo representam as funções ou papeis, e as extremidades representam as operações. Um ou mais mediadores devem existir no caminho entre um requisitante e um provedor. Mediadores, onde presentes, não podem interferir com o MEP. Mediadores devem realizar certas funções associadas com a mensagem assim como rotinas, segurança, gerenciamento, ou outras operações. Exemplos de MEPs incluem unilateralmente, requisições/respostas, publicação/aprovação, e transmissão. Arquitetura de componentes básica de Web Service são tipicamente definidas usando aplicações XML, usando definições XML tipos de mensagens e estruturação, e usando para transporte o http. Componentes de arquitetura estendida em Web services são tipicamente definidas usando extensões para conduzir aplicações XML e transportá-la, incluindo alternativas para o http. Uma mensagem é definida como uma combinação que pode incluir zeros ou mais cabeçalhos em adição para dados. A parte do cabeçalho de uma mensagem pode incluir informação pertinente para estender as funcionalidades, como segurança, contextos de transação, informação de orquestração, ou informação para roteamento de mensagens. O dado da parte da mensagem contém um conteúdo de mensagem ou dados. Um Web service é descrito usando um padrão, uma notação formal XML, chama-se isso de descrição do serviço, que provê todos os detalhes necessários para interagir com o serviço, incluindo formato de mensagens, transporte de protocolos, e localização. As naturezas das interfaces escondem os detalhes da implementação do serviço então isso pode ser usado independentemente da plataforma de hardware ou software na qual é implementada e independentemente da linguagem em que foi escrita. Web service pode ser usado sozinho ou em conjunto com outros Web services para atingir uma agregação complexa ou uma transação de negócios. A figura acima ilustra a relação entre requisitantes, provedores, serviços, descrições, e descobridores de serviço no caso, agentes onde agentes fazem o papel de requisitantes e provedores. O provedor de publicação um arquivo WSDL que contém a descrição da mensagem e ponto final da informação para permitir ao requisitante gerar a mensagem SOAP e enviá-la para o destino correto.

4 Para implantar um MEP comum (padrão de troca de mensagens) da requisição/resposta, por exemplo, uma implementação Web service prove agentes de software que funcionam ao mesmo tempo como requisitantes e provedores. O requisitante do serviço envia uma mensagem em forma de uma requisição de informação, ou para realizar uma operação, e receber uma mensagem do provedor do serviço que conterá um resultado para a requisição ou operação. O provedor do serviço recebe a requisição, processa a mensagem e envia uma resposta. A tecnologia tipicamente usada para esse tipo de interação Web service inclui SOAP, WSDL, e http. As seguintes seções provêem mais definições para os componentes, funções, e operações na arquitetura Web service. Componentes (components) Serviço: considerando que um Web service é uma interface descrita por uma descrição de serviço, esta implementação é o serviço. Um serviço é um modulo de software desenvolvido em plataformas de rede acessíveis providos por provedores de serviço. E existe para ser chamado ou interagir com um requisitante do serviço. Isto deve ser funcional também como um requisitante, usando outros Web services nessa implementação. Descrição do serviço: As descrições do serviço contem detalhes da interface e implementação do serviço. Isso inclui seus tipos de dados, operações, informações de ligações, e localização de rede, poderiam também incluir categorização e outros meta dados para descobrir facilidades e utilização pelos requisitantes. A descrição completa deve ser realizada como um conjunto de descrições de documentos XML. A descrição do serviço deve ser publicada para um requisitante diretamente ou para uma agencia descobridora. Papéis (funções) Roles Provedor de serviço: De uma perspectiva de serviço, este é o proprietário do serviço. De uma perspectiva de arquitetura é a plataforma que hospeda o acesso para o serviço. Também sendo referenciado como um ambiente de execução do serviço ou um compartimento do serviço. Esse papel no padrão de troca de mensagens é aquele de um servidor. Requisitante do serviço: de uma perspectiva de um negócio é uma tarefa que requer certas funções para ser satisfeita. De uma perspectiva de arquitetura esse é a aplicação que

5 esta olhando para uma invocação ou inicializando uma interação com um serviço. O papel de requisitante pode ser feito por um browser dirigido para uma pessoa ou um programa sem uma interface de usuário. Agência descobridora: Esta é uma localizadora padrão de descrição de serviços onde os provedores do serviço publicam suas descrições de serviço. O serviço de agencia descobridora pode ser centralizada ou distribuída. A agencia descobridora pode suportar ambos os padrões onde tenha que enviar descrições e onde possa ativamente inspecionar, procurar por provedores de descrições de serviços. Requisitantes de serviços devem localizar serviços e obter ligações de informações durante o desenvolvimento de ligações estáticas, ou durante a execução de ligações dinâmicas. Operações Operations Para uma aplicação tomar vantagens do Web services, três maneiras devem tomar lugar: publicação das descrições dos serviços, localização e recuperação das descrições dos serviços, e ligações ou invocação dos serviços baseados nos serviços de descrição. Essas maneiras podem ocorrer só ou interativamente com qualquer cardinalmente entre os papéis. Em detalhes, essas operações são: Publicação: para ser acessível, um serviço precisa publicar suas descrições assim como o requisitante pode subseqüentemente localizá-las. Localização: Na operação de localização, o requisitante do serviço recupera uma descrição do serviço diretamente ou perguntando pelo registro do serviço requerido. A operação de localização deve ser envolvida em duas fases de ciclos de vida para o requisitante do serviço: no tempo de construção para recuperar a interface da descrição do programa desenvolvido, e na hora de execução para recuperar a ligação do serviço e descrição da localização para invocação. Interação: eventualmente, um serviço necessita ser invocado. A operação de interação do requisitante do serviço invoca ou inicializa uma interação com o serviço na hora de execução usando os detalhes da descrição da ligação para localização, contatar, e inovar o serviço.

6 IV - Protocolos A implementação de Web Services é baseada em um conjunto de protocolos e linguagens padrões da Web, dentre eles podemos destacar o HyperText Transfer Protocol (HTTP), o Simple Object Access Protocol (SOAP), a Web Service Description Language (WSDL) e o UDDI. O formato XML é a base dos três últimos padrões. De uma maneira geral, o protocolo SOAP define o formato que as mensagens transportadas na rede devem ter para encaminhar requisições a serviços Web. Este protocolo também define o formato das mensagens de resposta às requisições. Já o WSDL consiste em uma linguagem XML para a descrição de interfaces de serviços, visando tornar essa descrição inteligível para programas que irão interagir com esses serviços. Nas páginas seguintes nós vamos descrever detalhadamente cada um destes protocolos XML, SOAP, WSDL e UDDI para dar um entendimento maior sobre o funcionamento do Web Services.

7 XML Extensible Markup Language XML é um formato de texto muito simples e flexível derivado do SGML. Originalmente projetado para encontrar chaves em documentos eletrônicos em larga escala, XML esta também se tornando um importante padrão para a troca de uma vasta variedade de dados na web. Com o advento do XML tornou-se fácil para sistemas de diferentes ambientes trocarem informações. A universalidade do XML tornou-se uma maneira muito atrativa para comunicação entre programas. Programadores podem usar diferentes sistemas operacionais, linguagens de programação etc. e ter seus softwares comunicando-se com outros de uma maneira ininterrupta. XML, XML namespaces e XML schemas são ferramentas úteis para prover mecanismos para realizar acordos com estruturas extensas em um ambiente distribuído, especialmente quando usados em conjunto, XML namespaces e XML schemas serão abordados mais adiante. No mundo em geral, sistemas de computador e bancos de dados contém dados em formatos incompatíveis, muito tempo se tem gasto no desafio de desenvolvedores em trocar dados entre sistemas e a Internet, portanto o objetivo do XML é a troca de dados. Convertendo dados para XML pode-se reduzir em muito esta complexidade e criar dados que podem ser lidos por uma variedade de diferentes tipos de sistemas. Alguns conceitos: XML foi desenvolvido para descrever dados e focar o que os dados são. HTML foi desenvolvido para mostrar dados e focar em como os dados aparecem. Com o XML os dados são armazenados fora do HTML. Quando o HTML é usado para mostrar dados, o dado é armazenado dentro do HTML. Com o XML, dados podem ser armazenados em arquivos XML separados, desta maneira pode-se concentrar o HTML para dados de layout e visualização, e ter certeza que as mudanças em dados essenciais não irão requerer nenhuma mudança para o HTML.

8 Dados XML também podem ser armazenados dentro de páginas HTML como ilhas de dados (data island), pode-se ainda concentrar em usar somente HTML unicamente para formatar e visualizar os dados. XML está se transformando para ser a principal linguagem para troca de informação financeira entre empresas na Internet, muitas aplicações interessantes de B2B estão sendo desenvolvidas. O XML possui outras vantagens nesse aspecto: Armazenamento de dados em arquivos ou bancos de dados, podendo ser recuperados mais tarde; Tornar os dados mais úteis para uma quantidade enorme de usuários, pois é independente de hardware; Pode ser usado para criar outras linguagens, XML é a mãe do WAP e WML; Exemplo de documento XML Documentos XML usam uma descrição própria e uma sintaxe simples: <?xml version="1.0" encoding="iso "?> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> A primeira linha no documento ( declaração XML) define a versão do XML e a codificação dos caracteres usados no documento; A próxima linha descreve o elemento raiz do documento, como se fosse um título; As próximas quatro linhas descrevem quatro elementos da raiz (to, from, heading, body); Na última linha aparece o fechamento do elemento raiz (root).

9 Um dado importante no XML é que todos os elementos possuem uma tag de abertura, ex.: <note> e uma tag de fechamento ex.: </note>, portanto a falta de um deles é considerada ilegal. As tags no XML são diferentes quando expressadas em maiúsculas ou minúsculas diferentemente do HTML, portanto deve-se tomar o cuidado em digitar as tags da mesma forma na sua abertura e fechamento. Além disso as tags devem merecer principal atenção no caso de sua inserção, pois apresentam erros se forem inseridas de maneira errada, ex.: Abaixo nota-se a inserção do <b><i> e o seu respectivo fechamento </i></b> a inserção errada desse detalhe ocasiona erros no XML, diferentemente do HTML onde é aceito essa inversão sem problemas. Forma aceita no XML <b><i>this text is bold and italic</i></b> Forma aceita no HTML <b><i>this text is bold and italic</b></i> Outros pontos que devem ser notados em documentos XML: Nomes e valores devem ser citados, ou seja, devem ser mencionados no documento com aspas para serem reconhecidos ex: <note date="12/11/2002"> - modelo correto; <note date=12/11/2002> - modelo incorreto. Espaços em branco que são digitados em documentos XML não são levados em consideração no momento da visualização. Novas linhas no XML são sempre armazenadas como LF, ou seja, no momento da impressão o carro da impressora deve ser voltado manualmente para a esquerda e o papel novamente realinhado, diferentemente de aplicativos Windows que usam o CR (carriage return retorno do carro de impressão).

10 Elementos XML (XML elements) nomes. Elementos XML são extensíveis e tem relacionamentos, possuem simples regras de Analisaremos o modelo abaixo: <note> <to>tove</to> <from>jani</from> <body>don't forget me this weekend!</body> </note> Podemos criar uma aplicação que extrai o elemento <to>, <from> e <body> desse documento XML para produzir esse resultado: MESSAGE To: Tove From: Jani Don't forget me this weekend! Por mais que o autor do documento acima adicione mais elementos ao documento a aplicação ainda será capaz de localizar os elementos <to>, <from> e <body> e produzir o mesmo resultado anterior. Elementos XML possuem relacionamentos Elementos são relacionados como pais (parents) e filhos (children). Imaginemos que essa seja a descrição de um livro: Book Title: My First XML Chapter 1: Introduction to XML What is HTML What is XML Chapter 2: XML Syntax Elements must have a closing tag Elements must be properly nested

11 Imagine que esse documento XML descreve o livro acima: <book> <title>my First XML</title> <prod id="33-657" media="paper"></prod> <chapter>introduction to XML <para>what is HTML</para> <para>what is XML</para> </chapter> <chapter>xml Syntax <para>elements must have a closing tag</para> <para>elements must be properly nested</para> </chapter> </book> Book é o elemento raiz (root element). Title, prod, e chapter são elementos filhos (child element) do livro. Book é o elemento pai (parent element) do elemento title, prod e chapter. Title, prod and chapter são irmãos (siblings ou sister elements) porque eles tem o mesmo pai. Elementos podem ainda ter diferentes tipos de conteúdo. Um elemento pode ter elemento de conteúdo, conteúdo misturado, conteúdo simples, ou conteúdo vazio. Um elemento pode também ter atributos. No exemplo acima temos os seguintes: book, tem um elemento de conteúdo, porque contem outros elementos; Chapter, tem um conteúdo misturado, porque contem texto e outro elemento; Para, tem conteúdo simples, porque contem somente texto. Prod, tem conteúdo vazio, porque não carrega nenhuma informação. Atributos XML Elementos XML podem ter atributos no início da tag, sendo parecido com HTML. Atributos são usados para prover informações adicionais sobre elementos.

12 De documentos HTML podemos lembrar isso: <IMG SRC="computer.gif">. O atributo SRC provê informações adicionais sobre o elemento IMG. No HTML e XML atributos provêem informações adicionais sobre elementos: <img src="computer.gif"> <a href="demo.asp"> Atributos geralmente provem informação que não são parte dos dados. No exemplo abaixo o tipo de arquivo é irrelevante para os dados, mas importante para o software que quer manipular o elemento. <file type="gif">computer.gif</file> XML embutido em HTML. abaixo: XML pode ser inserido diretamente dentro de uma página HTML, como mostrado <xml id="note"> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> </xml> ou separadamente, podem ser inserido assim: <xml id="note" src="note.xml"> </xml> XML News O XMLNews é uma especificação para troca de noticias e outras informações. Permite à produtores e consumidores de notícias produzir, receber e arquivar qualquer tipo de informação através de diferentes software, hardware e linguagens de programação.

13 Um exemplo de documento XMLNews: <?xml version="1.0" encoding="iso "?> <nitf> <head> <title>colombia Earthquake</title> </head> <body> <body.head> <headline> <hl1>143 Dead in Colombia Earthquake</hl1> </headline> <byline> <bytag>by Jared Kotler, Associated Press Writer</bytag> </byline> <dateline> <location>bogota, Colombia</location> <story.date>monday January :28 ET</story.date> </dateline> </body.head> </body> </nitf> XML Namespaces Com a visibilidade futura de aplicações XML onde um único documento pode conter elementos e atributos que são definidos para serem usados por múltiplos softwares, foram criados os Namespaces. Um XML Namespace é uma coleção de nomes, identificados por uma referencia URI, que é usada em documentos XML como tipos e elementos e atributo de nomes. XML Namespace difere dos Namespace convencionalmente usados em disciplinas de computação em que a versão XML tem uma estrutura interna e não é, matematicamente falando, um conjunto. XML Namespaces provêem um método de evitar conflitos de elementos em documentos XML. Desde que nomes de elementos em XML não são fixados, muito freqüentemente um nome irá conflitar com outro ocorrendo dois tipos diferentes de documentos usando a mesma descrição de nomes para dois tipos diferentes de elementos.

14 Este documento XML carrega informação em uma tabela: <table> <tr> <td>apples</td> <td>bananas</td> </tr> </table> Este documento XML carrega informação sobre uma tabela: <table> <name>african Coffee Table</name> <width>80</width> <length>120</length> </table> Nos casos acima gerará conflito pois os dois documentos contém uma <table> com o mesmo nome. Para resolver o problema exposto acima o XML usa um prefixo, um exemplo de documento XML usando prefixo: <h:table> <h:tr> <h:td>apples</h:td> <h:td>bananas</h:td> </h:tr> </h:table> <f:table> <f:name>african Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table> Agora os documentos não se conflitam pois usam diferentes tabelas. Usando Namespaces Este documento XML carrega informação em uma tabela:

15 <h:table xmlns:h=" <h:tr> <h:td>apples</h:td> <h:td>bananas</h:td> </h:tr> </h:table> Este documento XML carrega informação sobre uma peça: <f:table xmlns:f=" <f:name>african Coffee Table</f:name> <f:width>80</f:width> <f:length>120</f:length> </f:table> Ao invés de usar somente prefixos, um atributo xmlns foi adicionado na tag <table> para dar ao prefixo um nome qualificado associado com um Namespace. SOAP (Simple Object Access Protocol) SOAP é um protocolo simples e leve baseado em XML que proporciona troca de informações encima do protocolo HTTP, em suma, é um protocolo para acessar Web Services. A arquitetura tem sido desenhada para ser independente de qualquer modelo particular de programa e de outras implementações específicas. Os dois maiores objetivos do SOAP são a simplicidade e extensibilidade e esse protocolo obedece a esses requisitos pois trafega encima do http e o http é suportado por todos os servidores e browsers do mercado, com diferentes tecnologias e linguagens de programação. Bloco de estrutura SOAP elementos: Uma mensagem SOAP é um documento habitual em XML contendo os seguintes

16 Um elemento envelope que identifica o documento XML como um SOAP. Um elemento header opcional que contem informações de chamadas e repostas; Um elemento de falha opcional que prove informação sobre erros que ocorrem quando do processamento da mensagem. Esqueleto de mensagens SOAP Abaixo a estrutura de uma mensagem SOAP, explicaremos cada parte dessa estrutura nos capítulos abaixo: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> </soap:header> <soap:body> <soap:fault> </soap:fault> </soap:body> </soap:envelope> Envelope SOAP O envelope SOAP é o elemento mais importante, o elemento raiz de uma mensagem SOAP, ele define o documento XML como uma mensagem SOAP, em suma, é o mais importante em uma mensagem SOAP. Notamos o uso do xmlns:soap namespace. Ele deve sempre ter o valor de: e este define o envelope como um envelope SOAP:

17 <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" Message information goes here </soap:envelope> O xmlns:soap namespace Uma mensagem SOAP deve sempre ter um envelope associado com " namespace. Se um Namespace diferente é usado, a aplicação deve gerar um erro e descartar a mensagem. O Atributo encodingstyle O atributo encodingstyle é usado para definir tipos de dados usados no documento. Este atributo deve aparecer em qualquer elemento SOAP e ele irá aplicar o conteúdo desse elemento para todos os elementos filhos (children elements). Sintaxe: soap:encodingstyle="uri" Podemos visualizar um exemplo do encodingstyle nesse modelo: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" Message information goes here </soap:envelope>

18 Header SOAP O elemento Header (cabeçalho) contem informação específica da aplicação, sobre a mensagem SOAP. Se o Header estiver presente, este deve ser o primeiro elemento child (filho) do envelope. OBS: Todos os elementos child do header devem ser Namespaces qualificados. <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:mustunderstand="1">234</m:trans> </soap:header> </soap:envelope> O exemplo acima contem três atributos contendo um cabeçalho com um elemento Trans um atributo mustunderstand com valor de 1 e 234. SOAP define três atributos em Namespace padrão (" Esses atributos definidos no cabeçalho SOAP definem como um recipiente deve processar a mensagem SOAP. O atributo Actor (autor) Uma mensagem SOAP deve percorrer do remetente para o recebedor passando por diferentes endpoints ao longo do caminho da mensagem. Nem todas as partes de uma mensagem SOAP devem estar planejados para o ultimo endpoint da mensagem mas, ao invés disso, devem planejar um ou mais endpoints no caminho da mensagem. O atributo actor deve ser usado para endereçar o cabeçalho para um endpoint particular.

19 Sintaxe actor: soap:actor="uri" Exemplo: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:actor=" 234 </m:trans> </soap:header> </soap:envelope> O atributo mustunderstand O atributo mustunderstand pode ser usado para indicar se um cabeçalho de entrada é obrigatório ou opcional para o processo. Se adicionarmos mustunderstand= 1 para um elemento child do cabeçalho este indicara que o processo recebedor do cabeçalho deve reconhecer o elemento. Se o recebedor não identificar o elemento este deve falhar quando processar o cabeçalho. Sintaxe: soap:mustunderstand="0 1" Exemplo: <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:header> <m:trans xmlns:m=" soap:mustunderstand="1"> 234 </m:trans> </soap:header> </soap:envelope>

20 SOAP Body O SOAP Body (corpo) contem a mensagem SOAP presente, planejada para a conclusão do endpoint da mensagem. Logo os elementos child do corpo deve ser namespace-qualified (namespace qualificado). SOAP define um elemento dentro do corpo no namespace padrão (" Este é o elemento SOAP Fault (falha), que é usado para indicar mensagens de erro. WSDL WSDL é um formato XML para descrever serviços de rede como um conjunto de operações como ponto final nas mensagens contendo cada documento orientado ou informação orientada. As operações e mensagens são descritas de forma abstrata e então o salto para um protocolo de rede concreto e formato de mensagens para definir um ponto final. WSDL é extensível para permitir descrição do ponto final e suas mensagens não levem em consideração de quais formatos de mensagens ou protocolos de rede são usados para comunicação. Como protocolos de comunicação e formatos de mensagens são padronizadas na comunidade web, isso se torna crescente a possibilidade e importante ser capaz de descrever as comunicações em alguma forma de estrutura. Esses endereços WSDL necessitam pela definição de uma gramática XML para descrever serviços de rede como coleções de pontos finais de comunicações capazes de trocar mensagens. As definições de serviços WSDL provêem documentação para sistemas distribuídos e servem como um recipiente para detalhes de automação envolvidos em aplicações de comunicação. Um serviço WSDL define documentos como coleções de pontos finais de rede, ou portas. No WSDL, a definição abstrata de pontos finais e mensagens são separadas de suas organizações de redes concretas ou formatos de dados de comunicação. Isto permite a reutilização de definições abstratas: mensagens, que são descrições abstratas dos dados sendo trocados, e tipos de portas que são coleções abstratas de operações. O protocolo concreto e especificações de dados concretos para uma tipo de porta em particular constituídas como comunicações reutilizáveis. Uma porta é definida associando um endereço de rede como

21 ligação reutilizável, e uma coleção de portas definindo um serviço. Daqui, um documento WSDL usa os seguintes elementos em sua definição dos serviços de rede: Estrutura WSDL Types (tipos) Um recipiente para definição de tipos de dados usando alguns tipos de sistemas. WSDL usa sintaxe XML para definir tipos de dados. Message (mensagens) Um resumo de definições de tipos de dados sendo trafegados, podem conter uma ou mais partes, esses partes podem ser comparadas à parâmetros de uma função. porttype (Tipo de porta) Um resumo da configuração das operações suportadas por um ou mais endpoints. porta. Binding (Ligação): Define o formato da mensagem e detalhes de protocolos para cada Estrutura do WSDL: <definitions> <types> definition of types.. </types> <message> definition of a message. </message> <porttype> definition of a port. </porttype> <binding> definition of a binding. </binding> </definitions>

22 WSDL ports WSDL Ports é o elemento mais importante no WSDL, ele define um WS, suas operações desempenhadas e mensagens que estão envolvidas. Operation Types (Tipos de operação) One-Way A operação pode receber uma mensagem mas não irá retornar uma resposta. Request-responde A operação pode receber uma requisição e retornar uma resposta. Solicit-response A operação pode enviar uma requisição e esperar por uma resposta Notification A operação pode enviar uma mensagem mas não ir Bindings SOAP O elemento Binding tem dois atributos, name e type, o atributo name define o nome da ligação, e o type indica o ponto para a ligação da porta, nesse caso o glossary terms port. O elemento soap:binding tem dois atributos, style e transport, style pode ser o rpc ou documento, o transport define o protocolo SOAP a ser usado, no caso o http. UDDI Universal Description, Discovery and Integration. Quando se constrói Web services, esses serviços necessitam ser acessados em algum lugar na Web por uma aplicação-cliente. Uma forma de se acessar um Web service é fazer com que a aplicação-cliente conheça a URI do serviço, desta maneira caracterizando o modo estático de se localizar e acessar um serviço. Entretanto, quando a aplicação-cliente não detém, a priori, a localização de um Web service, esse, pode ser descoberto antes de ser acessado caracterizando o modo dinâmico de se descobrir a localização de um serviço. UDDI é uma especificação técnica para descrever (describing), descobrir (discovering) e integrar Web services. Assim, é portanto, uma parte crítica da pilha de