Exercícios de Desenvolvimento de Sistemas Distribuídos

1. Qual é a importância dos WebServices na internet?
2. Implemente um método RMI que receba dois parametros Double e retorne a sua multiplicação
3. Implemente um serviço web, que defina um método soma e receba dois atributos inteiros e retorne a soma destes dois atributos.
4. Qual é a importância do XML em uma troca de mensagens SOAP
5. Quais são os objetivos de um sistema de arquivos distribuídos? E quais são as vantagens e desvantagens de cada tipo deles? 
6. Descreva a importancia dos componentes de um webservice SOAP
7. Explique o que é e qual tipo de sistema distribuído é o CORBA?
8. Explique o que é e para que serve o Java RMI?

Exercícios IF, Else, Switch C#

Exercícios referentes a Estrutura Condicional em C#

1. Considere um programa que receba uma entrada de dados numérica, relativo a nota média da prova de um aluno e responda da seguinte meneira. Aprovado se a nota for entre 10 e 7, Exame se a nota for entre 4 e 6.99 e Reprovado se a nota for entre 0 e 3.99.
2. Escreva um programa em C# que receba uma lista e retorne o maior e o menor valor presente nesta lista.
3. Escreva um programa em C# que receba dois valores e determine se eles são múltiplos.
4. Crie um programa que contenha um menu. Neste menu o usuário poderá escolher, 1 -  para cadastrar o usuário (ao escolher esta opção o usuário deverá ser direcionado a uma tela de cadastro de usuário, aqui ele terá duas opções, digitar 1 para salvar e 2 para cancelar), 2 para apagar um usuário (ao escolher esta opção o programa deverá mostrar uma mensagem para o usuário digitar o id do usuário a ser removido e 2 opções, digitar 1 para confirmar a remoção ou 2 para cancelar) e 3 para sair do programa.

Sistemas distribuídos baseados na Web - SOAP

Sistemas distribuídos baseados na Web

No início da internet, as páginas basicamente eram documentos estáticos linkados (HTML, texto e XML), onde basicamente tinhamos um sistema cliente/servidor. O browser, neste caso, atuava como cliente e o servidor das páginas web, atuava como servidor.
Conforme a internet foi evoluindo, apareceram os scripts CGI (Common Gateway Interface) que permitiam a execução de scripts pelo browser, com isso era possível executar parte da regra de negócios nos clientes, os browsers, e prover conteúdo dinâmico para as páginas HTML.
Quanto mais páginas web eram criadas, maiores eram seus níveis de acesso, e com isso veio a necessidade de distribuir os servidores web.
Hoje o principal servidor de conteúdo web é o Apache Httpd Server Project, que é executado em 59.6% de todos os servidores da web, segundo esta pesquisa.
Clusterisar, ou distribuir um servidor não é uma tarefa fácil, mas isto deverá ser realizado de maneira transparente ao cliente. Quando um site possui várias instâncias de um servidor, a cada clique as chamadas realizadas pelo cliente pode migrar de um servidor para outro, mas sem que o cliente perceba, esta migração deverá ser transparente.
A clusterização foi feita para aumentar a performance dos servidores web, porém ao fazê-la devemos tomar certos cuidados, como a necessidade de mantê-los sincronizados, gerenciar os servidores através de monitoramento e a seleção do melhor servidor para executar uma requisição.

Comunicação

A comunicação na internet é realizada através do protocolo HTTP (Hipertext Transfer Protocol), ou protocolo de transferência de hipertexto. Este protocolo funciona com requisições e respostas, o browser como cliente faz uma requisição ao servidor web, o qual irá fornecer dados como resposta em forma de hipertexto.
O protocolo HTTP define 8 métodos, o GET, POST, PUT, HEAD, DELETE, TRACE, OPTIONS e CONNECT, sendo os 5 primeiros os mais utilizados.
O GET é utilizado quando queremos pegar algum recurso do servidor, o HEAD é uma variação do GET, porém ao invés de retornar todos os dados, em uma chamada HEAD só retornam os metadados da requisição e não os dados. Os metadados são dados que podem prover informações úteis sobre os dados daquele método, por exemplo os arquivos armazenados nos discos das máquinas possuem metadados, dentre eles os que identificam qual é o tipo de arquivo (bitmap, jpeg, mpeg, etc). O método POST é utilizado para enviar informações a serem processadas pelo serviço, como inserções de dados, já o método PUT é utilizado para enviar requisições de alteração de dados, finalmente o método DELETE é utilizado para remover um recurso do servidor.

