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
Download
Random flashcards
modelos atômicos

4 Cartões gabyagdasilva

Anamnese

2 Cartões oauth2_google_3d715a2d-c2e6-4bfb-b64e-c9a45261b2b4

A Jornada do Herói

6 Cartões filipe.donner

teste

2 Cartões juh16

paulo

2 Cartões oauth2_google_ddd7feab-6dd5-47da-9583-cdda567b48b3

Criar flashcards