Шина сообщений для сервисов OSGi - PullRequest
4 голосов
/ 30 января 2012

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

  • Синхронизация и доставка ASync
  • Только точка-точка
  • Гарантированная доставка - предпочтительно с сохранением через файлы
  • Строгое сообщение заказывается изтот же клиент (асинхронный режим), но обязательно от разных клиентов
  • Поддержка процессов от процесса к узлу и от узла к узлу хороша, но не обязательна

Решения с открытым исходным кодом будутпредпочтителен, но не обязателен.

Я рассмотрел eventbus (как рекомендовано в https://stackoverflow.com/a/1953453/796559),, но это, похоже, не работает хорошо.

Так чтовопрос в том, какие технологии соответствуют вышеперечисленному?

Ответы [ 5 ]

5 голосов
/ 03 февраля 2012

Тонни,

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

Чтобы ответить на это, хорошие люди во многих организациях придумали JBI, BPMN и множество других решений, которые позволяют деловым людям моделировать бизнес-процессы, которые они хотели «оцифровать». Но на самом деле все они были несовершенны на очень критическом уровне: они решали проблемы бизнеса, но не проблемы интеграции. Таким образом, многие из этих реализаций были безуспешны, если не были сделаны каким-либо дорогостоящим консультантом, и даже тогда ваши перспективы были отрывочны.

В то же время некоторые очень умные люди в самом конце 90-х годов опубликовали книгу под названием «Шаблоны корпоративной интеграции», в которой было выявлено более 60 шаблонов проектирования, используемых для решения общих проблем интеграции. Многие из тех, кто занимается ESB, поняли, что их проблема не в бизнес-моделировании. Скорее проблема заключалась в том, как интегрировать свои существующие приложения. Чтобы помочь решить эту проблему, Майкл Стрэчан и некоторые действительно умные ребята основали проект Apache Software Foundation «Camel». Camel - это строгая реализация шаблонов Enterprise Integration Patterns в дополнение к огромному количеству компонентов, разработанных для того, чтобы позволить таким людям, как вы и я, объединять все вместе.

Итак, если вы считаете свой бизнес-процесс просто необходимостью отправлять данные из одного приложения в другое с соответствующими преобразованиями данных между ними, то Camel - ваш ответ. Теперь, что, если вы хотите основать «маршрут» (определенную серию конечных точек приложения, которую вы хотите отправить с помощью данных) из набора настраиваемых правил в базе данных? Ну, верблюд тоже может это сделать! Для этого есть конечная точка! Во всяком случае, не делайте традиционного ESB, его старый и сломанный. И Абсолютно сделай верблюжью вещь.

Пожалуйста, дайте мне знать, если это поможет.

4 голосов
/ 14 февраля 2012

Спецификация OSGi определяет компонент «Администратор событий», который представляет собой облегченную подсистему событий pub-sub.Из RFC0157:

Event Admin указывает средство для источника события для отправки событий в прослушиватели событий.Источники событий могут создавать события с темой и свойствами и запрашивать администратора событий для доставки событий слушателям событий, которые заявили о своей заинтересованности в конкретных темах событий и / или значениях свойств.Источник события может запрашивать синхронную (и неупорядоченную) доставку или асинхронную (и упорядоченную) доставку.

По сравнению с вашими требованиями он оценивается следующим образом:

  • Синхронизация иAСинхронная доставка: Проверка
  • Только точка-точка: Нет.Pub-Sub
  • Гарантированная доставка - предпочтительно с сохранением через файлы: NO
  • Строгое сообщение, заказанное от того же клиента (асинхронный режим): YES
  • Поддержка межпроцессного взаимодействия: if (process == служба OSGi) -> Да
  • Поддержка узла к узлу: Еще нет .Над этим работали ребята из Distributed OSGi, но я не видел ничего конкретного.

Мне нравится концепция Camel, но недавно я решил использовать (более легкого) Event Admin в качестве моеготребования ограничены.+1 к Майку о мотивации верблюда.Я бы посмотрел на это и затем сравнил варианты, прежде чем принять решение.

1 голос
/ 12 апреля 2012

iPOJO Обработчики событий администратора - это более удобный способ доступа к службе администратора событий, упомянутой @ maasg.

1 голос
/ 30 января 2012

Разве вы не ищете ESB? ServiceMix - это:

гибкий контейнер интеграции с открытым исходным кодом, объединяющий функции и возможности Apache ActiveMQ , Camel , CXF , ODE , Karaf - мощная платформа времени исполнения, которую вы можете использовать для создания собственных интеграционных решений. Он предоставляет готовый корпоративный ESB, работающий исключительно на OSGi.

0 голосов
/ 30 января 2012

похоже, что вы говорите о ESB здесь.Если это так, то вы можете взглянуть на wso2 ESB .Он работает на apache synapse .он использует OSGi в качестве модульной структуры, так что вы можете добавлять / удалять функции в соответствии с вашими требованиями.Существует целый стек продуктов от wso2, подобных брокерам сообщений, серверам бизнес-процессов (ODE) и т. Д., Основанным на той же базовой платформе OSGi.

...