Nomes

Todo método de um webservice roda em um servidor na internet e com isso será acessado através de uma URL, que por sua vez obedece a sua estrutura:
esquema : // nome : porta / caminho

Evolução da Internet

No início a internet eram só páginas estáticas de HTML e com o advento dos javascripts e do AJAX, os WebServices granharam importância. Os javascripts propiciaram aos WebDesigners a possiblidade de executar parte da regra de negócio no cliente, o browser. Com o javascript é possível realizar chamadas ao servidor e com isso a necessidade de métodos aumentou consideravelmente.
Os webservices são utilizados não só para fornecer dados e operações nos dados das páginas, como também, para disponibilizar parte dos dados de uma empresa/aplicativo na internet.
A internet gerou uma mudança no comportamento das empresas em relação aos seus dados, antes as empresas eram muito fechadas e não expunham os seus dados na internet. Com a descoberta dos webservices as empresas passaram a disponibilizar estes dados aos seus usuários, o que gerou uma nova onda de aplicativos web, também conhecidos como mashup.
Muitas empresas passaram a disponiblizar uma API de métodos http, e em alguns casos, cobrar pela utilização destes dados, como pode ser visto aqui, aqui e em muitos outros lugares na internet.

SOAP

O SOAP é um dos protocolos que especifica como deve ser realizada a troca de informações em um WebService, o seu desenvolvimento foi baseado, entre outras coisas, no protocolo de RPC. Nele os dados são trocados através dos arquivos de XML, que nada mais é do que um arquivo texto utilizado para formatar os dados.
Este protocolo começou a ser desenvolvido por dois funcionários da Microsoft e depois de algum tempo a sua especificação migrou para um grupo multidisciplinar do World Wide Web Consortium.
Um serviço SOAP, por definição é extensível, neutro e independente e se tornou a base para a definição do WSDL (WebService Description Language). A implementação de um serviço simples em Java, pode ser encontrada em diversas páginas da web, como aqui.
Este protocolo é extensível pois para implementar algumas regras, como as de segurança, isso é feito extendendo-se as suas definições. Ele é independente, pois o consórcio que estabelece as suas regras não está vinculado a nenhuma empresa, linguagem, sistema operacional ou modelo. E finalmente ele é neutro, pois pode ser utilizado por muitos protocolos, como o HTTP, o HTTPS e o SMTP.
Uma das grandes vantagens do SOAP, em relação as outras formas de se executar chamadas a métodos remotas, é a facilidade de configuração do Firewall, já que todos os métodos serão acessados pelo mesmo endereço e porta, e todas as mensagens trocadas serão transmissões de xml, impossibilitando ataque de envio de arquivos executáveis aos servidores.
Mesmo assim, como a segurança não é definida pela especificação do SOAP, cada desenvolvedor deverá implementá-la da sua maneira e para isso deve-se tomar muito cuidado com as possíveis formas de ataques, como a Man in the Middle, quais dados liberar e para quais usuários.
Uma mensagem de SOAP é definida por quatro componentes:

• Envelope: que identifica aquela xml como uma mensagem SOAP
• Header: que contem informações de metadados
• Body: que contem as informações da chamada ou da resposta
• Fault: que é utilizada para enviar as informações referentes aos erros que aconteceram durante o processamento daquela requisição

WSDL

O WSDL é responsável por definir as informações referentes aos métodos de um webservice. Estas inforamações incluem, nome, parametros, método HTTP utilizado, resposta e possíveis erros.
É possível acharmos o WSDL de um serviço adicionando o:
?wsdl
ao final o seu endereço. Com isso conseguimos fazer o download do arquivo de definição do webservice e com ele é possível gerarmos código referente as chamadas aqueles serviços, na linguagem que estamos utilizando para desenvolver o nosso sistema.

Sistema distribuído baseado na Web
SOAP

Sistemas de Arquivos distribuídos

Sistema de arquivos distribuídos

Os sistemas de arquivos distribuídos não compartilham o acesso aos blocos de armazenamento dos hds das máquinas, eles usam um protocolo de rede para isso, que também são conhecidos como network file system (sistema de arquivos de rede).

