Este documento descreve padrões de projeto de middleware, incluindo: 1) Padrões básicos de comunicação remota como Requestor, Client Proxy e Invoker; 2) Padrões de identificação como Object ID e Absolute Object Reference; 3) Padrões de gerenciamento de ciclo de vida como Static Instance, Per-Request Instance e Client-Dependent Instance.

1. PADRÕES DE PROJETO DE
MIDDLEWARE
VICTOR HAZIN DA ROCHA

2. O QUE É UM
MIDDLEWARE ?

3. O QUE É UM MIDDLEWARE ?
▸ Depende...
▸ API que facilita a construção de sistemas distribuídos;
▸ Camada de software;
▸ Sistema;
▸ Camada de rede;
▸ Coleção de serviços distribuídos;
▸ “Socket turbinado”;

4. O QUE É UM MIDDLEWARE ?
▸ Software de Comunicação
▸ Camada de software entre SO e aplicação
▸ Implementação de camadas de REDE.

5. O QUE É UM PADRÃO
DE PROJETO?

6. O QUE É UM PADRÃO DE PROJETO
▸ Padrão de Projeto:
▸ SOLUÇÃO RECORRENTE para um PROBLEMA padrão
em um CONTEXTO particular;
▸ Solução de sucesso para problemas comuns;
▸ Linguagem de padrão de projeto:
▸ Padrões de projetos relacionados colocados juntos.

7. DESCRIÇÃO DE UM PADRÃO DE PROJETO
1. Nome;
2. Contexto;
3. Detalhe do problema;
4. Solução;
5. Cenário de uso;
6. Detalhe da Solução;
7. Consequências.

8. TÓPICOS “TERCEIRIZADOS" PELAS APLICAÇÕES
▸ Estabelecimento de conexões e inicialização de serviços;
▸ Demultiplexação e dispatching de eventos;
▸ Comunicação entre processos e protocolos de rede;
▸ Gerenciamento de armazenamento secundário e cache;
▸ Configuração de componente estático e dinâmico;
▸ Sincronização e concorrência.

9. ▸ Padrões remotos básicos;
▸ Padrões de identificação;
▸ Padrões de ciclo de vida;
▸ Padrões de extensão;
▸ Padrões de infra-estrutura estendido;
▸ Padrões de invocação assíncrona.
CATEGORIAS DE PADRÕES DE PROJETO DE MIDDLEWARE

10. PATTERN LANGUAGE
OVERVIEW

11. PADRÃO DE PROJETO: BROKER
▸ CONTEXTO:
▸ Projeto de um sistema distribuído;
▸ PROBLEMA:
▸ Comunicação não confiável através da rede Integração
de componentes heterogêneos Uso eficiente dos
recursos da rede;
▸ SOLUCÃO:
▸ Separar questões de comunicação em um broker;
▸ O broker esconde e media todas as comunicações entre
objetos;

12. PADRÃO DE PROJETO: BROKER

13. PADRÃO DE PROJETO: REMOTE OBJECT
▸ A aplicação é construída como uma coleção de objetos
remotos.

14. PADRÃO DE PROJETO: REMOTE OBJECT
▸ Não é participante do Broker;
▸ Implementado pelas aplicações que usam o Broker;
▸ Invocações atravessam processos e os limites das
máquinas;
▸ Latência e não confiabilidade da rede devem ser
considerados;
▸ Objetos não são únicos entre as máquinas.

15. PADRÃO DE PROJETO: SERVER APPLICATION
▸ Objetos remotos precisam de um servidor.

16. PADRÃO DE PROJETO: SERVER APPLICATIONS
▸ Gerencia o ciclo de vida dos objetos remotos e dos
componentes do middleware;
▸ Anuncia objetos remotos para os clientes (Lookup);
▸ Conecta objetos remotos a aplicação distribuída;
▸ Destrói objetos remotos.

17. BASIC REMOTTING
PATTERNS

18. BASIC REMOTTING PATTERNS

