18

2.2 MODELOS DE COMPUTAO DISTRIBUDAOs modelos apresentados a seguir podem ser tomados como base para o desenvolvimento de aplicaes distribudas. lgico que o modelo a ser escolhido depende do objetivo da aplicao a ser desenvolvida.

2.2.1 Chamada de procedimento remoto - Remote Procedure Call (RPC)A comunicao entre um componente e outro em um sistema distribudo usando a tcnica de RPC proporciona uma abordagem estruturada de alto nvel [6]. Por usar a arquitetura cliente/servidor com base, RPC permite que um processo que esteja em execuo em um computador cliente chame um procedimento que esteja em execuo em outro computador servidor [5], onde o usurio no sabe se o procedimento est sendo executado por seu computador ou por outro computador. A execuo desse procedimento sempre ocorre no servidor, e o resultado ento 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 invocao contm os parmetros do procedimento; j a mensagem de resposta contm os resultados da execuo do procedimento. J do lado do servidor, um processo permanece aguardando at chegar uma requisio e, quando essa requisio chega, seus parmetros so extrados e processados, gerando o resultado, que enviado na mensagem de resposta. Aps isso, o servidor volta a esperar uma requisio. Essa interao entre cliente e servidor ilustrada na gura 1.

19

Figura 1: Passos em uma comunicao cliente e servidor RPC A chamada de procedimento remoto introduz o conceito de stub, que o componente da aplicao servidora responsvel pela identicao do endereo da aplicao cliente, para empacotar informaes do mtodo cliente. Para emitir uma chamada de procedimento remoto, o processo cliente faz uma chamada ao procedimento no stub do cliente, passando os parmetros 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 transmisso via rede. Ao receber a mensagem do stub do cliente, o sistema operacional do servidor transmite a mensagem ao stub do servidor, ento a mensagem desmontada e o stub do servidor envia os parmetros ao procedimento local apropriado. Quando o procedimento for concludo, o stub do servidor monta o resultado e o envia de volta ao cliente. Por m, o stub do cliente desmonta o resultado, notica o processo e passa o resultado para ele [6].

As vantagens de se usar RPC que essa tcnica oculta os detalhes de soquetes, uma abstrao computacional que mapeia diretamente uma porta de transporte (TCP ou UDP) e mais um endereo de rede, do ponto de vista dos programadores de aplicaes, e ainda possui ligao dinmica com as portas dos servidores [6].

Existem diversas complicaes associadas chamada de procedimento remoto. Ela pode executar sobre protocolos TCP ou UDP, o que signica que implementaes diferentes podem oferecer nveis variveis de conabilidade. Implementao de cha-

20

mada de procedimento remoto est diretamente relacionada com o tipo de sistema de arquivos de rede, onde cada implementao pode oferecer um nvel diferente de segurana.

2.2.2 Invocao de mtodo remoto - Remote Method Invocation (RMI)Em sistemas distribudos, outra forma de comunicao entre componentes de uma rede usando a tcnica de invocao de mtodo remoto que, assim como o RPC, usa a arquitetura cliente/servidor como base. Tome duas aplicaes distintas onde estas aplicaes so construdas utilizando linguagens orientadas a objeto. A aplicao que prover o mtodo a ser utilizado chamada de aplicao servidora e a aplicao que ir fazer uso deste mtodo chamada de aplicao cliente. A aplicao servidora ir habilitar um determinado mtodo em seu corpo a m de este poder ser invocado a partir da aplicao cliente, seja esta local ou remota [6]. Trs camadas distintas de software caracterizam a arquitetura de invocao a mtodo remoto [5]: a camada de stub/esqueleto, a camada remota de referncia e a camada de transporte.

A camada de stub/skeleton usa o stub para empacotar informaes do mtodo cliente. E o skeleton, que o componente da aplicao cliente, usado para a identicao do endereo da aplicao que ir prover o mtodo desejado, para desempacotar as informaes do lado servidor. A camada remota de referncia onde o stub usa a serializao de objeto para criar sua mensagem montada, caracterstica que permite que objetos sejam codicados em correntes de bytes e transmitidos de um espao de endereamento para outro. A camada de transporte responsvel por pegar os dados enviados pela camada de referncia e separ-los em pacotes que sero transmitidos pela rede [6]. RMI tem seus mtodos denidos nas interfaces e tem seus mtodos implementados nas classes. Esse funcionamento do RMI pode ser visto na gura 2.