Objetivos

Os sistemas de arquivos distribuídos foram desenvolvidos com o objetivo de serem transparentes aos sistemas clientes, ou seja eles foram desenvolvidos para serem usados como se fossem pastas locais da máquina, e não remotas.

Um sistema de arquivos distribuídos almeja ter transparência em vários aspectos e por trás dos panos ele é responsável por localizar, transportar e potencialmente prover as funcionalidades de transparência listadas abaixo:

• Migração: Os arquivos podem se movimentar de um lugar ao outro, sem alterar as configurações dos clientes.
• Falha: Os softwares clientes devem continuar funcionando, mesmo quando uma falha acontecer no servidor
• Localização: Os nomes dos arquivos não devem indicar onde eles estão localizados.
• Acesso: Os clientes não devem saber que estão acessando um sistema distribuído de arquivos, e os arquivos devem ser acessados como se fossem arquivos locais.
• Escalabilidade: o sistema deve funcionar bem tanto em poucas máquinas (de um a 12 servidores), e quando escalar bem em sistemas grandes (milhares de máquinas)
• Concorrência: todos os clientes devem ver ter a mesma visão dos arquivos do sistema, ou seja, se algum cliente alterar algum arquivo, todos os processos que estiverem acessando este sistema de arquivos também irá ver estas alterações de uma forma coerente.
• Replicação: por motivos de escalabilidade e segurança, podemos querer replicar o sistema em várias máquinas, sem que os clientes saibam.
• Heterogeneidade: o sistema de arquivos deve ser provido em múltiplos hardwares e sistemas operacionais.

Armazenamento em rede e Disco compartilhado

Nos sistemas de arquivos de disco compartilhado utilizam uma Storage Area Network (SAN, uma área de armazenamento na rede) que provê acesso direto ao disco pela rede. Tanto o controle de acesso, quanto a tradução dos dados lidos do sistema de armazenamento são realizados nos clientes.

O tipo mais comum deste tipo de sistema, são os sistemas de arquivos de disco distribuídos, que adicionam uma camada de controle de concorrência, que prove um sistema consistente de serialização, evitando dados corrompidos e perda de dados, mesmo quando muitos clientes tentam acessar o mesmo arquivo, ao mesmo tempo. É comum nestes sistemas, a implementação de um mecanismo de isolamento dos dados, para prevenir o corrompimento dos dados, quando um nó falha.

Vários tipos de arquitetura foram utilizadas na implementação dos sistemas de arquivo de disco distribuído. Alguns deles distribuem as informações dos arquivos para todos os nós, outros utilizam servidores de metadados centralizados. Nestes dois casos é possível acessar todos os arquivos de todos os servidores.

Classificação dos sistemas de arquivos distribuídos

Existem dois tipos de configuração de acesso possíveis em um sistema de arquivos distribuídos. O sistema de acesso local e o sistema de acesso remoto.

Acesso Local

Em um sistema de acesso local, configuramos o sistema distribuído na rede interna da empresa. As vantagens deste tipo de sistema são:

• Podem ser configurados em várias linguagens diferentes
• Acesso local, gera melhor performance de acesso
• São administráveis e propiciam um melhor controle, já que a configuração é feita internamente.
• Melhor segurança, já que os arquivos ficam armazenados internamente e isso possibilita um melhor controle de quem tem acesso aos arquivos, ou mesmo as salas onde estão os servidores. Além de controlar quais patches serão aplicados aos servidores.

Já nas desvantagens podemos citar:

• Alto custo, com máquinas, softwares e equipe.
• Necessidade de compra de máquinas
• Maior custo de configuração de firewall, acessos, etc
• Mais trabalho com os backups.

Acesso Remoto

Já um sistema com acesso remoto, onde os arquivos ficam armazenados na nuvem, os arquivos são enviados a um provedor da nuvem que será responsável por armazenar e fazer backup destes arquivos.

As vantagens deste sistema são:

• Baixo custo, custam centavos por GB de armazenamento, por mês.
• Backup automático
• Administração fácil feita através de um website, muitas fontes de ajuda para resolver os problemas de configuração.
• Não há necessidade de alocação de hardware/máquinas para armazenar estes arquivos.
• Segurança, geralmente estes provedores possuem vários certificados de segurança de armazenamento e configuração que não são tão fáceis de obter, muito menos baratos. Neste tipo de sistema estes certificados já estão disponíveis.

