• Sonuç bulunamadı

1.3. Toxoplasma gondii 'nin epidemiyolojis

1.3.5. Köpeklerdeki yaygınlığı

4.6

UDDI

UDDI ou “Universal Description, Discovery and Integration” ´e um padr˜ao para registros baseados em XML que contˆem informa¸c˜oes sobre um Servi¸co Web. Um registro UDDI permite o acesso aos documentos WSDL dos Servi¸cos Web existentes na Internet (que foram publicados). As empresas ou qualquer um que queira divulgar seu Servi¸co Web faz a publica¸c˜ao das suas informa¸c˜oes atrav´es de um registro UDDI e qualquer um que queira usar este servi¸co pode encontrar as suas informa¸c˜oes atrav´es de uma busca em um reposit´orio de registros UDDI (Bellwood, 2002).

Um registro UDDI cont´em informa¸c˜oes sobre neg´ocios, dados da organiza¸c˜ao e dos servi¸cos que ela oferece. Ele pode ser comparado a uma lista telefˆonica dividida em trˆes grandes partes:

1. P´aginas brancas: permitem encontrar informa¸c˜oes sobre a empresa, como endere¸co, informa¸c˜oes de contato com a empresa, etc.

2. P´aginas amarelas: as informa¸c˜oes s˜ao classificadas com base em padr˜oes da ind´ustria ou segmento da qual a empresa e os seus servi¸cos fazem parte.

3. P´aginas verdes: cont´em a lista completa dos servi¸cos na Internet oferecidos pelas empresas relacionadas nas p´aginas brancas.

Com a finalidade de permitir a busca e descoberta de organiza¸c˜oes e dos servi¸cos oferecidos por elas, atrav´es da abordagem solicita¸c˜ao-resposta, o UDDI disponibiliza APIs (Application

Program Interface) que tornam estas fun¸c˜oes execut´aveis atrav´es de programas.

Est˜ao dispon´ıveis dois tipos de API para intera¸c˜ao via programa (Albinader e Lins, 2006):

1. API de publica¸c˜ao: ´e empregada para intera¸c˜ao entre aplica¸c˜oes do publicador e o registro UDDI, permitindo a cria¸c˜ao, modifica¸c˜ao e exclus˜ao de registros.

2. API de busca e localiza¸c˜ao: destinada a permitir que aplica¸c˜oes realizem buscas, pesquisas e localizem registros.

4.7

Axis

O Axis 2, um projeto da Apache (http://www.apache.org), ´e uma implementa¸c˜ao do pro- tocolo SOAP (ver se¸c˜ao 4.4) utilizado em Servi¸cos Web. Ele oferece uma arquitetura modular e um modelo de objetos completo que torna simples o emprego de especifica¸c˜oes e recomenda¸c˜oes relacionadas aos Servi¸cos Web (Axis2, 2007).

O Axis 2 permite realizar as seguintes tarefas: 1. Envio de mensagens SOAP ;

2. Recebimento e processamento de mensagens SOAP ; 3. Cria¸c˜ao de Servi¸cos Web a partir de classes Java;

4. Cria¸c˜ao de implementa¸c˜oes (por exemplo, classes Java) para aplica¸c˜oes clientes e servi- doras a partir do descritor WSDL ;

5. F´acil obten¸c˜ao do WSDL para um servi¸co;

6. Envio e recebimento de mensagens SOAP com anexos;

7. Cria¸c˜ao ou utiliza¸c˜ao de Servi¸cos Web baseados em REST ou Representational State

Transfer (Costello, 2007);

8. Cria¸c˜ao ou utiliza¸c˜ao de servi¸cos que utilizem as recomenda¸c˜oes de Servi¸cos Web em termos de seguran¸ca, confiabilidade, endere¸camento, entre outras;

9. Uso da sua estrutura modular para facilmente suportar novas recomenda¸c˜oes. Atualmente, o Axis 2 ´e disponibilizado para as linguagens Java e C++ (Axis2, 2007).

4.7.1

Funcionamento

A Figura 4.7 demonstra o funcionamento do Axis em um sistema em que o Axis esteja sendo usado tanto pelo cliente quanto pelo servidor do Servi¸co Web (o que n˜ao ´e obrigat´orio) (Axis2, 2007):

! " " # $ % & ' ( )

Figura 4.7: Esquema de funcionamento do Axis.

1. A aplica¸c˜ao cliente invoca o uso do Servi¸co Web fazendo uma chamada `a API cliente (implementa¸c˜ao do Axis );

2. A mensagem SOAP ´e criada e enviada aos interceptadores;

3. Caso seja necess´ario, a¸c˜oes como criptografia de seguran¸ca s˜ao realizadas sobre a men- sagem;

4. A mensagem ´e enviada pela camada de transporte;

5. Na outra ponta (passando pela Internet) a mensagem ´e recebida por um ouvinte da camada de transporte que a detecta;

6. A mensagem ´e repassada aos interceptadores para poss´ıveis manipula¸c˜oes; 7. A mensagem ´e encaminhada `a aplica¸c˜ao apropriada (Servi¸co Web).

A plataforma Axis ´e formada por v´arios componentes, cada um respons´avel por uma destas fases de opera¸c˜ao.

4.7.2

Disponibiliza¸c˜ao de Servi¸cos Web atrav´es do Axis

Atrav´es do Axis, ´e poss´ıvel a disponibiliza¸c˜ao dos Servi¸cos Web, de maneira r´apida e f´acil. No lado do servidor, o Axis ´e instalado em um contˆeiner Web como o Tomcat (ver se¸c˜ao 5.5), funcionando como um Servlet. Servi¸cos Web apropriadamente “empacotados” podem, ent˜ao, ser instalados no Axis, como ilustra a Figura 4.8.

!

Figura 4.8: Disponibiliza¸c˜ao de Servi¸cos Web com o Axis.

Na vers˜ao corrente na ´epoca do desenvolvimento deste trabalho (2007), o Axis 2 vers˜ao 1.2, os Servi¸cos Web s˜ao empacotados em um arquivo de extens˜ao “.aar” (Axis archive), similar ao “jar” da linguagem Java, para serem instalados no Axis. Este arquivo deve conter, al´em das classes do Servi¸co Web (skeleton ), um arquivo de configura¸c˜ao (services.xml) e arquivos jar de terceiros (outras classes necess´arias ao servi¸cos, dispostas em arquivos de extens˜ao “.jar”).

O arquivo de configura¸c˜ao do servi¸co, escrito em XML e com o nome services.xml, serve para informar ao Axis as opera¸c˜oes dispon´ıveis para o servi¸co, o nome da sua classe de implementa¸c˜ao (skeleton ), al´em de outros parˆametros espec´ıficos.

O C´odigo 4.5 mostra o arquivo services.xml para o Servi¸co Web de exemplo mostrado na se¸c˜ao 3.4.1.

<!-- This file was auto-generated from WSDL --> <!-- by the Apache Axis2 -->

<serviceGroup> <service name="SomaWS"> <messageReceivers> <messageReceiver mep="http://www.w3.org/2004/08/wsdl/in-out" class="exwsbobo.SomaWSMessageReceiverInOut" /> </messageReceivers>

<parameter name="ServiceClass" locked="false"> exwsbobo.SomaWSSkeleton </parameter> <operation name="somaInteiros" mep="http://www.w3.org/2004/08/wsdl/in-out"> <actionMapping>urn:somaInteiros</actionMapping> <outputActionMapping> http://exWSBobo/SomaWSPortType/somaInteirosResponse </outputActionMapping> </operation> </service> </serviceGroup>

Benzer Belgeler