Содержание


Теория и практика Java

Есть ли необходимость в использовании JMS в новом корпоративном приложении?

Узнайте о том, как организация очередей сообщений может повысить функциональную гибкость и масштабируемость Вашего корпоративного приложения

Comments

Серия контента:

Этот контент является частью # из серии # статей: Теория и практика Java

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Теория и практика Java

Следите за выходом новых статей этой серии.

Инструменты организации очередей сообщений (MQ), не так хорошо известны и изучены, как инструменты баз данных, например, реляционные базы данных (SQL), которые являются главными компонентами почти всех приложений для предприятий и большого числа более простых приложений. У разработчиков всегда был доступ к широкому спектру продуктов СУБД, начиная от дешевых баз данных для настольных компьютеров (например, dBase или Microsoft Access), серверов коллективных баз данных (например, Sybase SQL или других), до серверов баз данных для предприятий (например DB2 или Oracle). Независимо от проекта, всегда существует такая база данных с ценой, производительностью и функциональными возможностями, которые смогут удовлетворить Ваши потребности и возможности.

Как и базы данных, MQ-продукты, которые иногда тоже относят к промежуточному ПО, ориентированному на обработку сообщений (MOM), также активно использовались в течение определенного времени. Однако до недавнего времени, MQ-серверы являлись дорогостоящими продуктами высокого класса, доступными только для разработчиков хорошо финансируемых предприятий. В результате, только малая часть разработчиков использовала в своих приложениях преимущества обмена сообщениями.

Организация очередей сообщений приходит в массы

К счастью, эта ситуация начинает меняться. На данный момент в продаже появилось несколько недорогих MQ-серверов. В 1997 году Microsoft выпустил MSMQ - программу, осуществляющую организацию очереди деловых сообщений, интегрированную в Windows NT Server без дополнительной платы за лицензию. Включив интерфейс JMS API в исходную J2EE-спецификацию, корпорация Sun обеспечила стимул для развития технологий обмена сообщениями. А в версии 1.3 спецификации J2EE все J2EE-контейнеры требуют включения JMS-провайдера.

JMS, служба сообщений Java, является интерфейсом API, который позволяет Java-приложениям осуществлять доступ к самым различным MQ-серверам (или, на языке JMS, провайдерам) через стандартизированный интерфейс, также как JDBC позволяет программам осуществлять доступ ко многим серверам баз данных через стандартный интерфейс. Многие J2EE-контейнеры содержат JMS-провайдер. Планируется, что в будущем он будет присутствовать во всех J2EE-контейнерах. JMS также можно использовать и без J2EE-контейнера: в продаже имеются некоторые отдельные версии JMS-провайдеров. Вдобавок, спецификация EJB 2.0 представляет новый тип EJB - управляемый сообщениями компонент, позволяющий легко создавать компоненты, управляемые сообщениями и использующие компоненты управления данными и сессионные компоненты.

Теперь, когда у нас есть доступ к JMS-службам, нам необходимо узнать, как выгодно использовать преимущества обмена сообщениями в своих приложениях. Уилли Фаррелл (Willy Farrell), разработчик архитектуры электронного бизнеса в IBM, написал хорошее вводное руководство по использованию JMS (см. Ресурсы). В нем описаны основы создания сообщений и очередей, а также все варианты описания приоритетов, выборки и кодирования сообщений.

Обмен сообщениями и базы данных обладают взаимодополняющими преимуществами и зачастую совместное использование обмена сообщениями и реляционных баз данных обеспечивает решение, которое будет намного лучше, чем их использование по отдельности.

Раньше MQ-серверы использовались в приложениях, ориентированных на события, например, приложениях финансового обслуживания, или в качестве средств для взаимодействия несопоставимых систем (например, связь несопоставимых СУБД-приложений или соединение одной фирмы с другой в логическую последовательную сеть). Термин, "промежуточное ПО, ориентированное на обработку сообщений" часто используется для MQ-серверов из-за чего забывают про то, что главная функция MQ-технологии заключается в организации связи между несопоставимыми системами. Однако благодаря снижению стоимости на MQ-продукты, теперь и другие приложения смогут воспользоваться преимуществами организации очередей сообщений.

Что же делают MQ-серверы?