Nas desvantagens podemos citar:

• Privacidade dos dados, já que não temos controle de quem acessará os dados.
• Uso de banda, pois os arquivos deverão ser enviados pela internet, e com isso consumirão banda de acesso a internet.
• Performance mais baixa que dependerá da velocidade e estabilidade do seu acesso a internet.

Tipos de Sistemas de arquivos

Sistemas de arquivos são camadas de software responsáveis por armazenar os dados nos nossos dispositivos de hardware.

Os discos magnéticos eram distribuídos em trilhas, e dentro de cada trilha haviam bloos de dados. Existem uma série de validações de hardware que possibilitam a validação dos dados armazenados nestes sistemas.

Nos discos magnéticos, os dados que ficam mais próximos do centro, são acessados mais rapidamente, já que o sistema de leitura, descansa no centro dos hds. Por isso era preferível gravar os dados mais importantes nestas fileiras. Hoje isso mudou um pouco com os SSDs.

Inicialmente os sistemas de arquivos, reservavam um bloco, vamos assumir que de 32kb para cada arquivo. Isso foi feito para evitar ter que mover os dados toda vez que algo novo fosse acrescentado aquele arquivo. Porém isso fazia com que muit espaço, era disperdiçado, caso houvessem muitos arquivos pequenos. Um outro detalhe desta arquitetura é, quando um arquivo ultrapassava 32kb, um novo bloco deveria ser criado pra ele. Caso nenhum outro dado tivesse sido escrito no sistema, tudo certo, porém quando um outro bloco houvesse sido escrito, no hd, após aquele arquivo, isso fazia com que o arquivo ficasse fragmentado. A implicação disto é que o hd talvez precisasse ler diversas trilhas para ler um mesmo arquivo. Toda vez que um hd lia uma trilha, ele tinha que ler ela de forma completa, então se só um pedaço daquela trilha fosse usada, uma grande parte dos dados seria lida a toa. Colocar os arquivos em uma mesma sequência, garantia uma performance muito boa para este tipo de sistema de arquivos.

Os sistemas de arquivos podem ser divididos em três tipos, blocos, objetos ou arquivos.

Blocos

Nos sistemas de blocos, os dados são armazenados em blocos e ele foi feito em cima de uma abstração do que acontece nas camadas de hardware, cada bloco de dados é um bloco/trilha, do sistema de armazenamento de arquivos, fazendo com que fique muito fácil a conversão entre um e outro. Isso também torna estes sistemas bem rápidos.

Como os dados sempre são lidos um bloco por vez, ele casa muito bem com sistemas de backup, principalmente nas fitas magnéticas. Durante o processo de escrita, os dados são divididos em blocos, previamente especificados, e durante a leitura os dados são desempacotados.

Este tipo de sistema geralmente é interfaceado por um sistema de arquivos, ou um sistema de banco de dados, para interagir com o usuário.

Objetos

Nos sistemas de arquivos do tipo objetos, os dados são armazenados em forma de objeto, com isso, além dos dados, alguns metadados serão armazenados. Neste tipo de sistema, cada objeto possui um identificador global único, que identifica aquele objeto. 

Nestes sistemas o usuário não consegue alterar o tipo do sistema de arquivo, nem o tamanho da unidade de armazenamento.

Arquivos

Os sistemas do tipo arquivos são os mais conhecidos por nós, os dados são divididos em arquivos, seus caminhos e nomes identificam ele, sua extensão ou cabeçalho identificam o seu tipo e cada tipo de arquivo é armazenado com a sua formatação específica, por exemplo um arquivo texto é armazenado de acordo com a tabela ASCII ou UTF, já um arquivo de imagem é armazenado de acordo com a formatação daquele tipo de imagem.

Exemplos:

Abaixo serão explicados alguns tipos de sistema de arquivos distribuídos.

Gluster

O nome gluster vem de GNU + Cluster, e ele foi originalmente escrito por Anand Babu Periasamy, foi lançado como software de uma empresa chamada Gluster, a qual depois foi adquirida pela RedHat. Este sistema é baseado no GlusterFS, que é um sistema de arquivos de rede opensource, que pode ser instalado em máquinas comuns, com ele é possível escalar até Petabytes.