21

Figura 2: Ilustrao do funcionamento do RMI RMI pode ser utilizado da seguinte forma: imagine duas aplicaes que troquem informaes pela internet (via http), e que possam fazer uso da tcnica referida. Ao executar uma determinada tarefa, a aplicao cliente recorre a um mtodo; este, por sua vez, no se encontra em seu corpo. Tal mtodo chamado no corpo da aplicao e a aplicao ir procurar o referido mtodo em suas interfaces. Sendo encontrado, so passados para o mtodo os devidos parmetros e todo o trabalho de envio dos dados, computao efetuada e recebimento dos dados de resposta caro transparentes ao usurio.

Tal tecnologia muito utilizada para a distribuio de poder computacional a aplicaes que executem tarefas especcas, como por exemplo, uma determinada aplicao de uma agncia de turismo. Esta ir precisar vericar reservas em hotis, passagens areas dentre outros. Ao invs do agente de turismo ter uma aplicao para cada tipo de negcio, o mesmo pode ter uma nica aplicao que faa uso de outras aplicaes especcas, fazendo valer-se do RMI para a troca e execuo das informaes pretendidas.

2.2.3 Computao distribuda Peer-to-peer (P2P)Em sistemas distribudos, um dos modelos de distribuio de recurso o modelo P2P que consiste em uma distribuio de processamento e requisio de informao em uma rede de computadores, onde todos os componentes isolados do sistema P2P, chamado de ns, executam ambas as tarefas de cliente e servidor, distribuindo as responsabilidades de processamento e informao para muitos computadores [6].

22

Tal modelo apresentado na gura 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 esto ligados a outros blocos formando uma rede maior ainda, centralizadas ou descentralizadas [6].

Figura 3: Sistema de distribuio de recurso P2P

Clientes enviam consultas a servidores que, por sua vez, acessam as bases de dados, onde todas as informaes cam armazenadas e respondem com uma informao. Aplicaes P2P so diferentes de aplicaes cliente/servidor [10]. Enquanto aplicaes cliente/servidor possuem funes denidas, nas aplicaes peer-to-peer todos os componentes tm a capacidade de enviar uma requisio e enviar uma resposta, podendo compartilhar recursos. A grande vantagem de aplicaes P2P que no necessrio nenhum administrador de rede [6], [5].

Um sistema distribudo P2P prope um modelo com as seguintes caractersticas: 1. Todos os ns so usurios de servios em potencial e so, ao mesmo tempo, provedores em potencial desses servios. 2. Todo n independente. 3. Os ns so dinmicos, podem existir e deixar de existir imprevisivelmente.

23

4. A capacidade de cada n altamente varivel. Aplicaes peer-to-peer centralizada versus aplicaes peer-to-peer descentralizadas Aplicaes P2P podem ser de duas formas: centralizadas e descentralizadas [6].

Uma aplicao P2P centralizada usa um sistema servidor central que se conecta a cada par. Em uma aplicao centralizada, de mensagens instantneas, quando um par quer falar com outro par, primeiramente precisa obter o endereo do par requisitado no servidor. Ento, o par requisitante se comunica com o par requisitado. Se um ou mais servidores centrais falharem, a rede inteira poder falhar [10].

