Che cos'è un localizzatore di servizi?

Queste due cose sono essenzialmente le stesse. Un localizzatore di servizi è un qualsiasi sistema centralizzato che ti consente di trovare un servizio per elaborare una richiesta. Utilizzando il modello di progettazione del localizzatore di servizi , puoi utilizzare questo per ottenere un'implementazione di servizio (che è davvero un'interfaccia a livello di codice ) dal localizzatore di servizio.

Più in generale, questo sistema viene spesso utilizzato nel calcolo distribuito per trovare un nodo nella rete in grado di soddisfare la richiesta di altri nodi.

Ad esempio, alcuni client potrebbero voler eseguire alcuni calcoli su alcuni dati. Diciamo che ci sono molti modi per fare questo calcolo, ognuno implementato come un servizio, ma al cliente non importa quale sia effettivamente utilizzato. Il cliente potrebbe semplicemente richiedere qualsiasi servizio dal localizzatore di servizi, senza doversi preoccupare di quale tipo specifico viene restituito.

In entrambi i casi, i vantaggi e gli svantaggi sono in gran parte gli stessi. Il localizzatore di servizi ti consente di modulare meglio il tuo programma e ti fa preoccupare meno delle implementazioni di servizi specifici. D'altra parte, si ottiene questo punto di errore centralizzato che potrebbe essere un collegamento debole nel sistema. Come tutto il resto, è un compromesso quindi non c'è una semplice risposta "buona contro cattiva".

Le due definizioni che hai dato sono per cose diverse.

Il primo (Un registro glorificato) è in realtà chiamato localizzatore di servizi. Significa che esiste un'entità (chiamata localizzatore di servizio) che le altre classi dipendono per recuperare le loro dipendenze in fase di runtime. Dai un'occhiata a questo articolo per un esempio e per un motivo per cui è considerato un anti-modello.

Il secondo (contenitori DI) non è necessariamente considerato un localizzatore di servizi. Dipende da dove lo stai usando. Se lo si utilizza all'interno delle classi per ottenere le dipendenze, viene utilizzato come localizzatore di servizi. D'altra parte, se lo si utilizza solo nel Root di composizione , non viene utilizzato come un localizzatore di servizi. E molte persone considerano l'utilizzo di contenitori DI nella composizione di radice un ottimo modo per fare Iniezione di dipendenza .

Ci sono due problemi chiave con un localizzatore di servizio / registro:

1. Ricerca del registro. Spesso l'unico modo è far sì che il proprio codice venga esplicitamente indicato nella posizione del registro, anche se in alcuni casi (contenitori DI, protocolli di rilevamento come Jini ) la scoperta del registro non è così difficile, o è addirittura fornita come dato.
2. Garantire che le informazioni nel registro siano corrette / pertinenti. Questa è in realtà la parte più difficile di tutte. Anche senza il problema degli attacchi malevoli, garantire che qualsiasi raccolta permanente di servizi sia effettivamente curata correttamente è un problema terribilmente laborioso. (Di solito è possibile rilevare automaticamente quando le informazioni non sono corrette, con uno sforzo sufficiente, ma non è in grado di determinare effettivamente come risolvere la situazione senza l'intervento manuale.)

OTOH, è del tutto pratico replicare un registro distribuito purché la velocità di cambiamento dei mapping che contiene non sia troppo veloce. Cosa pensi che sia il DNS, se non un registro replicato? (Bene, anche con cose extra.) Questo suggerisce che usare DNS per gestire le parti difficili della gestione del registro potrebbe essere una mossa intelligente, piuttosto che replicare di nuovo tutte quelle cose a un livello più alto di stack di rete ...