Планируем перейти на J2EE технологию. Сейчас изучаю возможность организовать работу своих программистов по следующему принципу. Каждый из них, специалист в одной конкретной предметной области, пишет J2EE приложение со своими JSP просмотрами и бизнес-службами (организованными как Session Facade). Другие программисты встраивают в своих приложениях обращение к этим JSP просмотрами и/или бизнес-службами. Подскажите пожалуйста как лучше организовать взаимодействие между этими приложениями, очень не хочется изобретать велосипед ? Знаю точно, что не подойдут варианты с import-ом классов модуля и SOAP службы — ведь все будет работать на одном сервере.
Здравствуйте, Filtron, Вы писали:
F>Планируем перейти на J2EE технологию. Сейчас изучаю возможность организовать работу своих программистов по следующему принципу. Каждый из них, специалист в одной конкретной предметной области, пишет J2EE приложение со своими JSP просмотрами и бизнес-службами (организованными как Session Facade). Другие программисты встраивают в своих приложениях обращение к этим JSP просмотрами и/или бизнес-службами. Подскажите пожалуйста как лучше организовать взаимодействие между этими приложениями, очень не хочется изобретать велосипед ? Знаю точно, что не подойдут варианты с import-ом классов модуля и SOAP службы — ведь все будет работать на одном сервере.
F>Заранее спасибо за ответ.
Честно говоря как-то всё спутанно написано.
Если всё работает в одном сервере, то зачем делать несколько приложений?
Модульность. Если нужны бизнес компаненты то они выполняются в виде JavaBean, визуальные же в зависимости от выбранной технологии. Lля JSP это к примеру могут быть билиотеки тэгов.
Для нормальных компанентных фреймверков(Tapestry, JSF, Echo 2) это будут соответсвенно какие-то кастомные компаненты.
Бизнес компаненты общаются друг с другом непосредственными вызовами. Всё это дело собирается до кучи IoC контейнером (Spring).
Здравствуйте, Filtron, Вы писали:
F>Планируем перейти на J2EE технологию. Сейчас изучаю возможность организовать работу своих программистов по следующему принципу. Каждый из них, специалист в одной конкретной предметной области, пишет J2EE приложение со своими JSP просмотрами и бизнес-службами (организованными как Session Facade). Другие программисты встраивают в своих приложениях обращение к этим JSP просмотрами и/или бизнес-службами. Подскажите пожалуйста как лучше организовать взаимодействие между этими приложениями, очень не хочется изобретать велосипед ? Знаю точно, что не подойдут варианты с import-ом классов модуля и SOAP службы — ведь все будет работать на одном сервере. F>Заранее спасибо за ответ.
Что касается взаимодействия приложений, судя по тому, что у вас есть Session Facade, скорее всего вы используете EJB, поэтому если приложения задеплоены на один сервер (VM), и взаимодействие ограничивается вызовами методов бинов из разных приложений, тогда самый рекомендуемый способ взаимодействия между приложениями — через JNDI, лукапим хоум интерфейс, создаем бин, вызываем бизнес-методы. Даже если приложения не на одном сервере, можно связать в глобальное JNDI дерево — локальные деревья на разных серверах.
Кроме этого, можно использовать JMS сервисы — и соответственно Message Driven Beans, вещь очень полезная, позволяет асинхронное взаимодействие между компонентами в приложении/приложениях. Можно взаимодействовать через базу данных, используя фреймворки O/R мапинга, которых хоть пруд-пруди: Entity EJB, Hibernate, JDO, etc.
Вообщем способов взаимодействия хватает, было бы желание взаимодействовать
P.S. Вариант, когда каждый специалист делает свое приложение, решающее свои бизнес-задачи, определяет политику безопасности для приложения тоже сам, сам создает веб интерфейс к своей функциональности, определяет способы интеграции с внешними системами, выбирает базу данных и способ хранения данных — то бишь сам себе режиссер, наверно имеет право на жизнь. Хотя при этом возникают масса проблем, одна, не из самых крупных — проблема интеграции с остальными приложениями.
IMHO более жизнеспособным видится подход к разработке, когда в команде есть разделение на разработчиков, которые специализируются на системных задачах и прикладных.
Здравствуйте, deepsky, Вы писали:
D>... что у вас есть Session Facade, скорее всего вы используете EJB, поэтому если приложения задеплоены на один сервер (VM), и взаимодействие ограничивается вызовами методов бинов из разных приложений, тогда самый рекомендуемый способ взаимодействия между приложениями — через JNDI, лукапим хоум интерфейс, создаем бин, вызываем бизнес-методы.
В этой части я тоже так рассуждаю. Только мне кажется, что лукапить хоум интерфейс и создавать бин сессионного фасада не совсем оптимально, ведь этот объект вероятнее всего уже создан сервером, хотелось бы его просто найти и использовать, а еще лучше, найти в JNDI ссылку на ОБЪЕКТ фабрики которая управляет жизненным циклом, кэширует и предоставляет этот самый сессионный фасад ! Только вот я не догоняю, можно ли это сделать в принципе и если можно, то кто эту фабрику создаст и разместит ссылку на нее в JNDI ?
А как быть если мне нужен диалоговый модуль ? Тут видимо нужно как-то лукапить Front Contriller этого чужого модуля в сервлет контексте ? К сожалению Core J2EE Patterns ответы на такие вопросы не дают.
D>IMHO более жизнеспособным видится подход к разработке, когда в команде есть разделение на разработчиков, которые специализируются на системных задачах и прикладных.
С этим я полностью согласен, в своем вопросе я этот момент просто опустил.
Здравствуйте, Blazkowicz, Вы писали:
B>Если всё работает в одном сервере, то зачем делать несколько приложений?
Создать информационную систему предприятия одним приложением не получится, поэтому я и ищу механизм взаимодействия между приложениями как в части вызова готовых бизнес служб, так и вызова готовых диалогов для поиска нужной информации в чужой предметной области.
Вот, спасибо за наводку на IoC контейнер, попробую разобраться, что это за зверь и чем он мне поможет.
Здравствуйте, Filtron, Вы писали:
F>Здравствуйте, deepsky, Вы писали:
F>В этой части я тоже так рассуждаю. Только мне кажется, что лукапить хоум интерфейс и создавать бин сессионного фасада не совсем оптимально, ведь этот объект вероятнее всего уже создан сервером, хотелось бы его просто найти и использовать, а еще лучше, найти в JNDI ссылку на ОБЪЕКТ фабрики которая управляет жизненным циклом, кэширует и предоставляет этот самый сессионный фасад ! Только вот я не догоняю, можно ли это сделать в принципе и если можно, то кто эту фабрику создаст и разместит ссылку на нее в JNDI ?
Сервер приложений создает хоум интерфейс бина при деплое приложения. Ммм ... правильнее будет сказать не хоум интерфейс, а класс автоматически сгенеренный апп сервером, который имплиментирует хоум интерфейс. Он же — апп сервер, биндит хоум интерфейс к JNDI дереву, и это тоже происходит при деплое.
Что касается не оптимальности создания сессионого фасада — оверхиды здесь минимальные, запускающий поток для бина создавать не нужно, он уже как правило создан контейнером и находится в состоянии ожидания, сам бин, скорее всего тоже создан и находится в пуле — хотя тут могут быть варианты для разных типов бинов. Поэтому вызов метода create для хоум интерфейса, скорее всего достанет уже готовый экземпляр бина.
Роль фабрики экземпляров бинов и управления жизненным циклом EJB, контейнер EJB выполняет сам, и весьма хорошо, поэтому в этом вопросе ему лучше не помогать .
F>А как быть если мне нужен диалоговый модуль ? Тут видимо нужно как-то лукапить Front Contriller этого чужого модуля в сервлет контексте ? К сожалению Core J2EE Patterns ответы на такие вопросы не дают.
Лукап фронт контролера проходит на ура, не зависимо свой это модуль или чужой, если требуемые бины прибиндены к общему JNDI дереву. Соответсвенно, просто нужно корректно указать ссылки на бины в web.xml
