· Dicas de programação para a biblioteca IPC do Unix (aqui)
· Trabalhos e seminários da disciplina de Tópicos Especiais em Sistemas Distribuídos (graduação, UERJ) aqui
· Texto sobre comparação de middleware está disponível aqui
· Página do prof. Fábio Kon (USP) aqui
· Página do prof. Fábio M. Costa (UFG) aqui
· Página do prof. Markus Endler (PUC-Rio) aqui
· Página do prof. Renato Cerqueira (PUC-Rio) aqui
· O seminário sobre WebServices está disponível aqui
· Página sobre “Computação Autonômica” (autonomic computing) aqui
· Mini-curso sobre P2P do prof. Carlos Alberto Kamienski aqui <novo>
· Confiança no Funcionamento: Terminologia em Português http://www.cs.kent.ac.uk/people/staff/rdl/CoF/
· Experiences with Auto-adaptive and Reconfigurable Systems http://www3.interscience.wiley.com/cgi-bin/jissue/112751522
· Fault-Tolerant Distributed Systems http://www.ece.cmu.edu/~ece749/projects.html
· COMP 4705: Distributed Algorithms http://www.cs.du.edu/~hlee/Teaching/DistAlgo/home.html
· IEEE Distributed Systems Online aqui <novo>
Links para CORBA
· http://www.omg.org (o site da OMG, que mantém o padrão CORBA)
· MICO (CORBA com mapeamento para C++, para Unix)
· Washington University's TAO (CORBA em C++ com características de tempo-real)
· ORBacus for C++ and Java (da IONA. Trial de 30 dias)
· JacORB (em Java com mapeamento para Java)
· http://www.ime.uerj.br/javadocs/guide/idl/index.html (do JDK 1.5 da Sun)
Simuladores para Sistemas Distribuídos
· ?Projeto Neko aqui <novo>. ? Página do utilizado pelo prof. Endler da PUC aqui
· Ben Ari. Dar uma olhada aqui. Versão mais recente aqui <novo>.
Sockets, RMI, RPC
· Exemplos de programação de sockets “redondinhos” (C/Java/TCP/UDP) aqui
· Produtores e Consumidores local e RMI aqui
· Envio de mensagens com RMI (com tratamento de exceções remotas) aqui
· Esqueleto da calculadora remota com RPC aqui
· Outro exemplo simples de RPC aqui
Dica RMI
Dêem uma olhada neste texto aqui. Observem que o mais complicado é entender como o CLASSPATH afeta a execução dos elementos (rmiregistry, carga dos stubs, registro do servidor, carga dinâmica dos stubs dos clientes, carga da informação de política de segurança, etc.). O problema não é o RMI, mas os conceitos de JVM, ClassLoader, pacotes, etc. Ou seja, Java. O aluno deve perseguir a informação pró-ativamente.
Assim, para executar os dois programas o aluno deve abrir 3 interpretadores, cd para o diretório onde se encontram as classes do programa (isso, para facilitar o aluno, inicialmente, evitando ter que configurar e resolver os problemas com o ClassLoader e o conceito de classpath). Uma janela para o rmiregistry, e as outras para o servidor cliente. Num segundo passo, o aluno deve testar os programas de forma realmente distribuída. O problema não está no RMI, mas na preguiça do aluno em entender e resolver os problemas. Tem que correr atrás, a solução não brota!
Para facilitar nos programas, adicionamos um arquivo .bat (para o Windows, mas pode ser usado no Linux também, pasta setar a propriedade de execução no arquivo), para a carga do lado servidor. O cliente será executado da forma tradicional.
Dicas para colocar a sua página no ar...
Essas informações já deveriam ser do seu conhecimento, se você já fez PC II (e aprendeu sobre Applets) e SO I e SO II (arquivos, Unix, permissões). Se ainda não são do seu conhecimento, um pouco de interesse e uma rápida busca na Internet resolveriam o problema.
A sua página deve ser acessada pela Internet, através da URL: snarf.ime.uerj.br/~sd_gXY. Onde “XY” é o número do seu grupo (01, 02, 03, etc.). Por que o “~”? É o padrão do Unix para referenciar “o diretório home do usuário”.
Para o serviço Web, existe uma configuração que indica, para páginas de usuário, em que diretório do usuário será buscado o arquivo index.html (o nome do arquivo também depende da configuração, mas index.html é bem comum. Assim, você vai precisar criar um diretório ~/public_html e um arquivo index.html com as permissões e o conteúdo adequado.
Este link, na página de SO I, apresenta um rápido tutorial sobre Unix http://www.ime.uerj.br/~alexszt/UNIXhelp1.3/Pages/ Ele está disponível há mais de 10 anos neste mesmo lugar. Basta acessar o link "Controlling access to your files and directories" para entender o esquema de permissões do Unix que foi rapidamente apresentado em sala de aula.
Mas, se você fizer um simples busca com as palavras "file directory permissions index.html ~/public_html" o roteiro "mastigado" aparece em vários links. Por exemplo: http://helpdesk.ua.edu/unix/web-perm.html
Se você não sabe inglês, o que na nossa área seria muito prejudicial, use "arquivo diretório permissões index.html ~/public_html". Logo aparecem dicas como http://www.grsd.fee.unicamp.br/Como_publicar_p%C3%A1ginas_na_Web%3F
Mais do que isso, só se eu fizer...
Uma idéia dos critérios da avaliação dos trabalhos de programação:
· Execução – executa correto? Pela metade?
· Readme – arquivo explicando como executar, opções de projeto, etc.
· Comunicação Socket – programou corretamente o TCP?
· Exceções do Socket – capturou ou tratou erros e exceções do socket (ou um erro de conexão, por exemplo, aborta o programa todo?) ?
· Servidor Concorrente – usou Threads e/ou processos corretamente? Passou parâmetros para os tratadores?
· Implantação do sistema – a implantação foi facilitada de alguma forma (Script, arquivo, arquivo de propriedades)? Posso distribuir os componentes como achar melhor? Tem alguma restrição de localização, referências ou nomes?
· Balanceamento de carga (estrutura) – implementou uma política de balanceamento? Round-robin? Como identifica quantos Workers RMI são, como faz o rodízio, ficou hard-coded? Se eu mudar o número de workers, continua funcionando?
· RMI/RPC (especificação e implementação) – descrição das interfaces, geração dos stubs, implementação dos clientes e servidores
· Calculadora – funciona, está ok? Como repassa para os especialistas? Como trata ou repassa as exceções?
· Multiplicador e Divisor funcionam? Como faz com a Divisão por zero?
· Desempenho – mede o desempenho no fornt-end? Faz a média, apresenta a medida corretamente na tela?
· Cliente especial – esse tem vários requisitos. Vários grupos discutiram alguns pontos com o professor... não tem uma solução única. Vejam as fermentas httperf e jmetter
· Escalabilidade – é fácil mudar o numero de tratadores e workers? Parâmetro na linha de comando? Propriedades?
· Implementaram alguma forma de tolerância a falhas (não foi pedido, mas pode ser um plus)
· Código – está bem feito, bem dividido, bem documentado? É cópia (argh!!!)?
· Outros...