Как делиться бизнес-логикой между несколькими приложениями

Question

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

Есть одна общая черта, хотя они нуждаются в доступе к (почти) той же информации.

Проблема

Из-за сложности данных компания обрабатывает, мы имеем дело с множеством различных источников, некоторые из них в наследство от древних времен. Наши объекты домена могут отображаться во многих из этих источников. Например, объект домена Контракт сопоставляется с нашей основной базой данных, но связанные с ним (физические) файлы хранятся на сервере документов, а связанная с ним деятельность хранится в базе данных NoSQL. Поэтому добавление, удаление, поиск любого из этих объектов связано со многими внутренними операциями.

Наши источники данных (хотя это может быть любой):

• AS400 (с использованием DB2 в качестве базы данных)
• Documentum менеджер документ
• Монго DB
• Внешние веб-сервисы
• Другие устаревшие источники

Обычно мы используем Glas sfish как сервер приложений и maven как наш инструмент сборки.

Гол

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

• Compact
• последовательны
• Простота в использовании
• Прост в обслуживании
• Доступен с человека у разных клиентов

То, что мы нашли до сих пор

Мы боролись в течение нескольких недель и до сих пор мы не можем найти что-либо полностью удовлетворительным. Некоторые решения:

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

• Создайте проект Ejb, содержащий всю логику и доступ к нему удаленно: простота в обслуживании, безопасность, кэширование и конфигурация реализованы только один раз. Мы боимся штрафа за удаленные звонки. Как мы заметили в наших исследованиях, это кажется плохой практикой (у нас нет большого опыта работы с ejbs).

• Создайте проект уха со всем, что внутри, и используйте локальный доступ: ну, это быстрее, чем удаленная версия, но это ад для поддержки.

• Перейти к OSGI: Мы немного боимся этого, так как он не так популярен, как Ejb, и мы никогда не использовали его всерьез.

Есть ли обычная практика для такого рода проблем?

Большое спасибо!

Answer 1

Я бы не рекомендовал поместить всю логику в 1 проект EAR и использовать локальный доступ. Если у вас много кода в одном месте, его будет сложнее поддерживать, тестировать, развертывать и т. Д.

Я бы создал проект maven-модуля maven с общими зависимостями. Одна из зависимостей - служба с бизнес-логикой и доступом DAO, которая будет выставлять API. С проектом Maven вы можете легко управлять версиями файлов POM. Различные проекты могут работать с другой версией общего сервиса. Maven будет управлять версией для вас. Однако для этого требуются некоторые настройки и усилия по внедрению.

Другой вариант, упомянутый вами - автономный EAR с удаленными EJB, должен работать нормально. Не беспокойтесь о производительности и количестве удаленных вызовов, если у вас нет большой нагрузки. Просто кэшируйте удаленные EJB-заглушки на клиенте, чтобы избежать ненужного поиска JNDI.

Лично я предпочитаю первый вариант с общей зависимостью, управляемый Maven. Он прост в эксплуатации, легко управляется версиями, развертывается, настраивается. С Maven вам не нужно вручную менять файл jar для каждого проекта, вы можете просто использовать такие инструменты, как Nexus