На языке организации очередности обработки сообщений, сообщение представляет собой простой поток байтов (который может быть XML-документом, сериализованным Java-объектом, строковым текстом или даже пустым сообщением). Интерпретация сообщения возлагается на приложение: инфраструктура MQ не накладывает на сообщение никакой семантики или структуры. Сообщения хранятся в очередях, и MQ-серверы позволяют Вам ставить сообщения в очередь и удалять их из нее.

Таким образом, очередь сообщений выглядит как простой список с использованием указателей. Однако MQ-серверы для предприятий расширяют функциональность, добавляя к списку с использованием указателей несколько функциональных возможностей:

  • Контроль тех, кто может осуществлять чтение из или запись в очередь
  • Сетевые интерфейсы, позволяющие отправителям и получателям сообщений находиться в различных местах
  • Поддержка транзакций, следовательно, операции по постановке в очередь и вывода из нее представляют собой свойства транзакций - атомарность, непротиворечивость, локализация и надежность
  • Распространяемая поддержка транзакций, следовательно, операции с очередью могут происходить в распространяемых транзакциях наряду с другими системами управления ресурсами, например, базами данных SQL
  • Долговременное хранение
  • Распределение нагрузки
  • Восстановление после отказа
  • Управление

Преимущества MQ

Преимущества MQ происходят от внутренней слабой связности, которая обеспечивается благодаря асинхронному характеру обработки сообщений. Процесс постановки сообщения в очередь одним элементом и вывода сообщения из нее, а также обработка его другим элементом совершенно не связаны друг с другом. Два элемента не должны работать одновременно, располагаться в одной системе или даже знать имя друг друга. Каждый из них взаимодействует только с очередью и по своему собственному расписанию. Им необходимо только соглашаться с формой сообщений, которые они получают друг от друга, а в остальном не обязательно знать что-либо друг о друге.

У слабой связанности есть много преимуществ. Она предоставляет естественный механизм разделения операции на еще меньшие и независимые компоненты, создавая косвенные абстрактные конструкции между этапами обработки запроса. Данный процесс деления позволяет нам рассматривать выполнение каждого компонента отвлеченно друг от друга, лучше измерять и управлять использованием ресурсов каждым из компонентов или заменять один компонент другим, выполняющим аналогичные функции, без внесения изменений в другие компоненты.

Спецификация JMS требует, чтобы JMS-провайдеры также реализовывали функции издания и подписки, которые позволяют создавать отдельные, определяемые приложениями каналы, называемыми темами, а также позволяют индивидуальным элементам подписываться на темы. Сообщение, которое стоит в очереди на тему, автоматически помещается в личную очередь того элемента, который подписался на данную тему. Темы выполняют значительную функцию сортировки в приложениях финансового обслуживания или поставки новостей. Например, в то время как более 5000 фондов производят операции с ценными бумагами на главных биржах США, каждый инвестор может заинтересоваться только 30-ю. Таким образом, Вы можете создать тему для каждого стандартного символа, присвоенного ценной бумаге, позволив пользователю подписаться на те из них, в которых они заинтересованы, а затем MQ-движок отобразит только те цены, которые запрашивает каждый инвестор, исключив повтор цен. С помощью СУБД SQL такой процесс реализуется гораздо сложнее.

Классические шаблоны использования MQ

Существует ряд стандартных шаблонов использования, которые отлично подходят для построения очередей сообщений. Если Вы увидите один из таких шаблонов в своем приложении, то Вам необходимо будет использовать систему обмена сообщениями.

Ориентированные на события приложения

Приложения, ориентированные на события, очень хорошо подходят для MQ-технологии. Сюда входят приложения финансового обслуживания (подумайте о торговом агентстве, которое отображает обновления курса акций, производит торговые операции на основе изменений в ценах или выполняет другие операции, отчитывается о статусе операций и так далее), приложения служб новостей, приложения логических цепочек. На финансовых рынках, события должны происходить быстро. Например, Вы хотите, чтобы Вам сразу же сообщали, если происходит какое-либо важное событие.

Опрос баз данных

Базы данных отлично подходят для постоянного хранения данных, но хранение транзитных данных и оповещение Вас об изменении информации, является их слабой стороной.

Не смотря на неэффективность, опрос баз данных является обычным делом. Мониторы всех аэропортов постоянно опрашивают базу данных на наличие обновленной информации, которую они отображают. Любой банк с большим числом касс часто используют электронные табло для отображения следующей свободной кассы. Система обработки запросов внутри сайта по электронной коммерции может опросить базу данных, чтобы узнать о том, есть ли новые запросы для обработки. Или системы возмещения страховых убытков могут опрашивать базу данных, чтобы узнать, есть ли новые претензии, которые можно передать аджастерам претензий.

