OSGi против Jboss горячего развертывания - PullRequest
10 голосов
/ 06 октября 2011

Насколько я понимаю, в OSGi вы можете обновлять jars во время выполнения, не перезагружая сервер. Но у jboss также есть горячее развертывание, при котором обновляется весь слух, а сервер все еще работает.

Итак, каковы преимущества OSGi в корпоративном java-проекте в jboss?

Ответы [ 2 ]

9 голосов
/ 09 октября 2011

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

OSGi - это гораздо больше, чем обновление jar-файлов во время выполнения без перезагрузки сервера. С точки зрения вашего вопроса, это обновление JAR во время выполнения без перезапуска приложения .

Признаюсь, я не знаю конкретной реализации горячего развертывания EAR в JBoss AS, но в любом случае обновление EAR невозможно спроектировать так, чтобы сохранить все состояние приложения. Сервер все еще работает, но вы по существу перезапускаете приложение после обновления. Степень потери такого состояния действительно зависит от того, как вы разрабатываете свое приложение, но факт остается фактом: вы делаете вещи монолитно.

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

Следовательно, преимуществами дизайна OSGi в случае Enterprise является жизнеспособность приложений. Нет необходимости подчеркивать важность этого. Действительно, есть случаи, когда приложение может быть безопасно перезапущено. Но OSGi, на мой взгляд, является единственным действительно масштабируемым и поддерживаемым выбором для Java EE в настоящее время. Тот факт, что наиболее важные серверы приложений перешли (или собираются) в среду выполнения OSGi (и, следовательно, обеспечивает поддержку приложений OSGi), является доказательством этого.

6 голосов
/ 13 октября 2011

l10i писал: С OSGi это не так: приложение состоит из большого набора пакетов, каждый из которых, как мы надеемся, предназначен для обработки отдельной части функциональности.Этот подход позволяет выполнять горячее развертывание внутри приложения, поскольку платформа разработана с учетом эффекта, который перезапуск любого отдельного JAR-файла приносит приложению в целом, и позволяет другим JAR-системам реагировать соответствующим образом.Это дает возможность максимально сохранить состояние приложения.

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

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

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

Существует несколько способов использованияРеестр сервисов OSGi, вы можете использовать его с ServiceTracker API , который является довольно низким уровнем.В большинстве случаев для этого предпочтительнее использовать платформу, такую ​​как декларативные сервисы OSGi (DS), OSGi Blueprint или другие.В большинстве случаев эти платформы работают через внедрение и управляют динамичностью реестра служб OSGi для вас.Информацию о DS или Blueprint см. В спецификации OSGi 4.2 Enterprise .

...