Во время инициализации клиентским приложениям потребуется доступ к объектам ConnectionFactory и Destination (базовый тип для Queue и Topic). В совокупности такие типы называются администрируемые объекты , и в спецификации JMS указано, что они должны реализовывать интерфейсы javax.naming.Referenceable и java.io.Serializable.
Это означает, что вы можете сделать администрируемые объекты доступными для клиентов не только через службу имен, но и через другие механизмы. Например, вы можете сериализовать администрируемые объекты и сохранять их в файлах, передавать сериализованные объекты в виде вложений в сообщения электронной почты, делать файлы .jso (Java Serialized Object) доступными на веб-сервере / FTP-сервере и т. Д. Такой подход может быть полезен, если вы беспокоитесь о клиентах экстрасети в том, что они не будут знать контактные данные вашей внутренней службы имен.
Но на самом деле это не отвечает на ваш вопрос , какая является наилучшей технологией для предоставления администрируемых объектов доступным для клиентов JMS? Служба имен? Сериализованные объектные файлы в общей файловой системе? Веб или FTP сервер? База данных? Ответ в том, что не существует «универсально лучшего» способа. Некоторые организации стандартизируют использование одной технологии, а другие предпочитают использовать другую технологию. Если вы пишете JMS-клиент, который будет использоваться во многих организациях, вы можете сделать свой клиент гибким в том, как он обращается к администрируемым объектам. Вы можете сделать это, реализовав метод с сигнатурой, подобной следующей:
public Object importObject(String instructions);
Реализация этого метода должна смотреть в начале instructions, чтобы выяснить, какую технологию следует использовать для извлечения объекта. Например:
obj1 = importObject("naming#path/in/naming/service");
obj2 = importObject("file#path/to/file.jso");
obj3 = importObject("exec#command to execute");
(На практике инструкции должны быть получены, скажем, из аргумента командной строки или файла конфигурации, а не жестко запрограммированы в приложении.)
Показанный выше вариант "exec#..." позволит выполнить произвольную команду оболочки, которая может извлечь файл .jso с веб-сервера или FTP-сервера (возможно, с использованием curl ), базы данных или любой другой наиболее удобно для пользователя. Несколько лет назад я написал аналогичную служебную функцию для другой технологии промежуточного программного обеспечения (CORBA), и предложенная гибкость оказалась очень полезной. Вы можете прочитать немного о моей функции утилиты CORBA здесь .
Еще одна проблема, о которой следует знать (и о которой @skaffman упомянул в комментарии), заключается в том, что хотя спецификация JMS определяет API, она не определяет протокол на проводе. Из-за этого, как правило, отсутствует взаимодействие между различными продуктами JMS. Таким образом, если внутренние JMS-приложения вашей компании создаются с помощью продукта X, то внешние JMS-клиенты компании также должны быть созданы с помощью продукта X. Сказав это, некоторые поставщики могут продавать «мост», который может принимать входящие сообщения через протокол «на проводе», используемый продуктом X, а затем повторно передает сообщения с использованием протокола «на проводе» продукта Y. Это один из способов обеспечения взаимодействия между различными продуктами JMS.
Отказ от ответственности: не позволяйте многословности этого ответа одурачить вас, думая, что я эксперт JMS. На самом деле у меня очень ограниченный опыт использования JMS, поэтому, если кто-то добавит комментарий о том, что мой совет ошибочен, то, вероятно, он прав.