Juliano Alberto Batista Gonalves 0200140 / 8 semestre

DESENVOLVIMENTO DE UMA AGENDA DISTRIBUDA UTILIZANDO JAVA RMI

Jaguarina 2005

2

Juliano Alberto Batista Gonalves 0200140 / 8 semestre

DESENVOLVIMENTO DE UMA AGENDA DISTRIBUDA UTILIZANDO JAVA RMI

Monografia apresentada disciplina Trabalho de Graduao III, do curso de Cincia da Computao da Faculdade de Jaguarina, sob orientao do Prof. Ms. Peter Jandl Junior, como exigncia parcial para concluso do curso de graduao.

Jaguarina 2005

3

GONALVES, Juliano Alberto Batista. Desenvolvimento de uma agenda distribuda utilizando Java RMI. Monografia defendida e aprovada na Faculdade de Jaguarina FAJ em 15 de Dezembro de 2005 pela banca examinadora constituda pelos professores:

______________________________________ Prof. Ms. Peter Jandl Junior FAJ orientador

______________________________________ Prof. Ms. Fbio A. Gaion Casotti

______________________________________ Prof. Slvio Petroli Neto

4

AGRADECIMENTOSAgradeo primeiramente a Deus, sem o qual nada possvel. Gostaria tambm de agradecer a todas as pessoas que, direta ou indiretamente, contriburam para que este trabalho fosse concludo, em especial: a meus pais e toda a minha famlia, os quais me incentivaram e tornaram possvel que eu conclusse este curso. ao Professor e grande Mestre Peter Jandl Junior, que me orientou e me ajudou, no s durante toda a realizao deste trabalho, mas tambm durante o curso, e sendo um grande disseminador da tecnologia Java, me despertou o gosto por esta linguagem. a Vanessa Lixandro, que foi paciente e compreensiva quando eu precisava me ausentar para dar continuidade a este trabalho. a todos os professores e funcionrios da Faculdade de Jaguarina, os quais contriburam em mais este importante passo de minha vida.

5

GONALVES, Juliano Alberto Batista. Desenvolvimento de uma agenda distribuda utilizando Java RMI. 2005. Monografia (Bacharelado em Cincia da Computao) Curso de Cincia da Computao da Faculdade de Jaguarina, Jaguarina.

RESUMOAplicaes distribudas vm evoluindo de forma natural medida que a computao e o mundo evoluem. Dentre os fatores que levam a esta evoluo, talvez um dos mais importantes seja o fato de algumas aplicaes serem inerentemente distribudas. Nestes casos, tais aplicaes precisam ser projetadas e implementadas de maneira distribuda e, de preferncia, de tal forma que sejam de fcil implementao e manuteno, permitindo o mximo reaproveitamento do cdigo escrito. Atualmente, o paradigma de programao que oferece tais caractersticas o modelo de programao orientada a objetos. Problemas moldados com base em tal paradigma ficam mais prximos da realidade, tornando sua compreenso mais simples para os desenvolvedores. A linguagem de programao Java um exemplo de linguagem orientada a objetos. Incorporada a esta linguagem est a tecnologia Java RMI, que permite que objetos escritos na linguagem Java se comuniquem, invocando mtodos uns nos outros, de forma transparente para o programador. Atravs desta tecnologia se torna possvel o desenvolvimento de aplicaes distribudas de forma simples, aproveitando-se as caractersticas da orientao a objetos.

6

SUMRIOLISTA DE SIGLAS................................................................................................................. 9 LISTA DE EXEMPLOS ........................................................................................................ 10 1 INTRODUO ................................................................................................................. 11 2 SISTEMAS DISTRIBUDOS ............................................................................................. 13 2.1 Modelos de sistemas distribudos .................................................................................. 14 2.1.1 Modelo cliente/servidor............................................................................................... 14 2.1.2 Remote Procedure Call (RPC).................................................................................... 15 2.1.3 Middleware ................................................................................................................. 15 3 JAVA REMOTE METHOD INVOCATION ......................................................................... 17 3.1 API do Java RMI............................................................................................................ 18 3.2 Criando uma aplicao que utiliza o Java RMI .............................................................. 19 3.2.1 Definio da interface remota..................................................................................... 20 3.2.2 Implementao do objeto remoto ............................................................................... 20 3.2.3 Registro do objeto no servio de nomes..................................................................... 21 3.2.4 Criao da aplicao cliente....................................................................................... 22 4 AGENDA DISTRIBUDA ................................................................................................... 23 4.1 Metodologia de desenvolvimento da agenda distribuda................................................ 24 5 RESULTADOS OBTIDOS ................................................................................................ 28 6 CONCLUSES ................................................................................................................ 34 7 REFERNCIAS BIBLIOGRFICAS.................................................................................. 35

9

LISTA DE SIGLASAPI CORBA HTTP IDL IP J2SDK Java RMI JVM ORB RMI RPC UML Application Programming Interface Common Object Request Broker Architecture HyperText Transfer Protocol Interface Definition Language Internet Protocol Java 2 Software Development Kit Java Remote Method Invocation Java Virtual Machine Object Request Broker Remote Method Invocation Remote Procedure CallUnified Modeling Language

10