19. PADRÃO DE PROJETO: REQUESTOR
▸ CONTEXTO:
▸ Um cliente precisa acessar um ou mais objetos remotos;
▸ PROBLEMA:
▸ Execução do marshalling (linguagem → byte stream)
▸ Uma conexão precisa ser estabelecida;
▸ A solicitação precisa ser enviada para o objeto remoto;
▸ SOLUCÃO:
▸ Usar um Requestor para acessar o objeto remoto;
▸ Fornecer ao Requestor uma referência absoluta do objeto remoto,
nome da operação e argumentos;
▸ O Requestor constrói a invocação e envia ao objeto remoto.

20. PADRÃO DE PROJETO: REQUESTOR

21. PADRÃO DE PROJETO: CLIENT PROXY
▸ CONTEXTO:
▸ Um Requestor é fornecido pelo middleware;
▸ PROBLEMA:
▸ Acesso remoto e local similares;
▸ Requestor resolve parte do problema escondendo detalhes da rede, no
entanto, nome do método, argumento, localização e identificação precisam ser
passados para o Requestor a cada invocação;
▸ Requestor não suporta checagem estática de tipos;
▸ SOLUCÃO:
▸ Client proxy possui a mesma interface do objeto remoto;
▸ Clientes interagem apenas com Client Proxy local;
▸ Client proxy traduz a invocação local em parâmetros para o Requestor e invoca
a solicitação.

22. PADRÃO DE PROJETO: CLIENT PROXY

23. PADRÃO DE PROJETO: INVOKER
▸ CONTEXTO:
▸ Requestor invoca um objeto remoto;
▸ PROBLEMA:
▸ Objeto remoto precisa ser alcançado de alguma forma;
▸ Solução simples: objeto remoto tem um endereço de rede;
▸ Endpoints (e.g., portas) insuficientes para o número de objetos;
▸ Objeto remoto tem que tratar com questões de rede, receber e
demarshalling de mensagens;
▸ SOLUCÃO:
▸ Invoker aceita invocações do Requestor;
▸ Invoker recebe a solicitação e executa o unmarshalling;
▸ Faz um lookup do objeto e encaminha a invocação para ele.

24. PADRÃO DE PROJETO: INVOKER

25. PADRÃO DE PROJETO: CLIENT REQUEST HANDLER
▸ CONTEXTO:
▸ Requestor envia requests e precisa receber as respostas;
▸ PROBLEMA:
▸ Tarefas executadas a cada request;
▸ Estabelecimento e configuração da conexão, tratamento do resultado,
tratamento de timeout e detecção de erro;
▸ Conexão e tratamento de thread coordenados;
▸ SOLUCÃO:
▸ Client Request Handler trata conexões de rede para todos os Requestors
em um cliente;
▸ Enviar requests, receber e encaminhar respostas e trata timeouts, threads
e erros.

26. PADRÃO DE PROJETO: CLIENT REQUEST HANDLER

27. PADRÃO DE PROJETO: SERVER REQUEST HANDLER
▸ CONTEXTO:
▸ Remote objects executam em um servidor e Invokers são usados para o
encaminhamento de mensagens
▸ PROBLEMA:
▸ Requests precisam ser recebidos da rede;
▸ Gerenciamento de canais de comunicação eficiente;
▸ A comunicação precisa ser coordenada e otimizada;
▸ SOLUCÃO:
▸ Server Request Handler trata todas as questões de comunicação no servidor
Recebe mensagens da rede;
▸ Combina fragmentos para completar a mensagem;
▸ Encaminha a mensagem para o Invoker correto;
▸ Gerencia todos os recursos (conexões, threads, etc).

28. PADRÃO DE PROJETO: SERVER REQUESTE HANDLER