J uma aplicao descentralizada, ou aplicao P2P pura, no tem um servidor. Em uma aplicao P2P pura de mensagens instantneas, quando o par quer se comunicar com outro, ele no precisa mais se comunicar com o servidor; em vez disso, o par requisitante descobre o par requisitado visto mecanismos de busca distribuda e envia a mensagem ao par requisitado, diretamente [6]. Buscas em tempo real podem ser lentas e aumentam o trfego da rede medida que consultas se propagam por ela. Aplicaes P2P puras so completamente descentralizadas. A centralizao melhora o desempenho de busca, mas torna a rede dependente de um servidor. Fazer transferncias 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 aplicao P2P [5]. Uma soluo para a descoberta de par pode ser os usurios, primeiramente, se juntarem rede especicando o seu endereo de rede. Sem conhecer pelo menos um par servidor da rede, um usurio no 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 endereo de rede do par, ou pares, que contm o alvo da busca; no encontrando, no envia resultado algum. Outra forma de executar a des-

24

coberta de um par um par enviar uma mensagem com critrios de busca aos pares conectados a ele.

Ento, esses pares propagam a busca por toda a rede de pares. Se um par particular puder atender a busca, passa a informao de volta a quem enviou a primeira mensagem. Ento, esse primeiro par se conecta diretamente com o par alvo e, assim, podem trocar informaes. O par que fez a consulta original pode se identicar somente quando se conectar diretamente com o par que tem a informao requisitada para, assim, poder iniciar a transferncia requisitada [10].

Figura 4: Descoberta de par em um modelo P2P centralizado

Na gura 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 informao, este ir buscar no ndice do servidor a m de receber como resposta o endereo do par que contm a informao em questo.

Figura 5: Descoberta de par em um modelo P2P descentralizado

25

Na gura 5 apresentada a forma que os pares tomam quando se juntam rede P2P. Estes esto diretamente conectados a todos os outros ns do sistema P2P. Em tal sistema para a requisio de informaes, a pesquisa direcionada a todos os ns. E todos estes que contiverem a informao em questo iro responder ao par requisitante com seu determinado endereo.

2.2.4 GridA utilizao de forma cooperativa e transparente de recursos distribudos geogracamente considerando-os como um nico e poderoso computador algo desejado h bastante tempo [7]. Grid uma proposta promissora para resolver as crescentes demandas da computao paralela e distribuda por transparncia, desempenho e capacidade computacional. A infra-estrutura de Grid deve prover de forma global e transparente os recursos para aplicaes 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 gura 6 ilustra a arquitetura bsica de um Grid.

Figura 6: Arquitetura bsica de um Grid

Caractersticas Existem trs aspectos que caracterizam Grids computacionais [5]:

26

1. Heterogeneidade: um Grid envolve uma multiplicidade de recursos que so heterogneos por natureza e que podem estar dispersos geogracamente; 2. Escalabilidade: um Grid pode crescer de poucos recursos para milhes; 3. Dinamicidade ou adaptabilidade: em um Grid a falha de um recurso a regra, e no a exceo.

Os gerenciadores de recursos ou aplicaes devem adaptar o seu comportamento dinamicamente a m de extrair o mximo de desempenho a partir dos recursos e servios disponveis [9]. De modo a facilitar a colaborao entre mltiplas organizaes, executando diversos recursos heterogneos autnomos, um nmero de princpios bsicos deve ser seguido no desenvolvimento do ambiente de Grid [8]: 1. No interferir na autonomia e administrao existentes; 2. No comprometer a segurana existente; 3. No precisar substituir o sistema operacional, os protocolos de rede ou os servios existentes; 4. Permitir que computadores remotos se juntem ou saiam do ambiente quando eles decidirem; 5. No impor paradigma de programao, linguagens, ferramentas ou bibliotecas que o usurio precise usar; 6. Disponibilizar uma infra-estrutura convel e tolerante a falhas sem um ponto nico de falhas; e 7. Fornecer suporte para componentes heterogneos.

Um ambiente de Grid ideal ir prover acesso aos recursos disponveis de forma homognea de tal modo que descontinuidades fsicas tais como diferenas entre plataformas, protocolos de rede e bordas administrativas se tornem completamente transparentes [8].

Esses ambientes so voltados para aplicaes onde existem caractersticas como sincronizao de processos, transferncia e armazenamento de grandes volumes de dados e interoperabilidade entre aplicaes heterogneas.

27