Existem imagens de máquinas configuradas com o gluster prontas para serem utilizadas em provedores cloud como o a Amazon e a Azure.

O GlusterFS é capaz de mapear diversos sistemas de armazenamento, em um único sistema global de nomes, que permite que os arquivos sejam disponibilizados para diversas máquinas como se fossem local. Ele se adéqua bem para sistemas que usam muitos dados (data intensive) e em provedores de sistemas stream.

Sua arquitetura é baseada em um software servidor, que será instalado nas máquinas que possuem os sistemas de armazenamento que serão compartilhados e armazenarão os arquivos, e softwares clientes, que são nativos ao linux e são usados para armazenar os dados.

Um arquivos deve ser copiado em diversas máquinas, para garantir acessibilidade, e ele também pode ser dividido em partes, afim de aumentar a performance, quando isso acontece ele poderá ser escrito e lido, em paralelo. Máquinas que possuem o cliente instalado, podem montar um sistema de arquivos localmente, seu acesso também pode ser realizado por sistemas NFS versão 3, que é um padrão comum de comunicação de arquivos pela rede.

Ceph

Ceph é um sistema de arquivos distribuídos, que implementa armazenamento do tipo objeto, em cluster de máquinas comuns. Este sistema replica os arquivos, de maneira a ficar tolerante a falhas sem precisar de uma especificação ou configuração de hardware. O ceph possui três interfaces de acesso, uma por blocos, outra por arquivos e uma outra por objetos. Com ele é possível escalar até exabytes, sua grande vantagem é não ter um ponto simples de falha. Este sistema foi inicialmente criado por Sage Weil na sua tese de doutorado.

O ambiente do Ceph é composto por 5 softwares, os monitores de cluster, os sistemas de armazenamento de objetos, os servidores de metadados, os gateways http e os admnistradores, cada um deles rodando independentemente, podendo ser numa mesma máquina.

Ele divide os arquivos em múltiplas máquinas, de uma maneira semelhante ao que faz o Raid0. Um outro ponto interessante é que ele possui um load balance adaptativo, que faz com que os arquivos mais utilizados, sejam compartilhados e divididos de maneira que os dados sejam acessados mais rapidamente.

Com o Ceph é possível montar o sistema de arquivos distribuídos localmente, e todo o seu ambiente cuida de como e quando partilhar e replicar os arquivos. Ele implementou um sistema de backend de armazenamento que faz com que a latência de leitura e escrita dos dados seja muito baixa.

Em 2014 a RedHat comprou a empresa que era responsável pela implementação e suporte do Ceph.

DFS Distributed File System

Este é um sistema que foi criado para compartilhar arquivos em máquinas que usam o sistema operacional windows. Este sistema possui dois componentes, o componente localizador e o componente de redundância. 

O localizador serve para encontrar onde estão localizados os arquivos, e o componente de redundância será responsável por copiar os arquivos em múltiplas localidades, para evitar problemas em falhas, ou quando houver grande acesso aos dados.

A partir da versão 2003 R2 do windows, houve uma melhora no sistema redundante, fazendo com que ele copiasse apenas as partes alteradas dos arquivos e com isso a performance do sistema melhorou bastante, assim como diminui a exigência do hardware de rede.

HDFS é um outro tipo de sistema de arquivos, mas ele já foi explicado aqui.

Apresentação

Sistemas distribuídos baseado em objetos

Sistemas distribuídos baseado em objetos

Em um sistema distribuído temos muitos processos diferentes, rodando em diversas máquinas diferentes e trocando dados entre si. Uma das maneiras de se estabelecer uma comunicação entre dois processos é possível ser realizada se estabelecermos um protocolo de troca de dados entre eles, como o TCP.
Caso um processo A deseja receber o cálculo do determinante de um número inteiro n, ele pode realizar esta operação da seguinte forma:

det = determinante_matriz(n)

Porem, caso o processo A não saiba realizar o cálculo do determinante de uma matriz e o processo B sabe, esta chamada então, pode ser realizada da seguinte maneira.

stream = abreConexao(porta_processoB);
write(stream, "determinante_matriz"); // envia um comando
write_matrix(stream, n); // envia argumentos
read(stream, &det); // pega o resultado
fecha_conexao(stream);