29. PADRÃO DE PROJETO: MARSHALLER
▸ CONTEXTO:
▸ Requests e respostas precisam ser transportados através da rede;
▸ PROBLEMA:
▸ Dados dos requests:
▸ Object ID, nome da operação, parâmetros e valores de retorno;
▸ [informações de contexto];
▸ Apenas streams de bytes são transportados na rede;
▸ SOLUCÃO:
▸ Uso de marshallers no cliente e servidor que serializem os dados dos requests;
▸ Tipos (não)primitivos são serializados;
▸ Referências a objetos remotos são serializados como referências de objetos
absolutos.

30. PADRÃO DE PROJETO: MARSHALLER

31. PADRÃO DE PROJETO: INTERFACE DESCRIPTION
▸ CONTEXTO:
▸ Um cliente invoca uma operação a um Remote Object usando um Client Proxy;
▸ PROBLEMA:
▸ As interfaces do Client Proxy e Remote Object precisam ser compatíveis;
▸ Marshalling e unmarshalling precisam ser compatíveis;
▸ Desenvolvedores dos clientes precisam conhecer a interface do Remote
Object;
▸ SOLUCÃO:
▸ Interface Description descreve a interface do Remote Objects;
▸ Interface Description serve como um contrato entre o Client Proxy e o Invoker;
▸ Client Proxy e o Invoker usam geração de código ou técnicas de
reconfiguração para aderir ao contrato.

32. PADRÃO DE PROJETO: INTERFACE DESCRIPTION

33. PADRÃO DE PROJETO: REMOTING ERROR
▸ CONTEXTO:
▸ A comunicação remota é inerentemente não confiável;
▸ PROBLEMA:
▸ Acesso a Remote Objects pode não ser completamente
transparente (desejável) para os clientes;
▸ Erros que podem ocorrer:
▸ Falha na rede, queda do servidor, objetos indisponíveis, etc;
▸ Clientes não sabem como tratar estes erros;
▸ SOLUCÃO:
▸ Separar erros relacionados à distribuição e aplicação;
▸ Invoker, Requestor e Request Handlers detectam e propagam erros.

34. PADRÃO DE PROJETO: REMOTING ERROR

35. BASIC REMOTTING PATTERNS

36. INTERAÇÃO ENTRE OS PADRÕES

37. IDENTIFICATION PATTERNS

38. IDENTIFICATION PATTERNS

39. PADRÃO DE PROJETO: OBJECT ID
▸ CONTEXTO:
▸ O Invoker precisa selecionar um Remote Object para encaminhar
o request;
▸ PROBLEMA:
▸ Invoker trata invocações para vários objetos remotos;
▸ Invoker precisa determinar o Remote Object para um request
particular;
▸ SOLUCÃO:
▸ Associar instâncias de objetos remotos com um ID único no
contexto do Invoker;
▸ Cliente/Client Proxy precisa fornecer um ID único ao Requestor.

40. PADRÃO DE PROJETO: OBJECT ID

41. PADRÃO DE PROJETO: ABSOLUTE OBJECT REFERENCE
▸ CONTEXTO:
▸ O Invoker usa os IDs para encaminhar os requests;
▸ PROBLEMA:
▸ ID permite o Invoker encaminhar o request para o objeto correto, mas
primeiro o request precisa ser encaminhado para o Server Request
Handler correto;
▸ SOLUCÃO:
▸ Absolute Object Reference identifica unicamente o Invoker e o Remote
Object:
▸ Informação do endpoint (host, porta), ID do Invoker e ID do Objeto;
▸ Clientes referenciam objetos remotos usando Absolute Object
References.

42. PADRÃO DE PROJETO: ABSOLUTE OBJECT REFERENCE

43. PADRÃO DE PROJETO: LOOKUP
▸ CONTEXTO:
▸ Clientes querem usar serviços providos por Remote Objects;
▸ PROBLEMA:
▸ Cliente tem que obter uma Absolute Object References do
Remote Object;
▸ Remote object pode mudar (localização);
▸ SOLUCÃO:
▸ Serviço de Lookup é parte do middleware;
▸ Servidores registram referências de Remote Objects;
▸ Referências são associadas à propriedades (e.g. nomes).