В результате выполнения опросов выполняется много лишней работы. Если объектам необходимо часто выполнять опрос (а им приходится, если они хотят быстро отображать обновления данных), то есть вероятность возникновения существенной нагрузки на сервер СУБД и сеть. Большую часть времени опрашивание не возвращает каких-либо данных, или, что еще хуже, возвращает данные которые мы уже видели и которые нужно обработать снова или определить, что они уже были обработаны.

Базы данных просто не предназначены для опроса или для событий. Если Вам нужно выполнить какое-либо действие практически сразу после того, как произошло событие или изменились данные, то гораздо проще и эффективнее использовать асинхронную передачу сообщений. Каждый раз, когда Вам необходимо выполнить опрос базы данных на наличие обновлений, вспоминайте о том, что лучше использовать JMS.

Автоматизация деловых операций

Согласно порталу информационных потоков (совместный проект коалиции по автоматизации делопроизводства и международной ассоциации по автоматизации делопроизводства и реорганизации), автоматизация деловых операций - это "...полная или частичная автоматизация бизнес-процесса, во время которой документы, информация или задания передаются от одного участника к другому для обработки в соответствии с правилами процедуры." Приложения для автоматизации деловых операций (например, по маршрутизации и утверждению документов, по обработке страховых убытков и другие) особенно хорошо подходят для MQ-решений, так как MQ-технологии точно моделируют подход к проблеме автоматизации деловых операций в офисе с бумажным документооборотом, где у каждого участника есть входящая и исходящая почта.

Приложения для автоматизации деловых операций характеризуются наличием большого числа агентов (агентами могут быть люди, автоматизированные шаги обработки или даже физическое оборудование, например, техника или принтеры), каждый из которых выполняет свою часть задачи и передает ее следующему агенту в соответствии с бизнес-правилами. Помните о процессе утверждения и оплаты электронных расходов? Сотрудник создает и отправляет отчет, а затем этот отчет должен быть заверен руководителем сотрудников (и, возможно, более высоким руководством, если сумма в долларах превышает определенный порог). Затем он передается в отдел по работе с персоналом (HR), где будет тщательно проверен и исследован, чтобы удостовериться в том, что расходы соответствуют бизнес-расходам и отвечают правилам компании. Если он утвержден, то генерируется запрос на оплату, а чек поставят на очередь в печать. После этого он может быть передан в систему учета, где отдельные расходы будут включены в соответствующие счета и центры учета затрат. На каждой из этих стадий, отчет о затратах может вернуться к сотруднику или руководителю сотрудников.

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

Использование MQ для уменьшения уровня риска при выполнении критических операций

Процесс принятия, утверждения и заполнения заказа в приложениях электронной коммерции и приложениях логических цепочек имеет много общего с приложениями для автоматизации деловых операций, хотя в большей части шагов используются электронные участники, а не живые люди. Одобрение и выполнение заказа может состоять лишь из некоторых или даже всех представленных ниже шагов:

  • Принятие заказа и сохранение его в базе данных.
  • Для физических покупателей, проверка действительности кредитной карты.
  • Для коммерческих покупателей, проверка клиентской кредитной карты либо с помощью агентства отчета о кредитоспособности, либо с помощью кредитного отдела Вашей компании.
  • Выполнение какого-либо анализа на фальсификацию.
  • Проверка товаров в наличии.
  • Если центров несколько, то принятие решения о том, какой центр заполнит заказ.
  • Отправка покупателю электронного письма с подтверждением.
  • Отправка уведомления представителю клиентских продаж.
  • Генерирование и отправка накладных на отпуск товара в центры выполнения заказа.
  • Отправка заказа.
  • Взимание оплаты с покупателей.

