Sistemas Distribuidos…

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 tive 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 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 oferecido a partir do que ainda "o outro computador empresa".

A CII - HB participação nesse projeto foi inspirado pelo anterior CII investimento em NNA (New Network Architecture), que significativamente aproximar - se do mercado HDSA. Ambos, a CII - HB e da Honeywell desenhistas foram muito ativa, respectivamente, em ECMA e ANSI padronização comissões desenhando o 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 bases de dados distribuídas e aplicações.


Conjuntos de elementos de processamento independentes, que comunicam unicamente via mensagens.

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 distríbuidos 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 distríbuidos
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 (ex. arquitecturas RMI, SOAP e…CORBA!)