Suggerimenti per la coda JMS e convenzioni di denominazione per l'argomento

Question

Per le distribuzioni JMS di grandi dimensioni quali sono i suggerimenti migliori per le convenzioni di denominazione?

Attualmente stiamo seguendo i suggerimenti nello Sun Developer Network Blueprints. Per esempio:

jms/<resource-name>[Queue|Topic] 

Sono preoccupato per il ridimensionamento questo come otteniamo sempre più le code e gli argomenti del sistema. Sono particolarmente interessato a conoscere le esperienze che utilizzano la denominazione gerarchica e il modo in cui le persone hanno deciso le convenzioni di denominazione.

Answer 1

Suggerirei qualcosa che incorpori informazioni di gruppo, applicazione e versione aziendale in una gerarchia di namespace.

Per esempio: JMS/mygroup.myproject.version.resource.queue

Questo è utile se si dispone di gruppi tecnici disparati utilizzando cluster di server stessi JMS. Inoltre impedisce "crosstalk" tra diverse versioni della stessa applicazione.

Answer 2

Una società con cui lavoravo era molto dipendente da JMS per SOA. Erano anche nella progettazione basata sul dominio, quindi hanno organizzato i loro servizi per dominio aziendale nel formato <dominio>/<funzione>/<versione>. Ad esempio, prezzo/compute-foobar-maintenance-fee/1.0.

Il progetto non faceva parte del nome in quanto diversi progetti shouldn't have their own "version of the truth" - due app non avrebbero il proprio servizio di calcolo delle spese di manutenzione. E quale applicazione fornisce il servizio è irrilevante per nominare il servizio. Forse la mia applicazione fornisce il servizio oggi ma l'anno prossimo, la mia domanda verrà ritirata e un'altra subentrerà. Finché il contratto rimane lo stesso, il cliente non dovrebbe/non dovrebbe conoscere la differenza.