Arquitetura Grid possui uma arquitetura formada por quatro camadas sob a qual uma aplicao ser executada. O ponto central consiste dos protocolos de Recursos e Conectividade que facilitam o compartilhamento dos recursos individuais. Protocolos nestes nveis so projetados para que possam ser implementados no topo de vrios tipos de recursos denidos na camada de infra-estrutura e podem ser usados para construir um grande conjunto de servios globais e comportamentos especcos de aplicaes na camada Coletiva [6]. Essas camadas so mostradas na gura 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 ) - dene os protocolos bsicos de comunicao e autenticao exigida para transaes de rede especca para Grid. Os protocolos de comunicao permitem a troca de dados entre recursos da camada de infra-estrutura. Os protocolos de autenticao providenciam mecanismos de segurana com criptograa para vericar a identidade dos usurios e recursos. 3. Camada de recursos (Grid Resource layer ) - dene protocolos bem como APIs (Application Program Interface) e SDKs (Software Developers Kit). Estes protocolos so para negociaes seguras, inicializaes, monitoramento, controle, contabilidade e pagamento de operaes 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 aes atmicas atravs de colees distribudas. 4. Camada coletiva (Grid Collective layer ) contm protocolos e servios (APIs e SDKs) que no esto associados com nenhum recurso especco, mas, ao contrrio, so globais em natureza e capturam interaes entre colees de recursos. Compartilhamento de recursos O problema real e especco que est por trs do conceito de grid o compartilhamento de recursos de forma coordenada e a resoluo de problemas em organizaes virtuais e dinmicas. Organizao virtual um dos principais conceitos cuja implementao fundamental para a computao 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 disponvel sujeito s restries 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 dinmica das relaes de compartilhamento signica que so exigidos mecanismos de descoberta e caracterizao da natureza dos compartilhamentos que existem em um determinado ponto do tempo [5].

2.2.5 ClusterCluster pode ser denido 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 domnio administrativo [13]. Com isso, possvel realizar processamentos que at ento somente computadores de alta performance seriam capazes de fazer.

29

Caractersticas 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 acrscimo 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 responsvel, entre outras coisas, pela distribuio 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 atravs de um equipamento especco, ou seja, no depende apenas do software.

Para que exista, um cluster precisa de pelo menos dois computadores. Evidentemente, quanto mais computadores existirem no cluster, maiores sero os custos de implementao e manuteno. Isso no se deve apenas ao preo dos computadores, mas tambm pelos equipamentos (switches, cabos, hubs, no-breaks etc.). Mas, ainda assim, os custos costumam ser menores do que a aquisio/manuteno de computadores poderosos e, algumas vezes, o processamento at mais eciente (rpido) [6]. A gura 8 traz um exemplo de Cluster usando um servidor para controlar todo ele.

Aplicao de clusters Podem ser usados em aplicaes onde a demanda de processamento seja grande, como por exemplo, em aplicaes de previso meteorolgica, simulaes nanceiras, simulaes geomtricas, renderizao de efeitos especiais etc. [14].

30

Figura 8: Exemplo de Cluster controlado por um servidor Tipos de clusters 1. Cluster Beowulf : voltado para a computao paralela, com o objetivo de suprir a elevada capacidade de processamento em diversas reas cientcas, construindo sistemas computacionais poderosos e economicamente viveis. O sistema operacional Linux, onde um servidor responsvel pelo controle de todo o cluster, conhecido com Front-End, distribuindo as tarefas e processamento. O cluster Beowulf permite a construo de sistemas de processamento que podem atingir bilhes de instrues de ponto utuante executadas por segundo [6]. 2. Cluster para Alta Disponibilidade: a alta disponibilidade se refere a sistemas que praticamente no param de funcionar. So usados geralmente em banco de dados, web sites, e-business, dentre outros. 3. Cluster para Balanceamento de Cargas: balanceamento de carga se refere distribuio equilibrada de processamento, integrando seus ns para que todas as requisies vindas dos clientes sejam distribudas de maneira equilibrada ou balanceada entre eles [5]. 4. Cluster Combo: combina as caractersticas dos cluters de Alta Disponibilidade e de Balanceamento de Cargas, visando a uma soluo de alta performance aliada possibilidade da no existncia de falhas crticas. 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 no precisar de aplicaes e recursos de softwares voltados ao cluster. muito utilizado em universidades em seus projetos e pesquisas.

