Насколько я понимаю, в OSGi вы можете обновлять jar-файлы во время выполнения без перезапуска сервера. Но jboss также имеет горячее развертывание, при котором обновляется полное ухо, а сервер все еще работает.
Итак, каковы были бы преимущества OSGi в корпоративном java-проекте в jboss?
Я считаю, что ответ такой же, как и в любом случае использования OSGi: модульность и более высокая степень детализации обновления.
OSGi - это гораздо больше, чем просто обновление jar-файлов во время выполнения без перезапуска сервера. С точки зрения вашего вопроса, он обновляет jar-файлы во время выполнения без перезапуска приложения.
Я признаю, что не знаю конкретной реализации горячего развертывания EAR в JBoss AS, но в любом случае обновление EAR не может быть спроектировано таким образом, чтобы сохранить все состояние приложения. Сервер все еще работает, но вы перезапускаете приложение после обновления. Степень такой потери состояния действительно зависит от того, как вы разрабатываете свое приложение, но факт остается фактом: вы делаете что-то монолитно.
В OSGi дело обстоит иначе: приложение состоит из большого набора пакетов, каждый из которых, как мы надеемся, предназначен для обработки отдельной части функциональности. Этот подход обеспечивает горячее развертывание внутри приложения, поскольку структура предназначена для учета эффекта, который перезапуск любого отдельного jar-файла оказывает на приложение в целом, и позволяет другим jar-файлам реагировать должным образом. Это дает возможность максимально сохранить состояние приложения.
Следовательно, преимущества дизайна OSGi в случае Enterprise - это живучесть приложений. Нет необходимости подчеркивать важность этого. Действительно, есть случаи, когда приложение можно безопасно перезапустить. Но OSGi, на мой взгляд, в настоящее время является единственным действительно масштабируемым и поддерживаемым выбором для Java EE. Доказательством этого является тот факт, что наиболее важные серверы приложений перешли (или собираются) в среду выполнения OSGi (и, следовательно, предоставляют поддержку приложений OSGi).
l10i писал: «В OSGi дело обстоит иначе: приложение состоит из большого набора пакетов, каждый из которых, как мы надеемся, предназначен для обработки отдельной части функциональности. Этот подход обеспечивает горячее развертывание внутри приложения, поскольку структура предназначена для учета эффекта, который перезапуск любого отдельного jar-файла оказывает на приложение в целом, и позволяет другим jar-файлам реагировать должным образом. Это дает возможность максимально сохранить состояние приложения.
Чтобы подробнее остановиться на этом, лучшие приложения OSGi - это сервисно-ориентированные приложения, которые интегрируются через реестр сервисов OSGi. Этот реестр служб является динамическим, службы могут появляться и исчезать в любое время, и потребители служб OSGi соответствующим образом реагируют на эту динамику. Итак, предположим, ваше приложение состоит из ряда пакетов, включая пакет, который использует платежную службу (например, для обработки платежей по кредитным картам), и другой пакет, который предоставляет эту платежную службу. Если вы оказались в ситуации, когда платежный сервис необходимо обновить (из-за того, что у вас есть критическое исправление или, возможно, вы нашли более дешевого поставщика и т. Д.), Вы можете обновить этот платежный сервис, даже не отключая потребителей этого сервиса. Для этого вы можете обновить сам пакет платежных услуг, но в таком случае я бы порекомендовал сначала установить новую версию пакета платежных услуг вместе со старой версией. Это возможно, потому что OSGi позволяет сосуществовать нескольким версиям одного и того же пакета. Затем, как только новый пакет будет запущен и запущен, вы можете удалить старый пакет платежных услуг, после чего потребители автоматически переключатся на использование новых, любезно предоставленных реестром служб OSGi.
Такая архитектура, как в приведенном выше примере, действительно эффективна и отлично подходит для обеспечения бесперебойной работы ваших корпоративных приложений, и ее можно реализовать с помощью служб OSGi в сочетании с возможностью динамически устанавливать, удалять или обновлять пакеты OSGi.
Кстати, в приведенном выше примере есть немного больше деталей, поскольку пакеты также могут быть написаны для использования всех служб определенного типа - что лучше для вас, зависит от вашей ситуации.
Существует несколько способов использования реестра служб OSGi, вы можете использовать его с ServiceTracker API, что довольно низкоуровнево. В большинстве случаев для этого предпочтительнее использовать структуру, такую как OSGi Declarative Services (DS), OSGi Blueprint или другую структуру. В большинстве случаев эти фреймворки работают через внедрение и обрабатывают динамику OSGi Service Registry за вас. Для получения информации о DS или Blueprint см. OSGi 4.2 Enterprise Specification.
