Suggerimenti per le convenzioni di denominazione della coda JMS e degli argomenti

Question

Per le distribuzioni JMS più grandi quali sono i suggerimenti delle migliori pratiche per le convenzioni di denominazione?

Attualmente stiamo seguendo i suggerimenti nei Modelli della rete di sviluppatori Sun . Ad esempio:

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

Sono preoccupato per il ridimensionamento di questo sistema poiché riceviamo sempre più code e argomenti nel sistema. Sono particolarmente interessato a conoscere le esperienze sull'uso della denominazione gerarchica e su come le persone hanno deciso le loro convenzioni di denominazione.

Answer 1

Suggerirei qualcosa che incorpori le informazioni sul gruppo aziendale, sull'applicazione e sulla versione in una gerarchia di spazi dei nomi.

Ad esempio: jms / mygroup.myproject.version.resource.queue

Ciò è utile se si hanno gruppi tecnici diversi che utilizzano lo stesso cluster di server jms. Inoltre impedisce & Quot; crosstalk & Quot; tra versioni diverse della stessa applicazione.

Answer 2

Una società per la quale lavoravo dipendeva molto da JMS per SOA. Si occupavano anche della progettazione guidata dal dominio, quindi organizzarono i loro servizi per dominio aziendale nel formato & Lt; domain & Gt; / & Lt; function & Gt; / & Lt; versione > ;. Ad esempio, price / compute-foobar-maintenance-fee / 1.0.

Il progetto non faceva parte del nome perché diversi progetti non dovrebbero avere il proprio quot; versione della verità " - due app non avrebbero il proprio servizio di calcolo per il calcolo della 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 prenderà il controllo. Finché il contratto rimane lo stesso, il cliente non dovrebbe / non dovrebbe conoscere la differenza.