Modelo de projeto de TCC
Propaganda
UNIVERSIDADE FEDERAL DE SANTA CATARINA SERVIDOR MULTI-JOGOS LEONARDO DE SOUZA BRASIL ANTEPROJETO DE PESQUISA PARA TRABALHO DE CONCLUSÃO DO CURSO DE CIÊNCIAS DA COMPUTAÇÃO ORIENTADOR: RICARDO PEREIRA E SILVA FLORIANÓPOLIS, 25 DE JUNHO DE 2007 SUMÁRIO 1. INTRODUÇÃO........................................................................................................ 3 2. OBJETIVOS ........................................................................................................... 4 OBJETIVO GERAL ............................................................................................. 4 OBJETIVO ESPECÍFICO ................................................................................... 4 3. COMUNICAÇÃO DISTRIBUIDA ............................................................................ 5 4. RMI ......................................................................................................................... 5 5. WEB SERVICE ....................................................................................................... 8 6. TECNOLOGIA UTILIZADA .................................................................................. 12 7. CONCLUSÃO ....................................................................................................... 13 8. BIBLIOGRAFIA .................................................................................................... 14 1. INTRODUÇÃO Os jogos estão presentes na história da humanidade desde o seus primórdios. Com a evolução dos computadores e a criação das primeiras redes, com destaque para a internet, foi possível simular os jogos através de computadores em ambientes virtuais onde jogadores mesmo distantes fisicamente, compartilham do mesmo tempo e espaço “virtuais”. Surge nesse momento o conceito de jogos distribuídos ou jogos multi-jogadores. Jogos multi-jogadores são jogos de computador que permitem a participação simultânea de vários jogadores em uma mesma partida. Com a computação distribuída os jogos começaram a ser jogados por diversas pessoas ao mesmo tempo, estando elas em qualquer parte do mundo. Nesses jogos multi-jogadores, o procedimento normalmente realizado é o seguinte: O usuário (jogador) inicia seu jogo com o intuito de jogar via redes, ele então localiza um servidor onde seu jogo esteja rodando e solicita uma conexão nesse servidor, o jogador é então autorizado e pode iniciar partidas com outras pessoas que também estejam conectadas. O jogador realiza operações que são enviadas para os outros jogadores de forma que seus jogos sempre possuam o estado atual do jogo. O servidor simula o jogo, sincroniza os estados dos jogadores e sinaliza quando o jogo termina, normalmente com a vitória de um dos jogadores. Essa conexão também envolve aspectos de segurança de comunicação via redes e de controles de trapaças, etc... Dentro desse procedimento é possível identificar aspectos que são comuns para diversos jogos. O único aspecto diferente é a forma como cada jogo é implementado com suas regras e operações específicas.. Seguindo as melhores práticas de engenharia de software, a proposta desse trabalho é desenvolver um servidor multi-jogos, levando em conta o reuso dos aspectos acima citados. Esse servidor será abstrato no sentido de poder realizar a comunicação via rede entre jogos de diferentes desenvolvedores. Através dele será possível gerenciar as partidas de cada jogo de modo que ele controle o estado de cada partida e seus jogadores. Para que um jogo qualquer possa se conectar ao servidor e para facilitar o desenvolvimento de jogos para esse servidor a proposta é desenvolver um framework que deve ser utilizado pelo desenvolvedor do jogo. 2. OBJETIVOS OBJETIVO GERAL Desenvolver um servidor multi-jogos e um framework que possibilite o uso do servidor por desenvolvedores de jogos. OBJETIVO ESPECÍFICO Analisar tecnologias de computação distribuída em java. Escolher a tecnologia que melhor se encaixe para o projeto proposto Desenvolver o servidor multi-jogos; Desenvolver o framework cliente. Validar o projeto desenvolvendo uma aplicação cliente que utilize o framework desenvolvido e o servidor implementado. 3. COMUNICAÇÃO DISTRIBUIDA Considerando que o aplicativo servidor será implementado em linguagem Java, assim como os futuros jogos que utilizarão a arquitetura, foi realizada uma pesquisa sobre tecnologias de computação distribuídas em Java que possibilitem essa implementação levando em conta requisitos não funcionais como facilidade de desenvolvimento, tempo de resposta baixo, menor uso de rede, segurança e facilidade de uso. As duas tecnologias abordadas, Java RMI (Remote Method Invocation) e Web Service, são apresentadas a seguir. 4. RMI O que é. RMI (Remote Method Invocation) é uma das abordagens da tecnologia Java para prover as funcionalidades de uma plataforma de objetos distribuídos. Esse sistema de objetos distribuídos faz parte do núcleo básico de Java desde a versão JDK 1.1, com sua API sendo especificada através do pacote java.rmi. Através do RMI é possível realizar a comunicação entre objetos que estão em diferentes Máquinas Virtuais Java(JVM). Sendo possível inclusive transferir objetos serializados através da rede. Como funciona O RMI é baseado em uma arquitetura cliente/servidor, ou seja, existe o programa cliente que deseja realizar chamadas a um aplicativo remoto que se comporta como o servidor. Para que essa comunicação se realize o RMI fornece objetos “auxiliares” que facilitam a comunicação entre cliente e servidor, liberando o desenvolvedor de se preocupar com todo o código envolvido nessa troca de informações. Do lado do cliente existe um auxiliar que captura a chamada realizada pelo cliente e envia essa chamada para o servidor, esse auxiliar é chamado de Stub. O servidor por sua vez, também possui um auxiliar, chamado Skeleton, que captura a chamada passada por um Stub e chama o método no servidor. Com esse esquema de objetos “auxiliares” o RMI realiza a chama a objetos remotos simulando-os na máquina do cliente. Outro aspecto importante no RMI é a interface remota. Existe entre cliente e servidor uma interface remota de métodos. Essa interface permite que o cliente conheça as funções pré-estabelecidas que ele tem acesso no servidor. Essa interface define essas funções junto com seus parâmetros e retornos. Caso ocorra algo de errado na comunicação é lançada uma exceção do tipo RemoteException que deve sempre ser capturada e tratada pelo cliente. Tanto o Strub, do lado do cliente, quanto o Skeleton, do lado do servidor, são criados a partir dessa interface remota. No lado do servidor existe uma ou mais classes que implementam realmente essa interface remota. Para que o cliente decida para qual implementação da interface remota deseja se comunicar é necessário que o servidor registre seu serviço remoto. Isso é feito através de um cadastro no registro RMI. O registro RMI é similar a uma página de cadastro telefônico, ela possui um nome para o serviço e o local de sua implementação no servidor. Esse registro RMI deve ser sempre iniciado pelo servidor e chamado pelo cliente quando deseja utilizar um dos métodos da interface remota. Vantagens do uso do RMI Orientação a Objetos – Além dos tipos primitivos java, como por exemplo int, boolean,char. É possível, usando RMI, passar objetos como parâmetros de funções e obter objetos java como retorno de funções, além de tipo primitivos. Devido a isso não é necessário nenhum código extra para “montar” e “desmontar” objetos no cliente. “Mover o comportamento” – Usando-se do fato de ser possível mover objetos através de JVM’s, com RMI é possível trabalhar com interfaces e passar objetos que implementam essas interfaces em tempo de execução. Dessa forma é possível “mover o comportamento” para o outro lado da comunicação. Padrões de Projeto – O fato de ser possível passar objetos serializados do cliente para o servidor garante o uso de todo o poder do paradigma de orientação a objetos na computação distribuída. Como é possível “mover o comportamento” com o uso de interfaces java é possível usar padrões de projeto orientado a objetos facilmente. Segurança – Por fazer parte da API do java, RMI usa todo o mecanismo de segurança de Java, já bastante maduro. Facilidade para usar – RMI possui uma estrutura simples (como vista a anteriormente). Portabilidade – Essa característica é herdada pelo fato de RMI ser 100% Java. Se utilizado com JNI(Java Native Interface) é possível construir aplicativos java que se comuniquem com outro sistemas já existentes. Programação Paralela – RMI é multi-thread, garantindo que as requisições dos clientes seja atendidas sem necessidade código extra. 5. WEB SERVICE Uma das desvantagens no uso de RMI, ou de soluções similares, é o acoplamento existente entre suas camadas, ou seja, o cliente de um serviço RMI necessita conhecer exatamente qual método deve ser chamado no servidor, por conseqüência o acoplamento existente entre cliente e servidor é alto. No mundo real, onde aplicações evoluem à medida que as regras de negócio são modificadas e que surgem novos requisitos, um alto acoplamento entre diferentes aplicações faz com que qualquer aplicação dependente tenha que também ser atualizada para que a compatibilidade não seja perdida. É nesse contexto que surgem os web services, garantindo principalmente um baixo acoplamento entre diferentes aplicações, ou seja, reduzindo ao mínimo a quantidade de informações que uma aplicação precisa ter sobre as demais. O que é Um web service é um software identificado por uma URI, onde são publicadas interfaces e definidas e descritas usando XML. Um web service pode ser utilizado por outros sistemas de software que interagem com o web service através de mensagens baseadas em XML e através dos protocolos da Internet. Para ser possível implementar um web service são utilizadas várias tecnologias diferentes que garantem que esse trabalho se torne possível de uma maneira mais adequada.. Para a troca de mensagens usando-se web services é utilizado o XML (eXtensible Markup Language) uma linguagem de marcação de texto simples e legível e que está se tornando um padrão de fato, principalmente por sua simplicidade, legibilidade e organização. Segue um estudo mais detalhado sobre as tecnologias utilizadas em um web service. SOAP SOAP é um protocolo de comunicação baseado em documentos XML. Foi especificado de forma a ser independente de qualquer modelo de programação. Servidores SOAP são geralmente implementados utilizando de servidores http. A desvantagem do SOAP é o desempenho. Por utilizar o HTTP que é um protocolo ineficiente e limitado e pelo uso de documentos XML que exige um parser e torna as mensagens dezena de vezes maiores já que as marcações também ocupam espaço, às vezes maiores até que os dados. Uma mensagem em SOAP consiste em basicamente 3 elementos: Envelope: É o elemento raiz do documento XML. O Envelope pode conter declarações de namespaces e também atributos adicionais como o que define o estilo de codificação. Um "encoding style" define como os dados são representados no documento XML. Header: É um cabeçalho opcional. Ele carrega informações adicionais, como por exemplo, se a mensagem deve ser processada por um determinado nó intermediário. Body: Este elemento é obrigatório e contém o payload, ou a informação a ser transportada para o seu destino final. O elemento Body pode conter um elemento opcional Fault, usado para carregar mensagens de status e erros retornadas pelos "nós" ao processarem a mensagem. Web Service Description Language (WSDL) WSDL é uma linguagem baseada em XML utilizada para descrever um web service. É utilizando ela que um web service descreve todos seus serviços. Através de um documento escrito com a WSDL o cliente obtém todas as operações que pode realizar no web service. Universal Discovery, Description and Integration (UDDI) UDDI é o protocolo desenvolvido para a organização de registro de web services. Um web service precisa de alguma forma se registrar na rede para que seus clientes possam acessá-lo. A combinação de WSDL e UDDI é o que permite publicar o Web Service para que ele possa ser utilizado por outros usuários. Vantagens Baixo Aclopamento – Já citado anteriormente, é a principal característica dos web services quando comparado a outras tecnologias de computação distribuída. Usando web service é possível criar componentes de software que podem evoluir arquiteturalmente e independentes entre si. Firewalls – Web Services em geral não tem problema nenhum pois podem utilizar http para transporte. Padronização – Devido ao uso de XML. Desvantagens Desempenho – Não são uma boa solução quando a quantidade de dados a ser retornada é muito grande. Segurança - O maior problema nesse sentido é que não existe um padrão comum de segurança já implementado. Transações – Não existe um mecanismo padrão de transação confiável que possa ser usado em conjunto com Web services. Uso de XML – O XML é um formato ineficiente, que torna as mensagens dezenas de vezes maiores e mais caras de construir e interpretar, se comparado a outros formatos – como por exemplo o CDR(Common Data Representation). Interoperabilidade – Em teoria todas as plataformas de Web Services deveriam seguir os padrões e cada cliente poderia invocar um Web Service sem se preocupar com que plataforma o serviço foi implementado. Infelizmente, isso somente acontece se o desenvolvedor do serviço conhecer limitações existentes hoje e souber usá-las a seu favor 6. TECNOLOGIA UTILIZADA Um dos principais requisitos para qualquer jogo multi-player on-line é o desempenho, as jogadas devem ser transmitidas em menor tempo possível criando a ilusão de que foi realizada no mesmo instante. Nesse ponto, usar web-service em detrimento a RMI não seria aconselhável. Principalmente por causa uso de XML para a troca de mensagens.. Assim que o jogador efetua-se uma jogada, essa seria encapsulada em um documento XML e enviado ao servidor, o servidor gastaria um determinado tempo fazendo o parser nesse documento, realizando o processamento, montando uma novo documento, também em formato XML, para então enviar a todos os outros jogadores. Esses também iriam necessitar “ler” esses documentos para poder entender qual o estado em que o jogo se encontra. Por outro lado o uso de RMI acarreta apenas na serialização e deserialização de objetos Java em JVM distintas, se comparado a troca de documentos XML o desempenho se torna bastante melhor. Foi visando esses requisitos e aliando as necessidades do projeto que se decidiu pelo uso de RMI neste trabalho. Ele se adapta muito bem as necessidades do servidor, principalmente no que se refere a segurança e concorrência. 7. CONCLUSÃO Esse relatório apresenta um primeiro resultado visando o Trabalho de Conclusão de Curso. Foram apresentados: o tema proposto e um estudo sobre as possíveis escolhas tecnológicas, decidindo-se ao final pelo uso de RMI. 8. BIBLIOGRAFIA 1.SIERRA, Kate; SIERRA, Bert. Head First Java, 2ª ed. Alta Books Ltda, 2005. 2. Remote Method Invocation (RMI). Disponível em: <http://java.sun.com/javase/technologies/core/basic/rmi/whitepaper/index.jsp#10>. Acesso em 19 fev. 2007 3. Java RMI. Disponível em: <http://www.dca.fee.unicamp.br/cursos/PooJava/objdist/javarmi.html> Acesso em 20 fev. 2007 3. Web Services, SOAP e aplicações web. Disponível em: <http://devedgetemp.mozzila.org/viewsource/2002/soap-overview/index_pt_br.html> Acesso em 20 fev. 2007
