Java — распределенное программирование, RMI?

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

Для распределенной симуляции я планирую использовать «координатор» (звездообразная топология). Все участвующие симуляции просто регистрируются в нем и разговаривают только с координатором. Затем координатор координирует выполнение различных задач между каждой симуляцией.

Быстрый пример проблемы с распределением: когда одна симуляция «отвечает» за определенные объекты, например за дорогу. А другой «отвечает» за другие дороги. Однако эти дороги взаимосвязаны (и, следовательно, нам нужна синхронизация между этими симуляциями и возможность удаленного обмена данными/вызова методов).

Я взглянул на RMI и думаю, что он может подойти для этой задачи. (Чтобы абстрагироваться от необходимости создания дисциплины передачи сигналов по проводной сети).

Это нормально? Проблема здесь в том, что участникам симуляции необходимо централизовать некоторые свои хранилища данных в «координаторе», чтобы обеспечить явную синхронизацию между симуляциями. Кроме того, для некоторых моделей могут потребоваться компоненты или методы из других моделей. (Отсюда и идея использования RMI).

Мой основной подход заключается в том, чтобы «координатор» запускал гигантский реестр RMI. И каждое моделирование просто ищет все в реестре, гарантируя, что правильные объекты используются на каждом этапе.

У кого-нибудь есть советы, как идти по этому пути?


person Alex Lim    schedule 03.02.2009    source источник
comment
Если вы распространяете на такое большое количество компьютеров, почему бы не использовать фреймворк, предназначенный для этого? На ум приходят JPPF, OpenMPI или MPJ-Express.   -  person Tim    schedule 03.02.2009


Ответы (8)


Вы также можете проверить Hazelcast. Hazelcast — это транзакционная, распределенная/разделенная реализация очередей, топиков, карт, наборов, списков, блокировок и исполнителей с открытым исходным кодом. С ним очень легко работать; просто добавьте hazelcast.jar в путь к классам и начните программировать. Практически не требует настройки.

Если вы заинтересованы в распределенном выполнении задач Runnable, Callable, ознакомьтесь с документацией по службе Distributed Executor по адресу http://code.google.com/docreader/#p=hazelcast

Hazelcast выпускается под лицензией Apache, также доступна поддержка уровня предприятия.

person Talip Ozturk    schedule 04.02.2009

Это нормально? ИМХО нет. И я скажу вам, почему. Но сначала я добавлю отказ от ответственности, что это сложная тема, поэтому любой ответ следует рассматривать как поверхностный.

Сначала вместо того, чтобы повторяться, я укажу вам на краткое описание технологий сетки/кластера Java, которое я написал некоторое время назад. Это в основном полный список.

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

Что вам действительно нужно для этого, так это, вероятно, кластерное решение (а не сетка данных/вычислений), и я бы посоветовал вам взглянуть на Терракота. В идеале вам следует обратить внимание на Oracle Coherence, но это, несомненно, дорого ( по сравнению с бесплатным). Хотя это фантастический продукт.

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

Если вы ищете более распределенную модель, возможно, вам следует обратить внимание на подход, основанный на SOA.

person cletus    schedule 03.02.2009
comment
Клетус, мне кажется, что описываемая вами топология «звезда» очень похожа на ESB, так что вся ваша критика применима. Вы согласны? - person duffymo; 03.02.2009

Посмотрите на http://www.terracotta.org/

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

Я использовал его в приложениях, и скорость очень впечатляет.

Павел

person Paul Whelan    schedule 05.02.2009

Рассматривали ли вы возможность использования очереди сообщений? Вы можете использовать JMS для связи/координации задач и результатов среди набора серверов/узлов. Вы даже можете использовать Amazon SQS (Simple Queue Service: aws.amazon.com/sqs) и запустить свои серверы на EC2, чтобы вы могли увеличивать и уменьшать масштаб по мере необходимости.

Просто мои 2 цента.

