Propozycje konwencji dotyczących kolejkowania JMS i tematów

Question

W przypadku większych wdrożeń JMS jakie są najlepsze praktyki dotyczące konwencji nazewnictwa?

Obecnie postępujemy zgodnie z sugestiami podanymi w Sun Developer Network Blueprints. Na przykład:

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

Jestem zaniepokojony skalowaniem tego, ponieważ coraz więcej kolejek i tematów w systemie. Szczególnie interesuje mnie słuchanie o doświadczeniach z użyciem hierarchicznego nazewnictwa i tego, jak ludzie zdecydowali się na konwencje nazewnictwa.

Answer 1

Proponuję coś, co będzie zawierać informacje o grupie, aplikacji i wersji w hierarchii przestrzeni nazw.

Na przykład: JMS/mygroup.myproject.version.resource.queue

Jest to przydatne, jeśli masz odmienne grupy techniczne, stosując te same JMS klastra serwerów. Ponadto zapobiega "przesłuchom" między różnymi wersjami tej samej aplikacji.

Answer 2

Firma, w której pracowałem, bardzo polegała na JMS dla architektury SOA. Projekt był również oparty na domenie, więc zorganizowali swoje usługi według domeny biznesowej w formacie <domeny>/<funkcja>/ wersja >. Na przykład: price/compute-foobar-fee-fee/1.0.

Projekt nie był częścią nazwy, ponieważ różne projekty: shouldn't have their own "version of the truth" - dwie aplikacje nie miałyby własnej usługi opłaty obliczeniowej i foobar. I która aplikacja zapewnia tę usługę, jest nieistotna dla nazwania usługi. Może moja aplikacja zapewnia dziś usługę, ale w przyszłym roku moja aplikacja zostanie wycofana, a druga przejmie. Dopóki umowa pozostaje taka sama, klient nie powinien/nie powinien wiedzieć o różnicy.