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.
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!).
A Decisão que a empresa iria tomar seria escolher a estratégia que maior valor global apresentasse, no entanto, podemos ainda considerar a situação de que a empresa não é indiferente ao risco, como no caso apresentado mas sim aversa ao risco, para este caso as alterações que teriamos na nossa árvore de decisão seriam nada mais do que atribuir a cada um dos ramos da estratégia uma ponderação que reflectisse esse comportamento como por exemplo, atribuir uma ponderação de 0,3 á estratégia com maior risco, isto é com maior P(I) vs uma ponderação de 0,7 á estratégia com menor P(I) e incluir esse valor no apuramento do valor global das estratégias antes de se proceder à comparação dos mesmos.
