Изучаем Java EE 7 - [214]

Развертывание MDB на GlassFish

Как только MDB упакован в файл с расширением. jar, он должен быть развернут в GlassFish. Это можно сделать несколькими способами, в том числе через консоль веб-администрирования. Тем не менее командная строка asadmin довольно просто может решить данную задачу: откройте командную строку, перейдите в директорию, в которой находится файл chapter13-MDB-1.0.jar, убедитесь, что GlassFish все еще работает, и введите такую команду:

$ asadmin deploy chapter13-MDB-1.0.jar

Если развертывание прошло успешно, следующая команда должна вернуть имя развернутого файла. jar и его тип (в этом примере EJB):

$ asadmin list-components
chapter13-MDB-1.0

Выполнение примера

MDB развернут на GlassFish и слушает место назначения jms/javaee7/Topic, ожидая появления сообщений. Пришло время запустить клиенты OrderConsumer и OrderProducer. Эти классы являются автономными приложениями, имеющими метод main, который должен быть выполнен вне GlassFish, в чистой среде Java SE. Введите приведенную далее команду для запуска OrderConsumer:

$ java — cp target/classes OrderConsumer

Потребитель работает в бесконечном цикле и ждет входящих заказов. Теперь введите следующую команду, чтобы отправить сообщение с заказом на сумму $2000:

$ java — cp target/classes OrderProducer 2000

Сумма больше $1000 (граница суммы определена в селекторе сообщения), поэтому и OrderExpensiveMD, и OrderConsumer должны получить сообщение. Проверьте журналы GlassFish, чтобы убедиться в этом. Если передать параметр меньше чем $1000, MDB не получит сообщение, а только OrderConsumer:

$ java — cp target/classes OrderProducer 500

Резюме

В этой главе показано, что интеграция с помощью обмена сообщениями является слабосвязанной, асинхронной формой общения между компонентами. MOM можно рассматривать в качестве буфера между системами, которые должны производить и потреблять сообщения в своем темпе. Это отличается от архитектуры RPC (например, RMI), в которых клиенты должны знать методы доступных служб.

В первом разделе этой главы мы рассмотрели JMS API (классический и упрощенный) и его словарь. Асинхронная модель является очень мощным API, который можно использовать в среде Java SE или Java EE. Он базируется на моделях P2P и pub-sub, фабриках соединений, местах назначения, соединениях, сеансах, сообщениях (заголовок, свойства, тело) различных типов (текст, объект, словарь, поток, байты), селекторах и других механизмах надежности, таких как подтверждение или стойкость.

В Java EE имеется специальный компонент для потребления сообщений — MDB. Во втором разделе этой главы демонстрируется, как MDB можно использовать в качестве асинхронного потребителя и как они полагаются на контейнер, чтобы решить некоторые задачи (управление жизненным циклом, перехватчиками, транзакциями, безопасностью, параллельным доступом, сообщениями о подтверждении и т. д.).

В этой главе также показано, как собрать эти элементы вместе с помощью Maven, GlassFish и OpenMQ, и приведен пример автономного передатчика и приемника MDB.

В следующих главах будут продемонстрированы другие технологии, используемые для взаимодействия с внешними системами, — SOAP и веб-службы RESTful.

Глава 14. Веб-службы SOAP

Термин «веб-служба» подразумевает «нечто» доступное в Сети («веб»), что может сослужить вам «службу». Первый пример, который приходит на ум, — это HTML-страница: она доступна в Интернете и после прочтения дает вам информацию, которую вы ищете. Другой вид веб-служб — это сервлеты. Они связаны с URL, следовательно, доступны в Интернете и выполняют любую обработку. Но термин «веб-службы» быстро распространился и был приравнен к сервис-ориентированной архитектуре (SOA). Сегодняшние веб-службы являются частью нашей повседневной жизни. Приложения веб-служб могут быть реализованы с помощью различных технологий, таких как SOAP, описанная в этой главе, или REST (см. следующую главу).

Веб-службы SOAP, как говорят, слабо связаны, потому что клиент веб-службы, известный как потребитель, не должен знать детали его реализации (например, язык, использованный при разработке, сигнатуры методов или платформа, на которой он запущен). Потребитель имеет возможность вызвать веб-службу SOAP с помощью простого интерфейса, описывающего доступные бизнес-методы (параметры и возвращаемые значения). Реализация может быть выполнена на любом языке (Visual Basic, C#, C, C++, Java и т. д.). Потребитель и поставщик веб-службы будут по-прежнему иметь возможность обмениваться данными слабосвязанным способом: с помощью XML-документов. Потребитель отправляет запрос веб-службе SOAP в виде документа XML и, возможно, получает ответ также в формате XML.

Веб-службы SOAP заботятся и о распределении. Распределенное программное обеспечение существовало в течение недолгого времени, но, в отличие от существующих распределенных систем, веб-службы SOAP приспособлены для работы в Сети. По умолчанию используется HTTP — известный и надежный протокол, не сохраняющий состояние.

Веб-службы SOAP есть везде. Они могут быть вызваны с простого компьютера или использовать интеграцию business-to-business (B2B), так что операции, которые раньше требовали ручного вмешательства, выполняются автоматически. Веб-службы SOAP объединяют приложения, используемые различными организациями через Интернет или в рамках одной компании (что известно как Enterprise Application Integration, или EAI). Во всех случаях они предоставляют стандартный способ соединения разных частей программного обеспечения.