Distributed Systems - Sistemas Distribuídos

O que é que isto vos faz lembrar? Alguém? Ninguém? Eu? Está bem…faz-me lembrar Corba! ‘Cooorba?!’ Sim, isso! Porque nos tempos auges da faculdade, para estudar a concepção de aplicações distribuídas tínhamos de aprender esta arquitectura! Um autêntico pesadelo! Mas vamos ao que interessa…

O que é realmente um sistema distribuído?

Basicamente, é um conjunto de computadores ligados em rede, com software que permita a partilha de recursos e a coordenação de actividades, possibilitando um ambiente integrado.

O Nascimento desta arquitectura:

No final dos anos 1970s CII – Honeywell e Honeywell da Bull Information Systems realizaram um esforço de modo a projectar uma arquitectura que pudesse competir com a IBM SNA, mas com uma maior flexibilidade.

Honeywell tinha elaborado um anteprojecto de uma arquitectura distribuída chamada HDSA (Honeywell Distributed System Architecture), que tinha por objectivo renovar a Series 60, uma linha de produtos que foi anunciado em 1978 com um sufixo DPS. Foi pensado como uma alternativa para IBM's SCN, a partir da analogia ao "o outro computador da empresa".

A CII – HB, que participou nesse projecto foi inspirado pelo anterior CII investimento em NNA (New Network Architecture), aproximou-se significativamente do mercado HDSA. A CII – HB e a Honeywell, que desenharam a arquitectura de uma forma muito activa, respectivamente, em ECMA e ANSI – padronização de comissões em ISO/normas OSI (Open Communications System).

Esse esforço foi dado o nome de DSA – Distributed System Architecture; Ele abarcariam as estritas funções de rede e foi projectado para ser estendido em BD’s distribuídas e em aplicações.

Características (vantajosas, obviamente) de um sistema distribuído:

• Partilha de Recursos

• Hardware: impressoras, discos, etc;
• Dados – ferramentas de trabalho cooperativo; bases de dados;
• Interfaces;
• Motiva o modelo cliente-servidor.

• Abertura

• Extensibilidade de software e hardware, com possível heterogeneidade;
• Obtida especificando e documentando interfaces;
• Possui mecanismos uniformes de comunicação entre processos.

• Concorrência

• Vários utilizadores podem invocar vários comandos simultaneamente;
• Um servidor deve responder concorrentemente a vários pedidos;
• Vários servidores correm concorrentemente, possivelmente na resolução de pedidos.

• Escalabilidade

• O software pode ser pensado de modo a funcionar em grandes sistemas nem necessidade de mudança;
• Devem ser evitados algoritmos e estruturas de dados centralizados.

• Tolerância a faltas

• Faltas em elementos de processamento e comunicação;
• Solução pode passar por redundância de hardware e replicação de servidores/serviços;
• Motiva paradigmas mais avançados do que o cliente-servidor. Exemplo: comunicação em grupo, algoritmos de acordo, transacções;
• Em sistemas de distribuídos a disponibilidade perante a faltas pode ser maior do que em sistemas centralizados, mas exige uma maior complexidade do software.

• Transparência

• O sistema deve ser visto como um todo e não como uma colecção de componentes distribuídos;
  
• Exºs de transparência: acessos, localização, concorrência, replicação, falhas, migração, desempenho, escalabilidade.

Desenho lógico e físico de um sistema distribuído:

Aplicações Integradas:

• Middleware de BD (SQL, ODBC);
• Middleware de Aplicação;
• Middleware de WEB (CGI, ActiveX, Java);
• Remote Procedure Call (RPC);
• Middleware Orientado à Mensagem;
• Monitores de Processos de Transacção;
• Middleware Orientado aos Objectos (por exemplo em arquitecturas RMI, SOAP e…CORBA!).