← Voltar ao Portal da Disciplina
Conheça meu trabalho como perito
← Voltar ao Portal da Disciplina
Conheça meu trabalho como perito📅 16 de Março de 2026
🕒 19h - 21h30
"Um sistema distribuído é uma coleção de computadores independentes que se apresenta aos seus usuários como um sistema único e coerente."
— Tanenbaum & Steen (2007)
Componentes executam tarefas simultaneamente em diferentes nós da rede (Coulouris, 2013).
Diferente de sistemas locais, em um SD, um nó pode falhar enquanto outros continuam operando (Monteiro, 2020).
A rede deixa de ser um "cabo" e passa a ser um componente ativo e incerto.
Componentização: Segundo Coulouris et al. (2013), a componentização permite que sistemas distribuídos sejam estendidos e reconfigurados de forma independente, facilitando a evolução do software através de unidades autônomas que interagem via interfaces bem definidas.
Middleware: Conforme definido por Tanenbaum & Steen (2007), o middleware atua como uma camada de software que provê um modelo de programação comum, mascarando a heterogeneidade dos nós e permitindo que componentes distintos operem como um sistema único e transparente.
Interoperabilidade: A visão moderna de Monteiro et al. (2020) reforça que o sucesso da distribuição reside na capacidade de comunicação entre sistemas heterogêneos, garantida pelo uso rigoroso de padrões de projeto e protocolos de rede.
O App solicita a lista de filmes via API.
Autentica o usuário e roteia o pedido.
O componente busca os dados no NoSQL.
O "Pulo do Gato": Se o Nó B falhar, o Middleware redireciona para uma réplica. O usuário nem percebe a falha. Isso é a Transparência de Falha descrita por Coulouris (2013).
✔ Compreendo por que um Sistema Distribuído é diferente de um Monólito?
✔ Sei explicar o papel do Middleware como "camada de transparência"?
✔ Entendo que a falha em SD é parcial e precisa ser tratada?
A integração de sistemas heterogêneos exige que a comunicação ignore a implementação interna e foque estritamente em interfaces bem definidas. Segundo Coulouris et al. (2013), essa formalização é o que permite que componentes escritos em diferentes linguagens e rodando em diversos SOs colaborem de forma confiável.
Protocolos proprietários e acoplamento forte.
Interoperabilidade baseada em padrões abertos.
"O contrato garante que o provedor e o consumidor do serviço falem a mesma língua."
A arquitetura SOA (Service-Oriented Architecture) não é um software, mas um estilo para organizar recursos de TI em serviços reutilizáveis. Para Monteiro et al. (2020), o foco reside na agilidade organizacional e na redução do tempo de resposta ao mercado.
Serviços funcionam de forma independente, sem conhecer a tecnologia vizinha.
Regras rígidas de entrada e saída, garantindo que o diálogo nunca falhe.
Novas soluções são criadas apenas combinando serviços já existentes.
💡 Caso Colégio Mirassol: Ao criar um Serviço de Mensalidade, o colégio pode usá-lo tanto no App dos pais quanto na Secretaria, sem precisar programar a lógica financeira duas vezes.
O SOAP (Simple Object Access Protocol) é um protocolo baseado em XML que define um framework de mensagens para troca de informações estruturadas. Conforme Tanenbaum & Steen (2007), sua força reside na padronização e na capacidade de atravessar firewalls via HTTP.
"Diferente do REST, o SOAP é independente do protocolo de transporte (pode rodar em SMTP, FTP ou TCP)."
O REST (Representational State Transfer) utiliza a infraestrutura nativa da Web para a comunicação. Para Monteiro et al. (2020), sua simplicidade e natureza stateless o tornam o padrão ideal para a escalabilidade em nuvem.
| Verbo HTTP | Ação (CRUD) | Exemplo de Endpoint |
|---|---|---|
| GET | Leitura / Busca | /alunos/123 |
| POST | Criação | /alunos |
| PUT / PATCH | Atualização | /alunos/123 |
| DELETE | Exclusão | /alunos/123 |
"No REST, as URIs identificam Substantivos (Recursos), enquanto os verbos HTTP definem as Ações."
A escolha entre SOAP e REST não é sobre qual é "melhor", mas qual atende aos requisitos do projeto. Para Monteiro et al. (2020), entender esses trade-offs é vital para a arquitetura de sistemas escaláveis.
| Característica | SOAP (Rigor) | REST (Agilidade) |
|---|---|---|
| Formato de Dados | Apenas XML | JSON (leve), XML, HTML |
| Protocolo | Independente (HTTP, SMTP, etc.) | Estritamente HTTP / HTTPS |
| Estado (State) | Pode ser Stateful | Obrigatoriamente Stateless |
| Cache | Não cacheável nativamente | Nativo e eficiente (Performance) |
| Melhor Uso | Sistemas Bancários / Segurança | Web APIs / Apps Mobile / Cloud |
Dica do Analista: O SOAP exige mais banda devido ao XML pesado. O REST economiza recursos, sendo vital para dispositivos móveis com conexões instáveis.
A gestão do "Estado" define como o servidor lembra de interações passadas. Conforme Tanenbaum & Steen (2007), a escolha entre manter ou não o estado impacta diretamente a tolerância a falhas do sistema.
O servidor guarda a memória da conversa. Cada requisição depende do que aconteceu na anterior.
O servidor não guarda memória. Cada requisição deve conter toda a informação necessária (Self-contained).
"No modelo Stateless, se um servidor falha, qualquer outro nó pode assumir a requisição imediatamente."
— Monteiro et al. (2020)
O servidor abre um "envelope" para o cliente e o mantém aberto.
Risco: Se o servidor reiniciar ou o cliente for direcionado para outro nó, o "envelope" é perdido.
(Ref: Tanenbaum & Steen, 2007)
O cliente carrega seu próprio "envelope" (Token/JSON) e o apresenta em cada pedido.
Vantagem: Qualquer servidor pode atender o cliente a qualquer momento.
(Ref: Monteiro et al., 2020)
"No Stateless, a transação é autocontida. No Stateful, a transação é fragmentada e dependente de histórico."
GET /laudo/45
200 OK (JSON)
"A transparência de acesso é garantida quando o cliente interage com a interface do serviço sem preocupar-se com a localização do dado."
— Coulouris et al. (2013)
Cenário: O Colégio precisa integrar o sistema de Notas com o App dos Pais. Você deve definir os contratos de interface.
POST /notas
(Para criar um novo registro no banco)
"A modelagem correta de URIs é o primeiro passo para a escalabilidade horizontal."
— Monteiro et al. (2020)
POST /getNotasAlunos?id=123
GET /alunos/123/notas
Fundamentação:
Ao utilizar GET /alunos/{id}/notas, criamos uma interface autodocumentada e previsível. Segundo Coulouris et al. (2013), essa padronização reduz a carga cognitiva do desenvolvedor que irá consumir o serviço, facilitando a interoperabilidade entre o sistema acadêmico e o App mobile.
"A arquitetura moderna privilegia o REST pela aderência aos princípios de sistemas abertos."
— Monteiro et al. (2020)
É a "lei" do sistema. Define como os componentes conversam (Verbos e URIs), independente da linguagem (Java, Node, Python).
Ref: Coulouris et al. (2013)
O servidor não guarda passado. Cada requisição é autocontida. Sem isso, não há escalabilidade em nuvem.
Ref: Tanenbaum & Steen (2007)
Sem contrato, não há conversa. Sem Stateless, não há escala.
Sua opinião é fundamental para o ajuste contínuo da nossa disciplina.
Seu voto é anônimo.
Próxima Aula: Implementação prática de Microserviços e Segurança em APIs.
Até breve, Analistas!