Главная » Spring » Архитектура JMS Spring

0

Большинство из нас не раз пользовались услугами почты. Еже- дневно миллионы людей передают письма, открытки и посылки в руки почтальонов, будучи уверенными, что они будут доставлены

адресатам. Мир слишком велик, чтобы все эти отправления можно было передавать из рук в руки лично, поэтому мы полагаемся на почтовую службу. Мы обращаемся на почту, оплачиваем услуги за пересылку, передаем почтовое отправление и ни на секунду не за- думываемся, каким образом оно будет доставлено.

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

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

В JMS имеются две основные действующие стороны: брокеры со-

общений и приемники.

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

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

Но, в отличие от почтовых адресов, которые определяют имя че- ловека или номер дома с названием улицы, адреса в JMS являются

Рис. 13.3. Очередь сообщений обеспечивает независимость отправителя сообщения от его получателя.

Несмотря на то что очередь может использоваться несколькими получателями, каждое сообщение может быть вынуто

из очереди только один раз

менее определенными. Адреса в JMS определяют лишь место, где получатель сможет получить сообщение, но не определяют, кто смо- жет получить его. То есть в JMS допускается посылать письма по адресу, например: «действующему Президенту».

В JMS существуют два типа приемников: очереди и темы. Каж-

дый из них следует определенной модели обмена сообщениями: ли- бо модель «точка–точка» (очереди), либо модель «публикация–под- писка» (темы).

Модель «точка–точка»

В модели «точка–точка» каждое сообщение имеет точно одного получателя и одного отправителя, как показано на рис. 13.3. Когда брокер сообщений получает сообщение, он помещает его в очередь. Когда получатель обращается за следующим сообщением в очере- ди, это сообщение удаляется из очереди и передается получателю. Поскольку в момент доставки сообщение удаляется из очереди, его гарантированно получит только один получатель.

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

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

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

То же самое происходит и в JMS, если очередь обслуживается несколькими получателями, нет никакой возможности определить, который из них будет обрабатывать то или иное сообщение. Эта не- определенность – благо, потому что позволяет приложению увели-

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

Модель  «публикация–подписка»

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

Рис. 13.4. Подобно очередям, темы обеспечивают независимость отправителей сообщений от их получателей.

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

Как следует из названия модели «публикация–подписка», она во многом напоминает модель издательства, выпускающего журнал, и подписчиков. Журнал (сообщение) публикуется и передается почтовой службе, которая затем доставляет копии журнала под- писчикам.

Аналогия с журналом не совсем корректна в данном случае, по- тому что в JMS издатель не знает, кто будет играть роль подпис- чика. Единственное, что известно издателю, – его сообщения будут опубликованы в определенной теме, но не известно, кто подписан на эту тему. Из этого также следует, что издатель не знает, как будут обрабатываться его сообщения.

Теперь, после знакомства с основами JMS, можно попытаться сравнить асинхронный механизм JMS с синхронным механизмом RPC.

Источник:   Уоллс К., Spring в действии. – М.: ДМК Пресс, 2013. – 752 с.: ил.

По теме:

  • Комментарии