навеяную в этом топике тему:

мавен, компонентная архитектура?

хотелось бы обсудить тут.




прошу прощения, но меня немного "возмутил" ответ COVD.

скажи, а разве это вообще возможно? каким образом можно поистроить jee приложение в котором общие интерфейсы, например, на DAO? компонентная сборка гарантирует сначала дупликацию кода, а потом и в последствии (по другому не получится) его разницу при абсолютно идентичных задачах.

если слишком тяжело объяснил, попытаюсь объяснить траблу, на которую я не знаю ответа.

допустим есть

(1)

base
dao
manager

проекты, каждый из них собирается maven-ом как *.jar

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

приведу другой пример

(2)

component1
component2
component3

архитектура на первый взгляд кажется идеальной, а каким образом решать траблы с общими интерфейсами? в каждом пакете используются DAO и не плохо было бы иметь общий интерфейс на CRUD операции. ладно, скажешь ты, заведём ещё один проект, и положим туда интерфейсы:

base
component1
component2
component3

а как же быть теперь с утилитами? тоже положить в base? у компонентов начинаются зависимости между собой, как только они начинают интерагировать друг с другом, зависимости на entity уровне, manager-ах, утилитах и других "паттернах" программирования.

при малом коде, всё кажется идеально, но как только код растёт, все компоненты переплетаются друг с другом и хотя они могут иметь структуру зависимостей в виде дерева, чем выше компонент в дереве, тем всё тяжелее и тяжее от него отказаться. но мы ведь говорили о компонентах? типа, взял вытащил и туда другой вставил и всё работает? хорошо, когда пишутся framework-и, типа velocity, log4j и т.д. в них чётко разделена логика. НО... она возможна вообще в jee мире?? 

------------

пример из жизни: 

мы пишем некое приложение jee на spring. мы для сборки проекта использовали ант. само приложение собирается как бы из двух частей. дабы облегчить работу верстальщику мы сделали для него view и некие моки, которые просто описывали manager-ы (а не прямая работа с базой данных). всё было зашибить, пока проект не начал дико расти по всем направлениям. пришлось делить подпроекты. сначала из двух стало четыре. код ант-а стал просто беспощадно почти дублироваться и в нём, как всегда, были лишь некоторые мелочные различия. это дошло до того, что подправление каких-то мелочей в ант-е, начало занимать часы. не хватка все различных плагинов (которые в ант-е нужно подключать руками) начало тока раздувать ант. а ведь у нас ещё и не было написано половины приложения. тогда мы решили перейти на мавен, как спасение от ситуации.

ну чтож, типа всё просто, у нас интерфейсы чётко соблюдены, попробуем построить компоненты. через 4 дня беспощадных и продуктивных усилий мы сдались. файлы так переплитались через интерфейсы, что стало не возможно их разделить и построить хоть какое-то "приличное" дерево. это была попытка номер (1)

набравшись немного опыта, Алекс начал делить файлы уже не как компоненты, а как layer-ы: dao, manager, velocity, spring, base и т.д. размельчив примерно на 25 пакетов, проект из простой структуры вырос в какую-то непонятную машину. так прошло ещё дня четыре.

поняв, что пакетов много и попытавщись притащить за уши идею номер (1) с новыми мыслями и наработками мы сдались через дня 4 заного.

следующая попытка вернула нас на layer-ы + (только частичная!) компонентная структура. подпроектов стало 11, разделение стало чёткое и некоторые вещи просто объеденены.

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

как же строить JEE приложения?   

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

polosatij, извините, я не видел ваш пост в том топике, поэтому не ответил. С удовольствием поучаствую в обсуждении (только надо понемного разобраться). 

polosatij, 

Недавно я познакомился с такой штукой как Java Portal. 

Мне понравилась идея - есть ядро (portlet контейнер) и портлеты реализующие функционал. 

Портлеты являются независимыми приложениями, которые могут быть написаны с помощью различных технологий.  От них требуется только соответствие спецификации (JSR 168 или JSR 286
) и они будут работать с любым  portlet container-ом поддерживающим соответствующую спецификацию. 

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

