подарите мне zlinux, я буду его настраивать!

"Бро́кер — юридическое или физическое лицо, выполняющее посреднические функции между продавцом и покупателем, между страховщиком и страхователем, между судовладельцем и фрахтователем. Брокер получает вознаграждение в виде комиссионных." (с) Википедия.

Что есть брокер сообщений?

Это вообще не имеет отношения к Open Source, а к Linux крайне опосредованное.

Это то, что меня кормит последние 3 года.

Да, тема интересная - но узкоспециализированная, и слово линух там совершенно с боку-припеку.

посредник в доставке сообщений? :)

Вполне вероятно что, фирма IBM подарит zlinux тому, кто купит соотв. оборудование.

злинукс - звучит!

Строишь СОА на брокере? (читать как "продал душу дьяволу?")

Может запостить сразу один топик с перечислением ибмовского софта - чем не новость? а под топиком написать "ИТОГО" - и скока стоит.

Да какое там SOA... Тут таких словей и не произносят.

Демонов боятся. вот и отмалчиваются.

Нафик тада сдался брокер?

кто нить внятно обьяснит зачем эта гравицапа?

>"Бро́кер — юридическое или физическое лицо, выполняющее посреднические функции между продавцом и покупателем, между страховщиком и страхователем, между судовладельцем и фрахтователем. Брокер получает вознаграждение в виде комиссионных." (с) Википедия.

найдена причина кризиса!

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

websphere -движок для ява приложений
zlinux - практически SUSE даже с ястом под ibmские процессора
oracle сами знаете что
message broker 'это транспорт между явой и базой данных который не теряет сообщения
а IBM фирма которая толком ничего не может объяснить, и наоборот еще больше запутывет

zlinux это заточеный дистр линукс работающий на через виртуализацию на zOS. есть и RHEL и SUSE.

И зачем этот транспорт сдался?
когда я имплементирую очереди в базе (читай - простые инсерты) - они что - теряются, что-ли?
(ну, интерес ИБМ в сольюшнах понятен)

да бывали мы на ИБМовских курсях по быдло-энтерпрайзу разному. Начинаешь вопросы задавать (чем-же ваш быдлоентерпрайз-сольюшн Х лучше чем, скажем, <решение Б>). Вводятся в ступор и тупо повторяют быдлофразы, тупо заученные из быдломаркетинговых рекламок (а то что этим люди занимаются не один десяток лет - им даже не известно: ну кто там преподаёт: латентные виндузятники). Там со всем. Зато после курсов знаем: то чем мы давно занимаемся, или то как в банках что-то реализовано не один десяток лет - это оказывается модный сейчас сольюшен Х, во как).
Скажи быдло-жависту очередь или транзакция (или менагеру - объект) - так они себе виндузячью картинку представляют из последних рекламок: (JMS или JTS или коробочку такую, легко представимую).
Задолбали своей ограниченностью.

звиняйте за флейм: наступили на любимую мозоль.

(как-же задолбали пионеры, покупающиеся на рекламки, потом убеждающие начальника купить сольюшен за $$$, потом выучившие это одно, а потом с упорством достойным лучшего применения - распространяющие эту наркот^Wтехнологию ...(нужное подставить). На рекламки на какую-нить "мазь с золотом от старости" наверное не все покупаются. Почему-же с тырнета всё несут как Плюшкины, без разбора: начиная от "решений" и кончая фреймвоками (вместо того чтобы просто работать, и быстро написать под-задачу наиболее эффективно и просто)?
(Налог на дураков с другой стороны).

Это джля энтерпрайз шины сообщений чудо?

уважаемый IBM_dW расскажите лучше как установить WID 6.1.2 на linux(x86-64) ...

Пышы в суппорт, коль не осилил :) Оно оттого так дорого стоит, что там куча французов на английском суппортят. Через 10-20 писем проблема обычно сама решается :)

>websphere -движок для ява приложений > message broker 'это транспорт между явой и базой данных который не теряет сообщения

Херасе... Во образование прет...

>zlinux это заточеный дистр линукс работающий на через виртуализацию на zOS. есть и RHEL и SUSE.

Ниправда. zLinux - это линукс(ядро) для архитектуры IBM S390/S390x, работает как нативно, так и в среде z/VM в виде виртуальной машины на майнфрейме. z/OS нипричём. Дистр точат Novell и RedHat. IBM также точит аппаратные спецпроцы для оптимизаци выполнения Linux, для кода Java, для DB2 в среде z/OS, для оптимизации кластеризации фреймов... всех процов не помню. А вообще, конечно, майнфрейм точится для z/OS.

Тогда сам объясни, с удовольствием послушаю!

http://ru.wikipedia.org/wiki/Websphere

use your head!

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

