Предложения по соглашениям об именах очередей и тем JMS

Question

Для более крупных развертываний JMS, что вы посоветуете для соглашений по именованию?

В настоящее время мы следуем рекомендациям Sun Developer Network Blueprints . Например:

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

Я обеспокоен масштабированием, так как в системе появляется все больше очередей и тем. Мне особенно интересно узнать об опыте использования иерархического именования и о том, как люди выбирают свои соглашения об именах.

Answer 1

Я бы предложил нечто, включающее информацию о корпоративной группе, приложении и версии в иерархию пространства имен.

Например: JMS / mygroup.myproject.version.resource.queue

Это полезно, если у вас разные технические группы, использующие один и тот же кластер jms-серверов. Также он предотвращает "перекрестные помехи" между различными версиями одного и того же приложения.

Answer 2

Компания, в которой я работал, очень сильно зависела от JMS для SOA. Они также занимались проектированием на основе доменов, поэтому они организовали свои услуги по бизнес-доменам в формате / / . Например, цена / compute-foobar-maintenance-fee / 1.0.

Проект не был частью названия, потому что разные проекты не должны иметь свою собственную "версию правды" - два приложения не будут иметь собственную службу compute-foobar-maintenance-fee. , И какое приложение предоставляет услугу, не имеет отношения к наименованию сервиса. Возможно, моя заявка предоставляет услугу сегодня, но в следующем году моя заявка будет удалена, а другая вступит во владение. Пока контракт остается неизменным, клиент не будет / не должен знать разницу.