31

2.2.6 CORBACORBA uma arquitetura que estabelece e simplica a troca de dados entre sistemas distribudos heterogneos de forma transparente, no importando em qual linguagem de programao foi desenvolvida, nem o local onde est ou em qual plataforma ou sistema operacional esteja sendo executada.

O paradigma CORBA uma combinao de duas metodologias existentes. A primeira delas a computao cliente-servidor distribuda e a segunda a programao orientada a objetos, onde um importante conceito deve ser entendido, o conceito de objetos. Para efeito de conhecimento, objetos so instncias de classes, e essas classes denem o comportamento dos objetos atravs de mtodos e atributos. Um objeto capaz de armazenar estados atravs de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos que sero acessadas pelo cliente [6]. A gura 9 descreve uma viso geral de CORBA.

Figura 9: Viso Geral de CORBA

Interface Denition Language (IDL) Descreve uma classe chamada interface que contm as implementaes dos mtodos a serem requisitados. Essa descrio de interface especica o formato das chamadas das operaes e tambm especica os parmetros de entrada e sada necessrios para que a operao seja executada.

Um exemplo do uso da IDL seria fornecer um mtodo que retornasse o nome de um determinado usurio passando como parmetro o seu respectivo cdigo. Nessa

32

classe, existiria um mtodo que teria como assinatura, ou seja, os parmetros, o cdigo a ser localizado. Uma vez localizado o cdigo, o que restaria seria o mtodo retornar o nome do usurio relacionado ao cdigo encontrado. Object Request Broker (ORB) A comunicao entre cliente e servidor feita pelo ORB. Ele faz o intermdio entre cliente e objeto, permitindo que os objetos requisitados pelos clientes ao servidor faam e recebam requisies de mtodos de forma transparente em um ambiente distribudo e heterogneo. responsvel pela localizao do objeto a qual se destina uma determinada requisio, como tambm, pelo envio dos parmetros da requisio no formato aceito pelo objeto em questo, e responsvel pela entrega da resposta do objeto chamado, ao cliente, como pode ser visto na gura 10.

Figura 10: Requisio de um cliente

O ORB permite o acesso distribudo s implementaes de objetos atravs do repositrio de interfaces, onde ele coloca disposio as interfaces pblicas dos objetos especicados na IDL [6]. Invocao de um objeto Um cliente acessa um objeto atravs da referncia deste objeto e da requisio de operaes executadas pelo mesmo. Como o cliente precisa ter contato apenas com a interface do objeto, a estrutura interna deste se mantm transparente. A transferncia de controle de dados do cliente para o objeto e, em seguida, o retorno para o cliente, de responsabilidade do ORB. Se a invocao no for realizada perfeitamente, o

33

ORB informa ao cliente que ocorreu uma exceo. Os clientes de um objeto podem fazer a invocao utilizando a tcnica de stub, geradas na compilao da descrio de interface do objeto, ou um conjunto de rotinas para invocao dinmica de objetos que podem ser utilizado [6]. Interface de invocao esttica (Static Interface Invocation - SII) Para acessar uma operao sobre um objeto, o cliente precisa chamar - e estar estaticamente ligado ao stub correspondente. A interface stub conduz o ORB direto para o domnio de programao da aplicao: o cliente interage com objetos servidores chamando suas operaes como se houvesse chamado operaes de objetos locais. Quando um desenvolvedor escreve seu cdigo, ele determina quais stubs cada cliente contm, fazendo com que essa interface no possa acessar novos tipos de objetos adicionados futuramente ao sistema [6]. Interface de invocao dinmica (Dynamic Interface Invocation - DII) A interface dinmica necessria quando a interface do objeto no pode ser conhecida a tempo de compilao. Em uma invocao dinmica, o cliente especica, atravs da DII, o objeto ao qual se destina a requisio, a operao solicitada e os parmetros da operao atravs de uma seqncia de chamadas de rotinas de requisio. Como as implementaes de objeto no conseguem detectar se uma determinada invocao chegou ao ORB, via invocao de interface esttica ou invocao de interface dinmica, o cliente ca inteiramente responsvel pela escolha. O ORB ainda faz todo o trabalho, fazendo com que a requisio chegue de forma transparente para o objeto [6]. Interface dinmica de esqueleto (Dynamic Skeketib Interface - DSI) Na DSI, o receptor sabe que a requisio vem de um skeleton dinmico ou esttico, de forma transparente, ao contrrio do que acontece na interface de invocao dinmica. Ao invs de ser acessada atravs de um skeleton, que especco para uma operao particular, uma implementao de objetos alcanada atravs de uma interface que prov acesso aos nomes das operaes e parmetros de maneira anloga interface de invocao dinmica do lado do cliente. Os skeletons podem ser