44. PADRÃO DE PROJETO: LOOKUP

45. IDENTIFICATION PATTERNS

46. LIFECYCLE MANAGEMENT
PATTERNS

47. LIFECYCLE MANAGEMENT PATTERNS
▸ Servant é um objeto em tempo de execução que
representa o Remote Object.
▸ Tipos de objetos: stateful e stateless

48. PADRÃO DE PROJETO: STATIC INSTANCE
▸ CONTEXTO:
▸ Um Remote Object oferece um serviço que é independente de um cliente
específico;
▸ PROBLEMA:
▸ Número fixo de Remote Object previamente conhecidos;
▸ Remote Objects precisam estar disponíveis por um longo período;
▸ Não há timeout de expiração pré-determinado;
▸ Estado do Remote object precisa ser mantido;
▸ SOLUCÃO:
▸ Static Instances são independentes do estado e ciclo de vida do cliente;
▸ Ativados antes de serem usados (tipicamente no startup) pelos clientes;
▸ Instâncias são registradas no Lookup depois de suas ativações.

49. PADRÃO DE PROJETO: STATIC INSTANCE

50. PADRÃO DE PROJETO: PER-REQUEST INSTANCE
▸ CONTEXTO:
▸ Remote Objects que são stateless;
▸ PROBLEMA:
▸ Remote Objects são acessados por um grande número de clientes;
▸ Aplicações precisam ser escaláveis;
▸ Desempenho pode cair em função do overhead de sincronização
quando vários clientes acessam o Remote Object simultaneamente;
▸ SOLUCÃO:
▸ Um novo servant é instanciado para cada request;
▸ Servants tratam o request, retornam o resultado e são desativados.

51. PADRÃO DE PROJETO: PER-REQUEST INSTANCE

52. PADRÃO DE PROJETO: CLIENT-DEPENDENT INSTANCE
▸ CONTEXTO:
▸ Clientes usam serviços fornecidos por objetos remotos;
▸ PROBLEMA:
▸ Remote Object que estendem a lógica da aplicação do cliente;
▸ Ex: aplicação é composta pelo cliente e Remote Object;
▸ Onde colocar o estado de ambos?
▸ SOLUCÃO:
▸ Fornecer Remote Objects cujo tempo de vida é controlado
pelo cliente (criação + destruição);
▸ Cliente considera o estado de sua instância privado.

53. PADRÃO DE PROJETO: CLIENT-DEPENDENT INSTANCE

54. PADRÃO DE PROJETO: LAZY ACQUISITION
▸ CONTEXTO:
▸ Static Instances devem ser gerenciadas de forma eficiente;
▸ PROBLEMA:
▸ Criar servants para todos os Remote Objects na inicialização do servidor
pode causar perda de muitos recursos;
▸ Instanciar todos os servants durante a inicialização pode ser muito
demorado;
▸ SOLUCÃO:
▸ Instanciar os servants apenas quando eles são invocados pelos clientes;
▸ Remote objects estarão sempre disponíveis;
▸ Invoker dispara o gerenciador de ciclo de vida para instanciar o servant
tardiamente.

55. PADRÃO DE PROJETO: LAZE ACQUISITION

56. PADRÃO DE PROJETO: POOLING
▸ CONTEXTO:
▸ Toda instância do Remote Object consome recursos do servidor;
▸ PROBLEMA:
▸ Instanciar/destruir servants causa muito overhead: alocação de memória,
inicializações, Registro dos servants com o middleware;
▸ SOLUCÃO:
▸ Introduzir um pool de servants para cada tipo de Remote Object;
▸ Passo-a-passo:
1. Pegar um servant do pool;
2. Inicializá-lo;
3. Tratar o request;
4. Colocaro servant de volta no Pool.

57. PADRÃO DE PROJETO: POOLING

