Технология Клиент-Сервер 2004'3
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

Java API for XML Messaging (JAXM)

Автор: Александр Цимбал

Cпецификация JAXM (Java API for XML Messaging, версия 1.1 на момент написания статьи) определяет некоторый универсальный подход, связанный с реализацией классических принципов messaging-сервисов, подобных CORBA Messaging Service или JMS (Java Messaging Service), но с использованием SOAP-сообщений. Эта спецификация требует поддержки стандарта SOAP 1.1 и SOAP with Attachments (SAAJ). Как и технология Web-сервисов в целом, JAXM ориентирован, в первую очередь, на использование в режиме B2B («business to business») .

Любые системы, поддерживающие взаимодействие в стиле MOM (Message-Oriented Middleware) содержат API, который используют программисты, создающие клиентские приложения (т.е. приложения, которые получают и отправляют сообщения), и «ядро» системы, которое поддерживает реализацию этого API и реально обеспечивает хранение и передачу сообщений между клиентами. В JAXM это ядро называется «JAXM Provider». JAXM-провайдер обязан обеспечить поддержку SOAP и SAAJ, но при этом он может также уметь использовать такие протоколы, как FTP, SMTP или POP.

Хотя обмен сообщениями возможен и без использования провайдера JAXM, такой способ является очень ограниченным по своим возможностям. По сути, это очень похоже на посылку сообщения в стиле JAX-RPC по указанному адресу. Основные возможности JAXM могут быть реализованы только при наличии JAXM-провайдеров. В этом случае ссобщения, посылаемые отправителем, сначала попадают к JAXM-провайдеру, который доставляет его получателю, и наоборот, сообщения для получателя сначала попадают к соответствующему провайдеру и только через него – к получателю. JAXM-провайдера можно трактовать как «почтовый ящик».

Режимы обмена сообщениями в JAXM и пакеты JAXM API

В общем случае спецификация JAXM оговаривает пять режимов обмена сообщениями:

• Синхронная отправка сообщения с ожиданием уведомления, что сообщение получено.
• Отправка запроса с получением ответа на него в синхронном режиме.
• Асинхронная отправка сообщения, уведомления о получении сообщения может прийти позже.
• Асинхронная отправка запроса (ответ на него может прийти значительно позже).
• Отправка сообщения, не подразумевающая какого-либо ответа.

Не все эти режимы можно реализовать без JAXM-провайдера. Если программист использует JAXM для отправки сообщения непосредственно конечному получателю – минуя JAXM-провайдера – то возможна работа только в синхронном режиме «запрос-отклик». Тем не менее, это по-прежнему использование JAXM, а не JAX-RPC. В чем же состоит отличие?

Если вы используете режим JAX-RPC, то ни на стороне сервера, ни на стороне клиента не используете XML явно – трансформацию Java-запроса в XML-документ, соответствующий требованиям протокола SOAP на стороне клиента и обратное преобразование на стороне сервера, т.е. маршалинг и анмаршалинг, выполняет среда исполнения JAX-RPC (например, статически сгенерированные стабы на стороне клиента и сервлеты Axis на стороне сервера). При использовании же JAXM программист самостоятельно формирует сообщение в виде XML-документа и отсылает его по указанному адресу. Этот адрес может задаваться при отправке сообщения конечному получателю или провайдеру, который отправит его конечному получателю, но суть от этого не меняется.

Согласно спецификации JAXM 1.1, единственным пакетом, который входит в состав JAXM API, является пакет javax.xml.messaging. Тем не менее JAXM-программы используют также классы интерфейсы из пакета javax.xml.soap для установки соединения с конечным получателем сообщений и для динамического (при работе программы) формирования XML-сообщения, а также для работы с вложениями (attachments). Ниже мы рассмотрим основные методы и классы обоих пакетов.

Спецификация предусматривает два вида соединений и, соответственно, две фабрики видов соединений.

При использовании JAXM-провайдера программист использует фабрику javax.xml.messaging.ProviderConnectionFactory. Эта фабрика должна обеспечиваться средой исполнения JAXM и обычно программист получает к ней доступ с помощью JNDI (хотя и возможно создать экземпляр такой фабрики с помощью статического метода ProviderConnectionFactory.newInstance()). Клиентское приложение (т.е. приложение, которое отправляет или получает сообщения) должно обязательно устанавливаться в контейнер (EJB- или Web-контейнер). Единственное, что должен делать программист при использовании JAXM-провайдера – это получить тем или иным образом объектную ссылку на его фабрику соединений. Все остальное (хранение сообщений, их надежную доставку получателям и т.д.) провайдер выполняет без участия программиста.

Если же программист не пользуется услугами провайдера и посылает сообщение непосредственно адресату, то для получения соединения используется класс javax.xml.soap.SOAPConnectionFactory и, соответственно, соединения типа javax.xml.soap.SOAPConnection. Такое приложение может быть создано как независимое (standalone) приложение.

.....................

Заключение

Исторически получилось так, что производители реализаций Java-технологий, имеющих отношение к Web-сервисам, большее внимание уделяли средствам выполнения вызовов удаленных методов, т.е. технологии JAX-RPC. На момент написания книги поддержка JAXM в том же Axis была выполнена значительно слабее. Тем не менее, в самое ближайшее время следует ожидать появления общедоступных и качественных реализаций JAXM-провайдеров, реализаций и экспертов (wizards) в составе средств разработок, которые обеспечат полную поддержку технологии JAXM. Объективно JAXM обладает большими возможностями по сравнению с JAX-RPC – как за счет возможности выполнения асинхронных вызовов, так и за счет использования вложений произвольного вида.

Copyright © 1994-2016 ООО "К-Пресс"