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
Flávio Rodrigo Lovatti
Computação Distribuída, Web Service - um
estudo de caso
Trabalho de Conclusão de Curso apresen-tado 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
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.
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.
lado e fizeram todo esforço necessário para que este meu objetivo
fosse alcançado.
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 tor-namos esse sonho em realidade. É com grande satisfação que damos o nosso "Muito Obrigado!".
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
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
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
3 DEFINIÇÃO DO MODELO ESCOLHIDO 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 . . . 56
4 ESTUDO DE CASO 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.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
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 geogra-ficamente 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 pro-porcionar um melhor uso da capacidade computacional, propiciando vantagens como à interoperabilidade, o desempenho, a escalabilidade, a conectividade, a confiabili-dade, 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 aca-bará 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 com-putaçã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 es-tudo de caso foi definido, com o intuito de exemplificar o funcionamento e a troca de
informações entre aplicações clientes e os serviços propriamente ditos, além da inte-roperabilidade, 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 distri-buí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 ce-ná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 carac-terí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 (ser-viços web), dentre as estudadas, para um estudo mais aprofundado, mostrando suas características, benefícios e outras peculiaridades relacionadas.
O capítulo 4 apresenta um estudo de caso, baseado em um cenário onde a com-putaçã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.
2
REFERENCIAL TEÓRICO
Neste capítulo são apresentados o conceito de sistemas distribuídos e alguns mo-delos 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 cen-tralizados como desempenho e escalabilidade, conectividade e segurança, confiabili-dade, tolerância a falhas e transparência. Vantagens essas que são apresentadas ao longo deste tópico.
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 distri-buí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 re-cursos 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 dis-tribuí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 dis-tribuídos [7]. Esses sistemas devem implementar transparência de localização,
ocul-tando a localização de recursos no sistema distribuído daqueles que estão tenocul-tando 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 mas-carar 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, per-mitindo 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 distri-buí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
2.2 MODELOS DE COMPUTAÇÃO DISTRIBUÍDA
Os modelos apresentados a seguir podem ser tomados como base para o desen-volvimento 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 in-vocador 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 servi-dor, 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.
Figura 1: Passos em uma comunicação cliente e servidor RPC
A chamada de procedimento remoto introduz o conceito de stub, que é o compo-nente 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 monta-gem de dados, que empacota argumentos de procedimento juntamente com o nome do procedimento em uma mensagem para transmissão via rede. Ao receber a men-sagem do stub do cliente, o sistema operacional do servidor transmite a menmen-sagem 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 soque-tes, 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-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 identifi-cação do endereço da apliidentifi-caçã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.
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 da-dos, 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 cações que executem tarefas específicas, como por exemplo, uma determinada apli-cação de uma agência de turismo. Esta irá precisar verificar reservas em hotéis, pas-sagens 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].
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 com-putadores 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 des-centralizadas [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 infor-maçã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 res-posta, 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.
4. A capacidade de cada nó é altamente variável.
Aplicações peer-to-peer centralizada versus aplicações peer-to-peer descentra-lizadas
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 requisi-tado no servidor. Então, o par requisitante se comunica com o par requisirequisi-tado. 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 co-municar com outro, ele não precisa mais se coco-municar 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 me-lhora 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-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 par-ticular 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 so-mente quando se conectar diretaso-mente 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.
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 geogra-ficamente considerando-os como um único e poderoso computador é algo desejado há bastante tempo [7]. Grid é uma proposta promissora para resolver as crescen-tes 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
1. Heterogeneidade: um Grid envolve uma multiplicidade de recursos que são he-terogê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 ser-viç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 pla-taformas, protocolos de rede e bordas administrativas se tornem completamente trans-parentes [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.
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 Conecti-vidade 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 me-canismos 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 pro-tocolos são para negociações seguras, inicializações, monitoramento, controle, contabilidade e pagamento de operações compartilhadas sobre recursos duais. A camada de recursos está preocupada inteiramente com recursos
indivi-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 con-trário, são globais em natureza e capturam interações entre coleções de recur-sos.
Compartilhamento de recursos
O problema real e específico que está por trás do conceito de grid é o compartilha-mento 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 implemen-tação é fundamental para a compuimplemen-taçã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 relacio-namentos 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 comparti-lhamento 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
tra-balham de maneira conjunta para realizar processamento pesado. Em outras pala-vras, 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 per-formance seriam capazes de fazer.
Características
Cada computador de um cluster é denominado nó ou nodo. Todos devem ser in-terconectados 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 funci-onamento 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. Eviden-temente, 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 compu-tadores 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].
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, cons-truindo sistemas computacionais poderosos e economicamente viáveis. O sis-tema 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 softwa-res voltados ao cluster. É muito utilizado em universidades em seus projetos e pesquisas.
2.2.6 CORBA
CORBA é uma arquitetura que estabelece e simplifica a troca de dados entre siste-mas distribuídos heterogêneos de forma transparente, não importando em qual lingua-gem 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 pri-meira 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 clas-ses 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 envi-adas 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 ne-cessá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
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ó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 re-positó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
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 servi-dores 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 ob-jetos 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 co-nhecida 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 requi-sição. Como as implementações de objeto não conseguem detectar se uma determi-nada 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
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 dis-ponibilizados 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 pro-ver 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).
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.
A figura 12 mostra um exemplo de wsdl, com um método chamado transfe-rê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 provedo-res, 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.
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
(ser-vice requestor ) e servidor de registro (ser(ser-vice 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
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 conside-raçã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 arqui-tetura, 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 Serviço web CORBA
Protocolo SOAP, http, XML SCHEMA IIOP, GIOP
Descrição das Interfaces WSDL IDL
Descoberta de Serviço UDDI Repositório
de Interfaces Desvantagens Dependência de disponibilidade Alto custo de
implementação,
do serviço velocidade
relativamente baixo Vantagens Independência de linguagem, Independência de
sistemas operacionais, linguagem, sistemas hardware, plataforma; troca de operacionais,hardware, grandes quantidades de plataforma; Acesso a informações por XML. 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 cli-ente/servidor como base. A tabela 2.3.2 traz essas comparações.
Item RPC RMI
Características Execução de procedimentos e Execução de métodos remotos funções remotos, com passagem com passagem de objetos como de parâmetros. parâmetros entre métodos
remotos.
Vantagens Ligação dinâmica com portas do Métodos definidos na interface, servidor; Oculta detalhes de Objetos remotos implementam soquete ao programador. uma ou mais interfaces.
Desvantagens Não suporta variáveis globais, Dependente de uma linguagem Implementações diferentes orientada a objeto para ser podem oferecer níveis variáveis possível sua utilização. de confiabilidade.
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 Grid Cluster Peer-to-peer
Características Heterogeneidade; Sistema operacional Protocolo de Escabilidade; deve ser o mesmo compartilhamento
Adaptabilidade. de arquivo
Administração Global Local Global
do modelo
Vantagens Evolução do Cluster. Maior poder Confiabilidade, caso computacional; ocorra erro em Distribuição de algum peer, o processamento. sistema não irá
parar totalmente. Desvantagens Redes com baixas Quanto mais Vulnerabilidade e velocidades computadores dependência de comprometem o maiores os uma aplicação desempenho do grid. gastos com intermediária.
manutenção;
3
DEFINIÇÃO DO MODELO
ESCOLHIDO
Com base nas informações analisadas, o modelo de computação distribuída esco-lhido 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 desenvol-vimento, 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 pla-taforma e tecnologia. O cenário onde estão inseridos está expandindo rapidamente devido ao crescimento da necessidade de comunicação e interoperabilidade de apli-caçõ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
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), indepen-dente 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 determi-nada 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 possi-bilidade 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 co-nhecida 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 lingua-gens. Além disso, reduzem o custo operacional por permitirem que as organizações a expandam e reutilizem suas funcionalidades de sistemas já existentes.
No que diz respeito à arquitetura, um serviço web baseia-se na arquitetura ori-entada 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 clien-tes a descobrir os serviços disponibilizados;
3. clientes (incluindo clientes que podem ser serviços propriamente ditos) que des-cobrem 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 permi-tem 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 deter-minado 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 mes-mos 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 distri-buídos sejam executados em uma variedade de plataformas e arquiteturas, pos-sibilitando que eles sejam escritos em diferentes linguagens de programação. A
maior força do serviço web é sua capacidade de interoperabilidade em um ambi-ente 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 reu-tilizem 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 mo-nitoramento 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 serviservi-ç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. Pri-orizando o conceito, desenvolvedores especializados na área de computação distribuída têm encontrado um grande leque de tecnologias nem sempre compa-tí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:
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 ne-cessá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 ser-viços separados. Todos os serser-viç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, au-torizaçã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 proces-samento 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 ambi-ente de segurança integrado. Segurança necessita de ser compatível com os meca-nismos 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 es-cala. Com essas aplicações, a reusabilidade, a disponibilidade e a escalabilidade se tornam fatores importantes a serem considerados. Reusabilidade é o aspecto da re-presentação de quão bem mantido seus serviços e sua segurança estão. Um serviço
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 inte-rações entre padrões de negócio, suplemento da cadeia de gerenciamento, gerencia-mento 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 signifi-cativamente 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
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últi-plos 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 dis-poní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 corpora-tivas 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 tecno-logias existentes com novas tecnotecno-logias. Desde que são baseados no conceito de
’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 sem-pre 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 ma-nuais 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.
Para que serviços web sejam usados com sucesso, seus padrões devem ser am-plamente 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 indepen-dente 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
Lan-guage 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 ser-viç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 es-tabelecimento de uma linguagem comum de marcação seja importante, por si só não é suficiente para uma comunicação ideal entre as duas partes (especial-mente, os provedores de serviços e requisitantes de serviço). Para uma comu-nicaçã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
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 especifi-caçã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, requisi-tantes 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 prove-dores podem registrar suas especificações de serviços e onde requisitantes sai-bam 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 prove-dores 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 ser-viç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 aprofun-dado, 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
ser-viços
A figura 14 ilustra a comunicação de um serviço com outro serviço, sendo neces-sário um intermediário para controlar as requisições e respostas trocadas entre ambos os serviços.
