Во-первых. На картинке изображён кластер из 3 узлов. А бесплатная лицензия позволяет использовать только два. Значит, выяснить, подойдёт ли это. Hazelcast кеширует Java-объекты между узлами кластера для быстрого доступа к ним. Поскольку Java-объекты существуют внутри JVM, то копирование происходит между JVM (то есть обычно между разными компьютерами в сети). Таким образом, в картинке имеется ввиду, что есть несколько компьютеров. Кластер у Hazelcast - свой, не имеет отношения к другим кластерам, если они есть. Для наблюдения надо его работой и проверки, что вообще работает, полезно установить Mancester (он же Hazelcast Management Center).

Вообще-то, я мог забыть, надо самостоятельно посмотреть условия бесплатной и коммерческой лицензии.
Hazelcast - библиотека, устанавливаемая на каждом компьютере. Затем в настройках Hazelcast создать кластер (на каждом компьютере указать адрес кластера). На одном из компьютеров для администрирования установить Tomcat, в него Mancester и в нём проверить, что кластер работает. Больших знаний по Hazelcast у меня нет, но на сайтах Hazelcast есть подробная документация.

questionerпро near cash я тогда не понял. В чем его near
В том, что он на локальном комьютере для ускорения доступа. Вообще объект в кластере может оказаться на локальном или удалённом компьютере для обратившейся к нему программы. Near Cache позволяет сделать локальную копию. Рекомендуется в случае, если надо чаще читать, чем изменять объект, во избежание лишней работы по синхронизации объекта в кластере.
Но это - средство повышения скорости работы. Сначала надо добиться, чтоб вообще работало.

questionerauto-discovery of nodes
Автоматическое обнаружение из одного узла кластера других подключённых в настоящее время узлов. Есть 3 способа (описаны в докуметнации), например, по их адресу в сети.

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

Это нужно знать не клиенту, а Hazelcast-у. В его кластере работа распределяется между узлами. Значит, Hazelcast-у надо знать, какие узлы активны. В процессе работы узлы могут появляться или исчезать (потому что обычно они находятся на разных компьютерах в сети). Например, включили компьютер - Hazelcast-у надо знать, что его можно использовать в кластере. Функция автоматического обнаружения этим и занимается. Клиент обращается не к узлам, а к Hazelcast-у, поэтому ему знать не нужно (в чём можно убдиться, посмотрев программные примеры - там не указываются ни узлы, ни кластер).

Доклад плохой. Автор говорит на языке пиджин-инглиш (приходится переводить на русский) и не разбирается в темах, которые упоминает. Так, два мифа о JMS, которые он пытался опровергнуть, открывая (якобы) страшную тайну о недостатках JMS, остались неопровергнутыми (просто надо уметь пользоваться). Большинство предложенных им альтернатив не являются альтернативами. Например, он ругал JMS за потерю сообщений, но в предложенных им альтернативах Hazelcast, ZeroMQ и Redis нет средств её обеспечения. Упомянуто blocking queue вообще не по делу. Что такое ZeroMQ, он не понял.
Из того, что перечислено, реальная альтернатива JMS - AMQP. Это протокол и API, с AMQP работает например служба доставки сообщений RabbitMQ. Он неоднократно упоминал RabbitMQ и даже AMQP, но сам не понял, что это такое. Высказывание, что AMQP проще, чем JMS, заставляет сделать вывод, что с AMQP лучше знакомиться без помощи этого оратора. RabbitMQ можно использовать для JMS, но только потому, что к нему предоставляются адаптеры преобразования сообщений между JMS и AMQP. Но это не обязательно - есть клиентская библиотека для работы с AMQP, которую можно использовать с RabbitMQ.
В Hazelcast встроена простая функциональность доставки сообщений, но она предназначена только для работы с Hazelcast и не обеспечивает надёжного хранения сообщений, поэтому в качестве замены JMS рассматривать нелепо. Наоборот, если возможностей сообщений Hazelcast окажется недостаточно, то может появиться смысл использовать JMS или ещё что.

В общем, мысль была в том, что альтернативы JMS есть. Но не надо использовать программные средства не по назначению.
В дополнение к Hazelcast: он сказал, что там есть бэкап сообщений с одного узла на другие узлы кластера. Надо иметь ввиду, что этим не обеспечивается долговременное хранение сообщений (его надо программировать дополнительно). Просто если один узел отключится во время работы, то его объекты уже окажутся сохранёнными на других узлах, и после отключения этого узла будут восстановлены в их кеш.

questionerОна соответствует спецификации jms ?

Я кому писал, что не соответствует и вообще имеет иное назначение, так как не предназначена для долговременного хранения сообщений? На сайте Hazelcast подробная документация, можно было бы заглянуть.

GregTkДолговоменненнное хранение реализуется средствами map-store например, и не представляет проблем.

Представит проблемы, если какой-нибудь идиот возжелает заменить им JMS, как это предлагает автор знаменитого доклада. Придётся программировать половину замены JMS (в Hazelcast нужно своё программирование), и никаких гарантий, что получится лучше, чем JMS.