Разработчикам очень легко испытать искушение (или иногда необходимость) использовать проприетарную функциональность вендора в приложении на основе JMS.За короткий период времени, потраченный на использование JMS, я заметил четыре причины, по которым разработчик может прибегнуть к использованию проприетарного API.
Во-первых, получение Destination и ConnectionFactory объектов из службы именования неудобно,особенно для разработчика, новичка в JMS, который не хочет тратить время на изучение команд администрирования JMS, прежде чем сможет написать приложение.Возможно, было бы удобнее использовать проприетарные функции производителя для непосредственного создания Destination и ConnectionFactory объектов.
Во-вторых, продукты JMS обычно предлагают качество обслуживания, превышающее те, которые определены в JMS.Спецификация.Если эти качества обслуживания связаны, скажем, с Session, Producer или Consumer, то для поставщика естественно обеспечить проприетарные set<Name>() операции с этими типами.Проще говоря, не все проприетарные качества обслуживания могут быть инкапсулированы в администрируемых объектах.
В-третьих, в случае сбоя операции, связанной с JMS, она выдает (подтип) JMSException.Разработчик приложения может пожелать обработать перехваченное исключение одним из нескольких способов, в зависимости от характера исключения.Однако в спецификации JMS говорится, что две из трех частей информации, предоставляемой JMSException, являются собственностью поставщика JMS.Из-за этого разработчику, возможно, придется полагаться на информацию, принадлежащую поставщику, содержащуюся в исключении, при принятии решения, как ее обрабатывать.
Наконец, JMS указывает, что сообщение состоит из трех частей: (1) поля заголовка, (2) произвольные свойства (то есть имя = значение пары) и (3) тело.Предполагаемое использование (2) - поддержка гибкого выбора сообщений в пользовательских приложениях.Например, приложение-производитель, работающее, скажем, в Лондоне, может добавить location = London к свойствам сообщения перед его отправкой.Затем приложение-потребитель может использовать селектор сообщений "(location = 'London')", чтобы убедиться, что оно получает только сообщения с этим значением свойства.Это звучит неплохо.Плохо то, что спецификация JMS резервирует имена свойств, начинающиеся с JMS_<vendor>, для использования поставщиками JMS, и некоторые поставщики используют такие свойства для указания собственного качества обслуживания для каждого сообщения.Разработчик, желающий использовать проприетарное качество обслуживания для каждого сообщения, должен будет изменить код приложения-производителя, чтобы он устанавливал проприетарное свойство перед отправкой сообщения.
Предупреждение T.Rob оИерархии тем - это еще одна проблема, о которой следует опасаться.