Вы не хотите, чтобы покупателю пришлось ждать долгое время после того, как он нажмёт на "Купить" для получения номера подтверждения и платежной квитанции, следовательно, не важно какой путь выполняется кодом, но процесс отправки заказа должен быть быстрым и иметь предсказуемое время выполнения. Однако большинство из этих шагов содержит доступ к ресурсам, которые могут быть или не быть доступны в тот момент времени, когда покупатель генерирует заказ, или чье время ответа может быть непредсказуемым. В этом случае их необходимо убрать с критического пути - генерация заказа выстраивает последовательность событий в действии, а затем при первой возможности выводит пользователя из цикла так, чтобы на этапе подачи выполнялось как можно меньше действий для генерации заказа. Помимо того, что покупателю предлагаются наилучшие пользовательские условия, деление обработки заказа на множество отдельных (и коротких) шагов, улучшает использование ресурса и уменьшает вероятность возникновения конфликтных ситуаций - это означает, что транзакции становятся короче (таким образом, блокировки будут сняты раньше), и что используемые на каждом отдельном шаге ресурсы (такие как подключения к сети или базе данных) освобождаются гораздо раньше.

Один из самых непредсказуемых шагов в обработке заказа является отправка электронного письма с подтверждением. Почтовые серверы часто перегружены и возможно, что отправка письма займет большое количество времени или произойдет сбой связи. Если почтовый сервер покупателя отказывается принять письмо с подтверждением, то Вы можете попробовать переслать его позже. В этом случае отправка письма с подтверждением является "рискованной", потому что письмо может не быть отправлено с первого раза или обработка может занять много времени, а Вам бы не хотелось, чтобы покупатель (или кто-либо другой) ждал до тех пор, пока дойдет письмо. Аналогично, наличные товары могут храниться в базе данных отдельно от обработки заказа (база данных товаров может даже находиться на внешнем сервере) и могут быть недоступны в момент получения заказа. Либо кредитный отдел не работает по пятницам.

При помощи очередей сообщений для хранения электронных писем с подтверждениями, находящихся в ожидании, проверок товаров или проверок кредитных карт Вы можете отделить "рискованные" операции от всех остальных процессов, и, таким образом, оградить оставшуюся часть процесса обработки от риска, что операция вызовет ошибку или займет большой промежуток времени. Кроме того, значительно упрощается исправление ошибок в каждой отдельной задаче, так как на каждом этапе обработки выполняется лишь одна простая задача.

Заключение

Если правильно использовать технологию организации очередей сообщений, то она может значительно упростить обработку сложнейших задач посредством разложения задачи на простые подзадачи, а также усовершенствовать универсальность и масштабируемость Вашего приложения. Что касается J2EE версии 1.3, то каждый J2EE-контейнер будет содержать JMS-провайдера, а, следовательно, мы все сможем воспользоваться преимуществами асинхронной организации очередей сообщений в наших приложениях.

В следующем месяце мы рассмотрим работу сервиса транзакций Java (JTS). Несмотря на то, что ему уделяется меньше внимания, чем EJB или другим элементам J2EE, JTS, возможно, является наиболее ответственной частью J2EE - транзакции позволяют нам создавать надежные распространяемые приложения. Мы будем еще обращаться к MQ в будущих публикациях и создавать приложения для автоматизации деловых операций, чтобы показать, какие дополнительные преимущества дает организация очередей сообщений и реляционные базы данных.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: "Should you use JMS in your next enterprise application?"
  • Получите спецификации, ссылки и примеры по JMS от фирмы Sun.
  • Книга Служба сообщений Java, написанная Ричардом Монсон-Хэфелом (Richard Monson-Haefel) и Дэвидом Чэппеллом (David Chappell) (O'Reilly and Associates, 2000 г.), предлагает обзор интерфейса JMS API и приводит много практических примеров по их использованию.
  • Книга Enterprise JavaBeans, написанная Ричардом Монсон-Хэфелом (O'Reilly and Associates, 2000 г.), является полностью обновленным изданием, содержащим подробное описание изменений в спецификации EJB 2.0.
  • Портал по информационному потоку для электронного бизнеса - совместный проект коалиции по автоматизации делопроизводства и международной ассоциации по автоматизации делопроизводства и реорганизации, представляет исчерпывающие источники для разработчиков приложений для автоматизации деловых операций.
  • MQSeries Primer - справочник IBM, предлагающий подробное объяснение идей и терминов, используемых при обмене сообщениями на предприятиях.
  • Узнайте, как использовать MQSeries с JSP-технологией из статьи WebSphere Developer Domain.
  • Найдите другие источники по языку Java на сайте developerWorks в разделе технологии Java.

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=194628
ArticleTitle=Теория и практика Java: Есть ли необходимость в использовании JMS в новом корпоративном приложении?
publish-date=02082007