LISTA DE EXEMPLOSExemplo 1 Interface IHelloRMI ......................................................................................... 20 Exemplo 2 Classe HelloRMIImpl....................................................................................... 21 Exemplo 3 Classe HelloRMIServer................................................................................... 21 Exemplo 4 Classe HelloRMIClient .................................................................................... 22 Exemplo 5 Interface IServidor........................................................................................... 28 Exemplo 6 Interface IAgenda............................................................................................ 29 Exemplo 7 Classe ServidorImpl ........................................................................................ 30 Exemplo 8 Mtodo que efetua o login de uma agenda no servidor................................... 30 Exemplo 9 Mtodo que agenda um compromisso coletivo ............................................... 32

11

1 INTRODUOEm ambientes corporativos o agendamento de compromissos e reunies um processo relativamente fcil quando o nmero de pessoas envolvidas pequeno, o que pode ser feito sem maiores problemas atravs da troca de alguns e-mails ou at de um simples telefonema. Mas nos casos em que o nmero de pessoas grande, envolvendo funcionrios de diferentes departamentos ou at de vrias unidades da empresa, ou trabalhando em perodos diferentes, o processo de agendar uma reunio desta forma se torna uma tarefa complicada e tediosa, pois nem sempre as pessoas convocadas esto livres no horrio desejado, sendo difcil determinar um horrio ideal para a reunio, ou seja, aquele que no interfere nos compromissos dos funcionrios envolvidos. Nesses casos, h a necessidade de uma aplicao de agendamento, que opere em uma rede de computadores (Kurose et al., 2003; Tanenbaum, 2003), que seja capaz no somente de gerenciar os compromissos individuais, mas tambm de se encarregar dos eventos coletivos, permitindo que os horrios livres sejam consultados e que, dado um grupo de usurios, seja determinado automaticamente o melhor horrio para a convocao de uma reunio, fazendo com que o pr-agendamento de reunies seja feito de forma rpida e eficiente. Dado um grupo de trabalho, que usa uma aplicao de agendamento distribuda, possvel determinar automaticamente horrios livres e efetivar o pr-agendamento de reunies, reduzindo a taxa de mensagens e aumentando a rapidez deste processo. Os objetivos deste trabalho foram:

Demonstrar a convenincia e as caractersticas das aplicaes distribudas (Coulouris et al., 2001; Eckel, 2004A; Sun Microsystems, 2004B;); Relevar o uso da plataforma Java (Deitel, 2003; Eckel, 2004B; Horstmann et al., 2000; Jandl, 2002); Justificar a escolha da tecnologia Java RMI (Deitel, 2003; Horstmann et al., 2000; Jandl, 2003; Sun Microsystems, 2004B); Explicar os passos para a criao de aplicaes distribudas com Java RMI; Evidenciar as vantagens de uma agenda distribuda; Projetar e implementar uma agenda distribuda que utilize a tecnologia de distribuio de objetos Java RMI.

12

Espera-se com isso evidenciar as vantagens de uma agenda distribuda.

13

2 SISTEMAS DISTRIBUDOSSegundo Tanembaum (1995) um sistema distribudo uma coleo de computadores independentes que do ao usurio do sistema a impresso de ser um nico computador. Imaginemos uma casa com um computador instalado na sala e outro no quarto, o qual possui uma impressora conectada a ele. O computador da sala imprime documentos na impressora do computador do quarto atravs de uma rede. Temos neste caso um exemplo de um simples sistema distribudo. Outro exemplo de um sistema distribudo a Internet, que formada por milhes de computadores ao redor do mundo e permite que seus usurios se comuniquem e compartilhem recursos, como processamento, por exemplo. Podemos tambm citar como exemplo de um sistema distribudo uma cadeia de supermercados onde cada filial controla o estoque de seus produtos e suas vendas, e que podem ter seus estoques e vendas consultadas pela matriz. Os sistemas distribudos vm sendo desenvolvidos e aperfeioados ao longo de anos. Segundo Tanembaum (1995), tal desenvolvimento impulsionado principalmente pelos seguintes fatores:

Economia: sistemas distribudos permitem o compartilhamento de recursos, como impressoras. Alm disso, possvel se construir um computador com alto poder de processamento usando-se vrios computadores de pequeno porte a um preo mais baixo do que o de um computador de grande porte;

Desempenho: um computador formado por vrios computadores de pequeno porte pode alcanar um desempenho mais alto do que um computador de grande porte; Distribuio inerente: algumas aplicaes so distribudas por natureza, como a cadeia de supermercados citada anteriormente; Confiabilidade: um sistema distribudo bem projetado geralmente no apresenta um nico ponto de falha, o que permite que ele continue em operao embora com menor desempenho mesmo que parte do sistema falhe;

Escalabilidade: sistemas distribudos permitem que poder computacional seja adicionado de forma incremental; Compartilhamento de dados: sistemas distribudos permitem que dados sejam compartilhados entre computadores, o que evita a duplicao desnecessria de arquivos;

Comunicao: um dos principais benefcios trazidos pelos sistemas distribudos foi a facilidade de comunicao, atravs de correio eletrnico, mensagens instantneas e, mais recentemente, voz sobre IP.

14

Por outro lado o desenvolvimento de sistemas distribudos ainda enfrenta algumas barreias, tais como:

Software: para sistemas distribudos de difcil projeto e implementao; Rede: o principal gargalo e o principal ponto de falha em um sistema distribudo; Segurana: o compartilhamento de dados pode trazer problemas, como o acesso no autorizado.