58. PADRÃO DE PROJETO: LEASING
▸ CONTEXTO:
▸ Clientes usam os recursos do servidor;
▸ PROBLEMA:
▸ Recursos (não mais utilizados) podem ser liberados;
▸ O Lifecycle Manager não pode determinar quando um Remote Object não será
mais usado;
▸ SOLUCÃO:
▸ Associar cada uso do cliente do Remote Object com um “lease”;
▸ Quando o “lease” (ou todos os “leases”) expirarem, o servant é destruído pelo
Lifecycle Manager;
▸ Clientes podem renovar o “lease”
▸ Invocando uma operação;
▸ Revocando explicitamente o “lease”.

59. PADRÃO DE PROJETO: LEASING

60. PADRÃO DE PROJETO: PASSIVATION
▸ CONTEXTO:
▸ Quando o servidor de aplicação fornece Remote Object stateful;
▸ PROBLEMA:
▸ Remote objects podem não ser acessados por um longo período;
▸ Os servants do Remote Object continuam usando recursos do servidor;
▸ Problemas de desempenho e estabilidade;
▸ SOLUCÃO:
▸ Passivação:
▸ Tornar Remote Objects (não acessados por um tempo) persistentes;
▸ Remover o servant da memória;
▸ Lifecycle Manager reativa o objeto na próxima invocação.

61. PADRÃO DE PROJETO: PASSIVATION

62. LIFECYCLE MANAGEMENT PATTERNS

63. LAYERS
ARCHITECTURE

65. LAYERS ARCHITECTURE
Application:
▸ The top-level layer of the message
processing architecture of
distributed object middleware
consists of clients that perform
invocations and remote objects
that serve invocations.

66. LAYERS ARCHITECTURE
Invocation:
▸ Beneath the application layer,
CLIENT PROXY, REQUESTOR, and
INVOKER are responsible for
marshaling/de-marshaling and
multiplexing/demultiplexing of
invocations/replies.

67. LAYERS ARCHITECTURE
Request Handling:
▸ In the next layer, the REQUESTOR
uses a CLIENT REQUEST
HANDLER, and the INVOKER is
served by a SERVER REQUEST
HANDLER.
▸ This layer is responsible for the
basic tasks of establishing
connections and message passing
between client and server.

68. LAYERS ARCHITECTURE
Communication:
▸ The communication layer is
responsible for defining the basic
message flow and managing the
operating system resources, such
as connections, handles, or
threads.
▸ Depending on the concrete
architecture, this layer uses the
Reactor [SSRB00] pattern and/or
Acceptor/Connector [SSRB00]
pattern.

69. EXTENSION
PARTTERNS

70. EXTENSION PARTTERNS

71. PADRÃO DE PROJETO: INVOCATION INTERCEPTOR
▸ CONTEXTO:
▸ Aplicações que precisam integrar serviços de forma transparente;
▸ PROBLEMA:
▸ Cliente e servidor de aplicação frequentemente precisam integrar
serviços: Transação, log e segurança;
▸ Clientes e Remote objects precisam ser independentes destes serviços;
▸ SOLUCÃO:
▸ Definir “ganchos” no caminho da invocação para conectar
interceptadores;
▸ Interceptadores são invocados antes e depois da invocação/resposta;
▸ Fornecer ao interceptador todas as informações (nome da operação, Id,
parâmetros, contexto) necessárias à execução do serviço.

72. PADRÃO DE PROJETO: INVOCATION INTERCEPTOR
The INVOKER receives an invocation and checks whether INVOCATION
INTERCEPTORS are registered for the remote object.
If so, the interceptor is invoked before and after the actual invocation

73. PADRÃO DE PROJETO: INVOCATION CONTEXT
▸ CONTEXTO:
▸ Serviços são adicionados ao middleware;
▸ PROBLEMA:
▸ Invocações remotas incluem apenas nome da operação, ID, parâmetros
▸ Interceptadores, em geral, precisam de informações adicionais;
▸ Mudar a assinatura da operação (para incluir as informações adicionais) é
tedioso e sujeito a erros;
▸ SOLUCÃO:
▸ Colocar informação contextual numa versão estendida da invocação;
▸ Contexto da invocação transferido do cliente para o objeto remoto a cada
invocação;
▸ Interceptadores podem ser usados para adicionar ou consumir estas
informações.