Классная идея, жаль, что нормальной реализации я так и не нашел :-( Понравился LifeRay, но багов хватает. 

Полосатый, советую книги из серии Head First: Object Oriented Analysis and Design; Design Patterns. Вообще по поводу литературы просканируй первый пост отсюда: Лучшая Java литература.
А насчет разбития приложения на компоненты: это безусловно возможно, но приходит с опытом..

Vasay, я работаю на одной фирме, что использует в реализации JBoss Portal, с возможностью типа подключать компоненты. Ты наверно, плохо знаком с такой штукой и посмотрел её поверхностно. Этот портал можно посадить только на те приложения, в которых не важна скорость, причём не только старта приложения и его работы, но ещё и развития самого приложения. Мало того, это не решает проблем в моём случае (1), или же если захочешь посадить штуку номер (2)

Добавлено через 3 минуты и 41 секунду
Старовъръ, спасибо за линки  скажи мне, пожалуйста, если ты говоришь, что знаком с дизайн паттернами, и какой же паттерн решит описанную мной проблему? можешь назвать несколько их имён для обсуждения?

Идея порталов вообще очень хороша! У вас в рукаве море технологий, которые вы можете использовать в купе с портлетами, у того же Spring MVC есть портлетная часть. Т.е вы реально можете написать несколько небольших веб приложений и повесить их на одну старницу, получается очень здорово  Однако не все так хорошо, лично я работал с WebSphere Portal - очень тяжелая штука, Vasay говорит, что в LifrRay пока багов много, на счет JBoss ничего сказать не могу. Остается ждать пока производители порталов приведут их в порядок и сделаю более доступными.

Согласен, я серьезно не работал с порталом - поигрался, понял, что меня не устраивает. Основная проблема Java-порталов, как мне показалось, отдаленность от реальных задач, ребята в LifeRay пытаются довести до ума, но пока не все получается, однако, за LifeRay взялсяс SUN ( проект websynergy ) возможно, что-то из этого выйдет.

По поводу ресурсоемкости - согласен, но не больше, чем,  например у Магнолии.

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

Ну так просто не сказать, нужно использовать их в купе. Но первое, что приходит в мысли - это DI(dependency injection), хорошо знаком тем, кто использует Spring.
Так же перед тем как углубляться в шаблоны, лучше все-таки освоить OOD. Вот перечень основных принципов. Ну а если захочешь более глубоко в это проникнуть, то все-таки читай литературу, что я выше предлагал.

Я не имел в виду конкретно J2EE. У нас было монолитное серверное приложение, но оно не построено строго по J2EE. Мы не использовали application server и пр. (когда начинали, не было ясно как применять готовые решения). Поэтому я и подстраховался, допустив, что не везде возможно.  Возможно, я не точен в терминах. Это просто личный опыт.

Мы расщепляем наше серверное приложение, выделяя из него вэб-сервисы, т.е двигаемся в направлении SOA . Наверное, точнее, это подобие REST сервисов: один ресурс - один адрес - одно вэб-приложение. 

Например, клиентское приложение загружало ресурс - список компаний. Делаем веб-приложение companies, которое пакуется в companies.war . Поскольку этот ресурс не редактируется пользователем, т.е. из набора CRUD нужен только Read, то приложение состоит из одного index.jsp , который доступен по адресу http://.../companies/ .  В веб-приложение также включается класс, который отвечает за нахождение данных ( например, RMI клиент). Веб приложение не лезет само в базу, не держит кеш и не хранит ничего в сессии. Оно только выполняет первичную задачу веб сервера - обработку http запроса. Поэтому у каждого веб-сервиса должен быть партнер - сервис - java приложение, которое предоставляет данные веб-приложению по запросу (например, через RMI сервер). Получается, для каждого ресурса требуется пара приложений: 
- веб-сервис (?.war), обслуживающий запросы клиента (через интернет)
- сервис (?.jar), обслуживающий запросы веб-сервиса (предпочтительнее в локальной сети) .

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

garbuz, Vasay

1. ожидать, нет времени, нужно сейчас
2. то, что тяжёлая опустим
3. это не решает траблы (2) описанной мной - нужно выносить общие интерфейсы, утилиты и т.д. в отдельный base, который со временем становится свалкой

Добавлено через 3 минуты и 53 секунды
Старовъръ, наверно, ты не заметил, что я в самом первом топике писал, что мы используем spring и разрулили кучу вещей через DI. однако это решает только частичные траблы и не решает траблы (1) или траблы (2) описаные мной. в крупно написанном приложении компонент "врастает" в общую структуру и заменить его становится очень трудоёмкой задачей.

А кто-нибудь изучал серьезно OSGi ?

Добавлено через 1 минуту и 39 секунд
Скачал книжку Modular Java. Буду читать 

polosatij, 



А я не предлагаю Вам использовать портал - а предлагаю посмотреть, как реализована модульность там.





Данную проблему ИМХО нужно решать в контексте конкретного приложения.  Я не понимаю - зачем выносить все утилиты, интерфейсы в base. Да и в реальной задаче - это невозможно, так как ядро пишут одни люди, а модули другие, не имеющие возможности что-то поменять в ядре.  Я считаю, что ядро должно предоставлять определенный (оговоренный) АПИ, все остальное модули должны реализовывать сами. Впринципе, возможна зависимость между модулями - но это уже как Вы захотите. 

COVD, сама реализация SOA у вас в приложении, мне понятна. скажи, у вас есть некий core или компоненты беспощадно дублируют, например, обращения к базе?

Добавлено через 1 минуту и 54 секунды
fixxer, у меня тоже есть желание посмотреть в этом направлении, но я от людей слышал, что OSGi ещё сырой

пс: книгу пролистал в магазине, сложилось впечатление, что тема размазана (возможно, я ошибаюсь, и это было моё 5-утное впечатление)

Добавлено через 3 минуты и 31 секунду
fixxer, есть ещё такая книга: http://www.amazon.de/Spring-Dynamic-Module...6728&sr=8-1

Добавлено через 11 минут и 15 секунд


хе-хе.. в том-то и дело, что никак она там не реализована.. на основе xml ты имеешь возможность подключать ГУИ.. однако, всё, что бегает внизу столкнётся с проблемами (1) и (2) описаными выше

не все.. а только те, что используются для комуникации между модулями (это про интерфейсы) или же те утилиты, что используются в 2:n модулях



не совсем так.. легко возможна и обратная ситуация - все могу всё, такой политики придерживаемся мы




тогда у тебя будут дупликаты логики в модулях



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

Это вобщем-то не очень хорошо. Мы в свое время решали проблему тесной взаимозависимости через локализацию зависимых мест и заправку их через асинхронное взаимодействие (JMS)

Добавлено через 5 минут и 36 секунд


Ну и что сырой. К тому времени как изучишь и потестишь в той мере чтобы использовать в продакшене - высохнет 

Добавлено через 8 минут и 8 секунд


Вот это не понятно. Если абстракции вынесены и реализованы грамотно и полно, откуда же возмется дублирование?