2.1 Modelos de sistemas distribudosSistemas distribudos envolvem aspectos de hardware e software. O que determina a arquitetura de hardware como os componentes so organizados e os aspectos relacionados ao modo como os eles se interligam, se por um barramento ou por um cabo de fibra tica, por exemplo. J a arquitetura de software definida pelo modo como os componentes de software trocam mensagens. Quanto ao software, os sistemas distribudos possuem diversos modelos, sendo os mais comuns o modelo cliente-servidor, o modelo Remote Procedure Call (RPC) e o modelo Middleware.

2.1.1 Modelo cliente/servidorEsta arquitetura historicamente a mais importante e continua sendo a mais amplamente empregada (Coulouris et al., 2001). Neste modelo so definidos basicamente dois papis: o de cliente e o de servidor. O servidor administra um conjunto de recursos que so disponibilizados ao cliente na forma de servios. O cliente acessa os servios disponveis utilizando um mecanismo baseado em pedidos e respostas. A comunicao se d por meio de um protocolo comum ao cliente a ao servidor. Geralmente a comunicao iniciada pelo cliente, que tendo informaes sobre a localizao do servidor e sobre o servio desejado, faz uma requisio por tal servio. O servidor, por sua vez, recebe a requisio, e a processa de acordo com o servio solicitado. Em seguida o servidor retorna a resposta com o resultado ao cliente. Este modelo tem a vantagem de ser simples. Como exemplo, podemos citar um acesso a uma pgina da Internet, que utiliza o protocolo HyperText Transfer Protocol (HTTP) para a transferncia de dados entre cliente e servidor. O cliente um navegador de Internet rodando em um computador solicita a pgina ao servidor um servio de HTTP rodando em outro computador passando o endereo da pgina desejada. O servidor processa a requisio, localiza a pgina e a retorna ao cliente.

15

2.1.2 Remote Procedure Call (RPC)Embora o modelo cliente-servidor seja simples e eficiente, ele se resume a operaes de entrada e sada, o que faz com que um sistema distribudo fuja do seu objetivo de se parecer com um sistema centralizado, j que este baseado em muito mais do que a simples entrada e sada de dados. Pensando-se nisso, foi criado, em 1984 um novo modelo de sistema distribudo baseado na simples idia de permitir que um programa chame procedimentos localizados em outro computador (Jandl, 2003). Desta forma, um programa localizado no computador X chama um procedimento localizado no computador Y, passando parmetros, se necessrio. O computador Y recebe a chamada, interrompe o processo corrente e processa a chamada de X. Aps o processamento, Y retorna o resultado a X e retoma o processo que estava sendo executado. Assim, o processamento feito no computador onde reside o procedimento. Tudo isso ocorre de forma transparente ao programador. Sob certos aspectos, o Java Remote Method Invocation (Java RMI), se assemelha a este modelo.

2.1.3 MiddlewareEsta arquitetura semelhante ao RPC, mas se difere deste por haver uma camada entre cliente e servidor, fazendo com que a comunicao no mais se d diretamente entre eles, mas sim atravs desta camada intermediria. Isso permite a interoperabilidade de sistemas escritos em diferentes linguagens rodando em diferentes sistemas operacionais. Esta tecnologia se comunica sobre protocolos de Internet e abstrai as camadas de rede subjacentes, bem como as diferenas entre sistemas operacionais. Isso torna seu uso transparente ao programador, que trabalha como se estivesse programando chamadas a mtodos locais. A chamada de mtodos feita pelo cliente atravs de interfaces, que ocultam os detalhes da implementao do servidor. Essas caractersticas fazem com que o modelo middleware seja o usado na distribuio de objetos. Desta forma, possvel utilizar as facilidades da programao orientada a objetos no projeto de sistemas distribudos. No modelo middleware os objetos clientes no chamam mtodos diretamente nos objetos servidores. As chamadas so feitas a objetos especiais chamados stubs, que residem no lado do cliente e agem como um proxie da interface do objeto remoto. Tais objetos recebem a chamada localmente, empacotam seus parmetros e os repassam ao objeto remoto. Isso faz com que seja desnecessria a instncia local de objetos remotos.

16

O padro mais conhecido de middleware o CORBA (Common Object Request Broker Architecture). Tal padro permite a comunicao entre objetos independentemente da linguagem de programao e da plataforma de software e hardware. A definio das interfaces se d por meio da linguagem IDL (Interface Definition Language). Sendo assim, um programa escrito em Java pode invocar mtodos remotamente em um programa escrito em C++ atravs do CORBA, j que ambas as linguagens suportam a IDL. O componente intermedirio que permite a invocao de mtodos remotos o Object Request Broker (ORB). Ele responsvel por interceptar a chamada a um mtodo, fazer o mapeamento de tipos dos parmetros da linguagem do objeto cliente para os tipos da linguagem do objeto servidor e repassar os parmetros a este objeto. O CORBA oferece, alm da arquitetura necessria invocao de mtodos remotos, uma srie de servios que facilitam a sua implementao, tais como servio de nomes, servio de segurana, servio de transao, entre outros.

17