74. PADRÃO DE PROJETO: INVOCATION CONTEXT
The client invokes an operation. The REQUESTOR adds the required contextual
information in the INVOCATION CONTEXT.
The INVOKER extracts the information, uses it, and invokes the operation of
the remote object. Typically, the information is added and used by application-
specific INVOCATION INTERCEPTORS

75. PADRÃO DE PROJETO: PROTOCOL PLUGIN
▸ CONTEXTO:
▸ Client Request Handler e Server Request Handler aderem ao mesmo protocolo;
▸ PROBLEMA:
▸ Protocolos de comunicação podem ser configurados por desenvolvedores de
aplicações;
▸ Múltiplos protocolos precisam ser suportados;
▸ Protocolos especializados são necessários;
▸ Protocolos existentes precisam ser otimizados;
▸ SOLUCÃO:
▸ Plugins de protocolos podem estender o Client Request Handlers e o Server
Request Handler;
▸ Plugins devem possuir uma interface comum para permitir serem configurados
por camadas de mais alto nível.

76. PADRÃO DE PROJETO: PROTOCOL PLUGIN
The INVOKER receives an invocation and checks whether INVOCATION
INTERCEPTORS are registered for the remote object. If so, the interceptor is
invoked before and after the actual invocation

77. EXTENDED
INFRASTRUCTURE
PATTERNS

78. EXTENDED INFRASTRUCTURE PATTERNS

79. PADRÃO DE PROJETO: LIFECYCLE MANAGER
▸ CONTEXTO:
▸ O servidor de aplicação precisa gerenciar diversos tipos de ciclo de vida para
objetos remotos;
▸ PROBLEMA:
▸ Ciclo de vida de objetos remotos precisam ser gerenciados pelos servidores de
aplicação;
▸ Baseado em configuração, cenários de uso, disponibilidade de recursos, os
servants precisam ser instanciados, inicializados e destruídos;
▸ Tudo precisa ser coordenado;
▸ SOLUCÃO:
▸ Usar um Lifecycle manager para gerenciar o ciclo de vida de objetos remotos;
▸ Lifecycle manager dispara as operações de ciclo de vida;
▸ Lifecycle manager implementa estratégias de ciclo de vida configuradas.

80. PADRÃO DE PROJETO: LIFECYCLE MANAGER
A LIFECYCLE MANAGER is typically created by the server application during
start-up, and is registered with the distributed object middleware’s INVOKER.
Before an invocation is dispatched, the INVOKER informs the lifecycle
manager. If the servant is not active, the LIFECYCLE MANAGER activates it.
The INVOKER dispatches the invocation. After the invocation returns, the
LIFECYCLE MANAGER is informed again and can deactivate the servant if
required.

81. PADRÃO DE PROJETO: CONFIGURATION GROUP
▸ CONTEXTO:
▸ Objetos remotos que precisam de configurações similares;
▸ PROBLEMA:
▸ Objetos remotos que precisam ser configurados com algumas
propriedades: quality of service (QoS), gerenciamento de ciclo de
vida, protocolo suportado;
▸ Configuração por servidor não é suficientemente flexível;
▸ Configuração por objeto remoto possui um grande overhead;
▸ SOLUCÃO:
▸ Fornecer um gerenciamento de grupo de objetos remotos
agrupando objetos que tenham propriedades em comum.

82. PADRÃO DE PROJETO: CONFIGURATION GROUP
The figure depicts two CONFIGURATION GROUPS in a server application: one
group for embedded objects and one group for gateway objects.
The LIFECYCLE MANAGER, PROTOCOL PLUG-IN, MARSHALLER, and
INVOCATION INTERCEPTORS are configured accordingly.

