Лучшая среда обмена сообщениями для приложений SOA в реальном времени?

Question

Я работаю над приложением реального времени, реализованным в стиле SOA (читай слабосвязанные компоненты, подключенные через некоторый протокол обмена сообщениями - JMS, MQ или HTTP).

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

В этом случае есть ли какое-либо преимущество использования JMS по сравнению с чем-то вроде веб-службы HTTP (скорость, объем ресурсов и т. Д.)?

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

Я что-то упустил?

Answer 1

Я думаю, что это действительно зависит от ситуации. Там, где я работаю, мы поддерживаем Remoting, JMS, MQ, HTTP и sFTP. Мы реализуем промежуточное программное обеспечение, которое говорит на Remoting, JMS, MQ и HTTP, и программный компонент промежуточного программного обеспечения, который говорит на JMS, MQ и HTTP.

Как уже упоминалось в sgreeve, стандарты помогают нам стать гибкими, но собственные форматы обеспечивают большую функциональность.

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

Answer 2

Я совершенно не согласен с замечаниями С.Лотта, но вот несколько моментов, которые следует учитывать в отношении веб-служб HTTP:

• Ваши клиенты должны знать, как общаться через HTTP - протокол, хорошо поддерживаемый практически всеми современными языками в той или иной форме. JMS, хотя и популярный, более специализирован, чем HTTP, и поэтому ограничивает языки, которые могут использовать ваши взаимосвязанные системы. Возможно, в данный момент это не проблема для вашей системы, но нужно ли вам позже подключать другие системы, которые могут изо всех сил пытаться поддерживать соединение с JMS?

• Стандарты, такие как WSDL и SOAP, которые вы можете использовать для своих сервисов, хорошо поддерживаются многими языками, и существует множество инструментов, которые генерируют код для реализации обоих концов конвейера (клиента и сервера) для вас из файл WSDL, уменьшающий количество dev, которое вам придется сделать. Эти стандарты также позволяют относительно просто определять и публиковать спецификации данных, которые вы будете передавать между вашими системами, что вам, вероятно, придется делать вручную, используя технологию очередей, такую ​​как JMS.

• С другой стороны, как отмечает S.Lott, JMS предоставляет вам функциональность, которую вы отбрасываете, используя (без сохранения состояния) протокол HTTP: гарантированный порядок и надежность; мониторинг; масштабируемость; и т.д. Вы уверены, что они вам не нужны, и не понадобятся ли они в будущем?

Отличный вопрос, кстати.

Answer 3

Полагаю, это зависит от того, что вы подразумеваете под реальным временем ... Ни JMS, ни HTTP, по моему мнению, не поддерживают приложения в реальном времени, а это означает, что они не могут обеспечить предсказуемую / детерминированную производительность или должным образом расставить приоритеты для потоков в присутствии раздор.

Отчасти это то, что эти технологии построены на основе TCP, который сериализует весь трафик в единый FIFO, что означает, что разные потоки трафика не могут быть легко расставлены по приоритетам. Более того, таймеры TCP нелегко контролировать, что приводит к непредсказуемым блокировкам и тайм-аутам ... По этой причине многие потоковые приложения используют UDP вместо TCP в качестве базового протокола.

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

Если вы ищете промежуточное программное обеспечение, которое может предложить вам гарантии надежности и семантику публикации-подписки, которые вы получаете с JMS, но оно было разработано с учетом предметной области приложения реального времени, я рекомендую вам взглянуть на данные OMG. -Распределительная служба (ДДС). См. Dds.omg.org и эту статью, в которой я написал, где объясняется, почему DDS является лучшим промежуточным программным обеспечением для реализации SOA в реальном времени. http://soa.sys -con.com / node / 467488

Answer 4

Если вы идете по HTTP-маршруту и ​​хотите поддерживать более одного компьютера или какую-то надежность, вам понадобится балансировщик нагрузки, способный обнаруживать доступные веб-серверы и загружать запросы между ними, а затем переключаться на другой веб-сервер, если конкретный ящик / процесс умирает. Клиентам, отправляющим HTTP-запросы, также придется сталкиваться с ошибками серверов и повторять операции в некотором цикле.

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

Если вы сосредотачиваетесь только на стороне сервера, используя Java - будь то сервлеты или MessageListener / MDB, они в некотором роде похожи в любом случае. Разница в балансировке нагрузки.

Так что, возможно, вопрос на самом деле должен заключаться в том, проще ли установить и работать с JMS-брокером, чем настраивать инфраструктуру балансировки нагрузки DNS / NAT / IP / HTTP?

Answer 5

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

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

Кроме того, в JMS есть очереди и темы, позволяющие нескольким подписчикам одного издателя. Невозможно в HTTP.

Хотя вам, возможно, не нужны эти вещи в выпуске 1.0, возможно, вы захотите их в будущем.

Кроме того, JMS может использовать другие транспортные механизмы, такие как именованные сокеты, что сокращает накладные расходы, если не выполняется согласование всех сокетов с (почти) каждым запросом.