3 JAVA REMOTE METHOD INVOCATIONO Java Remote Method Invocation (Java RMI) uma arquitetura de distribuio de objetos baseada no modelo middleware projetada para a linguagem Java. Diferentemente do CORBA, que permite a interoperabilidade entre objetos escritos em diferentes linguagens, o Java RMI permite a invocao de mtodos remotos apenas entre objetos escritos na linguagem Java. Foi desenvolvida para permitir que um objeto Java invoque mtodos de objetos Java residentes em outra JVM (Java Virtual Machine) como se tais objetos estivessem na mesma JVM (Jandl, 2003). Isso feito de forma transparente, fazendo com que uma chamada a um mtodo remoto tenha a mesma sintaxe de uma chamada local. Aplicaes que usam Java RMI consistem de um programa denominado servidor, que instancia objetos e os registra como remotos no servio de nomes; e clientes, que pesquisam no servio de nomes do RMI por objetos remotos e obtm referncias a estes objetos atravs de suas interfaces. Assim como no CORBA, os objetos remotos so manipulados atravs de suas interfaces. A diferena que no Java RMI no h a necessidade de uma linguagem de definio de interfaces, como a IDL. As interfaces so escritas utilizando-se a prpria linguagem Java, seguindo-se a mesma sintaxe utilizada na definio de interfaces locais. Das interfaces dos objetos remotos so criados no lado cliente os stubs, que so classes que atuaro como proxies, ou seja, representantes do objeto servidor no lado cliente. O cliente usar estes proxies quando quiser referenciar objetos remotos. O Java RMI utiliza a serializao de objetos para transferir parmetros para o servidor no momento em que o cliente invoca um mtodo remoto; e para transferir os resultados, quando necessrio, de volta ao cliente. Esta tcnica garante a integridade de objetos transferidos atravs da rede. O Java RMI formado por um conjunto de APIs (Application Programming Interface) que inclui todas as classes necessrias invocao de mtodos remotos, e um conjunto de ferramentas para executar o servio de nomes e a gerao de objetos proxie. Todos estes recursos so fornecidos com a distribuio padro do kit de desenvolvimento do Java (J2SDK).

18

Para que objetos remotos possam ser localizados, necessrio o servio de nomes, chamado Registry. Este servio registra objetos que podero ter seus mtodos invocados remotamente, associando cada objeto a um nome. Sabendo o endereo do host e o nome do objeto remoto, um programa cliente pode obter referncias a objetos e invocar seus mtodos remotamente. Cada computador deve ter o servio de nomes local ativo. Tal servio executado por um programa chamado rmiregistry, que acompanha as distribuies do Java. A Figura 1 mostra resumidamente o funcionamento do Java RMI.

Cliente

(3) RMI

Servidor

(2) lookup

(1) bind

Registro

Figura 1 Funcionamento do Java RMI Basicamente, o Java RMI funciona em trs etapas: 1. O servidor cria objetos remotos e os registra no rmiregistry (bind); 2. O cliente consulta o servio de nomes do Java RMI em busca de objetos remotos (lookup) e obtm do servidor um stub; 3. O cliente acessa a interface do objeto remoto atravs do stub e invoca os mtodos deste objeto (RMI). O Java RMI permite criar aplicaes distribudas robustas e seguras. Mas, por se basear no modelo middleware, oferece um desempenho abaixo do de outras tecnologias.

3.1 API do Java RMIO Java RMI oferece um conjunto de classes e interfaces necessrias invocao remota de mtodos. Tal conjunto conhecido como API (Application Programming Interface) e prov as classes utilizadas pelos clientes, servidores e pelo servio de nomes.

19

A classe RemoteObject, do pacote java.rmi.server, a superclasse dos objetos remotos, da qual derivam as principais classes do Java RMI (Jandl, 2003). A classe RemoteServer, do pacote java.rmi.server, uma classe abstrata que serve de base para as classes dos objetos que sero servidos remotamente. Desta classe deriva a classe UnicastRemoteObject, que utilizada na definio de objetos remotos. No pacote java.rmi, temos a interface Remote, da qual devem derivar todas as interfaces remotas. Esta interface uma interface de marcao, servindo apenas para indicar que uma determinada interface remota. O servio de nomes do Java RMI acessado pela classe Naming, do pacotejava.rmi. Esta classe fornece os mtodos para a consulta, incluso e remoo de objetos

no registro de nomes.

3.2 Criando uma aplicao que utiliza o Java RMIResumidamente, uma aplicao Java RMI formada por:

Uma interface remota; Um ou mais objetos remotos que implementam esta interface; O rmiregistry, ou Registro; Um ou mais clientes; Os stubs. Os passos para a criao e execuo de uma aplicao com Java RMI so: 1. Definir uma interface remota; 2. Implementar um objeto remoto; 3. Registrar o objeto remoto no servio de nomes; 4. Criar um objeto cliente. Para exemplificar os passos citados acima foi criada uma simples aplicao Java RMI.

A aplicao de exemplo formada pelos seguintes componentes:

A interface remota IHelloRMI, que define o mtodo remoto helloRMI; Pela classe HelloRMIImpl, que implementa a interface IHelloRMI e seu mtodo;

20

Pela classe HelloRMIServer, que instancia um objeto do tipo HelloRMIImpl e o registra no servio de nomes; E pela classe HelloRMIClient, que busca no registro de nomes por um objeto do tipo HelloRMIImpl e, atravs de sua interface remota, invoca o mtodo helloRMI.

As prximas sees explicam com mais detalhes o funcionamento de cada componente.

3.2.1 Definio da interface remotaTodo objeto remoto necessita de uma interface remota para que possa ser manipulado pelo cliente. Segundo Jandl (2003), uma interface remota deve seguir as seguintes regras:

Ser pblica; Ser derivada da interface java.rmi.Remote; Todos os seus mtodos devem lanar a exceo java.rmi.RemoteException. No Exemplo 1 tem-se a definio da interface da aplicao de exemplo. Esta interface

