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

(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-8859-1"?>

<note>

<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);

(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)

Elementos XML são extensíveis e tem relacionamentos, possuem simples regras de nomes.

Analisaremos o modelo abaixo: <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

<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">

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 .

XML pode ser inserido diretamente dentro de uma página HTML, como mostrado abaixo: <xml id="note"> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading>

</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-8859-1"?> <nitf> <head> <title>Colombia Earthquake</title> </head> <body> <body.head> <headline>

<hl1>143 Dead in Colombia Earthquake</hl1> </headline>

<bytag>By Jared Kotler, Associated Press Writer</bytag> </byline>

<location>Bogota, Colombia</location>

<story.date>Monday January 25 1999 7: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>

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

(15)

<h:table xmlns:h="http://www.w3.org/TR/html4/"> <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="http://www.w3schools.com/furniture"> <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

Uma mensagem SOAP é um documento habitual em XML contendo os seguintes elementos:

(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="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <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: http://www.w3.org/2001/12/soap-envelope

(17)

<?xml version="1.0"?> <soap:Envelope

xmlns:soap="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ...

Message information goes here ...

</soap:Envelope>

O xmlns:soap namespace

Uma mensagem SOAP deve sempre ter um envelope associado com "http://www.w3.org/2001/12/soap-envelope" 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="http://www.w3.org/2001/12/soap-envelope"

soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ...

Message information goes here ...

(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="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" 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 ("http://www.w3.org/2001/12/soap-envelope"). 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="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" soap:actor="http://www.w3schools.com/appml/"> 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="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> <m:Trans xmlns:m="http://www.w3schools.com/transaction/" 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 ("http://www.w3.org/2001/12/soap-envelope"). 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.

Binding (Ligação): Define o formato da mensagem e detalhes de protocolos para cada porta. 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

(23)

protocolos Web services, habilitando usuários dos serviços a publicarem e descobrirem estes serviços.

Discovery é o processo de localizar Web services através de registries. Registries de Web services são repositórios contendo documentos que descrevem dados de negócios. Registries, também, proporcionam características tais como, capacidade de busca e acesso programático para aplicações remotas. Usando um registry, uma organização que deseja utilizar, por exemplo, um serviço para processar pagamentos de tickets de alimentação, pode localizar todos os serviços disponíveis publicamente, que proporcionam a necessária funcionalidade. A organização pode comparar serviços e então decidir qual serviço melhor se ajusta às necessidades da organização. Discovery pode ser caracterizado em Discovery direto ou Discovery indireto.

Discovery direto

É o processo de obter dados a partir de um registry mantido por um provedor de serviço. Dados obtidos por Discovery direto são mais precisos e, portanto, confiáveis, visto que a organização que provê a informação também opera o serviço na Web.

Discovery indireto

Com Discovery indireto, uma organização obtém dados através de uma terceiro registry, cujos dados podem não ser precisos, porque provedores de serviço poderiam não atualizar as informações nesse registry tão freqüentemente. Quando realizando Discovery indireto, organizações devem colocar a seguinte questão: quão freqüente, terceiros registries interagem com provedores de serviço para garantir que os dados são ainda precisos? Embora discovery indireto tenha seus “drawbacks”, ele ainda permite avaliar serviços de vários provedores antes do compromisso para usar um serviço particular.

Em seu núcleo, UDDI consiste de duas partes: API UDDI e UDDI Business Registry.

API UDDI

É uma especificação técnica para construir um diretório distribuído de negócios (business) e Web services. A informação UDDI é armazenada dentro de um formato

(24)

específico XML, definido por WSDL e XML Schema. A especificação inclui detalhes de uma API própria para buscar dados existentes ou publicar novos dados.

UDDI Business Registry

Também conhecido como “UDDI cloud services” é uma implementação operacional completa da especificação UDDI. Tal parte habilita qualquer um a buscar dados UDDI existentes, e também, a qualquer empresa registrar-se a si própria e seus respectivos serviços.

A informação capturada no contexto UDDI são classificadas em três categorias principais:

Páginas Brancas (White Pages)

Essas incluem informações sobre uma empresa específica, como por exemplo, nome de um negócio, descrição do negócio, informação de contato, endereço, números de telefone, fax, ou mesmo incluir identificadores de negócios (business identifiers), no formato de classificações Dun & Bradstreet’s D-U-N-S (Data Universal Numbering System), que são números de nove dígitos atribuídos a negócios. A especificação UDDI versão 2.0 oferece suporte para identificadores específicos de indústrias, tal como o sistema do Standard Industrial Classification (SIC), o qual atribui identificadores numéricos únicos a indústrias. Por exemplo, 7371 representa Serviços de Programação de Computadores e 2621 representa Paper Mills.

Páginas Amarelas (Yellow Pages)

Essas incluem dados de classificação geral para qualquer empresa ou serviço oferecido. Por exemplo, esses dados podem incluir a indústria, o produto, ou códigos geográficos baseados sobre taxionomias padronizadas.

(25)

Páginas Verdes (Green Pages)

Esta categoria contém informação técnica sobre um serviço na Web (Web service). Geralmente, essa informação inclui um apontador (ponteiro) para uma especificação externa e um endereço para invocar o serviço. UDDI não é restrito a descobrir serviços baseados em SOAP. Ao contrário, pode ser usado também, para descrever qualquer serviço, desde uma única página Web ou endereços de e-mail, até serviços CORBA, Java RMI, ou mesmo, serviços EJB.

Arquitetura UDDI

A arquitetura técnica de UDDI consiste de três partes: Um Modelo de Informação UDDI, o qual baseia-se num XML Schema para descrever negócios e Web Services, uma API UDDI baseada em SOAP para publicação e busca de informação UDDI e no UDDI Business Registry (UBR) os quais são os sites-operadores que provêem implementações da especificação UDDI e sincronizam todos os dados sobre uma “scheduled basis”. Exemplos de UBR’s providos por grandes corporações, são Microsoft, IBM, HP, SAP e NTT Communications do Japão

(26)

Sites-Operadores

Um site-operador é uma organização que hospeda uma implementação do UDDI Business Registry (UBR). Uma empresa usuária de UDDI necessita registrar-se somente em um site-operador, conhecido como custodian. O princípio básico do UDDI para um UBR é aquele de que uma empresa “registra uma vez e publica em qualquer lugar”. Princípio que afirma, que a informação contida em um UBR custodian é replicada sobre os outros UBR’s. Replicação é o processo de atualizar registros, de modo que todas as instâncias daqueles registros originais sejam idênticas. Assim, uma empresa registra os seus dados em um site-operador (custodian) e esses aparecem nos outros sites-site-operadores. Até a versão UDDI 2.0, uma empresa podia atualizar sua informação somente através de seu site-operador custodian. Isto porque, a especificação da API versão 2.0 de UDDI não provia um protocolo para reconciliar diferentes versões de UDDI. Tal limitação requer interação com somente um site-operador, proibindo, assim, usuários de entrarem em múltiplas versões de modelos de informação em diferentes sites-operadores.

Os UDDI Business Registries (UBR’s) proporcionam um diretório de sistes-operadores UDDI, fisicamente distribuído, mas logicamente centralizado. Isto significa que dados submetidos a um site-operador serão automaticamente replicados através de todos os outros sites-operadores. Tal replicação não ocorre instantaneamente, mas os sites-operadores se sincronizam para atualização de registros, em intervalos de tempo diariamente.

É também possível estabelecer registros UDDI privados. Por exemplo, uma grande empresa pode estabelecer seu próprio sistema UDDI privado, para registrar todos os seus serviços Web internos à empresa. Quando esses serviços não são automaticamente sincronizados com os sites-operadores UDDI, eles não são considerados partes do conjunto de UDDI Business Registries (os cloud services).

Registrars

Empresas usuárias de UDDI podem também publicar informação em um UBR, através de uma organização chamada registrar – uma outra empresa que auxilia na criação de informação de negócios e descrições de Web services, a serem armazenados nos UBR’s. Uma empresa registrar não é um site-operador, porque essas empresas não hospedam implementações de UDDI Business Registry.