Я не понимаю, почему в предыдущем ответе и обсуждении было предположение, что недолговечные подписки не переносимы. Вот пример кода ( ссылка для скачивания ), который не является долговечным и совместим с JMS 1.1.
session = connection.createSession(transacted, Session.AUTO_ACKNOWLEDGE);
myDest = (Destination)ctx.lookup(dLookup);
MessageConsumer myConsumer = session.createConsumer(myDest);
Message inMessage = null;
do {
inMessage = myConsumer.receive(10000);
if( inMessage instanceof TextMessage ) {
System.out.println( "\n" + "Got message: "+((TextMessage) inMessage).getText());
}
session.commit();
} while ( inMessage != null );
myConsumer.close();
Мало того, что подписчик недолговечен в предыдущем примере, но не имеет значения, является ли тема или очередь, извлеченная из поиска JNDI. Ссылка выше - на статью с примерами рабочего кода и объектами JNDI, написанными для WMQ v6, но одинаково хорошо работающими на WMQ v7 (но с немного другой настройкой в QMgr, так как pub / sub больше не требует отдельного компонента брокера).
Кроме того, исходный ответчик прав в том, что, пока приложение соответствует спецификации JMS, оно должно работать в любом JMS-совместимом транспорте. Поскольку это так, это не учитывает того, что различия в реализации транспорта поставщика всплывают через абстракцию JMS, чтобы повлиять на ваш код.
Например, JMS предоставляет многоуровневое исключение, где верхний уровень - это исключение JMS, а следующий уровень - это связанное исключение. Это связанное исключение, в котором поставщик может размещать коды ошибок конкретного поставщика. Например, в WMQ вы можете получить связанное исключение, указывающее, что очередь заполнена, или связанное исключение, сообщающее, что очередь повреждена. Одним из них является временное и повторное поведение является подходящим, в то время как другой указывает на фатальную ошибку. Если приложение не распознает ошибки в связанном исключении, оно не может определить разницу.
Некоторые приложения, предназначенные для переноски, справляются с этим, просто рассматривая все исключения как фатальные. Они закрывают все объекты и соединения и повторно инициализируют. Я также видел подход, при котором разработчик отказывается от всех попыток переносимости и просматривает связанные исключения для кодов, специфичных для поставщика. Где-то между этими подходами находятся магазины, в которых есть специфические для поставщика прокладки или подклассы, которые обертывают объекты JMS, так что приложение может оставаться переносимым, но при этом реагировать соответствующим образом на специфичные для поставщика исключения.
Даже если предположить, что эти вещи не являются проблемой, все равно важно понять , как производитель интерпретировал и реализовал спецификацию. Например, некоторые транспорты бесперебойно отказывают клиентам при сбое брокера. Разработчики могут полагаться на такое поведение и опускать любую логику переподключения в своем приложении. Но что, если проблема не в посреднике, а в сетевом соединении на клиенте? Как долго приложение зависает при попытке переключения при сбое и что видит пользователь? Спецификация не решает эти проблемы, и переносимость только позволяет вам.
Таким образом, во что бы то ни стало понимают спецификацию и пишут переносимый код, но также понимают реализацию спецификации поставщиком и то, где границы переносимости лежат с этой реализацией. В любом случае, эта граница не лежит между долговременными и недолговечными подписками.