define o mtodo helloRMI(), que ser invocado por um cliente para retornar a cadeia de caracteres Hello RMI!.01 02 03 04 05 06 import java.rmi.Remote; import java.rmi.RemoteException; public interface IHelloRMI extends Remote { public String helloRMI() throws RemoteException; }

Exemplo 1 Interface IHelloRMI

3.2.2 Implementao do objeto remotoOs objetos que implementam uma interface remota so chamados de remotos ou servidores. Suas classes devem seguir os seguintes requisitos:

Ser pblicas; Implementar uma interface remota; Ser derivadas da classe java.rmi.server.UnicastRemoteObject; Seus construtores devem lanar a exceo java.rmi.RemoteException;

21

No Exemplo 2 tem-se o cdigo de um objeto remoto que implementa a interface criada no passo anterior.

01 02 03 04 05 06 07 08 09 10 11 12

import java.rmi.RemoteException; import java.rmi.server.UnicastRemoteObject; public class HelloRMIImpl extends UnicastRemoteObject implements IHelloRMI { public HelloRMIImpl() throws RemoteException { super(); } public String helloRMI() throws RemoteException{ return "Hello RMI!"; } }

Exemplo 2 Classe HelloRMIImpl Este objeto implementa o mtodo helloRMI(), que faz nada mais do que retornar uma cadeia de caracteres que forma a frase "Hello RMI!".

3.2.3 Registro do objeto no servio de nomesO cdigo exibido no Exemplo 3 instancia um objeto do tipo HelloRMIImpl e o registra no servio de nomes do Java RMI. Desta forma, este objeto fica disponvel para ter os mtodos definidos em sua interface remota invocados por objetos residentes em outros computadores.

01 import java.rmi.Naming; 02 03 public class HelloRMIServer { 04 public static void main(String args[]) { 05 try { 06 HelloRMIImpl helloRMI = new HelloRMIImpl(); 07 Naming.bind("hello1", helloRMI); 08 } catch (Exception e) { 09 e.printStackTrace(); 10 } 11 } 12 }

Exemplo 3 Classe HelloRMIServer O mtodo esttico Naming.bind("hello1", helloRMI) registra o objeto helloRMI no registry com o nome hello1.

22

3.2.4 Criao da aplicao clientePara que a aplicao cliente possa invocar mtodos em um objeto remoto, ela deve saber: o endereo do host no qual o objeto remoto foi registrado; e o nome com o qual o objeto foi registrado. Sabendo isso, a aplicao obtm uma referncia interface deste objeto. O Exemplo 4 mostra o cdigo do objeto cliente.

