Должны ли 2 JMS-провайдера содержать классы контекста друг с другом для общения? - PullRequest
1 голос
/ 23 ноября 2011

Мы начнем с практического примера, а затем вернемся к концептуальному вопросу.

Я использую Weblogic (10.3) в качестве сервера приложений. Я хочу, чтобы у моего приложения были возможности JMS, и решил позволить ему использовать Weblogic, как это предусмотрено JMS / MOM. Я установил очередь в Weblogic и создал класс MDB в своем коде.

Теперь я хочу отправить сообщение в очередь Weblgic. Я использовал клиент openJMS. Мне потребовалось включить файл weblogic jar в его путь к классу, чтобы отправить сообщение в weblogic.

И то же самое, когда я настроил Weblogic для отправки сообщения в очередь openJMS - я использовал Foreign Destination - он выбрасывал исключение «класс не найден», пока я не поместил jAR openJMS в weblogic classpath.

Это потому, что все примеры взаимодействия с JMS, которые я видел, используют контекст JNDI для получения фабрики соединений.

Мой вопрос: это имеет смысл? Разве JMS не должен быть нейтральным коммуникационным протоколом? Это означает, что я не могу решить, к какому JMS-провайдеру я отправляю во время выполнения, потому что у меня не будет его контекстных классов в моем classpath?

Или я просто что-то упустил в настройке?

Есть ли другой способ предварительно подготовить фабрику соединений к удаленному провайдеру?

1 Ответ

1 голос
/ 24 ноября 2011

Разве JMS не должен быть нейтральным коммуникационным протоколом?

Хороший вопрос. Ответ: это не так. JMS - это только API, который определяет, как подключаться и отправлять сообщения в очереди / темы. Это не протокол, поэтому реализации JMS-провайдера могут использовать свой собственный внутренний формат сообщения & mdash; Вот почему вам нужно импортировать банки поставщика. Кроме того, вы не можете ожидать, что провайдер A сможет обмениваться сообщениями с провайдером B, если только оба провайдера не предоставят такую ​​возможность явно.

Открытый межплатформенный протокол обмена сообщениями: AMQP . Есть и другие коммерческие решения, например, IBM Websphere MQ.

...