Архитектура - несколько веб-приложений, работающих с одними и теми же данными.

Question

Я прошу подходящую архитектуру для следующего веб-приложения Java:

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

Возможный подход заключается в создании основного приложения, которое отвечает общим потребностям клиентов, а именно средствам хранения, обработки и поиска данных. Затем клиенты могут вызывать это основное приложение для выполнения своих запросов. Требование заключается в том, что приложения создаются поверх стека Wicket / Spring / Hibernate как WAR-ы.

Чтобы получить картину, вот некоторые из возможных подходов, о которых мы думали:

A Монолитный подход. Создайте одно огромное веб-приложение, которое соответствует всем потребностям (на самом деле это не вариант)

B Подход API. Создайте основной API доступа к базе данных (JAR) для доступа к данным / манипулирования ими. Каждое веб-приложение создается как отдельная WAR, которая использует API для доступа к базе данных. Нет отдельного основного приложения.

C RMI подход. Базовое приложение работает как отдельное приложение (возможно, WAR) и предлагает сервисы через RMI (или HttpInvoker).

D WS подход. Точно так же, как C, но замените RMI на веб-сервисы

E подход OSGi. Соберите все компоненты как модули OSGi, которые работают в контейнере OSGi. Возможно использовать SpringSource DM Server или ModuleFusion. Этот подход не был для нас вариантом по некоторым причинам ...

Надеюсь, я смог прояснить проблему. Мы просто выбираем вариант B, но я не очень уверен в этом. Каковы ваши мнения? Любые другие решения? Каковы недостатки каждого решения?

Answer 1

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

Подумайте о своих данных - схема БД, насколько важны транзакции (например, в банковских системах все касается транзакций) и т. Д.

Затем определите общий метод доступа - от набора хранимых процедур до механизма распределенных транзакций ...

Следующим шагом является бизнес-логика / презентация - что можно обобщить и что является предметом настройки.

И последний этап - интерфейсы, визуализация и отчеты

Answer 2

Похоже, что A и E находятся вне изображения, как вы указали в своем вопросе по разным причинам. Вариант А мог бы стать одним из огромных приложений, которые усложнили бы техническое обслуживание в будущем.

B, C и D, по сути, одинаковы по архитектуре, поскольку включают удаленный доступ к общим библиотекам из различных веб-приложений, единственное различие заключается в транспортном механизме. Я бы порекомендовал реализовать это в EJB 3 или Spring, если это возможно, вместо использования ваших собственных библиотек RMI, поскольку любая из них обеспечивает хорошую основу для RMI / Webservices.

Так что я думаю, что эта проблема в основном сводится к следующим двум вариантам:

1) Включите классы бизнес-уровня и уровня DAO в качестве общего jar, включенного в развертывание всех веб-приложений.

Преимущества:

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

Недостатки:

• Нельзя добавить больше аппаратного обеспечения специально для среднего уровня (уровни обслуживания и DAO), поскольку оно включено в каждое веб-приложение.
• Другие бизнес-группы в организации не будут иметь доступа к вашим бизнес-службам, поскольку отсутствует удаленный интерфейс.

2) Разверните классы бизнес-служб и уровней DAO на отдельном сервере приложений и предоставьте бизнес-методы удаленно.

Преимущества:

• При необходимости вы можете масштабировать бизнес-сервис и уровень DAO в зависимости от нагрузки от различных веб-приложений, вызывающих его.
• Другие приложения в организации могут использовать ваши интерфейсы при необходимости.
• более масштабируемый
• Вы получаете все преимущества Java EE.

Недостатки:

• Более сложное развертывание.
• Еще один сервер для обслуживания и мониторинга.
• Может быть медленнее, поскольку вызовы будут выполняться по сети, хотя это не должно быть слишком большой проблемой.

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

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

Answer 3

B, C и D - это просто разные способы достижения одного и того же.

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

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

Answer 4

Я думаю, что вам нужно отдельное приложение, которое все клиентские приложения будут использовать в качестве своего уровня данных. Причина этого заключается в том, что вы хотите, чтобы все они обращались к базе данных одинаково. Есть также некоторые условия гонки, которые вы можете получить, поскольку транзакции базы данных не смогут предотвратить. Другая причина заключается в том, что использование базы данных как формы RPC является известным антипаттерном. Если все ваши приложения обращаются к базе данных напрямую, вы почти неизбежно получите таблицу «событий», которую различные приложения периодически опрашивают ... не делайте этого.

Answer 5

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

В настоящее время мы занимаемся абстрагированием данных на более высокий уровень, чем раньше. Теперь у нас есть DAL, к которому можно обращаться напрямую, но мы поставили «Фабрику моделей» перед DAL. Целью фабрики моделей является посредничество как кеша, так и слоя данных, выступая в роли сквозного соединения. Таким образом, вызывающая сторона всегда вызывает фабрику моделей, а не DAL или кеширующий код напрямую. Этот уровень абстракции будет в основном извлекать данные из DAL при отсутствии кеша, не добавляя сложности API.