01 import java.rmi.Naming; 02 03 public class HelloRMIClient { 04 public static void main(String args[]) { 05 try { 06 IHelloRMI helloRMI = (IHelloRMI)Naming.lookup("rmi://"+ 07 "localhost/hello1"); 08 System.out.println(helloRMI.helloRMI()); 09 }catch(Exception e) { 10 System.out.println(Erro: " + e.getMessage()); 11 e.printStackTrace(); 12 } 13 } 14 }

Exemplo 4 Classe HelloRMIClient Na linha 06 a aplicao obtm uma referncia a um objeto do tipo IHelloRMI, que est registrado no host localhost com o nome hello1. Como o Registro do Java RMI armazena objetos de qualquer tipo, necessrio fazer a converso de Object paraIHelloRMI. Na linha 08 o programa imprime na tela a cadeia de caracteres retornada pelo

mtodo remoto helloRMI(). Note que a chamada ao mtodo remoto feita da mesma forma que a chamada feita a um mtodo de um objeto local.

23

4 AGENDA DISTRIBUDAPara demonstrar o uso de aplicaes distribudas e do Java RMI, projetamos uma agenda distribuda. Esta agenda uma aplicao que permite, alm de gerenciar compromissos pessoais, o gerenciamento de eventos em grupo. Um evento em grupo aquele que envolve duas ou mais pessoas, como por exemplo, uma reunio. No haver um servidor central que armazena as informaes de cada agenda, sendo que existiro cpias da agenda espalhadas por computadores na rede. No entanto haver um servidor no qual as agendas se registraro e faro buscas por outras agendas. Cada cpia pertencer a um usurio e armazenar, dentre outras informaes, os compromissos individuais, os compromissos coletivos e os contatos do usurio. Os contatos so os demais usurios da agenda, que podero compartilhar compromissos pessoais com outros usurios e agendar eventos coletivos envolvendo estes. O usurio poder pesquisar por contatos na rede e adicion-los sua lista. Quando um usurio desejar criar um evento coletivo, dever informar quais dos seus contatos participaro do evento, bem como a data e a hora do mesmo. A agenda ento, se encarregar de consultar a lista de compromissos dos contatos envolvidos para verificar se na data e horrio solicitados pelo usurio, todos os contatos estaro livres. Assim que um evento coletivo for criado, a agenda enviar um convite para cada contato participante. Quando um contato receber um convite, ele poder aceit-lo ou recuslo. A agenda remetente ser informada sobre a opo do usurio. Assim que todos os convites forem aceitos ou recusados, a agenda notificar o usurio remetente e solicitar a confirmao do evento. A aplicao, ento, acessar as agendas dos contatos envolvidos que aceitaram o convite e marcar o compromisso. Uma aplicao deste tipo apresenta diversas vantagens, pois agiliza o gerenciamento de compromissos envolvendo mais de uma pessoa. Suponhamos que uma determinada pessoa X deseje marcar uma reunio s 14:00 horas com as pessoas Y e Z, usando para isso o e-mail. A pessoa X comea enviando uma mensagem a Y e Z informando a hora da reunio. Imaginemos que Y esteja livre no horrio marcado, mas que Z tenha uma consulta mdica neste horrio. A pessoa Y responde o e-mail a X informando que poder participar da reunio s 14:00 horas. Mas Z responde dizendo que s 14:00 horas no ser possvel, e que voltar da consulta s 16:00 horas. A pessoa X, ento, envia outro e-mail a Y e Z mudando a reunio para as 16:00 horas. Mas desta vez Y responde dizendo que s 16:00 ele quem no poder participar do encontro, pois estar em outra reunio neste horrio.

24

Diante desta situao, X envia outro e-mail a Y e Z marcando um novo horrio, sem ter garantias de que ser um horrio livre para Y ou Z. Usando-se este mtodo, pode haver vrios ciclos de trocas de mensagens entre os envolvidos at que se chegue a um horrio livre comum a todos os participantes. No exemplo utilizou-se apenas trs pessoas, sendo que em situaes reais, poderia haver vrias, o que poderia aumentar em muito o nmero de mensagens trocadas entre elas. Agora, considerando-se que X, Y e Z estejam utilizando a agenda distribuda e que X deseje marcar a mesma reunio s 14:00 horas com Y e Z. X pode consultar a lista de compromissos de Y e Z para procurar um horrio livre. Desta forma, X fica sabendo imediatamente se sua reunio poder ocorrer no horrio desejado. Alm disso, a troca de mensagens entre X, Y e Z eliminada, sendo esta feita de forma transparente pelas agendas. Assim, o processo de agendar eventos coletivos se torna rpido e eficiente.

4.1 Metodologia de desenvolvimento da agenda distribudaO projeto da aplicao foi feito atravs da modelagem orientada a objetos (PageJones, 2001). Para isso foi utilizada a UML, que uma linguagem grfica usada para visualizar, especificar, construir e documentar os artefatos de um sistema de software (Booch et al., 2000). A UML fornece, atravs de seus diagramas, os mecanismos necessrios para modelar as funcionalidades da agenda distribuda, suas classes e a interao entre elas. Usamos diversos diagramas que fazem parte da UML, entre eles:

Diagramas de caso de uso: para mostrar a interao entre o usurio e a aplicao; Diagramas de seqncia: para mostrar a ordem em que os componentes da aplicao executam suas funes e trocam mensagens; Diagramas de classes: para especificar as classes que fazem parte da aplicao. Uma anlise de requisitos da agenda distribuda foi elaborada a fim de gerar uma lista

de funcionalidades da aplicao. Tendo por base tais funcionalidades, foram criados os casos de uso. Segue uma listagem dos requisitos da agenda com seus respectivos casos de uso: Gerenciar compromissos individuais: Criar Excluir Editar

25

Buscar Consultar compromissos de outros contatos Consultar compromissos pessoais Gerenciar eventos coletivos:

Agendar Cancelar (proprietrio) Declinar (quando o usurio aceita o convite e depois desiste) Aceitar/Recusar convite Alertar sobre eventos agendados:

Alertar Gerenciar contatos:

Adicionar Remover Verificar estado Determinar o horrio ideal para um evento coletivo dado um grupo de usurios:

Determinar horrio ideal Controlar acesso agenda:

Login Logout Com base na lista de requisitos, foram gerados os casos de uso, que serviram para

idealizar como a aplicao funcionar, descrevendo de forma genrica as aes que sero executadas durante o seu funcionamento. Na Figura 2, tem-se o caso de uso Adicionar Contato, que mostra os passos para se adicionar um contato lista de contatos, sem se preocupar se ser usada uma interface grfica ou comandos no modo texto.

26

Cenrio Principal 1. A Agenda solicita a identificao do contato. 2. O Usurio informa a identificao. 3. A Agenda encontra o contato na rede. 4. A Agenda obtm os dados do contato e cria uma instncia do mesmo. 5. A Agenda adiciona o contato criado sua lista de contatos. 6. Cenrios alternativos 7. A Agenda no encontra o contato. 8. A Agenda informa que o contato no existe ou que pode estar off-line. Figura 2 Caso de Uso Adicionar Contato Analisando os casos de uso, foram identificadas as principais classes que formaro a agenda distribuda. Na Figura 3, pode-se ver um esboo do diagrama de classes da aplicao.

Figura 3 Diagrama de classes da Agenda Distribuda

A Tabela 1 lista as classes do projeto da agenda distribuda e d uma breve descrio de cada classe.

27

Tabela 1 Relao das classes da Agenda Distribuda Descrio Uma classe abstrata que tem as caractersticas comuns de um compromisso. CompromissoIndividual Uma subclasse de Compromisso que representa um compromisso individual. CompromissoColetivo Subclasse de Compromisso, contendo as caractersticas adicionais de um compromisso coletivo ListaDeCompromissos Responsvel por armazenar classes do tipo Compromisso. Contato Representa os contatos de um usurio, ou seja, as entidades que podero estar envolvidas em eventos coletivos e ter seus compromissos consultados. ListaDeContatos Armazena os contatos. Convite Classe que contem um Compromisso e ser usado para convidar contatos para eventos em grupo. ListaDeConvites Cuida de armazenar os convites. GerenciadorDeCompromissos Classe que, alm de gerenciar os compromissos, ser responsvel por checar o estado de um contato, consultar compromissos de outros contatos, buscar horrios livres, enfim, tudo o que envolver a comunicao entre agendas ser feito por esta classe. Alerta Entidade que ser usada para alertar um usurio sobre um compromisso que est prximo. ListaDeAlerta Responsvel por armazenar os alertas. GerenciadorDeAlertas Classe que ser usada para disparar os alertas. Classe Compromisso

28

5 RESULTADOS OBTIDOSComo resultado deste trabalho foi obtido um prottipo de uma agenda distribuda que implementa algumas das funcionalidades apresentadas no captulo anterior:

Efetuar o login e o logout no registro de nomes; Inserir e remover compromissos localmente; Inserir compromissos em agendas remotas; A aplicao desenvolvida formada basicamente por dois componentes:

Um servidor: responsvel por registrar as agendas no servio de nomes; As agendas: que, atravs do servidor, efetuam o login e logout; e buscam no servidor por outras agendas, a fim de agendar compromissos remotamente. Neste prottipo, tanto o servidor como a agenda implementam interfaces remotas. O

Exemplo 5 mostra a definio da interface remota implementada pelo servidor.

package agenda.servidor; import java.rmi.Remote; import java.rmi.RemoteException; import agenda.IAgenda; public interface IServidor extends Remote { public void login(String nome, IAgenda agenda) throws RemoteException; public void logout(String nome) throws RemoteException; public boolean isOnline(String nomeContato) throws RemoteException; }

Exemplo 5 Interface IServidor Esta interface define os mtodos que sero invocados remotamente pelas agendas para que estas efetuem o login, logout e consultem se determinada agenda est online, ou seja, se est registrada no servio de nomes. J a interface remota implementada pelas agendas exibida no Exemplo 6.

29

package agenda; import java.rmi.Remote; import java.rmi.RemoteException; public interface IAgenda extends Remote { public Usuario getUsuario() throws RemoteException; public boolean enviarConvite(Convite c) throws RemoteException; public void aceitarConvite(Convite c) throws RemoteException; public void recusarConvite(Convite c) throws RemoteException; public ListaCompromissos getListaCompromissos() throws RemoteException; public boolean inserirCompromisso(Compromisso c) throws RemoteException; public boolean isHorarioLivre(Compromisso c) throws RemoteException; }

Exemplo 6 Interface IAgenda Na interface IAgenda mostrada no Exemplo 6, os principais mtodos utilizados pelo prottipo so:

public Usuario getUsuario(): que retorna o usurio da agenda;

e public boolean isHorarioLivre(Compromisso c): que retorna true se o horrio do compromisso passado como parmetro est livre, ou false se o horrio estiver ocupado. Na arquitetura definida no prottipo, uma agenda atua como servidora recebendo

chamadas dos mtodos remotos ou o como cliente invocando mtodos em outras agendas. Quando o servidor iniciado, ele se registra no servio de nomes do Java RMI e fica esperando que agendas remotas efetuem o login ou logout. O Exemplo 7 mostra trechos do cdigo do servidor que implementado pela classeServidorImpl que executa o seu prprio registro no servidor de nomes quando

instanciado; e do mtodo login(String nome, IAgenda agenda), invocado por uma agenda, quando esta iniciada. Parte do cdigo foi omitida:

30

//cdigo omitido public class ServidorImpl extends UnicastRemoteObject implements Servidor { public ServidorImpl(String nome) throws RemoteException { try { Naming.bind(nome, this); System.out.println("[ServidorImpl] Bind ok: " + nome); } catch(Exception e) { System.err.println("[ServidorImpl] Erro: " + e.getMessage()); e.printStackTrace(); System.exit(1); } } public void login(String nome, IAgenda agenda) { try { Naming.bind(nome, agenda); System.out.println("[ServidorImpl] Login ok: " + nome); } catch(AlreadyBoundException e) { System.err.println("[ServidorImpl] Usuario \"" + nome + "\"ja logado."); } catch(Exception e) { System.err.println("[ServidorImpl] Falha no login: " + e.getMessage()); e.printStackTrace(); } } //cdigo omitido }

Exemplo 7 Classe ServidorImpl Uma agenda que implementada pela classe AgendaImpl quando iniciada, busca pelo servidor no servio de nomes do Java RMI e efetua o login, ou seja, invoca no servidor o mtodo login(), que registra a agenda no servio de nomes. Esta, ento pode buscar por outras agendas que efetuaram o login no servidor, e invocar seus mtodos remotos. O Exemplo 8 exibe o mtodo na agenda que efetua o login no servidor de nomes.

public void login() { try { IServidor servidor = (IServidor)Naming.lookup(nomeServidor); System.out.println("[Agenda] Servidor encontrado."); servidor.login(this.usuario.getUsername(), this); System.out.println("[Agenda] Login efetuado."); } catch(Exception e) { System.err.println("[Agenda] Erro: " + e.getMessage()); e.printStackTrace(); } }

Exemplo 8 Mtodo que efetua o login de uma agenda no servidor

31

O mtodo login(), da classe AgendaImpl obtm uma referncia a um objeto do tipoIServidor atravs do mtodo Naming.lookup("rmi://localhost/Servidor"). Em

seguida, chamado o mtodo servidor.login(this.usuario.getUsername(), this) do objeto servidor. Este mtodo recebe dois parmetros: uma String como nome do usurio da agenda e um objeto do tipo AgendaImpl, que registrado com o nome fornecido, e assim fica disponvel para que outras agendas no servio de nomes do Java RMI. Estando registrada, uma agenda pode buscar por outras, para invocar os mtodos necessrios ao agendamento remoto de compromissos. O Exemplo 9 mostra trechos do cdigo do mtodo agendarCompromissoColetivo(CompromissoColetivo recebe como parmetro um compromisso coletivo.cmp), que

32

public boolean agendarCompromissoColetivo(CompromissoColetivo cmp) { int length = cmp.getContatos().size(); Contato[] contatos = (Contato[]) cmp.getContatos().toArray(new Contato[length]); IAgenda[] agendas = new IAgenda[length]; if(!compromissos.isHorarioLivre(cmp)) return false; System.out.println("[AgendaImpl] Horario local livre..."); try { IServidor servidor = (IServidor) Naming.lookup(nomeServidor); for(int i = 0; i < length; i++) { Contato c = contatos[i]; if(!servidor.isOnline(c.getUsername())) return false; } System.out.println("[AgendaImpl] Todos Online..."); for(int i = 0; i < length; i++) { agendas[i] = (IAgenda) Naming.lookup(contatos[i].getUsername()); if(!agendas[i].isHorarioLivre(cmp)) return false; } System.out.println("[AgendaImpl] Todos Livres..."); System.out.println("[AgendaImpl] Agendando compromissos..."); for(int i = 0; i < agendas.length; i++) { System.out.print("[AgendaImpl] Agendando para '" + contatos[i].getUsername() + "'..."); agendas[i].inserirCompromisso(cmp); System.out.println("OK."); } } catch(Exception e) { e.printStackTrace(); } System.out.println("[AgendaImpl] Agendando local..."); this.agendarCompromisso(cmp); return true; }

Exemplo 9 Mtodo que agenda um compromisso coletivo O mtodo exibido acima funciona da seguinte forma: 1. Checa se o compromisso pode ser agendado localmente; 2. Verifica se todos os contatos envolvidos esto online; 3. Verifica se todos os contatos esto com o horrio solicitado livre; 4. Agenda o compromisso na agenda de cada contato envolvido; 5. Caso algum destes passos falhe, toda a operao cancelada. Isto basicamente tudo o que foi implementado da Agenda Distribuda. Esta pequena parte mostra a idia geral do projeto de permitir o agendamento de compromissos em grupo

33

de forma automtica. Como continuao deste trabalho, prope-se a implementao das demais funcionalidades da agenda.

34

6 CONCLUSESConclui-se com este trabalho que as aplicaes distribudas so de grande utilidade por permitirem, entre outras coisas, o compartilhamento de recursos e a comunicao entre pessoas espalhadas geograficamente. Tambm chega-se concluso de que uma agenda distribuda proporciona grande flexibilidade e agilidade ao agendamento de compromissos em grupo, pois permite que esta tarefa seja feita de forma automtica, diminuindo o nmero de interaes do usurio. Este trabalho tambm mostrou a eficincia da tecnologia Java RMI, pois esta integra linguagem Java um poderoso modelo de distribuio de objetos que fcil de ser usado e oferece um meio rpido de se escrever aplicaes distribudas.

35

7 REFERNCIAS BIBLIOGRFICASBOOCH, Grady; JACOBSON, Ivar; RUMBAUGH, James. UML: Guia do usurio. Rio de Janeiro: Campus, 2000. 472 p. COULOURIS, George; DOLLIMORE, Jean; KINDBERG, Tim. Distributed systems: concepts and design. 3. ed. Harlow: Addison Wesley, 2001. 772 p. DEITEL, Harvey M; DEITEL, Paul J. Java: como programar. 4. ed. Porto Alegre: Bookman, 2003. 1386 p. ECKEL, Bruce. Thinking in Enterprise Java. Disponvel em: http://www.mindview.net/ Acesso em: 14 novembro 2004A. ECKEL, Bruce. Thinking in Java. 3. ed. Disponvel em: http://www.mindview.net/ Acesso em: 14 novembro 2004B. HORSTMANN, Cay S; CORNELL, Gary. Core Java 2 Volume II Recursos Avanados. So Paulo: Makron Books, 2000. JANDL JUNIOR, Peter. Introduo ao Java. So Paulo: Berkley Brasil, 2002. 518 p. JANDL JUNIOR, Peter. Mais Java. So Paulo: Futura, 2003. 635 p. KUROSE, James F; ROSS, Keith W. Redes de Computadores e a Internet: uma nova abordagem. So Paulo: Addison Wesley, 2003. 548 p. PAGE-JONES, Meilir. Fundamentos do desenho orientado a objeto com UML. So Paulo: Pearson Education do Brasil, 2001. 462 p. SUN 2004A. SUN MICROSYSTEMS. Remote Method Invocation (RMI) code samples. Disponvel em: http://java.sun.com/developer/codesamples/rmi.html Acesso em: 19 novembro 2004B. MICROSYSTEMS. Java RMI reference documentation. Disponvel em:

http://java.sun.com/products/jdk/rmi/reference/docs/index.html Acesso em: 19 novembro

36

SUN

MICROSYSTEMS.

The

Java

tutorial.

Disponvel

em:

http://java.sun.com/docs/books/tutorial/index.html Acesso em: 19 novembro 2004C. TANENBAUM, Andrew S. Distributed operating systems. Upper Saddle River: PrenticeHall, 1995. 614 p. TANENBAUM, Andrew S. Redes de computadores. 4. ed. Rio de Janeiro: Campus, 2003. 955 p.