Как лучше всего обмениваться экземплярами бизнес-объектов между веб-приложениями Java с помощью JBoss и Spring?
В настоящее время у нас есть веб-приложение, загружающее контекст приложения Spring, которое создает стек бизнес-объектов, объектов DAO и Hibernate. Мы хотели бы поделиться этим стеком с другим веб-приложением, чтобы избежать наличия нескольких экземпляров одних и тех же объектов.
Мы рассмотрели несколько подходов; отображение объектов с помощью JMX или JNDI или с помощью EJB3.
У всех разных подходов есть свои проблемы, и мы ищем более легкий метод.
Любые предложения о том, как это решить?
Обновлено: я получил комментарии с просьбой немного уточнить, так что вот:
Основная проблема, которую мы хотим решить, заключается в том, что мы хотим иметь только один экземпляр Hibernate. Это связано с проблемами с недействительностью кеша 2-го уровня Hibernate при запуске нескольких клиентских приложений, работающих с одним и тем же источником данных. Кроме того, стек бизнес / DAO / Hibernate становится довольно большим, поэтому отказ от его дублирования имеет больше смысла.
Во-первых, мы попытались посмотреть, как только бизнес-уровень может быть доступен другим веб-приложениям, а Spring предлагает оболочку JMX по цене небольшого количества XML. Однако нам не удалось привязать объекты JMX к дереву JNDI, поэтому мы не могли искать объекты в веб-приложениях.
Затем мы попробовали привязать бизнес-уровень напрямую к JNDI. Хотя Spring не предлагал никаких методов для этого, использование JNDITemplate для их привязки также было тривиальным. Но это привело к нескольким новым проблемам: 1) Менеджер безопасности запрещает доступ к загрузчику классов RMI, поэтому клиент потерпел неудачу, как только мы попытались вызвать методы на ресурсе JNDI. 2) Как только проблемы с безопасностью были решены, JBoss выбросил IllegalArgumentException: объект не является экземпляром объявления класса. Немного чтения показывает, что нам нужны реализации заглушек для ресурсов JNDI, но это кажется большим хлопотом (возможно, Spring может нам помочь?)
Мы еще не слишком много изучили EJB, но после первых двух попыток мне стало интересно, возможно ли вообще то, чего мы пытаемся достичь.
Подводя итог тому, чего мы пытаемся достичь: один экземпляр JBoss, несколько веб-приложений, использующих один стек бизнес-объектов поверх уровня DAO и Hibernate.
С уважением,
Нильс
Сложно было передать все 300 символов, поэтому я отредактировал вопрос, чтобы добавить больше деталей :-)
Ответы 9
Взгляните на JBossCache. Это позволяет вам легко обмениваться / реплицировать карты данных между несколькими экземплярами JVM (в одном или разных блоках). Он прост в использовании и имеет множество вариантов протокола на уровне проводов (TCP, UDP Multicast и т. д.).
Развернуты ли веб-приложения на одном сервере?
Я не могу говорить от имени Spring, но перенести бизнес-логику на уровень EJB с помощью Session Beans несложно.
Организация приложения проста. Логика входит в Session Beans, и эти Session Beans объединены в одну банку как артефакт Java EE с файлом ejb-jar.xml (в EJB3 он, вероятно, будет практически пустым).
Затем объедините классы Entity в отдельный файл jar.
Затем вы создадите каждое веб-приложение в отдельном файле WAR.
Наконец, все jar-файлы и войны объединены в Java EE EAR с соответствующим файлом application.xml (опять же, это, вероятно, будет довольно минимальным, просто перечисляя jar-файлы в EAR).
Этот EAR развертывается оптом на сервере приложений.
Каждая WAR фактически независима - их собственные сеансы, собственные пути контекста и т. д. Но они имеют общий бэкэнд EJB, поэтому у вас есть только один кеш 2-го уровня.
Вы также используете локальные ссылки и семантику вызова для взаимодействия с EJB, поскольку они находятся на одном сервере. Здесь нет необходимости в удаленных звонках.
Я думаю, что это довольно хорошо решает вашу проблему, и это довольно просто в Java EE 5 с EJB 3.
Кроме того, как я понимаю, вы все еще можете использовать Spring для большей части своей работы, но я не специалист по Spring, поэтому я не могу говорить о деталях.
Да, все развернуто на одном сервере. Это выглядит довольно интересно, сегодня я попробую EJB. Я хочу сказать, что Spring предлагает обернуть бобы, например, JMX без кода, но, видимо, не для EJB. Во всяком случае, сегодня я смотрю на подход EJB.
Терракотовый может здесь хорошо подойти (раскрытие: я разработчик Terracotta). Terracotta прозрачно кластеризует объекты Java на уровне JVM и интегрируется как с Spring, так и с Hibernate. Это бесплатно и с открытым исходным кодом.
Как вы сказали, проблема более чем одного клиентского веб-приложения, использующего кеш L2, заключается в том, чтобы эти кеши были синхронизированы. Используя Terracotta, вы можете кластеризовать один кэш L2 Hibernate. Каждый клиентский узел работает со своей копией этого кластерного кеша, а Terracotta синхронизирует его. Эта ссылка объясняет больше.
Что касается ваших бизнес-объектов, вы можете использовать Terracotta Весенняя интеграция для кластеризации ваших bean-компонентов - каждое веб-приложение может совместно использовать экземпляры кластеризованных bean-компонентов, а Terracotta прозрачно синхронизирует кластерное состояние.
Я не совсем уверен, что вы пытаетесь решить; в конце дня каждый jvm будет иметь либо реплицированные экземпляры объектов, либо заглушки, представляющие объекты, существующие на другом (логическом) сервере.
Вы можете настроить третий сервер «бизнес-логики» с удаленным API, который могут вызывать ваши два веб-приложения. Типичным решением является использование EJB, но я думаю, что в стеке Spring есть встроенные опции удаленного взаимодействия.
Другой вариант - использовать некоторую форму архитектуры общего кеша ... которая будет синхронизировать изменения объектов между серверами, но у вас все еще есть два набора экземпляров.
На самом деле, если вам нужно легкое решение и не нужны транзакции или кластеризация, просто используйте поддержку Spring для RMI. Он позволяет удаленно предоставлять компоненты Spring с помощью простых аннотаций в последних версиях. См. http://static.springframework.org/spring/docs/2.0.x/reference/remoting.html.
Я использовал этот подход для доступа к общим компонентам Spring из веб-приложения. Это работает, хотя я все еще чувствую, что, вероятно, есть лучшее / более чистое решение.
Если вам не нравится RMI, Spring предлагает несколько других вариантов удаленного взаимодействия - Hessian, Burlap и HttpInvoker (настраиваемое решение для удаленного взаимодействия Spring - сериализация Java через HTTP). Конечно, всегда есть и веб-сервисы.
Спасибо за ваши ответы. Мы все еще не совсем там, но сейчас мы попробовали несколько вещей и теперь видим вещи более ясно. Вот краткое обновление:
Наиболее жизнеспособным решением является EJB. Однако это потребует некоторого количества изменений в нашем коде, поэтому мы не собираемся полностью реализовывать это решение прямо сейчас. Я почти удивлен, что мы не смогли найти какую-то функцию Spring, которая могла бы нам помочь.
Мы также попробовали JNDI-маршрут, который заканчивается необходимостью заглушек для всех общих интерфейсов. Это вызывает много хлопот, учитывая, что в любом случае все находится на одном сервере.
Вчера у нас был небольшой прорыв с JMX. Хотя JMX определенно не предназначен для такого использования, мы доказали, что это возможно - без изменений кода и с минимальным объемом XML (большое спасибо Spring за MBeanExporter и MBeanProxyFactoryBean). Основными недостатками этого метода являются производительность и тот факт, что наши доменные классы должны совместно использоваться через папку server / lib JBoss. То есть мы должны удалить некоторые зависимости из наших WAR и переместить их в server / lib, иначе мы получим ClassCastException, когда бизнес-уровень возвращает объекты из нашей собственной модели домена. Я полностью понимаю, почему это происходит, но это не идеально для того, чего мы пытаемся достичь.
Я подумал, что пришло время для небольшого обновления, потому что то, что кажется лучшим решением, займет некоторое время. Я опубликую здесь наши выводы, как только мы выполним эту работу.
Я и другие предлагали это несколько раз в этой ветке, но вы смотрели на Terracotta? В отличие от всех других решений, представленных до сих пор, он разработан специально для разделения состояний, о чем вы и просили.
Вам следует взглянуть на веб-приложение Terracotta Reference - Examinator. В нем есть большинство необходимых вам компонентов - Hibernate, JPA и Spring с серверной частью MySQL.
Он был предварительно настроен для масштабирования до 16 узлов, 20 тысяч одновременных пользователей.
Посмотрите здесь: http://reference.terracotta.org/examinator
А как насчет spring parentContext? Ознакомьтесь с этой статьей:
http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html
В Spring есть точка интеграции, которая может вас заинтересовать: Инъекционный перехватчик EJB 3. Это позволяет вам получить доступ к компонентам Spring из EJB.
Не могли бы вы прокомментировать: 1. Какую проблему вы пытаетесь решить; 2. Проблемы, которые вы обнаружили с указанными вами подходами. Это позволит дать более конкретный ответ ...