83. PADRÃO DE PROJETO: LOCAL OBJECT
▸ CONTEXTO:
▸ Componentes de middleware que precisam ser configurados;
▸ PROBLEMA:
▸ Configurar plugins de protocolos, grupos de configuração, gerenciadores de ciclo
de vida através de suas interfaces;
▸ Interfaces não acessíveis remotamente;
▸ Por questão de consistência, interfaces devem se comportar similarmente as
interfaces dos objetos remotos;
▸ SOLUCÃO:
▸ Local Objects permitem que desenvolvedores de aplicações acessem as
configurações e parâmetros do middleware;
▸ Local Objects aderem as mesmas regras de passagem de parâmetros, sintaxe de
invocação e gerenciamento de memória dos objetos remotos;
▸ Local Objects não podem ser acessíveis remotamente.

84. PADRÃO DE PROJETO: LOCAL OBJECT
The server application and the implementations of remote objects access
LOCAL OBJECTS as if they were remote objects.

85. PADRÃO DE PROJETO: QoS OBSERVER
▸ CONTEXTO:
▸ Necessidade de controlar propriedades de QoS específicas da aplicação: largura de
banda, atraso, etc;
▸ PROBLEMA:
▸ Handlers, marshallers, plugins de protocolo, grupos de configuração fornecem
ganchos para implementar características de QoS;
▸ Aplicações querem reagir à mudanças de QoS;
▸ Código específico sobre mudanças de QoS devem ser desacoplados do middleware;
▸ SOLUCÃO:
▸ Fornecer ganchos aos elementos do middleware para que desenvolvedores de
aplicações possam registrar QoS Observers;
▸ Observers são informados sobre parâmetros de QoS: tamanho de mensagens,
contadores de invocações e tempos de execução;
▸ QoS Observers podem reagir se a qualidade do serviço cair.

86. PADRÃO DE PROJETO: QoS OBSERVER
On start-up, QOS OBSERVER implementations are registered with the
INVOKER, or any other relevant framework constituent.
The INVOKER notifies the QOS OBSERVERS of the start and end of each
invocation.
The QOS OBSERVERS can obtain relevant invocation data, such as duration
and size, from the constituent with which it is registered.

87. PADRÃO DE PROJETO: LOCATION FORWARDER
▸ CONTEXTO:
▸ Invocações que chegam a um servidor diferente de onde o objeto remoto se
encontra;
▸ PROBLEMA:
▸ Objetos remotos podem ser encontrar em servidores diferente deste onde a
invocação chega;
▸ Balanceamento descarga, tolerância a falhas;
▸ Objetos remotos que foram movidos para outro servidor;
▸ As invocações precisam chegar transparentemente ao objeto remoto correto;
▸ SOLUCÃO:
▸ Location Forwarder encaminha as invocações para um objeto remoto a outros
servidores;
▸ Location Forwarder mapeia o ID do objeto para uma referência absoluta de objeto
de outro objeto remoto.

88. PADRÃO DE PROJETO: LOCATION FORWARDER
A client invokes an operation on a remote object. Because the instance has
moved from one server application to another, the LOCATION FORWARDER
forwards the invocation to the server application where the remote object
currently resides.

89. EXTENDED INFRASTRUCTURE PATTERNS

90. INVOCATION
ASYNCHRONY PATTERNS

91. EXTENDED INFRASTRUCTURE PATTERNS

93. PADRÃO DE PROJETO: FIRE AND FORGET
▸ CONTEXTO:
▸ Operações do objeto remoto não retornam valores nem exceções;
▸ PROBLEMA:
▸ Clientes que apenas notificam eventos aos objetos remotos;
▸ Cliente não espera nenhum retorno;
▸ Confiabilidade da invocação não é crítica;
▸ SOLUCÃO:
▸ Usar um Lifecycle manager para gerenciar o ciclo de vida de objetos
Fornecer operações FIRE AND FORGET onde o Requestor envia a
invocação através da rede e já retorna o controle ao cliente
imediatamente;
▸ Cliente não recebe nenhum ack do objeto remoto.