34

invocados atravs de clientes stubs e atravs de interface de invocao dinmica. Nos dois modos de invocao o resultado obtido ser o mesmo [6]. Adaptador de objeto Uma implementao de objetos acessa as funes do ORB atravs do adaptador de objetos. Cabe a ele fazer a ativao e desativao de implementaes de objetos, manter o registro das implementaes, promover a requisio de mtodos e garantir a segurana da interao entre os elementos envolvidos na requisio da operao. A estrutura interna de um adaptador de objetos depende basicamente dos servios disponibilizados pelo ncleo ORB e dos outros requisitos das implementaes de objeto s quais se destina [6]. Repositrio de implementaes Local onde cam armazenadas informaes que permitem ao ORB localizar e ativar implementaes dos objetos. Atravs de operaes feitas no repositrio de implementaes possvel a instalao de implementaes e polticas de controle relacionadas ativao e execuo de implementaes de objetos. Persistncia Ao contrrio dos objetos tradicionais, os objetos em sistemas distribudos possuem uma caracterstica de dualidade: um estado dinmico, tipicamente alocado em memria voltil, e um estado persistente que no pode ser destrudo aps o encerramento do programa que os criou e que pode ser usado para reconstruir o estado dinmico, devendo ser armazenado em memria no voltil. A arquitetura CORBA, para prover a persistncia, dene o Persistent POS como sendo responsvel 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. Servios de Persistncia de Dados (Persistent Data Services); 4. Base de Dados (Datastores).

35

2.2.7 Servio web (Web Service)Um servio web uma soluo utilizada para a integrao de sistemas onde softwares ou hardwares podem enviar ou receber mensagens. Um servio web deve fornecer uma infra-estrutura para se ter uma forma mais rica e mais estruturada de interoperabilidade entre clientes e servidores. A representao de dados externa e o empacotamento das mensagens trocadas entre clientes e servios web so feitos em XML (Extensible Markup Language), o que resulta em um grupo de tipo de dados bem vasto [6].

A gura 11 ilustra o funcionamento bsico de um servio web.

Figura 11: Funcionamento bsico de um servio web.

As denies comentadas a seguir so de suma importncia para o entendimento de Web Services, de sua arquitetura e troca de dados entre cliente e servidor. Arquitetura So componentes da arquitetura de um servio web: 1. SOAP (Simple Object Access Protocol): um protocolo que permite a troca de informaes em ambientes distribudos. Contm as chamadas e retornos dos Web Services encapsuladas em sua estrutura. 2. WSDL (Web Service Description Language): a linguagem de descrio de Web Services, onde esto descritas as informaes necessrias para invocao dos Web Services, como a localizao, operaes disponveis e assinaturas de funes do mesmo.

36

A gura 12 mostra um exemplo de wsdl, com um mtodo chamado transferncia.

Figura 12: Exemplo de um WSDL

3. UDDI (Universal Description, Discovery and Integration): Uma implementao de UDDI equivale a um Web Service Registry, disponibilizando mecanismos para busca e publicao de Web Services. Ele gerencia informao sobre provedores, implementaes e metadados de servios. Alm disso, contm informaes sobre os servios e funcionalidades que os servios web oferecem, permitindo uma associao desses servios com suas informaes tcnicas.

