Sugerencias para la Cola JMS, y el Tema de las convenciones de nomenclatura

Question

Para mayor JMS implementaciones ¿cuáles son sus mejores prácticas sugerencias para convenciones de nomenclatura?

Actualmente estamos siguiendo las sugerencias de la Sun Developer Network Planos.Por ejemplo:

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

Estoy preocupado acerca de la escala de este a medida que más y más colas y tópicos en el sistema.Estoy particularmente interesado en escuchar acerca de experiencias en el uso de nomenclatura jerárquica y de cómo la gente ha decidido su convenciones de nomenclatura.

Answer 1

Sugeriría algo que incorpore información de grupo corporativo, aplicación y versión en una jerarquía de espacio de nombres.

Por ejemplo: jms / mygroup.myproject.version.resource.queue

Esto es útil si tiene grupos técnicos dispares que usan el mismo clúster de servidores jms. También evita & Quot; diafonía & Quot; entre diferentes versiones de la misma aplicación.

Answer 2

Una empresa en la que solía trabajar para basó en gran medida en JMS para SOA.También estaban en domain-driven design, así que organizaron sus servicios por el dominio de la empresa en el formato <domain>/<function>/<version>.Por ejemplo, el precio/informática-foobar cargos de mantenimiento/1.0.

El proyecto no era parte del nombre debido a que los diferentes proyectos no debería tener su propia "versión de la verdad" - dos aplicaciones no tienen sus propios cálculos foobar-mantenimiento-servicio de cuota.Y la aplicación que ofrece el servicio es irrelevante para la nomenclatura del servicio.Tal vez mi aplicación proporciona el servicio de hoy pero en el año siguiente, mi solicitud será retirado y el otro se hará cargo.Siempre que el contrato sigue siendo el mismo, el cliente no/no sabe la diferencia.