Padrões de
objetos
distribuídos
Ricardo Martinho
Desenvolvimento de Aplicações Empresariais
DEI – ESTG – Instituto Politécnico de Leiria
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Guias e Dicas
Prepare-se para as provas
Estude fácil! Tem muito documento disponível na Docsity
Encontrar documentos
Prepare-se para as provas com trabalhos de outros alunos como você, aqui na Docsity
Encontra documentos específicos para os exames da tua universidade
Encontra documentos específicos para os exames da tua universidade
Videoaulas
Prepare-se com as videoaulas e exercícios resolvidos criados a partir da grade da sua Universidade
Quiz
Responda perguntas de provas passadas e avalie sua preparação.
Ganhe pontos para baixar
Ganhe pontos ajudando outros esrudantes ou compre um plano Premium
Falácia dos Objetos Distribuídos e Interfaces Remotas e Locais, Resumos de Informática
Este documento discute as falácias comuns na distribuição de objetos em aplicações empresariais, incluindo a transparência falsa de middleware, a necessidade de interfaces remotas e locais diferentes e o custo de invocações remotas. O texto também apresenta soluções alternativas, como o remote facade e o data transfer object.
Tipologia: Resumos
2020
1 / 23
Esta página não é visível na pré-visualização
Não perca as partes importantes!
Documentos relacionados
Pré-visualização parcial do texto
Baixe Falácia dos Objetos Distribuídos e Interfaces Remotas e Locais e outras Resumos em PDF para Informática, somente na Docsity!
Padrões de
objetos
distribuídos
Ricardo Martinho ([email protected]) Desenvolvimento de Aplicações Empresariais DEI – ESTG – Instituto Politécnico de Leiria
A falácia dos objetos
distribuídos…
O que muitos fabricantes de ferramentas e
frameworks de software apregoam…
“Podemos agarrar num conjunto de objetos e
distribuí-los como quisermos por nodos (ou
nós) de processamento:”
(^) “Vamos ter um grande aumento de desempenho na aplicação!”
“O nosso middleware é poderoso na medida
que fornece total transparência:”
(^) “Os objetos invocam-se entre eles, sem terem de saber se o invocador está no mesmo processo, noutro processo ou mesmo noutra máquina!”
Interfaces remotas e locais (^) Distribuir objetos colocando as respetivas classes em máquinas diferentes nem sempre é a melhor solução: (^) Uma invocação a um procedimento (método) dentro do mesmo processo é muito, muito rápida; (^) Uma invocação a um procedimento entre dois processos separados é muito mais lenta… (^) …e se esses processos estiverem a correr em máquinas diferentes, ainda mais lenta se torna, ficando dependente da topografia da rede… (^) Consequentemente, as interfaces remota e local para um mesmo objeto têm de ser diferentes.
Interfaces remotas e locais
(cont.)
(^) A interface local: (^) Deve ser mais detalhada, com nível de granularidade maior ( fine-grained ). (^) Exemplo: para uma classe Morada, a interface deve definir separadamente getters e setters para os atributos rua, numero, localidade, codigo_postal); (^) Segue o princípio geral de POO onde podemos combinar e sobrepor muitas “peças” pequenas de várias formas para estender o design no futuro…
Interfaces remotas e locais
(cont.)
(^) O que os fabricantes de ferramentas e frameworks de software apregoam… (^) “Não existe overhead ao utilizarem o nosso middleware para invocações remotas ou locais…” (^) Verdade, mas não evita o ponto essencial: um objeto que pode ser utilizado remotamente deve ter uma interface menos detalhada do que outro a ser utilizado localmente… (^) Solução de compromisso entre granularidade e o custo de uma invocação remota + um modelo de programação mais estranho…
Interfaces remotas e locais
(cont.)
(^) Portanto, o objetivo passa por minimizar a quantidade de colaborações inter-processos ; (^) Não basta agarrar num conjunto de classes e “atirar-lhes para cima” uma framework de distribuição de objetos (e.g. Java RMI); (^) Vai originar uma grande quantidade de invocações remotas, e a necessidade de definir interfaces menos detalhadas… (^) …e mesmo assim, ficamos com muitas invocações remotas, e um sistema com pouca flexibilidade e capacidade de evoluir…
E quando temos mesmo de
distribuir?
(^) Evitar ao máximo a distribuição, eliminado as possíveis interações entre processos; (^) Adotar algumas estratégias de distribuição:
- Através de uma arquitetura cliente-servidor: (^) São necessários processos separados: os que correm nos PCs dos utilizadores, e os que correm nos servidores (^) É necessário que estes processos comuniquem.
- Entre o servidor aplicacional e a base de dados; (^) Não temos de o fazer necessariamente. Exemplo: pode programar-se muita lógica de negócio utilizando stored procedures ; (^) Não é prático… (^) Se o fizermos, já estamos a pagar um custo! (Felizmente que o SQL é desenhado como uma interface remota, pelo que o custo sai minimizado).
E quando temos mesmo de
distribuir? (cont.)
(^) Adotar algumas estratégias de distribuição (cont.):
- Entre o servidor Web e o servidor aplicacional: (^) É sempre melhor correr ambos os servidores num único processo, mas nem sempre é possível nem desejável…
- Distribuição devido à inclusão de packages de diferentes fabricantes de software: (^) Normalmente, correm num processo à parte. Um bom package deverá implementar uma boa interface remota ( coarse-grained );
- Outras razões para separar o software no servidor aplicacional: (^) Evitar ao máximo! (^) Dividir o software em componentes remotos, coarse- grained.
Remote Facade (^) Provides a coarse-grained facade on fine- grained objects to improve efficiency over a network.
Remote Facade (^) Utilizam-se objetos e invocações fine-grained num único processo, e coloca-se uma fachada (interface remota, coarse-grained ) sobre esses objetos na fronteira da distribuição; (^) Consegue-se o melhor dos 2 mundos: mais detalhe nas invocações locais, e uma interface remota optimizada para invocações inter-processos; (^) A Remote Facade não tem lógica de negócio… (^) A única função é traduzir os métodos com menos detalhe ( coarse-grained ) da fachada para os métodos com mais detalhe ( fine-grained ) dos objetos para a qual está a servir de fachada.
Remote Facade (^) Se as classes dos objetos fine-grained estão disponíveis em ambos os lados da ligação: (^) Posso transferi-los diretamente por cópia. Por exemplo: (^) getDadosMorada() - cria uma cópia do objeto original Morada; (^) setDadosMorada()- recebe um objeto Morada e utiliza-o para atualizar os dados de um objeto Morada já existente. (^) No entanto, pode ser difícil ou mesmo impossível “duplicar” o modelo de domínio em ambos os lados da ligação… (^) Pode não ser desejável… (^) Pode ser difícil serializar parte de um modelo de domínio (somente aquela que um cliente quer), devido à sua rede de associações complicada. >>>
Data Transfer Object (DTO) (^) An object that carries data between processes in order to reduce the number of method calls.
Data Transfer Object (DTO)
Porque não transferir um modelo de
domínio, em vez de um DTO?
Os modelos de domínio são muito complexos
em termos de número de objetos e respetivas
associações.
(^) Difíceis (senão impossíveis) de serializar!
Os atributos de um DTO devem ser de tipos
simples:
(^) Primitivos, classes simples (strings, datas, ou outros DTOs!). (^) Muitas vezes são desenhados tendo em conta determinado objeto/aplicação cliente (e.g.: DTOs para uma página Web).
Data Transfer Object (DTO) (^) Formas mais comuns: (^) Record Sets – por exemplo para transferir dados de uma BD SQL; (^) Collections – dicionários (e.g. Hashtables) são melhores que arrays … (^) Os índices dos arrays condicionam o código; (^) Nos dicionários podem utilizar-se strings com significado como chaves.