Agora suponha que A e B sejam sistemas baseados em objetos, não importa qual linguagem seja utilizada, um objeto é a mesma coisa em qualquer linguagem, basicamente uma lista de argumentos e métodos. A transmissão de um objeto entre estes dois sistemas pode ser transparente, caso os dois sistemas concordem na definição de um objeto. A conexão e transmissão pode ser realizada automaticamente.

O que é um sistema distribuído baseado em Objetos?

Um sistema distribuído baseado em objetos é exatamente isto. Assim que um objeto é definido em uma linguagem descritiva genérica, um gerador de interfaces é executado e produz definições específicas de linguagens e rotinas de como transmitir os objetos entre programas. Com isso, cada programa se torna um sistema de cliente/servidor para alguns objetos específicos.
Portanto nenhuma das partes precisa conhecer os detalhes da outra. Cada um dos softwares registram os tipos de objetos disponíveis, para comunicação como um tipo ORB (Object Request Broker). Quando um programa A necessita de um serviço, ele irá se conectar ao ORB, que fará o roteamente o colocará o programa A em contato com o softaware provedor do objeto requisitado. A sequencia de chamadas agora ficará da seguinte forma.

Programa A                           Programa B
inclui geraMatriz.h                inclui geraMatriz.h
                                               contacta_ORB(objetoORB);
                                               prove_servico_ORB(objetoORB, ClasseMatriz);
 contacta_ORB(objetoORB);
requisita_servico_ORB(objetoORB, ClasseMatriz);
ClasseMatriz minhaMatriz = new (...);
det = minhaMatriz.determinante();
Com isso a chamada ao método determinante da classe MinhaMatriz é transparente, o programa B manda uma matriz e a chamada ao método espera por uma resposta. O código tanto de A, quanto de B é bem mais simples.

Como isso funciona?

A classe MinhaMatriz é definida em uma linguagem de descriçao genérica, onde são especificadas os seus conteúdos e os métodos públicos. Esta linguagem geralmente é chamada de IDL (Interface Description Language). Em um primeiro passo da compilação, o arquivo MinhaMatriz.idl é traduzida em todas as linguagens definidas pelo sistema, como Java, C++, Lisp, etc...). Após isso, cada programa irá pegar os arquivos gerados para a sua linguagem e incluí-los em seu classpath.
O código gerado contem não apenas os seus atributos, como também os métodos que são utilizados para quebrar a classe em componentes (processo conhecido como marshalling), que serão enviados através de uma conexão ao outro programa, e ao ser recebido (o processo de unmarshalling) será responsável por reconstruir o objeto na outra ponta.

Problemas:

Tudo isso é bem simples quando estamos trabalhando com uma mesma linguagem, porém passar objetos entre linguagens diferentes, como Java, List, etc, é bem complicado, pois geradores de ORB diferentes serão utilizados.

Padrões

CORBA(Common Object Request Broker) gerado pela OMG define um padrão de implementação para o ORB. A última especificação do CORBA, que consta no site da OMG é a 3.1.1 de 2012.
O CORBA é uma especificação que vem crescendo ao longo dos anos, devido a sua facilidade de utilização, funcionalidade e portabilidade entre linguagens. CORBA é bem utilizada nas grandes empresas, onde muitos sistemas interagem, interagem entre si, e sistemas antigos não podem ser desligados (vide nossos bancos). O CORBA prove uma forte ligação entre linguagens e/ou plataformas diferentes, e a sua única limitação é ter uma implementação CORBA para cada uma das linguagens/plataformas necessárias.
Existem várias implementações da especificação do CORBA, como o Visibroker da Borland. Empresas como a Oracle a IBM também possuem suas implementações desta especificação.
Java tem uma implementação de RPC/ORB chamada RMI (remote method invocation), que possui algumas semelhanças com o CORBA e suas principais diferenças são. No RMI podemos enviar objetos como parâmetros, enquanto que no CORBA devemos enviar apenas tipos primitivos ou estrutura de dados. Além disto, no RMI é possível enviarmos implementações de código entre as máquinas, permitindo que tenhamos um servidor como provedor de código remoto.

Java RMI

Tutoriais de java RMI
DevMedia Portugues
Oracle Inglês

A apresentação se encontra neste arquivo zip