94. PADRÃO DE PROJETO: FIRE AND FORGET
When the client invokes a FIRE AND FORGET operation, the REQUESTOR
marshals the parameters and sends them to the server.

95. PADRÃO DE PROJETO: SYNC WITH SERVER
▸ CONTEXTO:
▸ Operações do objeto remoto não retornam valores nem exceções;
▸ PROBLEMA:
▸ Fire and Forget é “excessivamente” não confiável;
▸ Uma chamada síncrona não deve ser usada pelo o cliente até que o
servidor responda;
▸ SOLUCÃO:
▸ Fornecer a semântica Sync with Server à invocações remotas;
▸ Cliente invoca uma operação e espera por reply do servidor notificando
sobre o recebimento da invocação;
▸ Depois que o reply é recebido pelo requestor, o controle retorna ao cliente;
▸ Servidor executa a invocação independentemente.

96. PADRÃO DE PROJETO: SYNC WITH SERVER
A client invokes a remote operation. The REQUESTOR puts the bytes of the
invocation on the wire, as in FIRE AND FORGET, but then waits for a reply from
the server application as an acknowledgment that the invocation has been
received by the server.

97. PADRÃO DE PROJETO: POLL OBJECT
▸ CONTEXTO:
▸ Invocações devem executar assincronamente e os clientes dependem dos
resultados;
▸ PROBLEMA:
▸ Cliente não precisa imediatamente do resultado para continuar sua execução;
▸ Cliente decide quando usar os resultados;
▸ SOLUCÃO:
▸ Fornecer Poll Objects que recebem o resultado de invocações nos clientes;
▸ Cliente usa o Poll Object para consultar os resultados;
▸ Simplesmente verifica se o resultado está disponível ou;
▸ Bloqueia até que o resultado esteja disponível;
▸ Enquanto o resultado não estiver disponível, o cliente pode continuar a executar
outras tarefas.

98. PADRÃO DE PROJETO: POLL OBJECT
A client invokes a remote operation on the REQUESTOR, which in turn creates a POLL
OBJECT to be returned to the client immediately.
As long as the remote invocation has not returned, the ‘result available’ operation of the
POLL OBJECT returns false.
When the result becomes available, it is memorized in the POLL OBJECT.
When it is next polled it returns true, and the client can fetch the result by calling the
‘get result’ operation.

99. PADRÃO DE PROJETO: RESULT CALLBACK
▸ CONTEXTO:
▸ Invocações devem executar assincronamente e os clientes dependem dos
resultados;
▸ PROBLEMA:
▸ Quando o resultado estiver disponível no Requestor, o cliente quer ser
informado imediatamente;
▸ Enquanto isto o cliente executa outras tarefas concorrentemente;
▸ SOLUCÃO:
▸ Fornecer uma interface Callback para as chamadas remotas do cliente;
▸ Cliente passa um objeto Callback ao Requestor;
▸ A invocação retorna de imediato depois do seu envio ao objeto remoto;
▸ Quando o resultado estiver disponível, o middleware invoca a a operação de
callback.

100. PADRÃO DE PROJETO: RESULT CALLBACK
The client instantiates a callback object and invokes the operation on the
REQUESTOR.
When the result of the remote invocation re- turns, it is dispatched by the
distributed object middleware to the callback object, calling a predefined
callback method.

101. EXTENDED INFRASTRUCTURE PATTERNS

102. REFERÊNCIA
▸ Remoting Patterns (2005) - Foundations of
Enterprise, Internet and Realtime Distributed
Object Middleware - Markus Völter, Michael
Kircher, Uwe Zdun
▸ Página 19 até 184;
▸https://goo.gl/Yk1Hmo

103. PADRÕES DE PROJETO DE
MIDDLEWARE
VICTOR HAZIN DA ROCHA