Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.

HTTP (plain, rest, json, soap)

Здравствуйте, 6lackbird, Вы писали:

6>Здравствуйте, Аноним, Вы писали:

А>>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.

6>HTTP (plain, rest, json, soap)

ну это протоколы, а хотелось бы что то выше этих протоколов иметь )

On 12.08.2013 11:36, Аноним 87 wrote:

> А>>Добрый день. Есть несколько приложений, подскажите, как организовать
> между ними взаимодействие? Некоторые могут находится на разных даже
> серверах. Хотелось бы какую то простую технологию.
>
> 6>HTTP (plain, rest, json, soap)
>
> ну это протоколы, а хотелось бы что то выше этих протоколов иметь )

EJB remote call (транспортом чаще всего может быть и http(s))

--
WBR,
Serge.

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.
Слишком абстрактно. Какого типа приложения? JEE? На каком сервере?
RMI, как вариант. Если уже есть JEE, то можно спокойно EJB Session Bean взять. Там есть локальные и удаленные интерфейсы. С ними достаточно просто.
Если сервера очень удаленные, то, возможно, лучше что-то с HTTP. Сейчас есть куча решений, которые позволят локальный вызов заменить на удаленный с тем же интерфейсом. JAX-WS, Spring Http Invoker, Spring REST и т.п.

Здравствуйте, Аноним, Вы писали:

6>>HTTP (plain, rest, json, soap)
А>ну это протоколы, а хотелось бы что то выше этих протоколов иметь )
Большинство современных реализаций этих протоколов в Java позволяют работать с удаленными вызовами через Java интерфейс.
В итоге, для того чтобы переключиться между локальными и удаленными вызвовами достаточно просто поменять реализацию.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.
B>Слишком абстрактно. Какого типа приложения? JEE? На каком сервере?
B>RMI, как вариант. Если уже есть JEE, то можно спокойно EJB Session Bean взять. Там есть локальные и удаленные интерфейсы. С ними достаточно просто.
B>Если сервера очень удаленные, то, возможно, лучше что-то с HTTP. Сейчас есть куча решений, которые позволят локальный вызов заменить на удаленный с тем же интерфейсом. JAX-WS, Spring Http Invoker, Spring REST и т.п.

нужно чтобы несколько java-приложений между собой взаимодействовали по какому то сценарию или событиям. Или всё самому это нужно реализовывать?

Здравствуйте, Аноним, Вы писали:

А>нужно чтобы несколько java-приложений между собой взаимодействовали по какому то сценарию или событиям. Или всё самому это нужно реализовывать?
нужно чтобы приложение что-то делало. самому писать, или есть библиотеки?
Как "взаимодействовали"? Что значит "по-сценарию"? Почему "сценарий" и "события" это одно и то же?

Здравствуйте, Аноним, Вы писали:

А>нужно чтобы несколько java-приложений между собой взаимодействовали по какому то сценарию или событиям. Или всё самому это нужно реализовывать?
Существует масса готовых решений. Но из двух фраз, достаточно сложно понять что вам нужно. То ли просто очереди JMS, то ли workflow engine, то ли ещё чего.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, Аноним, Вы писали:

А>>нужно чтобы несколько java-приложений между собой взаимодействовали по какому то сценарию или событиям. Или всё самому это нужно реализовывать?
B>Существует масса готовых решений. Но из двух фраз, достаточно сложно понять что вам нужно. То ли просто очереди JMS, то ли workflow engine, то ли ещё чего.

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

А>это может быть и сценарий, а может быть и событий, еще точно не известно. но это не JEE-приложения, и не под какими серверами не работают.

А вы рисуете дизайн под несформировавшиеся требования? Нарисуйте стрелочку между квадратами, подпишите "remote interaction". Или не подписывайте. Сто раз такие диаграммы видел.

А>ну это протоколы, а хотелось бы что то выше этих протоколов иметь )
Akka — и просто и расширяемо и хорошо контролируемо на уровне диспетчеров/очередей сообщений.

On 12.08.2013 21:02, Аноним 87 wrote:

> это может быть и сценарий, а может быть и событий, еще точно не
> известно. но это не JEE-приложения, и не под какими серверами не работают.

Если центральный хаб допускается требованиями, то гуглите по слову ESB
(Enterprise Service Bus). Возможно вам и не подойдут имеющиеся
реализации, но как паттерн — это скорее всего то, что вам нужно.

--
WBR,
Serge.

Ну или протобув на цокетах )

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.
REST: JAX-RS и любая его реализация. Reference Implementation — это Jersey, там есть как серверная так и клиентская часть. Есть и другие. Строго говоря REST может быть и без JAX-RS, это скорее идеология.
JMS: Reference Implementation — OpenMQ, но большинство использует ActiveMQ

JAX-RS — проще, но при этом у нее более "динамическая типизация" (не знаю как описать это проще).
JMS — сложнее, но он как бы для той задачи, что вы указали, и делался.

Здравствуйте, silverwolf, Вы писали:

S>Здравствуйте, Аноним, Вы писали:

S>JMS: Reference Implementation — OpenMQ, но большинство использует ActiveMQ

Добавлю сюда же ZeroMQ — The Simplest Way to Connect Pieces, как они сами о себе говорят. Довольно просто и удобно в плане настройки топологии.

S>JMS — сложнее, но он как бы для той задачи, что вы указали, и делался.

Полностью соглашусь с предыдущим орптором.

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Есть несколько приложений, подскажите, как организовать между ними взаимодействие? Некоторые могут находится на разных даже серверах. Хотелось бы какую то простую технологию.

я бы посоветовал посмотреть на Apache Camel. Он как раз предназначен для интеграции приложений через месседжинг, в нём реализованы практически все интеграционные паттерны, использовать — достаточно просто.