Cancelado

Banco Distribuído com Webservices

Publicado em 18 de Abril de 2016 dias na TI e Programação

Sobre este projeto

Aberto

Este projeto tem duas fases:

Implementar um Sistema de Banco Distribuído que consistirá em:
● um servidor de dados (banco de dados)
● três servidores de negócio (responsáveis pela conexão com o cliente e com o servidor de dados)
● vários clientes, implementados em pelo menos duas linguagens de programação diferentes
.
Responsabilidades e comportamentos
Servidor de Dados
O servidor de dados é responsável por implementar o mecanismo de exclusão mútua no acesso às contas dos clientes. Deve ser implementado um modelo baseado no conceito de leitores e escritores, onde a exclusão mútua é imposta para o caso de escritores mas não para leitores.
O servidor de dados deverá implementar apenas serviços básicos de atualização de saldo e de lock das contas:
● getSaldo {numtransação, conta} → retorna ­1 se a conta estiver travada por outra transação
● setSaldo {numtransação, conta, valor} → retorna ­1 se a conta estiver travada por outra transação
● getLock {numtransação, conta} → retorna ­1 se a conta estiver travada por outra transação
● unLock {numtransação, conta} → retorna ­1 se a conta estiver travada por outra transação
O servidor de dados também deve manter um log de todas as transações. O log deve ser mantido em um arquivo específico, no qual todas as transações são gravadas em modo “append”. Como sugestão de campos de cada registro de log, pode­se pensar em:
TIMESTAMP, NumTransação, ID Servidor Negócio, TipoOperação, Conta, Valor
● TIMESTAMP ­ momento em que a operação foi efetivamente realizada;
● NumTransação ­ repassado pelo Servidor de Negócio
● ID Servidor Negócio
● TipoOperação ­ tipo da transação sendo efetuada (dentre as acima)
● Conta ­ sendo operada
● Valor da transação
O servidor de dados deve ser capaz de atender múltiplas conexões dos servidores de negócio; no caso de uma operação tentar acessar uma conta bloqueada por outra transação, a resposta padrão deve ter um valor ­1; outras conexões a contas não bloqueadas devem operar normalmente.

Servidor de Negócio
O servidor de negócio é responsável por receber as conexões dos clientes, gerenciar as transações e prover os serviços de manipulação das contas:
int begin_transaction(int cutm)
URI: /begintransaction/{cutm}
Primeira operação de um cliente antes de iniciar quaisquer outras operações.
Cutm é o ID do cliente; retorna um numero de transação
(ntrans) para ser utilizado pelo cliente.
Void deposito(int ntrans, int acnt,int amt)
URI:
/deposito/{ntrans}/{acnt}/{amt}
Aumenta o saldo da conta acnt pelo valor amt e retorna nada
void saque(int ntrans, int acnt, int amt)
URI: /saque/{ntrans}/{acnt}/{amt}
Diminui o saldo da conta acnt pelo valor amt e retorna nada
int saldo(int ntrans, int acnt)
URI: /saldo/{ntrans}/{acnt}
Retorna o saldo da conta acnt
void end_transaction(int ntrans)
URI: /endtransaction/{ntrans}
Faz o commit da transação do cliente
void abort_transaction(int ntrans)
URI: /aborttransaction/{ntrans}
Cancela a transação do cliente
O servidor de negócio gerencia todas as operações da transação e faz apenas a atualização final do saldo no servidor de dados. Mas para efetuar as operações, ele precisa obter os locks das contas que vai manipular junto ao servidor de dados; só depois inicia o processamento das mesmas.
O servidor de negócio deve manter um log de todas as transações que efetua, registrando informações do tipo:
TIMESTAMP, NumTransação, ID Cliente, Operação, Conta 1, Conta 2, Valor
O servidor de negócio deve ser capaz de atender mútliplos clientes, mas somente uma transação por cliente. Para tratar os múltiplos clientes, pode ser necessário adotar um paradigma de múltiplas threads, onde cada thread serve um cliente e se comunica com o servidor de dados. Em cada conexão com o servidor de dados, deve informar o Numero da Transação.

A conexão com o servidor de dados deve ser implementada ou com Webservices.
O servidor de negócio oferecerá uma interface rest para os clientes, devendo ser capaz​de enviar respostas tanto em formato xml como json, dependendo do que for solicitado pelo cliente no accept.
O servidor de negócio deverá fornecer um número de transação para os clientes quando for chamado o serviço begintransaction.​Para ter um número único de transação, cada servidor de negócio poderá ter um prefixo único e acrescenta um número ao final:
servidor um: 1​xx
servidor dois: 2​xx
etc.

Clientes
Os clientes serão basicamente os mesmos do projeto anterior, mas utilizarão Webservices agora e
poderão ​se conectar a mais de um servidor de negócio simultaneamente, realizando em cada um
transações/operações distintas ou a mesma (para fins de teste de consistência).
Deverá existir, obrigatoriamente​, pelo menos duas implementações dos clientes, com as mesmas
funcionalidades, feitas em linguagens de programação diferentes, que sejam multiplataforma, ou seja, possam ser executadas no Linux, Windows ou Mac.
Os clientes executarão as mesmas transações/operações do projeto anterior, listadas abaixo.
Os clientes se comunicarão com os servidores de negócio exclusivamente​através de Webservices, podendo escolher receber respostas em xml ou json.
Generalidades
O servidor de dados administra todas as informações de conta dos usuários. Uma pessoa cliente poderá invocar as seguintes operações em uma ATM:
1. Void deposito(int conta, int valor)
2.
Void saque(int conta, int valor)
3. Void transferencia(int conta_orig, int conta_dest, int valor)
4. Int saldo(int conta)
5.
Int begintransaction(int client)
6. Void end_transaction(int ntrans)
7. Void abort_transaction(int ntrans)
Cada uma das operações acima deverá ser transformada em um webservice, cujas URI's estão especificadas no servidor de negócios.

