Design Pattern simile a ESB

0

Sfondo

Sto provando a scrivere un simulatore in cui più agenti IA sono in competizione e / o collaborano per raggiungere l'obiettivo di massimizzare alcune funzioni di utilità.

Ogni agente ha la capacità di interagire con il mondo in cui potrebbe alterare lo stato dell'ambiente, in base ad alcune azioni che esegue. E come risultato di tali azioni, un segnale di ricompensa viene trasmesso dall'ambiente all'attore (agente che implementa l'azione).

Alcuni agenti sono progettati per mostrare azioni e ricompense di altri agenti, quindi non dovrebbe subire tutte le conseguenze mentre impara le mosse ottimali.

Quello che ho fatto inizialmente, sta definendo i seguenti metodi sulla classe dell'ambiente:

  • Interagisci (azione, attore) che restituisce una tupla sia del segnale di ricompensa che del nuovo stato
  • GetState () restituisce lo stato corrente
  • Spectate () restituisce una raccolta di ciò che è accaduto in termini di attore, azione, stato originale, nuovo stato, ricompensa ottenuta.

Ma ciò sembra complicare il mio design e mi impedisce di ridimensionare il sistema in seguito.

Stavo cercando un modo generale per interagire con agenti e ambienti diversi senza chiamare esplicitamente metodi di certo tipo o inviare un identificatore all'attore.

Soluzione proposta

Quindi pensavo di avere un sistema di mailing, in cui un attore (agente) invia un messaggio all'ambiente attraverso una cassetta postale, e l'ambiente legge il messaggio in arrivo, interagisce con esso e restituisce un messaggio al mittente (l'attore ).

Nel frattempo, agenti curiosi avrebbero letto una copia del messaggio restituito che è stato pubblicato per chiunque fosse interessato.

Questo potrebbe sembrare un pattern observer , eccetto che ogni agente e l'ambiente (i) sono idonei per osservare le interazioni, sia per l'interazione diretta che per l'apprendimento dagli errori degli altri.

Ciò significa che le notifiche sono bidirezionali, quindi sarà un overhead per ciascun oggetto mantenere un elenco di destinatari da notificare quando si verifica un evento. Inoltre, poiché questa è una simulazione AI, alcuni processi potrebbero essere stocastici, ad es. lo spettacolo potrebbe non essere il 100% del tempo per gli agenti curiosi.

Quindi abbiamo più classi client (che non condividono la stessa super-classe) che sono in grado di messaggiare l'un l'altro tramite ciò che è simile a un Enterprise Service Bus

E quello che ho chiamato PostOffice, avrebbe un metodo Factory, generando un oggetto mailbox per ogni oggetto che tentava di inviare messaggi ad altri oggetti.

Quindi, ogni volta che un oggetto client tenta di spedire qualche altro oggetto, cerca una sorta di metodo di directory e invia un messaggio all'indirizzo di posta elettronica identificato attraverso l'oggetto cassetta postale associato.

L'oggetto Mailbox a sua volta, notificherà l'oggetto dell'ufficio postale, che inoltrerà il messaggio alla casella di posta del destinatario, che manterrà questo messaggio fino a quando il client ricevente non verificherà un messaggio e lo leggerà.

È una sorta di accodamento dei messaggi ma a livello di oggetto non a livello aziendale

Domanda

  • Esiste un tale modello di design?
  • Ci sono degli svantaggi per questo approccio?
posta A.Rashad 28.08.2017 - 17:29
fonte

1 risposta

0

But this seems to complicate my design and prevent me from scaling the system afterwards.

I was seeking some general way for different agents and environment(s) to interact without explicitly calling methods of certain type or sending out an identifier to the actor.

Forse lo schema del Mediatore potrebbe semplificare il tuo design? Il suo ruolo è quello di contenere la logica per l'interazione tra oggetti diversi, ed è spesso usato in scenari in cui molti oggetti diversi devono interagire con molti altri oggetti (relazioni complesse).

Per favore, vedi la sezione "Java" in modo che tu la capisca meglio: link

Inoltre, usa lo schema Comando per creare possibili "azioni" che potrebbero essere eseguite da un attore in un determinato ambiente. Non implementare le interazioni tra attore e ambiente direttamente nella classe dell'ambiente. Ciò potrebbe aiutare il tuo progetto a scalare in modo migliore i nuovi modi di interazione futuri.

Per riassumere:

  • Attore: utilizzerà il Mediatore per interagire con il mondo - > questo in realtà chiamerà un'istanza di comando specifica che eseguirà l'azione utilizzando l'ambiente e genererà anche la ricompensa. Il Mediatore potrebbe notificare a tutti gli spettatori il risultato di questa azione;
  • Spettatore: si iscrive agli eventi del mediatore per vedere le azioni degli attori e imparare da loro;
  • Mediatore: conosce tutti i comandi specifici che possono modificare l'ambiente corrente e consente agli attori di avviare un'azione. Inoltre, contiene un elenco di eventi realizzati, disponibili per gli spettatori;
  • Ambiente: contiene il suo stato attuale e consente azioni specifiche, che sono disponibili implementate all'interno di specifiche classi di comando (che saranno utilizzate da Mediator);
risposta data 08.09.2017 - 15:09
fonte

Leggi altre domande sui tag