>Ещё стоит кучу денег и используется для откатов, с последующим засовыванием сабжа туда, где он нафиг не нужен.

+500

А чем бесплатный ActiveMQ плох?

А чем бесплатный ActiveMQ плох?

не нужен. (Лишняя прослойка между аппликацией и базой, увеличение вероятности отказа из-за введения ненужной сущности, дополнительные расходы на администрирование, железо и пр).

Так это типа для реализации ESB штоли? Для простых смертных вот это можно использовать: http://mule.mulesource.org/display/MULE/Home

Простым смертный esb не впился, и деже непростые могут юзать jms с костылями самописными. А вот esb это для бессмертных, пока его развернешь, пока ...

а на кой впился твой jms? В базе рекорды - типа не очередь? Или очередь in-process имплементировать долго (несколько строк кода) если надо вдруг?

Тогда предлагаю следующий Интерпрайз солюшн: "энтерпрайз стек" или "энтерпрайз массив", масштабируемые и всё такое.
"Только положив в наш стек - вы не потеряете данные" (они из него не исчезают! гарантируем). Данные в массиве будут хранится до тех пор - пока не понадобится - между вашей жава-аппликацией и базой. $$$ само собой.
Как такое решение? (ну понятно, адреса продюсеров, консюмеров, все дела - надо-же как-то потом разгребать - что куда ложить ;)

Кусочек Сахара Троллю

>а на кой впился твой jms? В базе рекорды - типа не очередь? Или очередь in-process имплементировать долго (несколько строк кода) если надо вдруг?

Ты непоследователен, накой впилась твоя база? Или долго базу написать?

> Ты непоследователен, накой впилась твоя база? Или долго базу написать?

ну зачем же базу переписывать? (хотя иногда и это имеет смысл: некоторые и делают свои базы на базе берклиДБ - для перформенса и пр). База она гораздо более стандартна, фундаментальна (эффективные операции над большими множествами) и обособлена (в отличие от десятков ненужных промежуточных процессов).

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

> message broker 'это транспорт между явой и базой данных который не теряет сообщения
Телефон дилера травы - в студию.

> А чем бесплатный ActiveMQ плох?
Тем, что WMQ чуть подревнее и вылизан как гениталии пса, которому несколько десятилетий делать было нечего.

А еще - где в AMQ брокер? Когда я последний раз смотрел - не обнаружил, даже рядом. Чтоб со средой разработки (в духе eclipse-based WMQMB Toolkit)

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

>А еще - где в AMQ брокер? Когда я последний раз смотрел - не обнаружил, даже рядом. Чтоб со средой разработки (в духе eclipse-based WMQMB Toolkit)

http://activemq.apache.org/camel/ вроде похож, хотя я с WS MB года три назад работал, точно не знаю чего он умеет. Но Apache Camel без IDE, ручками.

>а на кой впился твой jms? В базе рекорды - типа не очередь? Или очередь in-process имплементировать долго (несколько строк кода) если надо вдруг?

Можно, конечно. Только вот тот же ActiveMQ имеет 1000 и 1 дополнительных фич, которые могут пригодиться.

Для in-process общения в рамках одного узла можно взять java.util.concurrent.BlockingDeque (или даже написать, типичный consumer-producer) и общаться через неё.

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

Или какой-нибудь ещё enterprise фигни. Берешь, например, ActiveMQ — а там всё это есть. Не надо изобретать. И работать всё это, может, в частности и поверх реляционной СУБД. А может поверх своего хранилища, оптимизированного на работу с сообщениями.

>Данные в массиве будут хранится до тех пор - пока не понадобится - между вашей жава-аппликацией и базой. $$$ само собой.

Данные не обязательно сразу попадают в БД. Может быть, например, система которая реагирует на входящие запросы рассылкой соответствующих запросов в другие системы. Пришёл запрос на проведение конференции, ушли запросы (асинхронно, в 3rd-party системы) на бронирование номеров, заказ оборудования для презентаций, заказ комнаты для презентаций, бронирование столиков в ресторане, рассылка приглашений. Или что-нибудь в таком роде.

>деже непростые могут юзать jms с костылями самописными.

А причем тут java?

капча: pusdies

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

И вторая радость: это — не IBM. :)

Это палка о двух концах;)

> А чем бесплатный ActiveMQ плох?

Глючит на больших нагрузках. Не смогли найти причину (хотя шмонали его по полной), в итоге переползли на OpenMQ.

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

>Глючит на больших нагрузках. Не смогли найти причину (хотя шмонали его по полной), в итоге переползли на OpenMQ.

А в чём проявлялся глюк?

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

У нас такая байда с вебсервером была, из-за использования стандартного DataSource, косяк лечится либо уменьшеньшением кол-ва коннектов в единицу времени (один поток- одинн Connection) или использование апческого ConnectionFactory