37

Fucionamento de servios web Um servio 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 servios (operaes, mensagens, parmetros etc) so descritos na WSDL. O processo de publicao/pesquisa/descoberta utiliza o UDDI. Os Web Services podem ser ativados por demanda ou podem funcionar continuamente.

As interaes entre provedor do servio (service provider ), cliente do servio (service requestor ) e servidor de registro (service registry ) do base arquitetura dos Web Services. Elas so responsveis pela publicao, busca e execuo de operaes. A gura 13 ilustra um exemplo dessa interao.

Figura 13: Exemplo de interao entre entidades

O cliente acessa o servio, atravs do provedor de servio, que representa a plataforma onde o Web Service est hospedado. J o cliente do servio, nada mais do que a aplicao que est fazendo a chamada ou interao com o Web Service. E, nalmente, o servidor de registro a representao dos servidores de registro e busca de um Web Service.

Resumidamente, uma denio para a tcnica do funcionamento do Web Sevice seria: um cliente acessa o servio 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 padro XML.

2.3 TABELAS COMPARATIVASCom base nos estudos realizados, foram construdas tabelas comparativas, onde so feitas algumas comparaes entre os modelos estudados, levando em considerao a rea de aplicao, tecnologias usadas para sua implementao, vantagens e desvantagens.

2.3.1 CORBA vs servio webCompara-se CORBA com Web Service, pois ambas so independentes de arquitetura, linguagem de programao e sistema operacional, o que oferece portabilidade para ambas. Caractersticas como protocolo, descrio de interfaces, descoberta de servios, desvantagens e vantagens so apresentadas na tabela 2.3.1. Item Protocolo Descrio das Interfaces Descoberta de Servio Desvantagens Servio web SOAP, http, XML SCHEMA WSDL UDDI Dependncia de disponibilidade do servio Vantagens Independncia de linguagem, sistemas operacionais, hardware, plataforma; troca de grandes quantidades de informaes por XML. CORBA IIOP, GIOP IDL Repositrio de Interfaces Alto custo de implementao, velocidade relativamente baixo Independncia de linguagem, sistemas operacionais,hardware, plataforma; Acesso a implementaes de objetos.

Tabela 2.3.1 Comparao entre Web service e CORBA.

2.3.2 RPC vs RMICompara-se RPC e RMI, pois ambos implementam possuem a arquitetura cliente/servidor como base. A tabela 2.3.2 traz essas comparaes.

39

Item Caractersticas

RPC Execuo de procedimentos e funes remotos, com passagem de parmetros. Ligao dinmica com portas do servidor; Oculta detalhes de soquete ao programador. No suporta variveis globais, Implementaes diferentes podem oferecer nveis variveis de conabilidade.

Vantagens Desvantagens

RMI Execuo de mtodos remotos com passagem de objetos como parmetros entre mtodos remotos. Mtodos denidos na interface, Objetos remotos implementam uma ou mais interfaces. Dependente de uma linguagem orientada a objeto para ser possvel sua utilizao.

Tabela 2.3.2 comparao entre RPC e RMI.

2.3.3 Grid vs Cluster vs P2PCompara-se Grid, Cluster e P2P, pois estes esto relacionados com o uso de recursos ociosos geogracamente dispersos. Item Caractersticas Administrao do modelo Vantagens Grid Heterogeneidade; Escabilidade; Adaptabilidade. Global Evoluo do Cluster. Cluster Sistema operacional deve ser o mesmo Local Maior poder computacional; Distribuio de processamento. Quanto mais computadores maiores os gastos com manuteno; Peer-to-peer Protocolo de compartilhamento de arquivo Global Conabilidade, caso ocorra erro em algum peer, o sistema no ir parar totalmente. Vulnerabilidade e dependncia de uma aplicao intermediria.

Desvantagens

Redes com baixas velocidades comprometem o desempenho do grid.

Tabela 2.3.3: comparao entre grid, cluster e peer-to-peer.