person simonlord    schedule 05.02.2009
comment
Да, я согласен с тем, что подход с очередью сообщений кажется наиболее разумным (возможно, решение ESB), но время, затрачиваемое на настройку инфраструктуры по сравнению с возвратом, довольно мало. Проект, над которым я работаю, на самом деле является прототипом. - person Alex Lim; 05.02.2009

Взгляните на JINI, это может быть вам полезно.

person Marko    schedule 03.02.2009

Что ж, Jini или, точнее, Javaspaces — хорошее место для простого подхода к проблеме. Javaspaces позволяет реализовать модель мастер-воркер, в которой ваш мастер (координатор в вашем случае) записывает задачи в Javaspace, а рабочие запрашивают и обрабатывают эти задачи, записывая результаты обратно для мастера. Поскольку ваша проблема не является досадно параллельной, а вашим работникам необходимо синхронизировать/обменять данные, это усложнит ваше решение.

Использование Javaspaces добавит гораздо больше абстракции к вашей реализации, чем использование простого RMI (который используется фреймворком Jini внутри в качестве «проводного протокола» по умолчанию).

Взгляните на эту статью от Sun для введения.

И Jini Tutorial Яна Ньюмарча — неплохое место для начала изучения Jini.

person Mystic    schedule 03.02.2009
comment
Если вы собираетесь перейти на Javaspaces, лично я бы выбрал только GigaSpaces gigaspaces.com (хотя и коммерческий) . - person cletus; 03.02.2009
comment
+1 на GigaSpaces. Когда я впервые услышал о Jini на JavaOne в 1999 году, я подумал, что это замечательная идея, но я не вижу, чтобы она когда-либо получила поддержку. Объяснениями могут быть высокая стоимость лицензирования, проприетарный проводной протокол и т. д. Чувствуется мертвым, как дверной гвоздь. Я удивлен рекомендацией. - person duffymo; 03.02.2009
comment
Jini концептуально чист и прост, вы можете использовать любой проводной протокол, который вам нравится, он открыт и бесплатен для коммерческого использования. Я не уверен, что вы имеете в виду под мертвым, но что касается популярности, я думаю, что это была плохая маркетинговая стратегия Sun, когда они продемонстрировали Jini как технологию для (маленьких) устройств. - person Mystic; 03.02.2009
comment
dead == Я не знаю, чтобы кто-то в моем маленьком мире говорил, думал или использовал Джини. Признаться, мой мир ограничен. - person duffymo; 03.02.2009
comment
Ну ладно :), но называть его мертвым немного неуместно. Будучи легкой структурой для сервис-ориентированных вычислений, она может быть мертва только в том случае, если сервис-ориентированные вычисления мертвы, потому что это то, что делает Jini. Если бы кто-то назвал Джини мертвой, RMI был бы мертв задолго до этого. - person Mystic; 03.02.2009
comment
Jini, насколько я знал, подразумевала всех участников Java. Преимущество, которое я вижу в SOA через HTTP или XML, заключается в том, что протоколы открыты, а конечные точки могут быть написаны либо на Java, либо на .NET. - person duffymo; 03.02.2009
comment
Я думаю, что это все еще верно. Но реализация службы/клиента .Net не должна быть большой. Совершенно верно, Jini - это SOA, не предписывающая, какие протоколы используются. Если на самом деле вы можете реализовать веб-сервисы поверх Jini. - person Mystic; 04.02.2009

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

При параллельном и синхронизированном запуске распределенных имитационных моделей я вижу два варианта:

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

Первый вариант был тщательно исследован для архитектуры высокого уровня (HLA), см., например, http://en.wikipedia.org/wiki/IEEE_1516 для начала.

Однако второй вариант кажется мне более простым и с меньшими накладными расходами.

person Roy    schedule 03.05.2009

GridGain — хорошая альтернатива. У них есть реализация map/reduce с «прямой поддержкой API для разделения и агрегации» и «сеансом распределенной задачи». Вы можете просмотреть их примеры и посмотреть, подходят ли некоторые из них к вашему потребности.

person marcospereira    schedule 03.02.2009