Requerimentos de Programação
Os servidores de dados e de negócio deverão ser implementados preferencialmente na mesma linguagem de programação (Java, Python ou Go), observados os requisitos de comunicação descritos acima.
Você é livre para usar qualquer linguagem das opções dadas (Java, Python ou Go) contanto que seu código realize as mesmas operações mencionadas acima.
Este projeto utilizará exclusivamente REST​como protocolo de acesso aos serviços web (webservices). As mensagens poderão ser trocadas em xml ou json.
Funcionamento
Inicialmente, o servidor de dados vai criar 10 contas numeradas de 1 a 10 com saldo inicial 1000
O servidor de dados receberá apenas um parâmetro na sua invocação ­ a porta que estará escutando as conexões. Neste projeto, a porta deverá ser obrigatoriamente​, 8542. Este parâmetro deverá ser recebido via linha de comando, como parametro de invocação do executável.
Não deverá ser solicitado interativamente ao usuário.
Os servidores de negócio são uma mesma implementação (mesmo código executável), rodando em máquinas diferentes. Eles recebem como parâmetro de execução o endereço IP do servidor e a porta onde deve fazer a conexão, e também a porta em que ele estará escutando os clientes. Ou seja, três parâmetros: IP e Porta do servidor de dados, Porta onde estará escutando os clientes.

Minha sugestão: utilize a porta 8544 p​ara o servidor de negócio. Se rodar vários servidores na mesma máquina, incremente de dois ​a próxima porta (8546, 8548, …)
Os clientes recebem como parâmetros de entrada os seguintes:
● server_address: o endereço do servidor de negócio
● server_port: a porta do servidor de negócio
● transação: o número da transação (quando estiver implementado)
● operacao: uma dentre “deposito”, “saque”, “transferencia” e “saldo”
● conta: a conta do usuário; no caso de “transferencia”, duas contas, origem e destino.
● Valor: somente para as operações “deposito”, “transferencia” e “saldo”
Notas adicionais
O sistema desenvolvido deverá executar tanto em máquinas Linux (obrigatoriamente) como em máquinas Windows (opcional). Não deverá​ter nenhuma interface gráfica de usuário e sua operação deverá seguir o modelo dado abaixo.
Demo (faça as adaptações necessárias para Python)
Inicie o servidor de dados
$java ServidorDados 8542
Inicie o servidor de negócio (cada um)
$java ServidorNegocio <IP ServidorDados> 8542 8544
Finalmente, teste o cliente
$java Cliente <maquina_rodando_o_servidor_negocio> 8544 saldo 10
O saldo atual do usuario 10 e R$ 1000
$java Cliente <maquina_rodando_o_servidor_negocio> 8544 deposito 10 200
Deposito bem sucedido de R$ 200 na conta 10!
$java Cliente <maquina_rodando_o_servidor_negocio> 8544 saque 10 50
Saque bem sucedido de R$ 50 da conta 10!
$java Cliente <maquina_rodando_o_servidor_negocio> 8544 transferencia 5
10 100
Transferencia bem sucedida de R$ 100 da conta 5 para a conta 10!
$java Cliente <maquina_rodando_o_servidor_negocio> 8544 saldo 10
O saldo atual do usuario 10 e R$ 1250
Submissão
O projeto deverá ser entregue com todos os arquivos zipados. Os seguintes arquivos devem ser submetidos:
● Todos os códigos fonte
● Um arquivo Readme​, que descreve brevemente todos os arquivos submetidos. No arquivo
Readme você deve prover também informação acerca do ambiente de compilação, passos para a compilação, instruções de execução, etc.
Você deve prover tanta informação detalhada quanto você julgue que possa ajudar o processo de correção e execução do seu código.
● Um arquivo Amostra​, que descreve os testes que você executou no seu programa para se certificar de sua correção. Também descreva quaisquer casos para os quais o seu programa não esteja funcionando corretamente. Enviar os arquivos de logs dos servidores (dados e negócio).

● Um arquivo Projeto​, que descreve o projeto global do programa, uma descrição verbal de “como ele funciona”, incluindo as bases do que o sistema está fazendo (por trás das interfaces) e as deciões de projeto consideradas e tomadas. Também descreva possíveis melhorias e extensões ao seu programa (e rascunhe como elas poderia ser feitas).

Categoria TI e Programação
Subcategoria Aplicativos desktop
Isso é um projeto ou uma posição de trabalho? Um projeto
Tenho, atualmente Eu tenho especificações
Disponibilidade requerida Conforme necessário
Experiência nesse tipo de projeto Sim (Eu já gerenciei esse tipo de projeto)
Plataformas exigidas Windows

Prazo de Entrega: 14 de Maio de 2016

Habilidades necessárias

Outro projetos publicados por V. P.