CENTRO UNIVERSITÁRIO VILA VELHA
CURSO DE CIÊNCIA DA COMPUTAÇÃO
Diogo Francisco Sales da Silva
Flávio Rodrigo Lovatti
Computação Distribuída, Web Service - um
estudo de caso
VILA VELHA
2009
Diogo Francisco Sales da Silva
Flávio Rodrigo Lovatti
Computação Distribuída, Web Service - um
estudo de caso
Trabalho de Conclusão de Curso apresentado ao Centro Univertário Vila Velha como
requisito parcial para a obtenção do grau
de Bacharel em Ciência da Computação.
Orientador: Cristiano Biancardi
VILA VELHA
2009
Diogo Francisco Sales da Silva
Flávio Rodrigo Lovatti
Computação Distribuída, Web Service - um
estudo de caso
BANCA EXAMINADORA
Prof. Msc. Cristiano Biancardi
Centro Universitário Vila Velha
Orientador
Prof. Msc. Leonardo Muniz de Lima
Centro Universitário Vila Velha
Prof. Msc. Vinícius Rosalém
Centro Universitário Vila Velha
Trabalho de Conclusão de Curso
aprovado em 05/06/2009.
Dedico este trabalho aos meus pais e irmão, que abdicaram de muitas
coisas e se esforçaram para que eu atingisse meu objetivo. Dedico
também a minha tia Sandra, que me acolheu em sua casa durante o
tempo que precisei.
"Diogo Francisco Sales da Silva"
Dedico esse trabalho aos meus pais que estiveram sempre ao meu
lado e fizeram todo esforço necessário para que este meu objetivo
fosse alcançado.
"Flávio Rodrigo Lovatti"
AGRADECIMENTOS
Agradecemos primeiramente a Deus por ter nos dado a força e a perseverança
necessária para que este objetivo fosse alcançado. Agradecemos aos nossos pais
por terem sido nosso apoio e peça fundamental nesse difícil caminho que foi trilhado.
Agradecemos aos nossos familiares que, direta ou indiretamente nos ajudaram a tornamos esse sonho em realidade. É com grande satisfação que damos o nosso "Muito
Obrigado!".
“Não existe guerra que não possa ser vencida. Não existe barreira que não possa ser
quebrada. E não existe objetivo que não possa ser alcaçado”
Sun-Tzu
LISTA DE FIGURAS
1
Passos em uma comunicação cliente e servidor RPC . . . . . . . . . .
19
2
Ilustração do funcionamento do RMI . . . . . . . . . . . . . . . . . . . .
21
3
Sistema de distribuição de recurso P2P . . . . . . . . . . . . . . . . . .
22
4
Descoberta de par em um modelo P2P centralizado . . . . . . . . . . .
24
5
Descoberta de par em um modelo P2P descentralizado . . . . . . . . .
24
6
Arquitetura básica de um Grid . . . . . . . . . . . . . . . . . . . . . . . .
25
7
Arquitetura das camadas de um Grid
. . . . . . . . . . . . . . . . . . .
27
8
Exemplo de Cluster controlado por um servidor . . . . . . . . . . . . . .
30
9
Visão Geral de CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
10
Requisição de um cliente . . . . . . . . . . . . . . . . . . . . . . . . . .
32
11
Funcionamento básico de um serviço web. . . . . . . . . . . . . . . . .
35
12
Exemplo de um WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
13
Exemplo de interação entre entidades . . . . . . . . . . . . . . . . . . .
37
14
Comunicação entre dois serviços web . . . . . . . . . . . . . . . . . . .
50
15
Ilustração da comunicação entre um serviço cliente e um serviço servidor 52
16
comunicação entre uma aplicação cliente e um serviço web . . . . . . .
52
17
Demonstração da aplicção . . . . . . . . . . . . . . . . . . . . . . . . .
76
18
Caso de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
19
Método construtor da classe HibernateUtil . . . . . . . . . . . . . . . . .
79
20
Diagrama de pacotes . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
21
Diagrama de classes Entity . . . . . . . . . . . . . . . . . . . . . . . . .
81
22
diagrama de classe DAO . . . . . . . . . . . . . . . . . . . . . . . . . .
82
23
Diagrama de classes faces . . . . . . . . . . . . . . . . . . . . . . . . .
82
24
Diagrama de sequência . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
25
Diagrama de implantação . . . . . . . . . . . . . . . . . . . . . . . . . .
87
26
Classe TransfereciaService . . . . . . . . . . . . . . . . . . . . . . . . .
88
27
WSDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
28
Schema da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
29
WSDL do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
30
Classe ClienteFaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
31
Arquivo WSDL importado pelo C Sharp . . . . . . . . . . . . . . . . . .
94
32
Método criado dentro do arquivo reference.cs . . . . . . . . . . . . . . .
95
33
Chamada do método transferencia dentro do cliente C Sharp . . . . . .
95
34
Estado inicial do serviço web e aplicação cliente web . . . . . . . . . .
96
35
Estado do servidor e aplicação cliente após a execução da transferência 97
36
Estado do servidor e aplicação cliente C Sharp depois de realizada uma
transferência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
SUMÁRIO
1 INTRODUÇÃO
12
1.1 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
1.2 DESCRIÇÃO DOS CAPÍTULOS . . . . . . . . . . . . . . . . . . . . . .
13
2 REFERENCIAL TEÓRICO
15
2.1 SISTEMAS DISTRIBUÍDOS . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.1.1 Desempenho e escalabilidade . . . . . . . . . . . . . . . . . . .
16
2.1.2 Conectividade e segurança . . . . . . . . . . . . . . . . . . . . .
16
2.1.3 Confiabilidade e tolerância a falhas em sistemas distribuídos . .
16
2.1.4 Transparência . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2.1.5 Comunicação em sistemas distribuídos . . . . . . . . . . . . . .
17
2.2 MODELOS DE COMPUTAÇÃO DISTRIBUÍDA . . . . . . . . . . . . . .
18
2.2.1 Chamada de procedimento remoto - Remote Procedure Call (RPC) 18
2.2.2 Invocação de método remoto - Remote Method Invocation (RMI)
20
2.2.3 Computação distribuída Peer-to-peer (P2P) . . . . . . . . . . . .
21
2.2.4 Grid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
2.2.5 Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
2.2.6 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
2.2.7 Serviço web (Web Service) . . . . . . . . . . . . . . . . . . . . .
35
2.3 TABELAS COMPARATIVAS . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.3.1 CORBA vs serviço web . . . . . . . . . . . . . . . . . . . . . . .
38
2.3.2 RPC vs RMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.3.3 Grid vs Cluster vs P2P . . . . . . . . . . . . . . . . . . . . . . . .
3 DEFINIÇÃO DO MODELO ESCOLHIDO
39
40
3.1 Serviços web, uma visão mais abrangente . . . . . . . . . . . . . . . . .
40
3.1.1 Benefícios de serviços web . . . . . . . . . . . . . . . . . . . . .
42
3.1.2 Evolução de tecnologias e produtos . . . . . . . . . . . . . . . .
43
3.1.3 Segurança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
3.1.4 Reusabilidade, disponibilidade e escalabilidade. . . . . . . . . .
44
3.1.5 Típicos cenários de serviços web . . . . . . . . . . . . . . . . . .
45
3.1.6 Interação com padrões de negócio . . . . . . . . . . . . . . . . .
46
3.1.7 Integrando com sistemas de informação existentes . . . . . . . .
46
3.1.8 Alcançando diversos clientes . . . . . . . . . . . . . . . . . . . .
47
3.2 Padrões e Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
3.2.1 Overview dos padrões de serviços web . . . . . . . . . . . . . .
47
3.3 Modelos de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . .
49
3.3.1 Desenvolvimento de serviços web para usarem outros serviços .
49
3.3.2 Desenvolvimento de aplicações clientes para usarem serviços web 52
3.3.3 Design de serviço de ponto final . . . . . . . . . . . . . . . . . .
4 ESTUDO DE CASO
56
76
4.1 DESCRIÇÃO DA APLICAÇÃO EXEMPLO . . . . . . . . . . . . . . . . .
76
4.2 DIAGRAMA DE CASO DE USO . . . . . . . . . . . . . . . . . . . . . .
77
4.3 ESPECIFICAÇÃO DO PROJETO . . . . . . . . . . . . . . . . . . . . . .
77
4.3.1 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
4.3.2 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
4.3.3 Diagramas de classes . . . . . . . . . . . . . . . . . . . . . . . .
80
4.3.4 Diagrama de sequência . . . . . . . . . . . . . . . . . . . . . . .
83
4.3.5 Classes Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
4.3.6 Classes DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.3.7 Classes faces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
4.3.8 Páginas web . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
4.3.9 Diagrama de implantação . . . . . . . . . . . . . . . . . . . . . .
86
4.4 CONSTRUINDO E CONSUMINDO O SERVIÇO WEB . . . . . . . . . .
87
4.4.1 Implementando um serviço web . . . . . . . . . . . . . . . . . .
87
4.4.2 Consumindo um serviço web . . . . . . . . . . . . . . . . . . . .
91
4.4.3 Visualização da aplicação em funcionamento . . . . . . . . . . .
95
5 CONCLUSÃO
98
REFERÊNCIAS
100
Anexo 1 - Classe HibernateUtil
102
Anexo 2 - Classe Cliente - Entity
103
Anexo 3 - Classe Conta - Entity
104
Anexo 4 - Classe ClienteConta - Entity
105
Anexo 5 - Classe ClienteContaPK - Entity
106
Anexo 6 - Classe GenericDAO
107
Anexo 7 - Classe ClienteContaFaces
108
Anexo 8 - Classe TransferenciaFaces
109
12
1
INTRODUÇÃO
A computação toma rumos onde aplicações deixam de ser apenas locais, ou seja,
concentradas em uma única estação ou servidor, e passam a ser distribuídas geograficamente em um ambiente qualquer, a fim de distribuir tarefas em uma rede. Nestas
aplicações, há necessidade de se ter um maior recurso computacional com um custo
baixo, motivando o uso da computação distribuída nos últimos anos, resultando em
um aumento de pesquisa nesta área.
Com o aumento do uso de redes de computadores e a sofisticação dos ambientes
multitarefa torna-se inquestionável a importância dos mecanismos de otimização de
computação. A utilização de técnicas de programação distribuída visa cumprir metas
importantes baseadas em funcionalidades cujo objetivo é prover soluções a fim de proporcionar um melhor uso da capacidade computacional, propiciando vantagens como
à interoperabilidade, o desempenho, a escalabilidade, a conectividade, a confiabilidade, a transparência, a tolerância à falhas e segurança em ambientes heterogêneos
e homogêneos. Assim, cresce o número de aplicações que demandam acesso de
forma integrada, uniforme em tais ambientes [6].
Quando se fala em aplicações hoje em dia é praticamente certo que o assunto acabará em web. E com essa visão, o trabalho foi direcionado a discutir uma tecnologia
de comunicação, entre aplicações, que abstraísse em qual plataforma as aplicações
estão rodando ou em quais linguagens de programação foram desenvolvidas.
Dentro deste contexto, este trabalho apresenta um estudo dos modelos de computação distribuída, conceituando e exemplificando suas características de uma forma
bem ampla e aprofundada, fazendo uma comparação entre elas. Além disso, um estudo de caso foi definido, com o intuito de exemplificar o funcionamento e a troca de
13
informações entre aplicações clientes e os serviços propriamente ditos, além da interoperabilidade, que é uma das principais características dos modelos de computação
distribuída. Esse estudo de caso é baseado em um cenário onde a computação distribuída é fortemente usada, simulando uma transferência entre contas de um banco.
Com base no estudo feito e no cenário do estudo de caso (ver capítulo 4), foi
escolhido um modelo específico (web service) para o desenvolvimento. Para tanto, um
serviço e uma aplicação cliente foram desenvolvidos na linguagem de programação
Java, e com o intuito de mostrar a interoperabilidade dos serviços web, outra aplicação
cliente foi desenvolvida na linguagem C Sharp.
1.1 JUSTIFICATIVA
O foco das empresas e a crescente demanda por aplicações distribuídas no cenário do mercado nacional, os desafios e a inovação que serviços web proporcionam
às empresas de software, acrescidos da vontade de conhecer a fundo uma tecnologia
nova, tomando como base uma linguagem de desenvolvimento nova, como o Java e o
C Sharp, para o estudo aprofundado da referida tecnologia nos motivou a realizar este
estudo. E a cada vez que detínhamos conhecimento sobre o assunto, era necessário
aprender mais e mais.
1.2 DESCRIÇÃO DOS CAPÍTULOS
O capítulo 2 apresenta um referencial teórico, descrevendo o conceito de sistemas
distribuídos e alguns modelos de computação distribuída com suas principais características, exemplos de aplicação, vantagens e desvantagens. Além disso, apresenta
também uma comparação entre os modelos estudados.
O capítulo 3 apresenta a definição de um modelo de computação distribuída (serviços web), dentre as estudadas, para um estudo mais aprofundado, mostrando suas
características, benefícios e outras peculiaridades relacionadas.
14
O capítulo 4 apresenta um estudo de caso, baseado em um cenário onde a computação distribuída é usada com ênfase. Esse estudo mostra a descrição de uma
aplicação exemplo, bem como o seu desenvolvimento. Além disso, caracteriza uma
demonstração prática da aplicação desenvolvida.
O capítulo 5 contém a conclusão do trabalho, mostrando os pontos que foram
abordados durante o mesmo. Além disso, são apresentadas algumas sugestões de
trabalhos futuros.
O capítulo 6 mostra as referências dos conceitos que foram utilizadas ao longo do
trabalho.
15
2
REFERENCIAL TEÓRICO
Neste capítulo são apresentados o conceito de sistemas distribuídos e alguns modelos de computação distribuída, usados como base para a análise de suas principais
características e escolha de um modelo para o desenvolvimento de uma aplicação
exemplo.
2.1 SISTEMAS DISTRIBUÍDOS
A comunicação remota via rede, originalmente reservada para grandes instalações
de computadores e ambientes acadêmicos, foi amplamente difundida. Em um sistema
distribuído, computadores independentes cooperam via rede de modo que pareçam
uma máquina local. Aplicações de sistemas distribuídos podem executar código em
máquinas locais e remotas e compartilhar dados, arquivos, e outros recursos entre
máquinas. Sistemas distribuídos quase sempre surgem da necessidade de melhorar
a capacidade, a confiabilidade de uma única máquina e atender uma grande base de
usuários. Algumas das vantagens de se utilizar a tecnologia de sistema distribuído
é que se pode atingir um alto nível de desempenho por um custo menor do que um
sistema único [6]
Os sistemas distribuídos são atribuídos de vantagens em relação a sistemas centralizados como desempenho e escalabilidade, conectividade e segurança, confiabilidade, tolerância a falhas e transparência. Vantagens essas que são apresentadas ao
longo deste tópico.
16
2.1.1 Desempenho e escalabilidade
Em um sistema centralizado, um único servidor trata todas as requisições de usuários. Com um sistema distribuído, as requisições podem ser enviadas a diferentes
servidores aumentando o desempenho. Escalabilidade permite que um sistema distribuído cresça sem afetar as aplicações e os usuários existentes [6].
2.1.2 Conectividade e segurança
Um sistema distribuído pode fornecer acesso sem descontinuidade e recursos
através da rede [5]. Se o recurso for um processador, o sistema distribuído deverá
permitir que tarefas sejam executadas em qualquer máquina. Se o recurso for um
sistema de arquivos globalmente compartilhado, usuários remotos poderão acessá-lo
como acessariam um sistema de arquivos local, privado. Conectividade em sistemas
distribuídos requer protocolos de comunicação de estado a fim de manter uma operação eficiente, devem fornecer interfaces comuns a todos os computadores do sistema.
Sistemas distribuídos devem permitir que apenas usuários autorizados acessem recursos e garantir que a informação transmitida pela rede somente possa ser lida pelos
recipientes pretendidos [6].
2.1.3 Confiabilidade e tolerância a falhas em sistemas distribuídos
Sistemas distribuídos implementam tolerância a falhas fornecendo replicação de
recursos através do sistema. A replicação oferece aos usuários maior confiabilidade
e disponibilidade em relação a implementações de máquinas isoladas. Sistemas distribuídos devem ter um software que detecte e reaja a falhas no sistema, fornecer
mecanismos para assegurar a consistência entre informações de estado de máquinas
diferentes, e precisam estar equipados para reintegrar recursos que falharam, logo
que sejam reparados [5].
2.1.4 Transparência
Transparência em sistemas distribuídos é ocultar dos usuários seus aspectos distribuídos [7]. Esses sistemas devem implementar transparência de localização, ocul-
17
tando a localização de recursos no sistema distribuído daqueles que estão tentando
acessá-lo, permitindo acesso a arquivos remotos como se fossem locais.
Essa característica pode ser alcançada por replicação ou por ponto de verificação/recuperação de sistema onde a replicação fornece vários recursos que executam
a mesma função e, ao usar pontos de verificação, periodicamente serão armazenados
informações de estado de um objeto, como um processo.
Além dessas, também devem ser implementadas transparências de migração ou
transparência de realocação, onde a transparência de migração se preocupa em mascarar a movimentação de um objeto de uma localização para outra no sistema. Já a
transparência de realocação mascara a realocação de um objeto por meio de outros
objetos que se comunicam entre eles.
Por fim, sistemas distribuídos devem implementar transparência de transação, permitindo que um sistema obtenha consistência mascarando a coordenação entre um
conjunto de recursos [6].
2.1.5 Comunicação em sistemas distribuídos
Gerenciar a comunicação entre computadores é um desafio em sistemas distribuídos, onde se deve estabelecer interoperabilidade entre computadores e aplicações
heterogêneas [6].
Para que um sistema, ao ser projetado, alcance as características de um sistema
distribuído, esse deve ser desenvolvido em cima de algum modelo de computação
distribuída, e como exemplo desses modelos, tem-se: RPC, RMI, P2P, CORBA, Grid,
Cluster e Web Services, que são apenas alguns, de vários existentes. Esses modelos
serão apresentados e discutidos nos próximos tópicos.
18
2.2 MODELOS DE COMPUTAÇÃO DISTRIBUÍDA
Os modelos apresentados a seguir podem ser tomados como base para o desenvolvimento de aplicações distribuídas. É lógico que o modelo a ser escolhido depende
do objetivo da aplicação a ser desenvolvida.
2.2.1 Chamada de procedimento remoto - Remote Procedure Call
(RPC)
A comunicação entre um componente e outro em um sistema distribuído usando
a técnica de RPC proporciona uma abordagem estruturada de alto nível [6]. Por usar
a arquitetura cliente/servidor com base, RPC permite que um processo que esteja em
execução em um computador cliente chame um procedimento que esteja em execução
em outro computador servidor [5], onde o usuário não sabe se o procedimento está
sendo executado por seu computador ou por outro computador. A execução desse
procedimento sempre ocorre no servidor, e o resultado então é transmitido pela rede
ao cliente.
O funcionamento do RPC é semelhante a uma chamada de procedimento local,
levando em conta que existem dois processos, um invocador e um servidor, onde o invocador envia uma mensagem para o servidor e aguarda uma mensagem de resposta.
A mensagem de invocação contém os parâmetros do procedimento; já a mensagem
de resposta contém os resultados da execução do procedimento. Já do lado do servidor, um processo permanece aguardando até chegar uma requisição e, quando essa
requisição chega, seus parâmetros são extraídos e processados, gerando o resultado,
que é enviado na mensagem de resposta. Após isso, o servidor volta a esperar uma
requisição. Essa interação entre cliente e servidor é ilustrada na figura 1.
19
Figura 1: Passos em uma comunicação cliente e servidor RPC
A chamada de procedimento remoto introduz o conceito de stub, que é o componente da aplicação servidora responsável pela identificação do endereço da aplicação
cliente, para empacotar informações do método cliente. Para emitir uma chamada de
procedimento remoto, o processo cliente faz uma chamada ao procedimento no stub
do cliente, passando os parâmetros apropriados. O stub do cliente executa a montagem de dados, que empacota argumentos de procedimento juntamente com o nome
do procedimento em uma mensagem para transmissão via rede. Ao receber a mensagem do stub do cliente, o sistema operacional do servidor transmite a mensagem
ao stub do servidor, então a mensagem é desmontada e o stub do servidor envia os
parâmetros ao procedimento local apropriado. Quando o procedimento for concluído,
o stub do servidor monta o resultado e o envia de volta ao cliente. Por fim, o stub do
cliente desmonta o resultado, notifica o processo e passa o resultado para ele [6].
As vantagens de se usar RPC é que essa técnica oculta os detalhes de soquetes, uma abstração computacional que mapeia diretamente uma porta de transporte
(TCP ou UDP) e mais um endereço de rede, do ponto de vista dos programadores de
aplicações, e ainda possui ligação dinâmica com as portas dos servidores [6].
Existem diversas complicações associadas à chamada de procedimento remoto.
Ela pode executar sobre protocolos TCP ou UDP, o que significa que implementações
diferentes podem oferecer níveis variáveis de confiabilidade. Implementação de cha-
20
mada de procedimento remoto está diretamente relacionada com o tipo de sistema
de arquivos de rede, onde cada implementação pode oferecer um nível diferente de
segurança.
2.2.2 Invocação de método remoto - Remote Method Invocation
(RMI)
Em sistemas distribuídos, outra forma de comunicação entre componentes de uma
rede é usando a técnica de invocação de método remoto que, assim como o RPC, usa
a arquitetura cliente/servidor como base. Tome duas aplicações distintas onde estas
aplicações são construídas utilizando linguagens orientadas a objeto. A aplicação que
proverá o método a ser utilizado é chamada de aplicação servidora e a aplicação que
irá fazer uso deste método é chamada de aplicação cliente. A aplicação servidora irá
habilitar um determinado método em seu corpo a fim de este poder ser invocado a
partir da aplicação cliente, seja esta local ou remota [6]. Três camadas distintas de
software caracterizam a arquitetura de invocação a método remoto [5]: a camada de
stub/esqueleto, a camada remota de referência e a camada de transporte.
A camada de stub/skeleton usa o stub para empacotar informações do método
cliente. E o skeleton, que é o componente da aplicação cliente, usado para a identificação do endereço da aplicação que irá prover o método desejado, para desempacotar
as informações do lado servidor. A camada remota de referência é onde o stub usa a
serialização de objeto para criar sua mensagem montada, característica que permite
que objetos sejam codificados em correntes de bytes e transmitidos de um espaço de
endereçamento para outro. A camada de transporte é responsável por pegar os dados
enviados pela camada de referência e separá-los em pacotes que serão transmitidos
pela rede [6]. RMI tem seus métodos definidos nas interfaces e tem seus métodos
implementados nas classes. Esse funcionamento do RMI pode ser visto na figura 2.
21
Figura 2: Ilustração do funcionamento do RMI
RMI pode ser utilizado da seguinte forma: imagine duas aplicações que troquem
informações pela internet (via http), e que possam fazer uso da técnica referida. Ao
executar uma determinada tarefa, a aplicação cliente recorre a um método; este, por
sua vez, não se encontra em seu corpo. Tal método é chamado no corpo da aplicação
e a aplicação irá procurar o referido método em suas interfaces. Sendo encontrado,
são passados para o método os devidos parâmetros e todo o trabalho de envio dos dados, computação efetuada e recebimento dos dados de resposta ficarão transparentes
ao usuário.
Tal tecnologia é muito utilizada para a distribuição de poder computacional a aplicações que executem tarefas específicas, como por exemplo, uma determinada aplicação de uma agência de turismo. Esta irá precisar verificar reservas em hotéis, passagens aéreas dentre outros. Ao invés do agente de turismo ter uma aplicação para
cada tipo de negócio, o mesmo pode ter uma única aplicação que faça uso de outras
aplicações específicas, fazendo valer-se do RMI para a troca e execução das informações pretendidas.
2.2.3 Computação distribuída Peer-to-peer (P2P)
Em sistemas distribuídos, um dos modelos de distribuição de recurso é o modelo
P2P que consiste em uma distribuição de processamento e requisição de informação
em uma rede de computadores, onde todos os componentes isolados do sistema P2P,
chamado de nós, executam ambas as tarefas de cliente e servidor, distribuindo as
responsabilidades de processamento e informação para muitos computadores [6].
22
Tal modelo é apresentado na figura 3, mostrando de forma visual o conceito de
um sistema P2P. Note que computadores distintos, juntos, formam as redes de computadores do sistema P2P, e essas se ligam a outras redes formando blocos, os quais
estão ligados a outros blocos formando uma rede maior ainda, centralizadas ou descentralizadas [6].
Figura 3: Sistema de distribuição de recurso P2P
Clientes enviam consultas a servidores que, por sua vez, acessam as bases de
dados, onde todas as informações ficam armazenadas e respondem com uma informação. Aplicações P2P são diferentes de aplicações cliente/servidor [10]. Enquanto
aplicações cliente/servidor possuem funções definidas, nas aplicações peer-to-peer
todos os componentes têm a capacidade de enviar uma requisição e enviar uma resposta, podendo compartilhar recursos. A grande vantagem de aplicações P2P é que
não é necessário nenhum administrador de rede [6], [5].
Um sistema distribuído P2P propõe um modelo com as seguintes características:
1. Todos os nós são usuários de serviços em potencial e são, ao mesmo tempo,
provedores em potencial desses serviços.
2. Todo nó é independente.
3. Os nós são dinâmicos, podem existir e deixar de existir imprevisivelmente.
23
4. A capacidade de cada nó é altamente variável.
Aplicações peer-to-peer centralizada versus aplicações peer-to-peer descentralizadas
Aplicações P2P podem ser de duas formas: centralizadas e descentralizadas [6].
Uma aplicação P2P centralizada usa um sistema servidor central que se conecta
a cada par. Em uma aplicação centralizada, de mensagens instantâneas, quando um
par quer falar com outro par, primeiramente precisa obter o endereço do par requisitado no servidor. Então, o par requisitante se comunica com o par requisitado. Se um
ou mais servidores centrais falharem, a rede inteira poderá falhar [10].
Já uma aplicação descentralizada, ou aplicação P2P pura, não tem um servidor.
Em uma aplicação P2P pura de mensagens instantâneas, quando o par quer se comunicar com outro, ele não precisa mais se comunicar com o servidor; em vez disso,
o par requisitante descobre o par requisitado visto mecanismos de busca distribuída e
envia a mensagem ao par requisitado, diretamente [6]. Buscas em tempo real podem
ser lentas e aumentam o tráfego da rede à medida que consultas se propagam por
ela. Aplicações P2P puras são completamente descentralizadas. A centralização melhora o desempenho de busca, mas torna a rede dependente de um servidor. Fazer
transferências de arquivos entre pares reduz a carga do servidor [6].
Descoberta e busca de par
Descoberta de par é o ato de descobrir pares em uma aplicação P2P [5]. Uma
solução para a descoberta de par pode ser os usuários, primeiramente, se juntarem
à rede especificando o seu endereço de rede. Sem conhecer pelo menos um par
servidor da rede, um usuário não pode se juntar à ela. O servidor da rede recebe a
pesquisa que o par previamente acoplado à rede e realiza uma busca nos arquivos
indexados contidos nela.
Encontrando, envia o endereço de rede do par, ou pares, que contém o alvo da
busca; não encontrando, não envia resultado algum. Outra forma de executar a des-
24
coberta de um par é um par enviar uma mensagem com critérios de busca aos pares
conectados a ele.
Então, esses pares propagam a busca por toda a rede de pares. Se um par particular puder atender a busca, passa a informação de volta a quem enviou a primeira
mensagem. Então, esse primeiro par se conecta diretamente com o par alvo e, assim,
podem trocar informações. O par que fez a consulta original pode se identificar somente quando se conectar diretamente com o par que tem a informação requisitada
para, assim, poder iniciar a transferência requisitada [10].
Figura 4: Descoberta de par em um modelo P2P centralizado
Na figura 4 é apresentado o diagrama de como funciona a conectividade entre
pares em um sistema P2P centralizado no que tange a descoberta de par. Quando
um par requer uma determinada informação, este irá buscar no índice do servidor a fim
de receber como resposta o endereço do par que contém a informação em questão.
Figura 5: Descoberta de par em um modelo P2P descentralizado
25
Na figura 5 é apresentada a forma que os pares tomam quando se juntam à rede
P2P. Estes estão diretamente conectados a todos os outros nós do sistema P2P. Em
tal sistema para a requisição de informações, a pesquisa é direcionada a todos os
nós. E todos estes que contiverem a informação em questão irão responder ao par
requisitante com seu determinado endereço.
2.2.4 Grid
A utilização de forma cooperativa e transparente de recursos distribuídos geograficamente considerando-os como um único e poderoso computador é algo desejado
há bastante tempo [7]. Grid é uma proposta promissora para resolver as crescentes demandas da computação paralela e distribuída por transparência, desempenho
e capacidade computacional. A infra-estrutura de Grid deve prover de forma global
e transparente os recursos para aplicações de grande demanda computacional e/ou
de dados [5]. Estes recursos manipulados podem ser de diferentes tipos, havendo
grande heterogeneidade dentro de uma mesma classe de recursos [6]. A figura 6
ilustra a arquitetura básica de um Grid.
Figura 6: Arquitetura básica de um Grid
Características
Existem três aspectos que caracterizam Grids computacionais [5]:
26
1. Heterogeneidade: um Grid envolve uma multiplicidade de recursos que são heterogêneos por natureza e que podem estar dispersos geograficamente;
2. Escalabilidade: um Grid pode crescer de poucos recursos para milhões;
3. Dinamicidade ou adaptabilidade: em um Grid a falha de um recurso é a regra, e
não a exceção.
Os gerenciadores de recursos ou aplicações devem adaptar o seu comportamento
dinamicamente a fim de extrair o máximo de desempenho a partir dos recursos e serviços disponíveis [9]. De modo a facilitar a colaboração entre múltiplas organizações,
executando diversos recursos heterogêneos autônomos, um número de princípios básicos deve ser seguido no desenvolvimento do ambiente de Grid [8]:
1. Não interferir na autonomia e administração existentes;
2. Não comprometer a segurança existente;
3. Não precisar substituir o sistema operacional, os protocolos de rede ou os serviços existentes;
4. Permitir que computadores remotos se juntem ou saiam do ambiente quando
eles decidirem;
5. Não impor paradigma de programação, linguagens, ferramentas ou bibliotecas
que o usuário precise usar;
6. Disponibilizar uma infra-estrutura confiável e tolerante a falhas sem um ponto
único de falhas; e
7. Fornecer suporte para componentes heterogêneos.
Um ambiente de Grid ideal irá prover acesso aos recursos disponíveis de forma
homogênea de tal modo que descontinuidades físicas tais como diferenças entre plataformas, protocolos de rede e bordas administrativas se tornem completamente transparentes [8].
Esses ambientes são voltados para aplicações onde existem características como
sincronização de processos, transferência e armazenamento de grandes volumes de
dados e interoperabilidade entre aplicações heterogêneas.
27
Arquitetura
Grid possui uma arquitetura formada por quatro camadas sob a qual uma aplicação será executada. O ponto central consiste dos protocolos de Recursos e Conectividade que facilitam o compartilhamento dos recursos individuais. Protocolos nestes
níveis são projetados para que possam ser implementados no topo de vários tipos de
recursos definidos na camada de infra-estrutura e podem ser usados para construir
um grande conjunto de serviços globais e comportamentos específicos de aplicações
na camada Coletiva [6]. Essas camadas são mostradas na figura 7.
Figura 7: Arquitetura das camadas de um Grid
1. Infra-estrutura (Grid Fabric layer ) - provê os recursos que permitem o acesso
compartilhado.
2. Camada de conectividade (Grid Connectivity layer ) - define os protocolos básicos
de comunicação e autenticação exigida para transações de rede específica para
Grid. Os protocolos de comunicação permitem a troca de dados entre recursos
da camada de infra-estrutura. Os protocolos de autenticação providenciam mecanismos de segurança com criptografia para verificar a identidade dos usuários
e recursos.
3. Camada de recursos (Grid Resource layer ) - define protocolos bem como APIs
(Application Program Interface) e SDKs (Software Developer’s Kit). Estes protocolos são para negociações seguras, inicializações, monitoramento, controle,
contabilidade e pagamento de operações compartilhadas sobre recursos individuais. A camada de recursos está preocupada inteiramente com recursos indivi-
28
duais e, deste modo, ignora aspectos de estado global e ações atômicas através
de coleções distribuídas.
4. Camada coletiva (Grid Collective layer ) contém protocolos e serviços (APIs e
SDKs) que não estão associados com nenhum recurso específico, mas, ao contrário, são globais em natureza e capturam interações entre coleções de recursos.
Compartilhamento de recursos
O problema real e específico que está por trás do conceito de grid é o compartilhamento de recursos de forma coordenada e a resolução de problemas em organizações
virtuais e dinâmicas. Organização virtual é um dos principais conceitos cuja implementação é fundamental para a computação em grids [8]. Grupos distintos compartilham
recursos de uma forma controlada de tal modo que os membros podem colaborar para
atingir um objetivo compartilhado. O compartilhamento é mais do que apenas troca
de documentos: pode envolver o acesso remoto a programas, computadores, dados,
sensores e outros recursos. Ele é condicional: cada dono de um recurso torna-o
disponível sujeito às restrições sobre quando, onde e o que pode ser feito. Os relacionamentos de compartilhamento podem variar dinamicamente ao longo do tempo, em
termos dos recursos envolvidos, da natureza do acesso permitido e dos participantes
para o qual o acesso é permitido. A natureza dinâmica das relações de compartilhamento significa que são exigidos mecanismos de descoberta e caracterização da
natureza dos compartilhamentos que existem em um determinado ponto do tempo [5].
2.2.5 Cluster
Cluster pode ser definido como um sistema onde dois ou mais computadores trabalham de maneira conjunta para realizar processamento pesado. Em outras palavras, os computadores dividem as tarefas de processamento e trabalham como se
fossem um único computador sob um mesmo domínio administrativo [13]. Com isso,
é possível realizar processamentos que até então somente computadores de alta performance seriam capazes de fazer.
29
Características
Cada computador de um cluster é denominado nó ou nodo. Todos devem ser interconectados de maneira a formar uma rede. Essa rede precisa ser criada de uma
forma que permita o acréscimo ou a retirada de um nó, mas sem interromper o funcionamento do cluster [13].
O sistema operacional usado nos computadores deve ser de um mesmo tipo, isso
porque existem particularidades em cada sistema operacional que poderiam impedir
o funcionamento do cluster. Independente do sistema operacional usado, é preciso
usar um software que permita a montagem do cluster em si. Esse software vai ser
responsável, entre outras coisas, pela distribuição do processamento. Esse é um
ponto crucial na montagem de um cluster. É preciso que o software trabalhe de forma
que erros e defeitos sejam detectados, oferecendo meios de providenciar reparos,
mas sem interromper as atividades do cluster [13]. Esse tipo de necessidade pode
ser controlado através de um equipamento específico, ou seja, não depende apenas
do software.
Para que exista, um cluster precisa de pelo menos dois computadores. Evidentemente, quanto mais computadores existirem no cluster, maiores serão os custos de
implementação e manutenção. Isso não se deve apenas ao preço dos computadores,
mas também pelos equipamentos (switches, cabos, hubs, no-breaks etc.). Mas, ainda
assim, os custos costumam ser menores do que a aquisição/manutenção de computadores poderosos e, algumas vezes, o processamento é até mais eficiente (rápido)
[6]. A figura 8 traz um exemplo de Cluster usando um servidor para controlar todo ele.
Aplicação de clusters
Podem ser usados em aplicações onde a demanda de processamento seja grande,
como por exemplo, em aplicações de previsão meteorológica, simulações financeiras,
simulações geométricas, renderização de efeitos especiais etc. [14].
30
Figura 8: Exemplo de Cluster controlado por um servidor
Tipos de clusters
1. Cluster Beowulf : voltado para a computação paralela, com o objetivo de suprir
a elevada capacidade de processamento em diversas áreas científicas, construindo sistemas computacionais poderosos e economicamente viáveis. O sistema operacional é Linux, onde um servidor é responsável pelo controle de todo
o cluster, conhecido com Front-End, distribuindo as tarefas e processamento. O
cluster Beowulf permite a construção de sistemas de processamento que podem
atingir bilhões de instruções de ponto flutuante executadas por segundo [6].
2. Cluster para Alta Disponibilidade: a alta disponibilidade se refere a sistemas que
praticamente não param de funcionar. São usados geralmente em banco de
dados, web sites, e-business, dentre outros.
3. Cluster para Balanceamento de Cargas: balanceamento de carga se refere à
distribuição equilibrada de processamento, integrando seus nós para que todas
as requisições vindas dos clientes sejam distribuídas de maneira equilibrada ou
balanceada entre eles [5].
4. Cluster Combo: combina as características dos cluters de Alta Disponibilidade
e de Balanceamento de Cargas, visando a uma solução de alta performance
aliada à possibilidade da não existência de falhas críticas.
5. Cluster MOSIX (Multicomputer Operating System for Unix): é um conjunto de
ferramentas de cluster para Linux voltado para o tipo Balanceamento de Cargas.
Ele se difere do Beowulf por não precisar de aplicações e recursos de softwares voltados ao cluster. É muito utilizado em universidades em seus projetos e
pesquisas.
31
2.2.6 CORBA
CORBA é uma arquitetura que estabelece e simplifica a troca de dados entre sistemas distribuídos heterogêneos de forma transparente, não importando em qual linguagem de programação foi desenvolvida, nem o local onde está ou em qual plataforma
ou sistema operacional esteja sendo executada.
O paradigma CORBA é uma combinação de duas metodologias existentes. A primeira delas é a computação cliente-servidor distribuída e a segunda é a programação
orientada a objetos, onde um importante conceito deve ser entendido, o conceito de
objetos. Para efeito de conhecimento, objetos são instâncias de classes, e essas classes definem o comportamento dos objetos através de métodos e atributos. Um objeto
é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos que serão
acessadas pelo cliente [6]. A figura 9 descreve uma visão geral de CORBA.
Figura 9: Visão Geral de CORBA
Interface Definition Language (IDL)
Descreve uma classe chamada interface que contém as implementações dos métodos a serem requisitados. Essa descrição de interface especifica o formato das
chamadas das operações e também especifica os parâmetros de entrada e saída necessários para que a operação seja executada.
Um exemplo do uso da IDL seria fornecer um método que retornasse o nome de
um determinado usuário passando como parâmetro o seu respectivo código. Nessa
32
classe, existiria um método que teria como assinatura, ou seja, os parâmetros, o código a ser localizado. Uma vez localizado o código, o que restaria seria o método
retornar o nome do usuário relacionado ao código encontrado.
Object Request Broker (ORB)
A comunicação entre cliente e servidor é feita pelo ORB. Ele faz o intermédio
entre cliente e objeto, permitindo que os objetos requisitados pelos clientes ao servidor
façam e recebam requisições de métodos de forma transparente em um ambiente
distribuído e heterogêneo. É responsável pela localização do objeto a qual se destina
uma determinada requisição, como também, pelo envio dos parâmetros da requisição
no formato aceito pelo objeto em questão, e responsável pela entrega da resposta do
objeto chamado, ao cliente, como pode ser visto na figura 10.
Figura 10: Requisição de um cliente
O ORB permite o acesso distribuído às implementações de objetos através do repositório de interfaces, onde ele coloca à disposição as interfaces públicas dos objetos
especificados na IDL [6].
Invocação de um objeto
Um cliente acessa um objeto através da referência deste objeto e da requisição de
operações executadas pelo mesmo. Como o cliente precisa ter contato apenas com a
interface do objeto, a estrutura interna deste se mantém transparente. A transferência
de controle de dados do cliente para o objeto e, em seguida, o retorno para o cliente,
é de responsabilidade do ORB. Se a invocação não for realizada perfeitamente, o
33
ORB informa ao cliente que ocorreu uma exceção. Os clientes de um objeto podem
fazer a invocação utilizando a técnica de stub, geradas na compilação da descrição
de interface do objeto, ou um conjunto de rotinas para invocação dinâmica de objetos
que podem ser utilizado [6].
Interface de invocação estática (Static Interface Invocation - SII)
Para acessar uma operação sobre um objeto, o cliente precisa chamar - e estar
estaticamente ligado ao stub correspondente. A interface stub conduz o ORB direto
para o domínio de programação da aplicação: o cliente interage com objetos servidores chamando suas operações como se houvesse chamado operações de objetos
locais. Quando um desenvolvedor escreve seu código, ele determina quais stubs cada
cliente contém, fazendo com que essa interface não possa acessar novos tipos de objetos adicionados futuramente ao sistema [6].
Interface de invocação dinâmica (Dynamic Interface Invocation - DII)
A interface dinâmica é necessária quando a interface do objeto não pode ser conhecida a tempo de compilação. Em uma invocação dinâmica, o cliente especifica,
através da DII, o objeto ao qual se destina a requisição, a operação solicitada e os
parâmetros da operação através de uma seqüência de chamadas de rotinas de requisição. Como as implementações de objeto não conseguem detectar se uma determinada invocação chegou ao ORB, via invocação de interface estática ou invocação de
interface dinâmica, o cliente fica inteiramente responsável pela escolha. O ORB ainda
faz todo o trabalho, fazendo com que a requisição chegue de forma transparente para
o objeto [6].
Interface dinâmica de esqueleto (Dynamic Skeketib Interface - DSI)
Na DSI, o receptor sabe que a requisição vem de um skeleton dinâmico ou estático, de forma transparente, ao contrário do que acontece na interface de invocação
dinâmica. Ao invés de ser acessada através de um skeleton, que é específico para
uma operação particular, uma implementação de objetos é alcançada através de uma
interface que provê acesso aos nomes das operações e parâmetros de maneira análoga à interface de invocação dinâmica do lado do cliente. Os skeletons podem ser
34
invocados através de clientes stubs e através de interface de invocação dinâmica. Nos
dois modos de invocação o resultado obtido será o mesmo [6].
Adaptador de objeto
Uma implementação de objetos acessa as funções do ORB através do adaptador
de objetos. Cabe a ele fazer a ativação e desativação de implementações de objetos,
manter o registro das implementações, promover a requisição de métodos e garantir a
segurança da interação entre os elementos envolvidos na requisição da operação. A
estrutura interna de um adaptador de objetos depende basicamente dos serviços disponibilizados pelo núcleo ORB e dos outros requisitos das implementações de objeto
às quais se destina [6].
Repositório de implementações
Local onde ficam armazenadas informações que permitem ao ORB localizar e
ativar implementações dos objetos. Através de operações feitas no repositório de
implementações é possível a instalação de implementações e políticas de controle
relacionadas à ativação e execução de implementações de objetos.
Persistência
Ao contrário dos objetos tradicionais, os objetos em sistemas distribuídos possuem
uma característica de dualidade: um estado dinâmico, tipicamente alocado em memória volátil, e um estado persistente que não pode ser destruído após o encerramento
do programa que os criou e que pode ser usado para reconstruir o estado dinâmico,
devendo ser armazenado em memória não volátil. A arquitetura CORBA, para prover a persistência, define o Persistent POS como sendo responsável por armazenar o
estado persistente dos objetos, utilizando quatro elementos [6]:
1. Objetos Persistentes (Persistent Object);
2. Gerenciador de Objetos Persistentes (Persistent Objects Manager );
3. Serviços de Persistência de Dados (Persistent Data Services);
4. Base de Dados (Datastores).
35
2.2.7 Serviço web (Web Service)
Um serviço web é uma solução utilizada para a integração de sistemas onde
softwares ou hardwares podem enviar ou receber mensagens. Um serviço web deve
fornecer uma infra-estrutura para se ter uma forma mais rica e mais estruturada de
interoperabilidade entre clientes e servidores. A representação de dados externa e o
empacotamento das mensagens trocadas entre clientes e serviços web são feitos em
XML (Extensible Markup Language), o que resulta em um grupo de tipo de dados bem
vasto [6].
A figura 11 ilustra o funcionamento básico de um serviço web.
Figura 11: Funcionamento básico de um serviço web.
As definições comentadas a seguir são de suma importância para o entendimento
de Web Services, de sua arquitetura e troca de dados entre cliente e servidor.
Arquitetura
São componentes da arquitetura de um serviço web:
1. SOAP (Simple Object Access Protocol): É um protocolo que permite a troca de
informações em ambientes distribuídos. Contém as chamadas e retornos dos
Web Services encapsuladas em sua estrutura.
2. WSDL (Web Service Description Language): É a linguagem de descrição de
Web Services, onde estão descritas as informações necessárias para invocação
dos Web Services, como a localização, operações disponíveis e assinaturas de
funções do mesmo.
36
A figura 12 mostra um exemplo de wsdl, com um método chamado transferência.
Figura 12: Exemplo de um WSDL
3. UDDI (Universal Description, Discovery and Integration): Uma implementação de
UDDI equivale a um Web Service Registry, disponibilizando mecanismos para
busca e publicação de Web Services. Ele gerencia informação sobre provedores, implementações e metadados de serviços. Além disso, contém informações
sobre os serviços e funcionalidades que os serviços web oferecem, permitindo
uma associação desses serviços com suas informações técnicas.
37
Fucionamento de serviços web
Um serviço web é acessado pelos seus clientes usando mensagens formatadas
em XML. O SOAP encapsula essas mensagens e transmite-as por HTTP, ou por outro
protocolo, por exemplo, TCP ou SMTP. Os serviços (operações, mensagens, parâmetros etc) são descritos na WSDL. O processo de publicação/pesquisa/descoberta
utiliza o UDDI. Os Web Services podem ser ativados por demanda ou podem funcionar
continuamente.
As interações entre provedor do serviço (service provider ), cliente do serviço (service requestor ) e servidor de registro (service registry ) dão base à arquitetura dos Web
Services. Elas são responsáveis pela publicação, busca e execução de operações. A
figura 13 ilustra um exemplo dessa interação.
Figura 13: Exemplo de interação entre entidades
O cliente acessa o serviço, através do provedor de serviço, que representa a
plataforma onde o Web Service está hospedado. Já o cliente do serviço, nada mais
é do que a aplicação que está fazendo a chamada ou interação com o Web Service.
E, finalmente, o servidor de registro é a representação dos servidores de registro e
busca de um Web Service.
Resumidamente, uma definição para a técnica do funcionamento do Web Sevice
seria: um cliente acessa o serviço disponibilizado em algum lugar da web, que foi
38
descrito via WSDL, registrado via UDDI, acessado utilizando SOAP e com os dados
transmitidos formatados no padrão XML.
2.3 TABELAS COMPARATIVAS
Com base nos estudos realizados, foram construídas tabelas comparativas, onde
são feitas algumas comparações entre os modelos estudados, levando em consideração a área de aplicação, tecnologias usadas para sua implementação, vantagens e
desvantagens.
2.3.1 CORBA vs serviço web
Compara-se CORBA com Web Service, pois ambas são independentes de arquitetura, linguagem de programação e sistema operacional, o que oferece portabilidade
para ambas. Características como protocolo, descrição de interfaces, descoberta de
serviços, desvantagens e vantagens são apresentadas na tabela 2.3.1.
Item
Protocolo
Descrição das Interfaces
Descoberta de Serviço
Serviço web
SOAP, http, XML SCHEMA
WSDL
UDDI
Desvantagens
Dependência de disponibilidade
do serviço
Vantagens
Independência de linguagem,
sistemas operacionais,
hardware, plataforma; troca de
grandes quantidades de
informações por XML.
CORBA
IIOP, GIOP
IDL
Repositório
de Interfaces
Alto custo de
implementação,
velocidade
relativamente baixo
Independência de
linguagem, sistemas
operacionais,hardware,
plataforma; Acesso a
implementações de
objetos.
Tabela 2.3.1 Comparação entre Web service e CORBA.
2.3.2 RPC vs RMI
Compara-se RPC e RMI, pois ambos implementam possuem a arquitetura cliente/servidor como base. A tabela 2.3.2 traz essas comparações.
39
Item
Características
RPC
Execução de procedimentos e
funções remotos, com passagem
de parâmetros.
Vantagens
Ligação dinâmica com portas do
servidor; Oculta detalhes de
soquete ao programador.
Não suporta variáveis globais,
Implementações diferentes
podem oferecer níveis variáveis
de confiabilidade.
Desvantagens
RMI
Execução de métodos remotos
com passagem de objetos como
parâmetros entre métodos
remotos.
Métodos definidos na interface,
Objetos remotos implementam
uma ou mais interfaces.
Dependente de uma linguagem
orientada a objeto para ser
possível sua utilização.
Tabela 2.3.2 comparação entre RPC e RMI.
2.3.3 Grid vs Cluster vs P2P
Compara-se Grid, Cluster e P2P, pois estes estão relacionados com o uso de
recursos ociosos geograficamente dispersos.
Item
Características
Administração
do modelo
Vantagens
Desvantagens
Grid
Heterogeneidade;
Escabilidade;
Adaptabilidade.
Global
Cluster
Sistema operacional
deve ser o mesmo
Evolução do Cluster.
Maior poder
computacional;
Distribuição de
processamento.
Redes com baixas
velocidades
comprometem o
desempenho do grid.
Quanto mais
computadores
maiores os
gastos com
manutenção;
Tabela 2.3.3: comparação entre grid, cluster e peer-to-peer.
Local
Peer-to-peer
Protocolo de
compartilhamento
de arquivo
Global
Confiabilidade, caso
ocorra erro em
algum peer, o
sistema não irá
parar totalmente.
Vulnerabilidade e
dependência de
uma aplicação
intermediária.
40
3
DEFINIÇÃO DO MODELO
ESCOLHIDO
Com base nas informações analisadas, o modelo de computação distribuída escolhido para o desenvolvimento do trabalho foi o serviço web. Essa escolha teve como
base suas características principais como independência de linguagem de desenvolvimento, sistemas operacionais, hardware, plataforma e troca de grandes quantidades
de informações por XML.
Além disso, o cenário escolhido para o exemplo é mais propício aos serviços web,
por se tratar de um ambiente em que são trocadas grandes quantidades de informação
e que um servidor é necessário para coordenar toda a parte da regra de negócio da
aplicação.
Na seção 2.2.7, os conceitos foram apresentados de forma bem sucinta. De agora
em diante, estes conceitos serão discutidos de uma forma mais abrangente.
3.1 Serviços web, uma visão mais abrangente
Serviços web apresentam um padrão de interface, sendo independentes de plataforma e tecnologia. O cenário onde estão inseridos está expandindo rapidamente
devido ao crescimento da necessidade de comunicação e interoperabilidade de aplicações.
A organização world wide web Consortium (W3C), a qual estabelece os padrões
para serviços web define como: "Um serviço web é um sistema de software identificado por uma URL onde as interfaces públicas e suas vinculações são definidas
41
e descritas usando XML. Sua definição pode ser descoberta por outros sistemas de
software. Estes sistemas podem interagir com serviços de um modo prescrito por sua
definição, usando mensagens baseadas em XML, tendo como base a comunicação
por protocolos da internet"[11].
Outra definição, porém, mais simplificada para serviços web é "Um serviço web é
uma aplicação de software acessível pela web (ou intranet, redes corporativas) através
de uma URL, que é acessada por clientes usando protocolos baseados em XML,
como Simple Object Access Protocol (SOAP), enviado através de protocolos aceitos
na internet, como HTTP. Clientes acessam uma aplicação baseada em serviços web
através de suas interfaces e vinculações, os quais são definidos usando artefatos
XML, como o arquivo web Service Definition Language (WSDL)"[11].
Serviços web se baseiam no conhecimento engajado dos mais maduros ambientes de computação distribuída (como o CORBA e o Java Remote Method Invocation RMI) permitindo a comunicação direta e a interoperabilidade entre aplicações. Estes
oferecem uma forma padronizada para aplicações exporem suas funcionalidades ou
se comunicar com outras aplicações através da web (ou uma rede interna), independente da implementação da aplicação, linguagem de programação ou plataforma na
qual está sendo executada. Além disso, podem fornecer recursos para uma determinada corporação expandir seus negócios, aumentando a eficiência do processamento
destes, e melhorando a experiência de seus usuários[11].
Um ponto interessante nas características dos serviços web é que existe a possibilidade de comunicação com serviços externos, ou seja, serviços de terceiros, como
exemplo, os serviços do Google, com funcionalidades importantes, sendo a mais conhecida o sistema de busca dentro de sites de terceiros.
O motivo mais importante para o aumento do uso de serviços web é o fato de que
eles provêem interoperabilidade através de diferentes plataformas, sistemas e linguagens. Além disso, reduzem o custo operacional por permitirem que as organizações a
expandam e reutilizem suas funcionalidades de sistemas já existentes.
42
No que diz respeito à arquitetura, um serviço web baseia-se na arquitetura orientada a serviço (SOA), que é um estilo arquitetural que concede a reusabilidade do
software e o poder de se criar serviços reutilizáveis.
Em um serviço-orientado à arquitetura tem-se:
1. Um serviço implementa uma lógica de negócio e expõe essa lógica através de
uma interface bem definida;
2. Um registro onde os serviços publicam suas interfaces a fim de permitirem clientes a descobrir os serviços disponibilizados;
3. clientes (incluindo clientes que podem ser serviços propriamente ditos) que descobrem o serviço usando os registros e acessam os serviços diretamente através
de interfaces expostas.
Uma importante vantagem de serviços-orientados à arquitetura é que eles permitem o desenvolvimento de aplicações levemente acopladas que podem ser distribuídas através de uma rede acessível. Para prover esta arquitetura, é necessário:
1. Um mecanismo que permita aos clientes acessarem serviços e registros;
2. um mecanismo que permita diferentes serviços a registrarem sua existência em
um registro e um modo para diferentes clientes procurarem no registro um determinado serviço disponível; e
3. um mecanismo para serviços apresentarem uma interface bem definida e um
modo para clientes acessarem essas interfaces.
3.1.1 Benefícios de serviços web
Os serviços web têm ganhado popularidade por causa dos benefícios que os mesmos provêm. Abaixo uma lista de alguns benefícios chave:
1. Interoperabilidade em um ambiente heterogêneo - provavelmente, o benefício
chave de um modelo de serviços web é permitir que diferentes serviços distribuídos sejam executados em uma variedade de plataformas e arquiteturas, possibilitando que eles sejam escritos em diferentes linguagens de programação. A
43
maior força do serviço web é sua capacidade de interoperabilidade em um ambiente heterogêneo. À medida que os vários sistemas se permitem usar o serviço
web, eles podem usar os serviços facilmente para interoperar entre si;
2. Serviços de negócios através da web - uma corporação pode usar um serviço
para ampliar suas vantagens através da world wide web (WWW) utilizando-os
em suas aplicações;
3. Integração com sistemas existentes - serviços web permitem que aplicações reutilizem e até economizem informações existentes. Fornecem uma forma padrão
para desenvolvedores acessarem a camada de controle e o mais alto nível de
um serviço, como o gerenciamento de banco de dados ou simplesmente o monitoramento de transações, e integra-los a outras aplicações;
4. Liberdade de escolha - padrões de serviços web abriram um grande mercado
para ferramentas, produtos e tecnologias. Isto dá às corporações uma vasta
variedade de escolha, e eles podem escolher as configurações que melhor se
encaixem em suas aplicações;
5. Suporte a diferentes tipos de clientes - desde que o principal objetivo de serviços web é prover interoperabilidade, expondo aplicações existentes ou serviços
como um serviço web, eles alcançam uma maior leva de diferentes tipos de
clientes. Isso acontece independente da plataforma operacional que o cliente
trabalha;
6. Produtividade de programação - serviços web, por criarem um padrão comum
de desenvolvimento, ajudam a aumentar a produtividade na programação. Priorizando o conceito, desenvolvedores especializados na área de computação
distribuída têm encontrado um grande leque de tecnologias nem sempre compatíveis. Eles vêm tentado compactar vários sistemas de alto nível, porém isso os
faz lidar com um método de programação nem sempre na mesma camada.
3.1.2 Evolução de tecnologias e produtos
Serviços web, por causa de sua ênfase em interoperabilidade e independência de
plataforma, sistema operacional e linguagem de programação, encontram-se em uma
coleção de tecnologias, vários padrões e especificações, muitos dos quais ainda estão
sendo definidos e refinados, como exemplo a interoperabilidade e a ordem:
44
1. Interoperabilidade é um desafio contínuo. Serviços web já têm alcançado um
significante degrau de interoperabilidade, mas, futuramente, padrões serão necessários para uma seleção de melhores meio de alcançar tal objetivo.
2. Geralmente, o que acontece para o usuário final que vê um único processamento
de negócio é que realmente tudo foi implementado como uma série de estágios
em etapas, e cada estágio do processamento pode ser implementado como serviços separados. Todos os serviços devem se coordenar entre si durante os
vários estágios do processamento da lógica de negócio a fim de se alcançar o
objetivo desejado, por isso padrões são necessários para coordenação de serviços.
3.1.3 Segurança
Questões de segurança para serviços web se preocupam com autenticação, autorização e a certificação da existência de confidencialidade. Padrão de segurança é
uma área de alta prioridade para a comunidade de serviços web, pois, à medida que
os sistemas evoluem, o grau de segurança acompanha essa evolução.
De fato, agora que aplicações são disponibilizadas na web, abrindo mais processamento de negócio e informação, a fim de distribuí-las a clientes, segurança se torna
um fator fundamental.
Uma das dificuldades é lidar com sistemas de realidades separadas em um ambiente de segurança integrado. Segurança necessita de ser compatível com os mecanismos existentes. Em casos onde clientes precisam acessar informações protegidas,
o mecanismo precisa manter um alto nível de segurança (e a confidência do usuário)
e ainda fazê-lo o máximo desobstruído e transparente possível.
3.1.4 Reusabilidade, disponibilidade e escalabilidade.
Serviços web são geralmente citados em distribuições de aplicações de larga escala. Com essas aplicações, a reusabilidade, a disponibilidade e a escalabilidade se
tornam fatores importantes a serem considerados. Reusabilidade é o aspecto da representação de quão bem mantido seus serviços e sua segurança estão. Um serviço
45
web é considerado reutilizável quanto mais facilmente e automaticamente se pode
lidar com a mudança no uso de padrões e configurações do sistema.
Já a disponibilidade se preocupa com o quanto um serviço está disponível para
uso imediato; em outras palavras, representa a probabilidade que um serviço está
disponível sempre que desejado.
Serviços web que escalam efetivamente podem facilmente lidar com uma grande
porção de transações por parte de seus clientes. Da mesma forma que o serviço, a
plataforma operacional e as tecnologias empregadas devem gerenciar eficientemente
os recursos dos sistemas (tais como conexões a banco de dados e suas transações).
Para conseguir alcançar reusabilidade, disponibilidade e escalabilidade, serviços
web devem ser flexíveis o suficiente para serem executados em qualquer configuração
de servidor a fim de se antecipar e suportar determinados volumes de clientes. Eles
deveriam, também, serem capazes de mudar essas configurações facilmente, quando
necessário.
3.1.5 Típicos cenários de serviços web
Aplicações em corporações cobrem um grande espectro de cenários, como interações entre padrões de negócio, suplemento da cadeia de gerenciamento, gerenciamento de inventário e até simples serviços (conversores especializados, calculadoras
específicas e assim por diante).
Assim, os serviços web, quando usados estrategicamente, podem aumentar significativamente as funcionalidades de uma determinada aplicação, porém não podem ser
tomados como soluções apropriadas em todos os pontos de uma aplicação. Enquanto
eles fornecem essa riqueza funcional e interoperabilidade, esses serviços podem se
tornar de alto custo se levada em conta sua performance.
Devem ser levados em conta alguns itens ao escolher uma solução baseada em
serviços web, como requerimentos de interoperabilidade para aplicações corporativas
46
em um ambiente heterogêneo, requerimentos de integração para os ambientes que
contêm vários sistemas de informação corporativos, tipos de clientes esperados a
serem suportados, como tecnologias empregadas e arquitetura da rede comunicação,
disponibilidade de ferramentas a fim de implementarem tal solução, nível de sacrifício,
em termos de complexidade e performance, que podem ser tolerados a fim de se
alcançar as vantagens (interoperabilidade, alcance de diversos clientes e assim por
diante) do serviço web.
3.1.6 Interação com padrões de negócio
Serviços web podem ser um meio ideal de se integrar à corporação com múltiplos padrões de negócios, por várias razões: são efetivamente mais baratos do que a
integração de informações eletrônicas (EDI), atualmente a solução mais comum disponível para padrões de integração de negócio.
EDI requer um significativo investimento em infraestrutura, o que limita a grandes
corporações. Uma solução baseada em serviços web se torna plausível para negócios pequenos que não podem investir em uma infraestrutura EDI e podem ser mais
eficientes em um ambiente com uma infraestrutura EDI existente.
Interações baseadas em serviços fornecem aos padrões, especialmente a maior
parte dos padrões com significante tecnologia e investimento em infraestrutura, uma
boa vantagem: eles podem usar serviços web para integrar suas aplicações corporativas existentes, baixando os custos e aumentando a interoperabilidade, por exemplo.
3.1.7 Integrando com sistemas de informação existentes
A maioria das empresas tem feito investimentos no decorrer de muitos anos em
tecnologia da informação e recursos de sistema. Geralmente, a maior parte desse
investimento é em um sistema de integração de informação corporativo ou sistemas
legados.
Serviços web podem eficientemente suprir essa necessidade de integrar tecnologias existentes com novas tecnologias. Desde que são baseados no conceito de
47
’universalmente aceitos’, independentes de plataforma ou de padrões, serviços web
criam uma camada de integração natural. Assim, é possível fornecer um software que
exponha suas funcionalidades em um serviço web, o que torna mais acessível esse
tipo de ferramenta ao usuário que necessita acessar certas funcionalidades pela web.
3.1.8 Alcançando diversos clientes
Os serviços web tornam a relação clientes e empresa mais amigável e dinâmica.
Isso é possível tornando suas funcionalidades disponíveis, aumentando a experiência
de seus clientes, fornecendo serviços como rastreamento de pedido de um cliente
ou informações de clima e tempo em pontos do destino do cliente do sistema; e a
empresa pode assegurar-se de que estes serviços web serão acessíveis por parte de
qualquer tipo de cliente.
Clientes podem conseguir essas informações de qualquer lugar e quase sempre usando qualquer aparelho. Alguns clientes podem usar um serviço web em um
browser (navegador) a fim de acessar estes serviços, outros podem usar dispositivos
móveis, como celulares ou PDA’s.
A experiência do usuário é melhorada quando eles possuem um vasto cartel de
opções através das quais podem acessar esses serviços, tornando-se, assim, uma
opção ideal para abrir a seus clientes essas vastas opções de serviços.
3.2 Padrões e Tecnologias
3.2.1 Overview dos padrões de serviços web
Padrões diferem de tecnologia, pois são coleções de especificações, regras e manuais formulados que são aceitos por participantes líderes do mercado. Enquanto
estas regras e manuais prescrevem um modo comum de se alcançar um estratificado
objetivo padrão, eles não prescrevem detalhes de sua implementação. No entanto,
mesmo que os detalhes da implementação se diferenciem, tecnologia pode trabalhar
em conjunto desde que seja construída de acordo com as especificações dos padrões.
48
Para que serviços web sejam usados com sucesso, seus padrões devem ser amplamente aceitos. A fim de permitirem sua ampla aceitação, os padrões usados e
tecnologias que implementam estes padrões devem seguir os seguintes critérios:
1. Um serviço web deve permitir requisições de qualquer cliente, independente de
em qual plataforma foi implementado.
2. Um cliente deve ser capaz de encontrar e usar qualquer serviço web independente da implementação do serviço e da plataforma em que o mesmo é baseado.
Os padrões estabelecem uma base comum e permitem serviços web alcançarem
uma ampla aceitação e interoperabilidade. Esses padrões cobrem áreas como:
1. Linguagem comum de marcação para comunicação (Commom Markup Language for Communication) - para começar, provedores de serviços, os quais
tornam serviços disponíveis, e requisitantes de serviços, os quais usam os serviços, devem ser capazes de se comunicar um com o outro. Uma linguagem
comum de marcação facilita a comunicação entre provedores e requisitantes,
onde cada parte é capaz de ler e entender a troca de informação baseados
em tags definidas. No entanto provedores e requisitantes podem se comunicar
usando interpretadores ou tradutores, porém o uso desses não é praticado, pois
agentes intermediários são ineficientes e não é efetivamente uma vantagem em
relação ao seu custo. Serviços web usam XML (Extensible Markup Language)
como linguagem comum de marcação.
2. Formatação de mensagem comum para troca de informação - mesmo que o estabelecimento de uma linguagem comum de marcação seja importante, por si
só não é suficiente para uma comunicação ideal entre as duas partes (especialmente, os provedores de serviços e requisitantes de serviço). Para uma comunicação efetiva, as partes devem ser capazes de trocar mensagens de acordo
com uma formatação combinada. Desde que tenham um formato, as partes que
são desconhecidas podem se comunicar efetivamente. O protocolo simples de
acesso a objetos SOAP (Simple Object Access Protocol) fornece uma formatação padrão para serviços web.
3. Formatação comum de especificação de serviços - nos formatos de mensagens
comuns e linguagens de marcação deve existir um formato comum que todos
49
os provedores possam usar para especificar detalhes dos serviços, como o seu
tipo, como acessa-lo, e assim por diante. Um mecanismo padrão para especificação de detalhes dos serviços permite provedores de serviços a especificá-los
de modo que qualquer requisitante pode entendê-los e usá-los. Por exemplo,
linguagem de descrição de serviços web (Web Services Description Language WSDL) fornece serviços web com uma especificação de formatos comuns.
4. Resultados comuns para procura de serviços - do mesmo modo que provedores
necessitam de um modo comum de especificar os detalhes dos serviços, requisitantes de serviços devem ter um modo comum de procurar e obter detalhes dos
serviços. Isto é necessário para terem localizações bem definidas onde provedores podem registrar suas especificações de serviços e onde requisitantes saibam procura-los. Por terem estas localizações bem definidas e um padrão para
acessá-las, serviços podem ser universalmente acessados por todos os provedores e requisitantes. Especificações de descrição universal, descobrimento e
integração (Universal Description, Discovery and Integration - UDDI) definem um
senso comum de procura por serviços web.
3.3 Modelos de desenvolvimento
Existem dois tipos de modelos de desenvolvimento de serviços web. São eles:
serviços web consumindo outros serviços, e aplicações clientes consumindo um serviço. O primeiro modelo não é o foco do trabalho, portanto será somente apresentado,
deixando-o como proposta de trabalhos futuros.
Já o segundo modelo será apresentado e discutido em um contexto mais aprofundado, com exemplos de construção e consumo do mesmo, através de uma aplicação
exemplo elaborada com fins didáticos para o escopo deste trabalho.
3.3.1 Desenvolvimento de serviços web para usarem outros serviços
A figura 14 ilustra a comunicação de um serviço com outro serviço, sendo necessário um intermediário para controlar as requisições e respostas trocadas entre ambos
os serviços.
50
Figura 14: Comunicação entre dois serviços web
Toda aplicação cliente segue certos passos para usar serviços web. Em resumo,
elas devem primeiro localizar o serviço, fazer uma chamada ao serviço e processar
qualquer informação retornada. No caso de serviços web consumindo outros serviços
web, temos um serviço cliente, que irá requerer algo a um outro serviço já conhecido
e temos um ou mais serviços que irão fazer parte do corpo do serviço servidor.
Os serviços que estabelecem comunicação entre si necessitam de ter uma camada
de interação bem definida, garantindo assim a forma que eles irão trabalhar em conjunto. Tal camada para o cliente, servirá para garantir que sua requisição não estará
em segundo plano quando uma nova requisição chegar ao serviço servidor, e servirá
para o servidor para que o mesmo detenha um maior controle de todas as requisições
que estarão chegando.
A comunicação de um cliente para um serviço, na forma de serviço para serviço,
dá-se obedecendo aos seguintes passos.
Do lado do cliente:
1. O serviço cliente procura pelo serviço servidor;
2. Depois de encontrado, o cliente irá montar sua requisição para o servidor, sendo
que esta pode ser por meio de uma chamada passando somente atributos como
parâmetro, ou pode ainda passar arquivos xml como parâmetros;
3. Se o parâmetro a ser passado é um arquivo xml, o cliente precisa montar o arquivo xml em conformidade com o schema usado pelo servidor, a fim de garantir
51
a integridade do processamento das informações. Se os parâmetros são atributos, o cliente não necessita de efetuar nenhuma operação antes de enviá-los;
4. Cliente envia a chamada ao serviço e envia os parâmetros para o servidor;
5. Cliente aguarda a resposta.
Do lado do servidor:
1. Servidor recebe a requisição e os parâmetros;
2. Se o parâmetro passado é um arquivo xml (ou arquivos xml), estes são validados.
Se forem atributos, não passam por nenhum processo de validação;
3. À camada de interação delega os parâmetros ao método específico, que irá processar a requisição do cliente. Tal processamento dar-se-á na camada de processamento;
4. Processa a requisição;
5. Se o tipo do parâmetro de resposta for um arquivo xml, o serviço servidor irá
construir o arquivo xml a ser enviado de acordo com o seu schema. Caso não
seja, nenhuma atividade é executada, somente os resultados são guardados;
6. Envia a resposta para o cliente, seja ela um arquivo xml ou somente um resultado
comum, como um atributo.
Um exemplo desse tipo de comunicação pode ser visto na figura 15.
Tais passos se deram na comunicação entre um serviço cliente que realizou uma
requisição a um outro serviço. Nesse caso, a comunicação entre os dois pode se dar
de duas formas. São elas: síncrona e assíncrona.
Na forma síncrona, o serviço servidor após efetivamente receber a requisição do
serviço cliente, bloqueia-se para não mais processar requisições antes de completar
a requisição já recebida.
52
Figura 15: Ilustração da comunicação entre um serviço cliente e um serviço servidor
Na forma assíncrona, o oposto acontece. O serviço servidor pode continuar recebendo as requisições, enquanto aguarda um possível processamento, seja ele externo
ou interno. Pode iniciar um outro processamento, introduzindo assim o conceito de threads nos serviços web.
3.3.2 Desenvolvimento de aplicações clientes para usarem serviços web
A figura 16 ilustra a comunicação de uma aplicação cliente com um serviço.
Figura 16: comunicação entre uma aplicação cliente e um serviço web
53
Da mesma forma que serviços clientes consomem serviços servidores, aplicações clientes também seguem certos passos para usarem os serviços web, tendo que
primeiro localizar o serviço, fazer uma chamada ao serviço e processar qualquer informação retornada. A escolha do modo de comunicação determina muito dos detalhes
para a realização de tais tarefas para este tipo de iteração.
Uma aplicação pode se comunicar com um serviço usando stubs, proxies dinâmicos ou interfaces de invocação dinâmica (Dinamic Invocation interface - DII). Com
esses modos, um desenvolvedor depende de alguns moldes do lado cliente para representar um serviço web a fim de acessar suas funcionalidades. O desenvolvedor
dos serviços decide qual representação usar baseadas na disponibilidade do WSDL,
o endereço do ponto final do serviço e os casos de uso para este serviço.
A aplicação exemplificada para demonstrar o uso do serviço web usará stubs, pois
o mesmo se dá de forma mais simplória, excluindo a necessidade de um software
específico de proxy e o uso de interfaces dinâmicas que tornariam o desenvolvimento
obsoleto para o exemplo apresentado.
Após decidir o modo de comunicação, os desenvolvedores necessitam seguir no
projeto e no desenvolvimento de uma aplicação cliente:
1. Avaliar a natureza e a disponibilidade do serviço e a descrição do serviço - geralmente, o primeiro passo é determinar a localização do documento WSDL do
serviço web e escolher o modo de comunicação. Usando stubs ou proxies dinâmicos, deve-se primeiro localizar e conseguir acesso total ao documento WSDL
representante do serviço web, desde que se desenvolva a aplicação cliente a
partir de stubs e suporte de arquivos gerados a partir do WSDL. Se possuir o
acesso somente a uma parte do documento WSDL, então usa-se o DII, desde
que a DII permita localizar o serviço em tempo de execução.
2. Criar a delegação do lado do cliente:
(a) Se aplicável, gerar o stub necessário e o suporte de classes - gerar classes pode não ser portável através da implementação. Portabilidade está
diretamente ligada ao uso de limitação do uso de métodos específicos de
54
chamadas nas classes do stub. Quanto menos, mais portável por se desprender da plataforma que o cliente está sendo executado.
(b) Localizar o serviço - dependendo do modo de comunicação, existem diferentes modos de se localizar um serviço.
(c) Configurar o stub ou objetos de chamada.
3. Invocar o serviço:
(a) No uso de stubs e de proxies dinâmicos, invocações são síncronas. Usa-se
o DII se desejar ter uma chamada de caminho único.
(b) Trabalho com parâmetros, valores de retorno e exceções.
4. Apresentar a interface (view).
Geralmente o cliente pode precisar gerar sua interface para usuários finais. Existem diferentes modos com que clientes podem lidar com apresentações das respostas
a usuários do serviço web. Em alguns casos, um serviço envia sua resposta, sendo
este um documento XML, e este documento poderá vir a ser transformado ou, ainda,
mapeado a um formato compatível para apresentação.
Modelos de comunicação para acessar um serviço
Para melhor determinar o modo de comunicação para a aplicação cliente, é preciso saber as respostas de questões como: o documento WSDL do serviço web é
totalmente conhecido? O endereço do ponto final é conhecido pelo serviço web?
Como indicado, existem três modo principais para a comunicação de uma aplicação
cliente com um serviço web: stub, proxies dinâmicos e interface de invocação dinâmica
(Dinamic Invocation interface - DII).
Clientes usando tanto stub quanto proxies dinâmicos para acessar um serviço
requer, por regra, uma definição de interface de um ponto final do serviço. Quando
referenciado à interface de ponto final do serviço, esta é a interface entre o stub e o
proxy dinâmico do cliente.
55
O stub, o qual está entre o cliente e a representação do cliente à interface do
serviço do ponto final, é responsável por converter uma requisição de um cliente em
uma mensagem SOAP e enviá-la ao serviço. O stub também converte respostas de
serviços de ponto final, as quais são recebidas como mensagem SOAP em um formato
que será compreendido pelo cliente.
Por outro lado, os proxies dinâmicos fornecem a mesma funcionalidade como os
stubs, mas isso é feito de uma forma mais dinâmica. O modelo de proxy dinâmico difere do modelo de stub principalmente por ele não requerer geração de código durante
o desenvolvimento.
Já DII é uma interface de chamada que suporta invocação programática e, usandoa, um cliente pode chamar um serviço ou um procedimento remoto sem conhecer em
tempo de compilação o exato nome do serviço ou a assinatura do procedimento. Um
cliente DII pode descobrir esta informação em tempo de execução e pode dinamicamente procurar pelos serviços e seus procedimentos remotos, diferindo dos stubs,
que dependem de uma ferramenta que usam arquivos WSDL para criar a interface do
serviço de ponto final, assim gerando o stub e outras classes necessárias.
Localizando e acessando serviços
Localizar um serviço difere de tecnologia para tecnologia. Assim, um cliente pode
acessar um serviço de várias formas. Sua dependência é dada pela geração das
classes do stub, que é baseada na tecnologia em que o cliente é desenvolvido.
Acessar um serviço independe da utilização de stubs ou de proxies dinâmicos.
Um cliente, após procurar pela porta de acesso ao serviço, poderá fazer qualquer
chamada desejada pela aplicação. Deve ser assumido que a instância da porta utilizada pelo serviço não será a mesma para as chamadas do serviço, pois portas são
independentes de estado.
Configuração de stubs e chamadas
Desenvolvedores podem querer configurar uma instância do stub ou uma interface
de chamada priorizando a invocação do serviço ou podem preferir permitir a configu-
56
ração a tomar lugar dinamicamente em tempo de execução. Geralmente, o desenvolvedor configura o stub ou a interface de chamada priorizando a invocação do serviço
quando o serviço requer uma autenticação básica.
Stubs podem ser configurados estaticamente ou dinamicamente. A configuração
de um stub estático é feita a partir da descrição do documento WSDL na hora em
que o stub é gerado; já a configuração de um stub dinâmico é feita através de dados
de entrada processados em uma regra programada pelo desenvolvedor em classes
específicas para o mesmo.
Tratamento de exceções
Há dois tipos de exceções em aplicações clientes que acessam serviços web:
exceções de sistema e exceções específicas do serviço, as quais são lançadas pelo
ponto final do serviço. Exceções de sistema são lançadas por condições como uma
passagem incorreta de parâmetro na invocação de um método de um serviço, por um
serviço estar inacessível, por erro de rede, ou por algum outro erro além do controle
da aplicação. Exceções de serviços, as quais são mapeadas a partir de falhas, são
lançadas quando um erro específico do serviço é encontrado. A aplicação cliente deve
lidar com os dois tipos de exceção.
3.3.3 Design de serviço de ponto final
Serviços web interagem com clientes a fim de receberem suas requisições e retornarlhes uma resposta. Entre a requisição e a resposta, um serviço aplica uma lógica de
negócio apropriada e responde a requisição do cliente. A efetiva elaboração de um
serviço web começa no entendimento da natureza do serviço a fim de ser fornecido
- que é como o serviço irá interagir com o cliente e como irá responder a suas requisições - acompanhado de como os usuários do serviço encontram e realizam suas
requisições.
A maior parte das decisões que devem ser feitas no desenvolvimento e implementação de serviços web será abordada, incluindo a identificação de diferentes possibilidades que oferecem uma gama de diferentes soluções. Além disso, serão apresentados os conceitos de como receber requisições, delegar requisições de lógica
57
de negócio, formular respostas, publicar um serviço e como lidar com uma interação
baseada em documentos.
Serão abordados três tipos diferentes de serviços web:
1. Um serviço web provedor de informação que oferece informação que é mais lida
do que atualizada - clientes leem a informação mais do que eles podem atualizála.
2. Um serviço web que atualmente completa as requisições de clientes enquanto
lida com uma alta proporção de informações compartilhadas que frequentemente
é atualizada e que sofre pesadas requisições que utilizam sistemas de integração (EIS) ou transações de banco de dados.
3. Serviços web de processamento de negócio, o quais processam requisições de
clientes incluindo uma serie de longos processamentos de dados das regras
de negócio, mas, sendo o último caso, usado no desenvolvimento da aplicação
exemplo.
Decisões chaves no design de serviços web
Tecnologias voltadas para serviços web basicamente ajudam a expor uma interface a fim de se obter interoperabilidade para aplicações existentes ou novas, ou seja,
você pode adicionar uma interface de um serviço web a uma aplicação existente a fim
de torná-la interoperável com outras aplicações, ou você pode desenvolver uma aplicação completamente nova que será interoperável a partir da interceptação do novo
serviço.
É importante citar que a capacidade de design de serviços web é separada do design da lógica de negócio da aplicação, ou seja, quando se planeja o design de uma
interface de um determinado serviço, devem-se considerar tais problemas que podem
ser provenientes especialmente da interoperabilidade, e não problemas provenientes
da lógica de negócio, e assim, toma-se decisões de design do serviço baseadas nestes problemas.
58
No design de serviços web deve ser considerado o fluxo para um típico serviço e
os problemas que os mesmos levam. Em geral, um serviço web:
1. Expõe uma interface que clientes usam para criarem requisições a um serviço.
2. Torna um serviço disponível a parceiros e clientes interessados em publicarem
os detalhes do serviço.
3. Recebe requisições de clientes.
4. Delega requisições feitas a uma apropriada lógica de negócio e processa essas
requisições.
5. Formula e envia resposta ao requisitante.
Dado o fluxo lógico, segue passos típicos no projeto de serviços web.
1. Decisão da interface para os clientes. Decidir quando e como publicar esta interface - o desenvolvimento de um serviço web começa decidindo qual interface o
serviço tornará pública a clientes. A interface deve refletir o tipo e a natureza das
chamadas que clientes irão realizar a fim de usar o serviço. Deve ser considerado o tipo de ponto final que se deseja usar. Deve ser decidido onde trabalhar o
arquivo SOAP e deve-se, ainda, certificar-se de que estas decisões não afetarão
a interoperabilidade do serviço como um todo.
2. Determinar como receber e processar requisições - será necessário que o projeto do serviço web permita não somente receber chamada de um determinado
cliente, mas também realizar qualquer processamento necessário a tal requisição, como traduzir o conteúdo da mesma para um formato interno antes da
aplicação da lógica de negócio.
3. Determinar como delegar requisições à lógica de negócio - uma vez que a requisição tenha sido recebida e processada, então o serviço se encontra pronto
para delegá-la à lógica de negócio.
4. Decidir como processar a requisição - se o serviço oferece uma interface de
um serviço web a uma lógica de negócio existente, então o trabalho para este
passo pode ser simplesmente determinar como interfaces de lógicas de negócio
existentes podem ser usadas para tratar a requisição do serviço.
59
5. Determinar como formular e enviar respostas - como os serviços web formularão
e enviarão respostas de volta para o cliente. É melhor manter estas operações
logicamente juntas. Existem ainda outras considerações a serem feitas neste
contexto antes de enviar respostas para os clientes.
6. Determinar como reportar problemas - serviços web não serão imunes a erros;
deve ser decidido como tratar esses erros que podem ocorrer. Será necessário
endereçar tais problemas como quando lançar específicas exceções de sistema
ou quando permitir que um sistema base lance uma exceção específica de sistema. Deve ser formulado também um plano de recuperação de exceção em tais
situações que exigirem uma recuperação.
Após considerar tais passos, as seguintes questões devem ser feitas a fim de se
determinar diretivas para o projeto do serviço web desejado.
1. Como clientes fazem uso dos serviços? Considerar quais tipos de chamadas
clientes irão fazer e quais podem ser os parâmetros destas chamadas.
2. Como o serviço web irá receber as requisições dos clientes? Considerar qual
tipo de ponto final irá usar o serviço.
3. Processamentos comuns como transformações, traduções e logins precisarão
ser realizados?
4. Como a requisição será delegada para a lógica de negócio?
5. Como será formulada a resposta e enviada para o cliente?
6. Quais tipos de exceções o serviço irá tratar e quando podem ocorrer?
7. Como clientes saberão do serviço web? Será publicado em registros públicos,
em registros privados ou em outro tipo de registro?
Essencialmente, a implementação de um serviço web pode ser vista como duas
camadas: uma camada de interação e outra de processamento.
A camada de interação consiste na interface do ponto final que o serviço web
expõe aos clientes através da qual o mesmo recebe suas requisições.
60
Quando o mesmo recebe requisições dos clientes, a camada de interação define
qualquer processamento necessário antes de delegar requisições à lógica de negócio.
Quando o processamento da lógica de negócio se completa, a camada interação envia
de volta a resposta para o cliente.
A camada de processamento envolve toda a lógica de negócio usada para processar as requisições de clientes. É também responsável por integrar-se a sistemas
de integração existentes e a outros serviços web. No caso de aplicações existentes adicionando a interface do serviço, a aplicação tipicamente formula a camada de
processamento por si só.
Visualizar a implementação do serviço web em termos de camadas, ajuda a:
1. Facilmente dividir responsabilidades.
2. Prover uma localização comum ou única para processamento lógico de requisições (ambas, pré e pós processamento) na camada de interação.
3. Expor toda lógica de negócio como um serviço web.
No entanto existem vantagens, como se nota na descrição anterior, em visualizar
um serviço em termos de camadas de interação e processamento. Um serviço pode
optar por juntar estas duas camadas em uma única. Há vezes em que múltiplas camadas tornam um serviço desnecessariamente complicado e, nestes casos, o serviço
poderia ser mais simples se o seu projeto fosse feito em uma camada. Tipicamente,
isto acontece em cenários onde a lógica nas duas camadas é muito pequena para
necessitar de camadas separadas.
Projeto da camada de interação
A camada de interação de um serviço possui muitas responsabilidades. Clientes
acessam o serviço web através de serviços específicos, e a interface é o ponto de
partida da interação de um cliente com o serviço web. A camada de interação também
lida com outras responsabilidades, tais como receber requisições de clientes, delegar
requisições a apropriadas lógicas de negócio e a criação e o envio de respostas.
61
Desenvolvendo a interface - existem algumas considerações que devem ser levadas em conta, como problemas de sobrecarga de métodos, escolha do tipo de ponto
final, e assim por diante.
Escolha do tipo de interface do ponto final - quando você desenvolve um novo
serviço web que não usa uma lógica de negócio existente, a escolha de tipo de ponto
final para usar a interface de um determinado serviço web é de extrema cautela.
Quando se adiciona uma interface de um serviço web a uma aplicação existente
ou a um serviço, deve-se considerar onde a aplicação existente ou serviço processa
requisições antes de delegá-las à lógica de negócio. Além disso, deve-se escolher o
tipo de ponto final que se adapte à camada onde a lógica de processamento ocorre
na aplicação existente.
Se a aplicação ou serviço existente não requer processamento de requisições,
escolhe-se o ponto final apropriado que está presente na mesma camada que a lógica
de negócio.
Na escolha de um ponto final ideal seria necessário levar em conta alguns tópicos:
1. Considerações de acesso multi-thread - sincronizações no código fonte podem
ser necessárias dependendo da tecnologia empregada no desenvolvimento do
serviço web.
2. Considerações de transação - o contexto de transação de implementação do serviço determina o contexto transacional no qual a implementação é executada. Se
a lógica do serviço requer o uso de transações, será necessária a implementação do gerenciamento lógico das transações.
3. Considerações para as permissões de acesso de métodos - um método de um
serviço web pode ser acessado por uma gama de clientes diferentes, e será necessário adicionar determinadas restrições aos métodos para diferentes clientes.
4. Considerações a acesso de sessões HTTP - suporte a sessões HTTP é apropriado para interações de curta duração, onde um serviço web geralmente re-
62
presenta o processamento de negócio com durações maiores sem precisar de
mecanismos adicionais.
Granularidade de serviços
A granularidade está relacionada ao nível de detalhamento do comportamento de
um objeto que é exposto. O detalhamento do comportamento do objeto determina se
a mesma será granularidade grossa ou fina. Quanto mais detalhado, mais fina é a
granularidade.
Muito do projeto da interface de serviços web envolve o projeto de operações de
serviços ou seus métodos. Primeiro determinam-se as operações do serviço, para
depois definir a assinatura do método para cada operação, ou seja, define-se cada
parâmetro de cada operação e o mesmo retorna valores ou qualquer erro que poderá
ser gerado.
Para aqueles serviços que implementam processamento de negócio, a natureza
do mesmo geralmente está sujeita à granularidade. Processos de negócio que trocam
documentos por natureza resultam em uma interface de serviço web que é de granularidade grossa. Com mais serviços web interativos, será necessário um cuidado na
granularidade das operações existentes.
Deve ser mantida a mesma consideração no projeto de métodos para serviços web
como quando desenvolvendo métodos para conteúdos remotos. É particularmente
verdadeiro não somente para evitar o impacto de acesso remoto na performance, mas
também nos serviços web. É altamente importante em serviços web, pois existe uma
representação XML requerendo banda para seu envio. Assim, uma boa regra é definir
a interface do serviço web para otimizar a granularidade de suas operações, ou seja,
encontrar o balanceamento certo entre granularidade grossa e granularidade fina.
Geralmente, devem-se consolidar operações de granularidade fina dentro de operações de granularidade grossa para minimizar chamada de métodos remotos custosos.
63
Operações de granularidade grossa mantêm o consumo da rede baixo e melhora a
performance, no entanto, algumas vezes são menos flexíveis do ponto de vista do lado
cliente; enquanto operações de granularidade fina resultam em um maior consumo da
rede e em uma redução de performance.
É importante citar que muita consolidação leva à ineficiência. Por exemplo, consolidar logicamente diferentes operações é ineficiente; é melhor consolidar operações
similares ou operações que os cliente mais usam, como operações de consulta.
Quando um serviço web é exposto, deve-se assegurar que as operações do serviço
estão suficientemente com granularidade grossa.
Tipos de parâmetros para operações de serviços web
Na invocação de um método de uma interface de um serviço, um cliente pode
ter um grupo de valores para associá-lo como parâmetros à chamada. Devem ser
escolhidos cuidadosamente os tipos de parâmetros quando se desenvolve métodos
em uma interface de um serviço. Uma chamada a um método e seus parâmetros é
enviada como mensagens SOAP entre o cliente e o serviço. Para ser parte de uma
mensagem SOAP, os parâmetros devem ter mapeamento XML. Quando recebida pelo
cliente ou pelo serviço final, os mesmos parâmetros devem ser mapeados a partir do
mapeamento XML para seus tipos apropriados ou objetos específicos.
No projeto dos parâmetros para chamada a métodos na interface do serviço web,
escolhe-se parâmetros que tenham tipos de mapeamento padrão, pois a portabilidade
e a interoperabilidade do serviço web é reduzida quando se usa tipos de parâmetros
que não são suportados.
Documentos XML como parâmetros
Existem casos quando se deseja passar um documento XML como parâmetro. Tipicamente, esses casos ocorrem em interações de negócio-para-negócio onde existe
a necessidade de troca de documentos legalmente conectados, rastreamento do que
é trocado, e assim por diante. Troca de documentos XML como parte de um serviço
web é endereçado em uma sessão separada.
64
Interfaces com métodos sobrecarregados
Na interface de um serviço web, pode-se sobrecarregar métodos e apresentá-los
a clientes desses serviços. Métodos sobrecarregados compartilham o mesmo nome
do método, mas têm diferentes parâmetros e valores de retorno.
Tratamento de exceções
Uma aplicação web pode encontrar um erro de condição na requisição de processamento de um determinado cliente. Ela necessita tratar qualquer exceção lançada
por alguma condição de erro e propagar essa exceção.
Lançar exceções em aplicações de serviço web tem restrições adicionais que impactam no projeto do serviço de ponto final. Para considerar como o serviço de ponto
final lida com condições de erro e notifica os clientes de erros, devem-se considerar
os seguintes pontos:
1. Similar a respostas e requisições, exceções também são enviadas de volta para
clientes como parte das mensagens SOAP.
2. O serviço web deve suportar cliente que não trabalha com a mesma tecnologia em que o serviço web foi desenvolvido, o que impacta na possibilidade de
incompatibilidade de tratamento desses erros.
Uma aplicação de serviço web pode encontrar dois tipos de condições de erro. O
primeiro é o tipo de erro de sistema irrecuperável, como erro devido a problemas na
conexão da rede. O segundo tipo é o tipo de erro de aplicação recuperável. Este tipo
de erro é chamado de exceção de serviço específico, pois o erro é particular a um
serviço específico.
Mesmo prometendo interoperabilidade através de plataformas heterogêneas, padrões de serviços web não podem endereçar todo tipo de exceções lançadas por
diferentes plataformas.
65
É importante para serviços web - do ponto de vista de interoperabiidade do serviço
- não expor exceções específicas de uma determinada tecnologia em uma interface de
um serviço, ao invés disso, lançar uma exceção específica do serviço. É importante
ainda citar os seguintes pontos:
1. Não se podem lançar exceções não serializáveis a clientes através do ponto final
do serviço web.
2. Quando um serviço lança uma exceção que não pertence à tecnologia que o cliente usa, o tipo de exceção e seu contexto são perdidos pelo cliente que recebe
a exceção lançada.
3. Exceções herdadas são perdidas quando se lança uma exceção específica de
serviço.
4. Deve-se evitar a definição de exceções específicas de serviços que herdam ou
estendem a outras exceções.
5. A pilha de rastreamento de erro não é passada ao cliente.
A pilha de erro para uma exceção é relevante somente para o ambiente atual de
execução e é insignificante em um sistema diferente. Quando um serviço lança uma
exceção a um cliente, este não tem a pilha de rastreamento explicando as condições
de acontecimento da exceção.
Assim, deve-se considerar a passagem de informação adicional na mensagem
para a exceção.
Padrões de serviço web tornam isso mais fácil para um serviço passar condições
de erro a um cliente em uma diferente plataforma. A especificação SOAP define um
tipo de mensagem que os serviços retornam aos clientes. Define também um tipo de
mensagem chamado fault, que permite condições de erro a serem passadas como
parte da mensagem SOAP, indiferenciável da porção de requisições ou resposta. O
termo fault de uma especificação SOAP define exceções de nível de sistema, como
exceções de erros irrecuperáveis.
66
Interoperabilidade
O grande benefício do serviço web é interoperabilidade entre plataformas heterogêneas. A fim de conseguir o máximo benefício, deseja-se desenvolver o serviço
a fim de ser interoperável com clientes e qualquer plataforma, e a organização de
interoperabilidade do serviço web (Web Service Interoperability organization - WS-I)
ajuda neste quesito. WS-I promove uma grade de protocolos genéricos para a troca
interoperável de mensagens entre serviços web. O perfil básico da WS-I promove interoperabilidade por definir e recomendar como a grade central especificada e padrões
para serviços web (incluindo SOAP, WSDL, UDDI e XML) podem ser usados para o
desenvolvimento de serviços interoperáveis.
Para máxima interoperabilidade, devem-se considerar os seguintes pontos:
1. Dois estilos e ligações suportados pelo WSDL.
2. A WS-I suporta anexos.
A WSDL suporta dois tipos de estilo de mensagem: rpc e document. O atributo
WSDL style indica o estilo da mensagem. O atributo style configurado como rpc indica
operações orientadas a chamadas a procedimentos remotos (Remote Procedure Call
- RPC), onde mensagens contêm parâmetros e valores de retorno ou assinatura de
funções. Quando o atributo style é configurado como document, indica operações
orientadas a documentos. Uma em cada mensagem contém documentos. Cada estilo
de operação tem um efeito diferente no formato do corpo da mensagem SOAP.
Além de estilos de operações, WSDL suporta dois tipos de mecanismos de serialização e desserialização: mecanismo literal e encoded. O atributo WSDL use indica
qual mecanismo é suportado.
O valor literal para o atributo use indica que a informação é formatada de acordo
com as definições abstratas no documento WSDL. O atributo encoded significa que
a informação é formatada de acordo com a codificação definida na URI, especificada
pelo atributo encodingStyle. Assim, pode-se escolher entre o estilo rpc ou encoded
67
na passagem de mensagem e cada mensagem pode usar tanto a formatação de informação literal ou encoded.
Recebendo requisições
A camada de interação, através do ponto final, recebe requisições de clientes. A
plataforma mapeia as requisições recebidas de clientes, as quais estão na forma de
mensagens SOAP, a uma chamada de método presente na interface do serviço web.
Antes de delegar estas requisições recebidas à lógica de negócio do serviço web,
deve se realizar qualquer validação de segurança necessária, transformação de parâmetros ou qualquer pré processamento de parâmetros necessário.
Devem-se levar em conta passos adicionais para lidar com documentos XML que
são passados como parâmetros. Estes passos, os quais são mais bem realizados na
camada de interação do serviço, são como segue:
1. O ponto final do serviço deve validar documentos XML recebidos em relação a
seu schema.
2. Quando a camada de processamento e a lógica de negócio do serviço web são
desenvolvidas para lidar com documentos XML, deve-se transformar o documento XML a um schema internamente suportado se o schema para o documento XML diferenciar do schema interno, antes da passagem de documento à
camada de processamento.
3. Quando a camada de processamento lida com objetos, mas a interface do serviço recebe documentos XML, então, como parte da camada de interação, mapeiase o documento XML recebido para o objeto de domínio antes de delegar a requisição à camada de processamento.
É importante que estes três passos - validação de parâmetros ou documentos
XML recebidos, tradução de documentos XML a um schema interno suportado, e o
mapeamento de documentos a objetos de domínio - realizem o mais perto possível do
serviço de ponto final e, certamente, na camada de interação.
68
Um projeto como este ajuda a capturar erros mais cedo e, assim, evitam-se chamadas desnecessárias e meias voltas à camada de processamento.
A camada de interação do serviço web lida com todas as requisições recebidas
e delega-as à camada de lógica de negócio na camada de processamento. Quando
implementada dessa maneira, a camada de interação do serviço web possui muitas
vantagens, desde que se dê uma localização comum para as seguintes atividades:
1. Gerenciamento e manuseamento de requisições que o serviço de ponto final
serve como contato de ponto inicial.
2. Serviços de invocação de segurança, incluindo autenticação e autorização.
3. Validação e transformação de documentos XML recebidos e mapeamento de
documentos XML a objetos de domínio.
4. Delegação à lógica de negócio existente.
5. Tratamento de erros.
É recomendável realizar todo processamento comum como checagem de segurança, login, auditoria, validações de entrada - para requisições na camada de interação assim que recebida e antes da passá-la para a camada de processamento.
Delegando requisições do serviço web à camada de processamento
O próximo passo é projetar como delegar requisições à camada de processamento. Considerar o tipo de processamento que a requisição necessita, ajudará a
decidir como delegar a requisição à camada de processamento. Todas as requisições podem ser categorizadas em duas grandes categorias baseadas no tempo que
o processamento demora, nomeadas:
1. Requisições que são processadas em um curto espaço de tempo, onde o cliente
pode esperar pela resposta antes de seguir adiante com processamentos futuros. Em outras palavras, o cliente e o serviço interagem de forma síncrona, onde
o cliente fica bloqueado até que a requisição é processada completamente e a
resposta recebida.
69
2. Requisições que demoram muito tempo. O cliente e o serviço interagem de
forma assíncrona onde o cliente não precisa se bloquear para esperar o processamento ser completado totalmente.
Quando o serviço recebe a requisição do cliente, o mesmo deve procurar pela informação requisitada e enviar de volta a resposta para o cliente. Esta procura e retorno
de informação podem ser alcançados em um curto espaço de tempo, onde o cliente
pode ser bloqueado e esperar. O cliente continuará seu processamento somente após
obter uma resposta do serviço.
Um serviço web pode ser projetado usando um serviço de ponto final que recebe
as requisições dos clientes e então as delega diretamente à camada apropriada de
processamento do serviço. A camada de processamento do serviço processa a requisição e, assim que completo, o serviço de ponto final retorna a resposta ao cliente.
Quando se faz uma requisição a um serviço assíncrono, o cliente não pode esperar
pelo processamento. Neste tipo de requisição, o cliente pode esperar e continuar
com alguns outros processamentos. Mais tarde, quando receber a resposta, o cliente
pausa ou simplesmente interrompe seja lá o que estiver em atividade no momento.
Tipicamente, em serviços assíncronos, o conteúdo dos parâmetros de requisição inicia
e determina o curso do processamento - o passo para completar a requisição - para o
serviço web. Geralmente, completar uma requisição necessita de vários passos.
Em uma arquitetura de serviços assíncronos, o cliente envia uma requisição para
o serviço de ponto final, então tal requisição é validada na camada de interação e
então delegada à camada apropriada de interação do serviço. Isto é feito enviando a
requisição a uma camada específica de troca de mensagem, como uma API de envio
e recebimento de mensagem, por exemplo, JMS.
A validação garante que uma requisição está correta. Delegar uma requisição antes de validá-la pode resultar na passagem de uma requisição inválida à camada de
processamento. Após a requisição ser delegada corretamente à camada de processamento, o serviço de ponto final pode retornar uma identificação co-relacionada para
70
o cliente. Essa identificação é para futuras referências do cliente e pode ajudá-lo a
associar respostas que correspondam a requisições anteriores.
O serviço pode tornar resultados de requisições de clientes disponíveis em uma
das duas maneiras seguintes:
1. O cliente que invocou o serviço verifica periodicamente o status de sua requisição usando a identificação co-relacionada que foi fornecida na hora em que a
requisição foi realizada.
2. Ou, se o cliente é o próprio nó do serviço web, o serviço chama novamente o
serviço do cliente com os resultados. O cliente pode usar a identificação corelacionada para relacionar a resposta com a requisição original.
Geralmente, isto é decidido pela natureza do próprio serviço.
Formulando respostas
Após delegar a requisição à porção de lógica de processamento da aplicação, e a
lógica de negócio completar seu processamento, o serviço encontra-se pronto para o
próximo passo: formular a resposta para a requisição.
Devem-se construir respostas generalizadas o mais perto possível do serviço de
ponto final, as quais simplesmente construindo-se a chamada do método de retorno,
retornará valores e parâmetros de saída na camada de interação.
Isto permite ter uma localização comum para a construção da resposta e transformações de documentos XML, particularmente se o documento que se retorna para
quem o requisitou deve ser conforme a um schema diferente do schema interno. Manter esta funcionalidade próxima do ponto final permite implementar armazenamento
temporário de informação (caching data) evitando-se voltas extras na camada de processamento.
71
Um serviço bem projetado deveria construir suas respostas em formatos compatíveis com diferentes tipos de clientes. No entanto, não é um bom projeto ter diferentes
implementações da lógica de serviços para cada tipo de cliente. Preferivelmente, é
melhor projetar lógicas de negócio comuns para todos os tipos de clientes. Então,
na camada de interação, transformar os resultados para cada construção de tipo de
cliente.
Projeto da camada de processamento
A camada de processamento está onde a lógica de negócio é aplicada à requisição
do serviço web. Deve-se projetar a lógica de negócio considerando tais problemas.
Existem alguns problemas no design da camada de processamento que devem ser
citados. São eles:
1. "Manter a camada de processamento independente da camada de interação mantendo as camadas independentes e pouco acopladas, a camada de processamento fica genérica e pode suportar diferentes tipos de clientes. Para se
conseguir um nível de acoplamento baixo entre as camadas, considere usar a
delegação de classes que encapsulam o acesso aos componentes de negócio.
2. "Ligue documentos XML à camada de interação - existem casos em que o serviço web espera receber do cliente um documento XML contendo uma requisição
completa, mas a lógica de serviço não tem necessidade de operar no documento
em si. Nesses casos, é recomendado que a camada de interação ligue o conteúdo do documento XML a objetos antes de passar a requisição para a camada
de processamento. Lembrando que a lógica de processamento pode operar nos
conteúdos de um documento XML recebidos do cliente.
Dependendo do cenário da aplicação, a camada de processamento pode ser requisitada para trabalhar com outros fornecedores de serviços web a fim de completar
uma requisição web. Caso isso aconteça, a camada de processamento efetivamente
se torna um cliente de outro serviço.
72
Publicando um serviço web
O serviço web precisa ser acessível a clientes, relembrando que alguns serviços
são de interesse público, e outros serviços de interesse entre parceiros confiáveis e,
ainda, outros são de interesse somente de uma única empresa.
Independente da localização do serviço, para acesso público ou privado, primeiro
deve-se criar os detalhes sobre os serviços web - sua interface, parâmetros, onde o
serviço está localizado, e assim por diante. Esta atividade é possível tornando disponível a descrição dos serviços web às partes interessadas. Como dito anteriormente,
a linguagem de descrição de um serviço web (Web service Description Language WSDL) é a linguagem padrão para descrição de serviços. Criando essa descrição
WSDL disponível a clientes, permiti-se o uso dos serviços.
Publicando um serviço em um registro
Publicar um serviço web em um registro é um método de tornar o serviço disponível a clientes.
Pode-se querer registrar um serviço web para uma consumação pública generalizada em um registro bem definido. Quando um serviço é disponibilizado através de
registros públicos, qualquer cliente, até um sem conhecimento prioritário do serviço,
pode procurar e usar o serviço. Registros públicos mantêm a descrição do serviço
web, o qual consiste em não somente no WSDL do serviço, mas também em qualquer schema XML referenciado pela descrição do serviço. Em outras palavras, o
serviço web deve publicar seus schemas XML públicos e qualquer schema definido
no contexto do serviço. Deve ainda publicar no mesmo registro público schemas XML
referenciados pela descrição do serviço.
Quando um serviço web é estritamente para uso propietário, deve-se publicar a
sua descrição em um registro da corporação na própria empresa.
Não é necessário o uso de um registro se todos os clientes do serviço web são
parceiros dedicados e existir um acordo entre as parte no uso do serviço. Neste caso,
73
pode-se publicar a descrição do serviço web - WSDL e os schemas XML - em uma
localização bem conhecida com acessos e proteções apropriados.
Entendendo conceitos do registro
Registros públicos não são repositórios. Ao invés de conterem detalhes completos
nos serviços, registros públicos contêm somente detalhes sobre o que os serviços são
capazes e como acessar esses serviços.
Um registro pode somente armazenar o tipo do serviço, sua localização e informações necessárias para acessá-lo. Um cliente interessado em um serviço deve primeiro
descobri-lo a partir do registro e então ligar-se com a ele para obter um completo catálogo do serviço em questão.
Uma vez obtido o catálogo do serviço, o cliente pode certamente acessar um
determinado serviço a fim de sanar sua necessidade. Caso contrário, o cliente deve
procurar novamente no registro e repetir o processo de descoberta e ligação - o cliente
procura no registro por algum outro serviço que potencialmente oferece o que deseja,
liga-se a ele, obtém acesso ao seu catálogo, e assim por diante.
Usar padrões de taxonomia (identificação) existentes oferece aos clientes dos serviços web uma base padrão a partir da qual o serviço web será procurado, tornando a
tarefa de encontrar um determinado serviço mais fácil. Pode-se publicar o serviço web
em mais de um registro, para futuramente ajudar clientes a encontrarem os serviços.
É também uma boa idéia publicar em quantas categorias forem possíveis.
Por exemplo, se múltiplas instâncias de um serviço existem para um produto particular, o cliente pode futuramente refinar sua pesquisa considerando diferentes fatores
de busca.
Trabalhando com documentos XML em um serviço web
Existem considerações adicionais quando uma implementação de um serviço web
espera receber um documento XML contendo toda informação de um cliente, e qual
74
serviço usado para iniciar um processamento de negócio para manusear a requisição.
Existem muitas razões para justificar a troca de documentos:
1. Documentos, especialmente documentos relacionados ao negócio, podem ser
muito grandes, e eles são geralmente enviados como base das informações relacionadas. Eles podem ser compressados independente da mensagem SOAP.
2. Documentos podem ser legalmente ligados a documentos de negócio. No mínimo, sua forma original deve ser conservada através da troca e, ainda, eles
podem precisar de serem arquivados e mantidos como evidências no caso de
um descumprimento de acordo. Para estes documentos, uma documentação
completa deveria ser guardada, incluindo comentários e referências a entidades
externas.
3. Algum processamento da aplicação requer o completo descritivo do documento,
incluindo comentários e referência à entidade externa. Com a legalidade de ligação dos documentos, é necessário preservar a completa descrição do mesmo,
incluindo comentários e referências de entidades externas do documento original.
4. Quando enviado como anexo, é possível manusear o documento que pode estar
expresso em uma linguagem não suportada expressa no schema do serviço web,
sem estar no descritivo SOAP (como o Documento Type Declaration - DTD).
Em essência, o serviço o qual recebe a requisição com o documento XML inicia
um processamento de negócio a fim de realizar uma série de passos para completar
a requisição.
O conteúdo do documento XML é usado no processamento do negócio. Lidar
com esse tipo de cenário efetivamente requer algumas considerações adicionais para
serviços web.
1. É um bom projeto realizar a validação de qualquer informação requerida do documento XML o mais próximo possível do ponto final. Validações e transformações devem ser realizadas antes de se aplicar toda lógica de processamento no
conteúdo do documento.
75
2. É importante considerar o tempo de processamento para uma requisição e o
quanto o cliente pode esperar pela resposta. Quando um serviço espera por um
documento XML como dado de entrada, incia-se o processamento de negócio
baseado no conteúdo do documento, então clientes tipicamente não querem esperar por uma resposta. Um bom projeto quando o tempo de processamento
pode ser alto é delegar uma requisição a um middleware a fim de retornar um
identificador correlacionado para futuras referências do cliente.
Tendo esses conceitos fundamentais de um serviço web bem definidos, o próximo capítulo mostra uma aplicação exemplo, bem como exemplos práticos desses
conceitos.
76
4
ESTUDO DE CASO
Antes de começar o capítulo, devemos definir o conceito de aplicação cliente web
e aplicacão cliente desktop, onde o primeiro é uma aplicação que é usada via browser,
mais especificamente, uma página web. Já o segundo, é uma aplicação instalada e
executada em várias máquinas, onde cada máquina tem o seu executável.
4.1 DESCRIÇÃO DA APLICAÇÃO EXEMPLO
Um cenário característico de computação distribuída bastante interessante é o
bancário, onde os bancos possuem muitas agências espalhadas geograficamente,
necessitando assim de uma forma de comunicação entre elas. Usando esse cenário,
a aplicação exemplo deste trabalho visa simular uma transferência entre contas da
mesma agência, usando um serviço web, para possibilitar a transferência por meio
de uma aplicação cliente desktop e uma aplicação cliente web (Internet Banking). A
figura 17 ilustra esse conceito.
Figura 17: Demonstração da aplicção
77
4.2 DIAGRAMA DE CASO DE USO
"O Diagrama de Caso de Uso descreve a funcionalidade proposta para o novo sistema. Segundo Ivar Jacobson, podemos dizer que um Caso de Uso é um documento
narrativo que descreve a sequência de eventos de um ator que usa um sistema para
completar um processo"[16].
Nesta seção, temos o diagrama de caso de uso da aplicação exemplo, onde o
cliente solicita uma transferência ao serviço que, por sua vez, valida o usuário e verifica
o saldo, para depois realizar a transferência de uma conta para outra.
A figura 18 ilustra o caso de uso:
Figura 18: Caso de uso
Esse é o funcionamento da aplicação como um todo. As partes onde são tratadas
as questões características do projeto serão detalhadas nos próximos tópicos.
4.3 ESPECIFICAÇÃO DO PROJETO
4.3.1 Tecnologias
Para que a aplicação apresentada pudesse ser concreta e para que o objetivo
deste trabalho fosse alcançado, foi necessária a utilização de uma base de dados
78
simples, pois o foco do trabalho não condiz com os interesses de pesquisa relacionados a banco de dados. Mas para tal, foi usado o banco de dados JavaDB, um banco
próprio do Java de fácil manuseio, pois não possui grandes implementações de um
banco de dados Robusto.
A linguagem de programação Java foi utilizada para o desenvolvimento do serviço
web e uma das aplicações cliente que consumirá o serviço em questão. Tal aplicação
se dá pela crescente demanda de provimento de serviços portáveis, e Java oferece
essa portabilidade acompanhada de segurança e estabilidade, tanto para o serviço
web quanto para a aplicação cliente [1].
Para o mapeamento das tabelas, pertinentes ao JavaDB citado acima, no que
tange ao serviço web, foi utilizado o framework Hibernate, que acompanha a portabilidade do Java. Ele oferece para o serviço todas as ferramentas para que o serviço
web esteja em plena comunicação com a base de dados [3].
Em relação à aplicação cliente web, desenvolvida em Java, foi utilizada uma tecnologia bem difundida no ambiente de desenvolvimento web, o JavaServer faces, que
facilita de forma significante o desenvolvimento e aumenta a produtividade do desenvolvimento de qualquer tipo de aplicação web baseada em Java [4].
Para ser apresentado o verdadeiro potencial que um serviço web oferece, foi necessário o desenvolvimento de uma aplicação que mostrasse sua característica marcante,
a interoperabilidade. Aplicação esta, construída utilizando a linguagem de programação C Sharp. Essa aplicação cliente, diferentemente da primeira, não é uma aplicação
web, e sim uma aplicação desktop, apresentando, assim, uma outra característica dos
serviços web, a independência de linguagem de programação.
Hibernate
Para iniciar o desenvolvimento da aplicação web servidor, primeiramente definiuse que a mesma utilizará os padrões de projeto Singleton e o desenvolvimento em
camadas. O Singleton se justifica no argumento que, vários clientes terão acesso à
aplicação, mas não necessariamente a aplicação necessita de ter vários acessos à
79
base de dados. Abrir uma conexão com uma base de dados, do ponto de vista do
desempenho, é muito custoso. Assim, utilizando o padrão Singleton, que diz que uma
determinada classe terá somente uma instância durante toda a aplicação, tal instância
é criada pelo método construtor da classe, entào teremos a classe que efetivamente
gerencia toda a conexão com a base de dados somente instanciada uma única vez
[3]. Isso pode ser visto na figura 19, que corresponde ao método construtor da classe
HibernateUtil.
Figura 19: Método construtor da classe HibernateUtil
A aplicação web a ser apresentada será desenvolvida utilizando a linguagem de
programação Java, por ser uma linguagem portável e segura. Utilizando a linguagem
Java para o desenvolvimento, será necessário criar uma forma da aplicação se comunicar com a base de dados. Mas, como visto anteriormente, a aplicação possui
uma única conexão com o servidor de aplicação. Teremos vários usuários fazendo
requisições a todo tempo e precisaremos de alguém para gerenciar essas requisições
e respostas e, ainda, será necessário que quem gerencie as requisições e respostas
seja também portável, já que a linguagem de desenvolvimento é portável.
Para tal feito, foi utilizado o framework Hibernate. O Hibernate trabalha da seguinte
forma:
Mapeia os dados relacionais da base de dados da aplicação em classes Java,
tendo essas classes regras específicas da base de dados, criando uma base estrutural
para a aplicação de forma consistente, sem ferir as regras especificadas na criação
da base de dados. O Hibernate, além de mapear, gerenciará a conexão da aplicação
com a base de dados, pois o mesmo é que fará a comunicação dos dados de entrada
e saída da aplicação com o repositório da aplicação web (banco de dados).
80
Foi criada uma classe chamada HibernateUtil que possui várias diretivas; diretivas
estas que norteiam o hibernate sobre a forma de trabalhar, de se comunicar e de como
gerenciar todas as conexões que são a ele requisitadas. Para maiores informações
sobre a classe HibernateUtil, vide anexo 5.
4.3.2 Arquitetura
"O Diagrama de pacotes, ou diagrama de módulos, definido pela UML descreve
os pacotes ou pedaços do sistema divididos em agrupamentos lógicos mostrando as
dependências entre estes, ou seja, pacotes podem depender de outros pacotes"[17].
A arquitetura do serviço web é representada através do diagrama de pacotes. Tal
diagrama contém os pacotes usados no exemplo, bem como acontece a comunicação
entre eles.
A figura 20 representa este diagrama:
Figura 20: Diagrama de pacotes
4.3.3 Diagramas de classes
"O diagrama de classe está no núcleo do processo de modelagem de objetos. Ele
modela as definições de recursos essenciais à operação correta do sistema. Todos os
81
outros diagramas de modelagem descobrem informações sobre esses recursos (como
valores de atributo, estado e restrições no comportamento) que por fim precisam ser
encaminhados ao diagrama de classes. O diagrama de classes é a origem para a
geração de código (converter do modelo para o código) e o destino para a engenharia
reversa (converter do código para o modelo)"[2].
Os diagramas a seguir, descrevem as classes que foram utilizadas no projeto do
serviço web.
Diagrama de classes Entity
Essas classes representadas no diagrama da figura 21 são classes mapeadas
pelo hibernate, baseadas no banco relacional da aplicação, pertinentes à camada de
modelo entre a aplicação e o banco de dados.
Figura 21: Diagrama de classes Entity
Diagrama de Classes DAO
As classes descritas na figura 22 são responsáveis pelo acesso à base de dados.
82
Figura 22: diagrama de classe DAO
Diagrama de classes Faces
Na figura 23, estão representadas as classes que são interfaces entre a camada
de regra de negócio e a camada de interface web.
Para uma melhor visualização, veja a figura 20 (4.3.2 Arquitetura).
Figura 23: Diagrama de classes faces
83
4.3.4 Diagrama de sequência
"Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a sequência de
processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos
em classes diferentes, pode ser difícil determinar a seqüência global do comportamento. O diagrama de sequência representa essa informação de uma forma simples
e lógica"[18].
A figura 24 ilustra o diagrama de sequência da aplicação.
Figura 24: Diagrama de sequência
4.3.5 Classes Entity
As classes de entidade (classes entity ) são classes mapeadas do banco de dados
pelo framework usado na aplicação apresentada. Essas classes possuem métodos e
atributos que estão em conformidade com o banco de dados relacional usado.
Cada atributo em uma entidade está diretamente relacionado a uma coluna em
uma determinada tabela (a qual essa entidade faz referência).
84
Toda classe de entidade deve ser declarada na classe HibernateUtil, para que esta
tenha conhecimento de sua existência podendo gerenciá-la.
Caso ela não seja declarada, a mesma não será reconhecida internamente no
projeto e acarretará em um erro.
Na aplicação apresentada, foram criadas quatro classes de entidade que estão
descritas nos anexos 2, 3, 4 e 5.
4.3.6 Classes DAO
Agora que temos a base estrutural da aplicação, que é a base de dados e a classe
que gerenciará a aplicação, inicia-se a fase de desenvolvimento das classes que irão
manipular as informações que serão passadas ou recebidas das classes mapeadas
pelo hibernate, e são chamadas classes DAO, que fazem parte do padrão de projeto
DAO, chamado de acesso direto a objetos. Essas classes irão fazer toda a manipulação dos dados na base de dados utilizada pela aplicação. As classes mapeadas pelo
hibernate chamam-se entidades, e as entidades são utilizadas exclusivamente pelas
DAO, quando se utiliza esse padrão de desenvolvimento.
Na aplicação apresentada, foi criada uma classe genérica abstrata. A classe abstrata é sempre uma superclasse que não possui instâncias. Ela define um modelo
para uma funcionalidade e fornece uma implementação incompleta - a parte genérica dessa funcionalidade - que é compartilhada por um grupo de classes derivadas.
Cada uma das classes derivadas completa a funcionalidade da classe abstrata adicionando um comportamento específico. Essa classe foi chamada de GenericDAO e
está representada no anexo 6.
4.3.7 Classes faces
As classes faces fazem parte de uma camada da aplicação que pode conter várias
subdivisões, a camada da regra de negócio. A camada da regra de negócio de uma
aplicação web pode conter divisões como controle, interação, processamento e, ainda,
85
conter uma divisão só pra servir de meio entre a camada de controle e a camada de
interface da aplicação web.
Na aplicação apresentada, as camadas de controle, interação e processamento
não foram divididas, pois o exemplo apresentado é muito pequeno para que haja efetivamente a necessidade de tais divisões. Muitas camadas em aplicações robustas são
necessárias para que se detenha um maior controle sob o fluxo de informação por que
cada camada é responsável, mas em aplicações pequenas, como o exemplo apresentado, essas divisões só tornariam a aplicação mais complexa para o desenvolvimento,
sem incremento no desempenho e tampouco uma melhora no resultado obtido.
A aplicação apresentada possui uma única camada de regra de negócio, chamando suas classes de classes faces. Estas classes, além de controlarem o fluxo
das informações são responsáveis pela interação entre a camada de interface para
o usuário e a camada DAO, gerenciando as informações de entrada e saída da aplicação. Entende-se entrada de informação as informações que o usuário fornece na
interface gráfica, e, saída de informação, tudo aquilo que é apresentado para o usuário
após realizar determinada tarefa e o resultado que é obtido com a realização dessa
determinada tarefa.
A aplicação apresentada possui somente duas classes faces. Nas camadas DAO,
para cada classe de entidade existe uma classe DAO, mas na camada de regra de
negócio isso não é necessário. Tal necessidade só se justifica quando a aplicação
possui meio de interação de negócio com a classe implementada. No caso da aplicação apresentada, teremos uma classe faces ClienteContaFaces que é referente a
ClienteConta (pojo, que é a classe de entidades gerada pelo hibernate) e uma outra
classe faces que não fará menção a nenhum pojo específico, TransferenciaFaces.
ClienteContaFaces tem por finalidade controlar toda informação pertinente a uma
determinada conta de um cliente específico, atrelado a uma única senha.
As classes faces podem ser conferidas nos anexos 7 e 8.
86
4.3.8 Páginas web
As páginas de uma aplicação web representam a camada de interação entre o
usuário e a aplicação. Estas podem ser desenvolvidas de várias formas, usando vários
tipos de padrões e vários tipos de frameworks e bibliotecas especificas que melhoram
o desempenho e ajudam na melhora dos componentes, proporcionando uma melhor
experiência para o usuário. As páginas podem ser desenvolvidas de vários modos,
porém todos estes usando HTML como linguagem de desenvolvimento.
A aplicação apresentada utilizou o framework JavaServer faces que fará parte
do container da aplicação (arquivo xml onde estão descritas diretivas de execução da
aplicação), que será quem fará a ligação dos atributos de uma página com os atributos
de uma determinada classe.
Na utilização do framework JavaServer faces, toda informação a ser manipulada,
seja ela de entrada ou de saída, deve estar entre as tags <h:form></h:form>, e todas
as páginas da aplicação apresentada utilizam-se dessa tag.
Não serão abordados e explicados os códigos HTML das páginas, por não ser o
foco do trabalho.
4.3.9 Diagrama de implantação
"O diagrama de implantação modela o hardware do ambiente de implantação.
Cada nó em um diagrama de implantação normalmente representa um tipo de hardware. Um nó também pode representar um ser humano ou uma unidade organizacional, ou, mais precisamente, a função que uma pessoa pode realizar"[2].
O ambiente físico teórico da aplicação exemplo está descrito na figura 25:
87
Figura 25: Diagrama de implantação
4.4 CONSTRUINDO E CONSUMINDO O SERVIÇO WEB
Nesta seção será apresentada a maneira como o serviço web foi construído, publicado e consumido, com exemplos práticos e demonstrações de fragmentos de códigos
Java e C Sharp, usados no desenvolvimento da aplicação.
4.4.1 Implementando um serviço web
A primeira coisa a fazer para se implementar um serviço web é criar uma classe
que detenha todo seu escopo, e nessa aplicação exemplo foi criada uma classe chamada TransferenciaService. Esta classe fará uso de toda a estrutura da aplicação
já desenvolvida, porém provê a funcionalidade de transferir um determinado valor de
uma conta para outra de forma mais simplória.
O código-fonte da classe TransferenciaService é mostrado a seguir, na figura 26:
88
Figura 26: Classe TransfereciaService
O trecho entre a linha 1 e a linha 6, mostra a qual pacote pertence a classe e as
devidas importações necessárias para a classe, sendo esta a parte básica do serviço.
A anotação na linha 8 informa que esta classe em questão será um serviço web.
Esse é o motivo da anotação @WebService() aparecer antes da declaração da classe.
Após a classe ser informada que ela será um serviço, devemos desenvolver o método
(função que realizará a transferência) que será provido, feitos assim como na linha
15. Esta anotação informa que o método descrito ali será disponibilizado pelo serviço
web.
Uma vez que a classe e os métodos foram declarados, os atributos do método
seguem o mesmo princípio assim como mostrado no código entre as linhas 16 e 20.
Esta classe faz uso de outra classe, que já está definida e declarada na aplicação,
tendo como objetivo somente fornecer uma de suas funcionalidades, ou seja, TransferenciaFaces compõe o acervo de funcionalidades que o serviço irá prover, podendo
ser conferido no anexo 8.
Logo após testar o seu status, o método realizarTransferencia() que foi criado
na classe TransferenciaFaces para realizar uma transferência é chamado, passando
os devidos argumentos e assim realizando a transferência. O atributo mensagem que
89
está no escopo da classe é para retornar uma mensagem ao usuário quando o serviço
completar sua tarefa, e o método de transferência utilizado retorna uma mensagem.
Sendo assim, seu valor será certamente atribuído ao atributo mensagem. Depois de
concluído o método, o serviço encerra sua execução enviando para a interface web do
cliente o resultado obtido.
Agora, falta apenas registrar o serviço e descrevê-lo no arquivo que fará referência
ao serviço disponibilizado, o WSDL.
Segue abaixo, na figura 27, o arquivo WSDL da aplicação apresentada.
Figura 27: WSDL
Na linha 1 encontra-se a versão do arquivo e a formatação empregada no uso dos
caracteres que irão compor o serviço. A linha 4 possui a tag <definition>. Esta tag
90
inicia a definição do schema a ser usado pelo serviço web. No schema estão descritas informações como os tipos dos atributos esperados pelo(s) métodos(s) oferecidos
pelo(s) serviço(s). A tag também define a localização do serviço, definindo para o
mesmo um namespace e define o envelope SOAP do serviço web.
Na linha 10, é associado ao namespace o seu devido schema. A partir da linha
16 até a linha 21 são definidos os nomes das mensagens que serão trocadas entre
o provedor do serviço e a aplicação que o consome. "Transferencia" diz respeito à
mensagem do lado cliente e "TransferenciaResponse" diz respeito à mensagem que
virá do servidor.
A partir da linha 22, inicia-se a identificação do porto dos serviços, que no caso da
aplicação apresentada será somente um único serviço. O porto será responsável por
interpretar a mensagem que vem do cliente e a mensagem que é enviada do servidor.
Note que os nomes que foram definidos entre a linha 16 e a linha 21 está sendo
referido na tag pertinente ao porto. A partir da linha 28 é explicitado ao arquivo wsdl
quais serão as características do envelope SOAP a serem trocadas entre provedor
de serviço e consumidor deste. A linha que inicia essas explicitações diz qual porto
será usado para qual serviço e, logo abaixo, na linha 29, é dito qual será o tipo de
informação que será trocada e sob qual protocolo este irá ser transportado e, no caso
da aplicação apresentada, o tipo será de documento (document) e o protocolo será o
HTTP.
A próxima etapa do arquivo, que está na linha 30, diz para o arquivo qual será
o nome do operação que ele irá se referenciar quando uma requisição chegar a ele.
E até a linha 38 é descrito que o transporte dos atributos passados como parâmetro
à operação esperada dar-se-á na forma literal que é a forma que os atributos não
sofrerão nenhum tipo de criptografia antes e nem depois de serem enviados.
Finalmente, a linha 40 irá explicitar o nome do serviço a ser procurado no provedor
do mesmo, e a linha 41 mostra qual o seu porto e quem será responsável por sua ligação com o serviço que está no endereço fornecido na linha 42. E, assim, foi definido
o arquivo wsdl para o serviço apresentado neste trabalho.
91
4.4.2 Consumindo um serviço web
Cliente web Java
Agora que o serviço web já está disponível e pronto para aceitar requisições, iremos criar uma simples aplicação web que faça o consumo do serviço web.
Essa aplicação cliente não fará uso de nenhuma biblioteca. Sendo a aplicação
cliente portável, seria injustificável ter que obrigar uma determinada aplicação que
deseje fazer uso de um serviço, ter que fazer uso de alguma biblioteca para tal.
Primeiro a se fazer será construir o schema que será usado pelo arquivo wsdl do
cliente.
O schema da aplicação apresentada está descrito abaixo, na figura 28:
Figura 28: Schema da aplicação
O arquivo começa descrevendo o elemento que irá usar e logo após, define a
aplicação que irá usar (o mesmo atributo foi descrito no wsdl do servidor do serviço,
e estes devem ser iguais para que se comuniquem). Após, é definido o nome dos
atributos que o serviço web está esperando e o tipo dos mesmos. Tais tipos foram
descritos na classe onde o serviço web foi implementado e precisam estar conformes.
92
A última parte do arquivo define o nome da mensagem resposta que será enviada
ao cliente. A mesma foi descrita no wsdl da aplicação servidora.
Agora que tem-se o schema que o arquivo wsdl do cliente irá usar, a figura 29
ilustra o arquivo wsdl do cliente:
Figura 29: WSDL do cliente
A mesma estrutura usada para descrever o wsdl do serviço servidor é usada para
descrever o arquivo wsdl do serviço cliente.
Agora, será construída a classe que efetivamente fará uso do serviço web.
Chamamos o arquivo de ClienteFaces, e este tem por finalidade receber os atributos descritos na página que lhe é apresentada e, a partir do método descrito nessa
classe, fazer uso do serviço web.
93
A figura 30 apresenta o código-fonte da classe:
Figura 30: Classe ClienteFaces
Além de todos os métodos getters e setters dos atributos da classe, esta possui o
método que efetivamente irá chamar o serviço web. Este método recupera o seu porto
a partir do serviço encontrado no wsdl e, a partir daí, faz uso do método transferencia()
como se estivesse trabalhando localmente, independente da linguagem ou plataforma
em que o método foi desenvolvido, alcançando, assim, o objetivo da aplicação apresentada.
Após a conclusão do método, o mesmo retorna para o usuário uma mensagem,
informando se a transferência foi efetuada ou não.
94
Cliente web C Sharp
Visando a mostrar a interoperabilidade de um serviço web, o próximo passo é uma
aplicação cliente desktop desenvolvida na linguagem C Sharp. Este cliente tem o
mesmo objetivo do cliente Java, que é realizar uma transferência de uma conta para
outra.
Mas para que esse cliente consiga ter acesso ao serviço web, primeiramente, ele
deve saber onde esse serviço está, ou seja, sua localização. Isto é feito, informando
a ele o WSDL do serviço, que tem em seu conteúdo a localização do mesmo, bem
como seus métodos e parâmetros, como pode ser visto na figura 31.
Figura 31: Arquivo WSDL importado pelo C Sharp
95
Depois que o wsdl é conhecido, todos os métodos e parâmetros do serviço são
conhecidos. São criadas referências dentro do projeto C Sharp, dentro do arquivo
reference.cs, como segue no fragmento de código a seguir:
Figura 32: Método criado dentro do arquivo reference.cs
Depois que o serviço e seus métodos foram localizados, basta ser acessado de
dentro do arquivo onde ele será chamado. Normalmente, como se fosse um método
local, como exemplificado na figura 33:
Figura 33: Chamada do método transferencia dentro do cliente C Sharp
4.4.3 Visualização da aplicação em funcionamento
Ao iniciar a aplicação o seu estado inicial é mostrado na figura 34, onde há o
netBeans ao fundo, contendo os resultados de uma consulta ao banco e a saída do
servidor de aplicação, antes de executar qualquer requisição. Já em primeiro plano,
há a aplicação cliente web, rodando no firefox em seu estado inicial.
96
Figura 34: Estado inicial do serviço web e aplicação cliente web
Ao efetuar uma transferência da conta de origem 1 para a conta de destino 2, a
aplicação cliente obteve uma resposta do serviço web, dizendo que a transferência foi
realizada com sucesso. Já em segundo plano, há o netBeans com o resultado de uma
consulta ao banco e a saída do servidor de aplicação após a excução da transferência,
como pode ser visto na figura 35.
De maneira análoga ao cliente web Java, o cliente desktop C Sharp envia a requisição para o servidor e recebe uma resposta dizendo que a transferência foi realizada,
como pode ser visto na figura 36.
Desta maneira, ocorre toda a transação entre cliente e servidor. Além de mostrar
essa transação, pode-se perceber a interoperabilidade entre aplicações desenvolvidas em linguagens diferentes, deixando todo o processamento para o serviço web, e
ficando o cliente responsável apenas por enviar uma requisição, receber uma resposta
do servidor e mostrar um resultado ao usuário.
97
Figura 35: Estado do servidor e aplicação cliente após a execução da transferência
Figura 36: Estado do servidor e aplicação cliente C Sharp depois de realizada uma
transferência
98
5
CONCLUSÃO
Vários modelos de computação distribuída foram estudados, em todos os casos
foram levantadas vantagens, desvantagens e características marcantes de cada um.
Dessa forma, foi possível constatar que cada modelo possui peculiaridades que fazem
com que se adequem a determinado tipo de cenário de aplicação.
Com base no estudo feito e no cenário do estudo de caso, foi escolhido um modelo
específico (web service) para o desenvolvimento de uma aplicação. Além disso, o
volume de pesquisas realizadas na área de serviços web evidencia a sua importância
e o grande interesse ainda remanescente por parte de organizações e instituições
acadêmicas, por essas razões, tal modelo foi escolhido para ser utilizado.
No estudo de caso desenvolvido, foi exemplificado de modo prático um serviço
web, desde a sua fase inicial, passando pela implementação até sua publicação para
consumo de terceiros. Mostrando também a interoperabilidade entre linguagens de
desenvolvimento diferentes, justificando assim um dos objetivos do trabalho.
Para auxiliar no desenvolvimento da aplicação, frameworks como Hibernate, JavaServerFaces e a IDE NetBeans foram utilizados, trazendo desta forma facilidades que
antes não existiam, tornando mais fácil o aprendizado e desenvolvimento do serviço
web e das aplicações clientes.
Em um contexto geral, com a existência de sistemas legados, possibilidades de
consumo de serviços de terceiros e levando em consideração as características apresentadas ao longo do trabalho, o conceito mais importante foi o de interoperabilidade,
pois, permitiu-se que uma aplicação construída em uma linguagem diferente consumisse o serviço sem problemas.
99
Caracterizando assim, a integração entre sistemas de plataformas e linguagens
diferentes.
Por fim, ao longo desse trabalho foram observados alguns tópicos que não faziam
parte do escopo da pesquisa, mas foram entendidos como interessantes fontes de
trabalhos futuros: propõe-se a pesquisa mais detalhada em soluções para o gerenciamento de serviços por meio de outros serviços web, mostrando quais são os pontos
fracos e fortes desse modelo de desenvolvimento de serviços web; Além disso, evoluir
o estudo de caso de forma a agregar aspectos de segurança, confiabilidade, tolerância
a falhas e disponibilidade é outro ponto interessante, visto como trabalho futuro.
100
REFERÊNCIAS
[1] Edson Gonçalves. Desenvolvendo Aplicações web com JSP, Servlets, JavaServer
Faces, Hibernate, EJB 3 Persistence e Ajax. Ed. Ciência Moderna. 2007
[2] Tom Pender. UML a Bíblia. Ed. Campus. 2004.
[3] Cristian Bauer, Gavin King. Java Persistence com Hibernate. Editora Ciência Moderna. 2005.
[4] David Geary, Cay Horstmann. JavaServer Faces, Fundamentos 2a Edição. Editora
AltaBooks. 2007.
[5] George Couluris, Jean Dollimore, Tim Kindberg. Sistema Distribuído: Conceito e
Projeto. Ed. Bookman. 2007.
[6] Deitel, Choffnes. Sistemas Operacionais. Prenticel-Hall. 2007.
[7] Sudkamp T.. Languages and machines in an introduction to the theory of computer
science. Addisson Wesley. 1988.
[8] Ian Foster, Carl Kesselman. The Grid: Blueprint for a New Computing Infrastructure. Morgan Kaufmann. 1998.
[9] Rajkumar Buyya, David Abramson, Jonathan Giddy, Nimrod/G. An Architecture for
a Resource Management and Scheduling System in a Global Computational Grid.
Beijing, China. 2000.
[10] M. P. Papazoglou, B. J. Kramer, and J. Yang. Leveraging Web-services and peerto-peer Networks. 15th Int. Conf. on Advanced Information Systems Engineering.
2003.
[11] Gregory R. Andrews. Foundation of multithreaded, parallel, and Distributed Pogramming 1st Edition. Ed. Addison-Wesley. 2000.
[12] Wikkipedia.
Wikkipedia
Distributed
Programming.
http://www.wikipedia.org. Acessado em 21/03/2007.
2007.
URL:
[13] InfoWester. Cluster. 2007. URL: http://www.infowester.com/cluster.php. Acessado
em 10/11/2007.
[14] Clube do Hardware. Clube do Hardware - Clusters. 2007.
http://www.clubedohardware.com.br/artigos/153. Acessado em 10/11/2007.
URL:
[15] Web Service Consortium - W3C. WSDL. 2009. URL: http://www.w3.org/TR/wsdl.
Acessado em 10/05/2009.
101
[16] Wikkipedia.
Diagrama
de
Cado
de
Uso.
2009.
URL:
http://pt.wikipedia.org/wiki/DiagramadeCasodeUso. Acessado em 20/05/2009.
[17] Wikkipedia.
Diagrama
de
Pacotes.
2009.
http://pt.wikipedia.org/wiki/Diagramadepacotes. Acessado em 20/05/2009.
URL:
[18] Wikkipedia.
Diagrama
de
Sequência.
2009.
URL:
http://pt.wikipedia.org/wiki/Diagramadesequência. Acessado em 20/05/2009.
[19] Sun
MicroSystem.
Java
BluePrints,
Designing
Web
Services
with
the
J2EE
com
JAX-RPC.
2009.
URL:
http://java.sun.com/blueprints/guidelines/designingwebservices/. Acessado em
16/03/2009.
102
Anexo 1 - Classe HibernateUtil
103
Anexo 2 - Classe Cliente - Entity
104
Anexo 3 - Classe Conta - Entity
105
Anexo 4 - Classe ClienteConta - Entity
106
Anexo 5 - Classe ClienteContaPK Entity
107
Anexo 6 - Classe GenericDAO
108
Anexo 7 - Classe ClienteContaFaces
109
Anexo 8 - Classe TransferenciaFaces
110