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

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

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




прошу прощения, но меня немного "возмутил" ответ 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 секунд


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

  скажи, у вас в проекте всё разделено чётко, структурно и всё лежит идеально грамотно?  

возьмём два "компонента": account и payment, надеюсь понятно, чем занимается каждый из них  payment получается зависит от account-а, ему нужен entity account, чтоб работать с ним, например, выставлять счёт. если так, то payment-у нужно также, либо написать отдельные методы на DAO и manager-ы в account-е, либо написать (частично дупликаты в payment-e). так?  если так, то на этих участках, payment уже начинает прилипать к account-у и пока только двумя вещами: entity и manager  при расшерении логики, payment начёт прирастать к account-у, я не говорю, что account станет дёргать payment, хочешь этого или нет   приложение растёт и за payment рано или поздно схватится ещё какой-то "компонент", и на этом этапе вырвать какой-то из компонентов не являющийся последним в цепочке (дерево) уже становится невозможно или не просто  

Вообще уникальный "core" в распределенной системе - слабое место. Полностью его устранить сложно, но логично его максимально облегчить для ускорения рестарта в случае аварии, чтобы не подвешивать всю систему. Что касается базы, то да, компоненты открывают собственные соединения с базой. Поскольку ресурсы относительно независимые, то компоненты работают с разными таблицами (можно было бы и базу разделить на части). Если же есть конкурентный доступ к одной таблице из разных компонентов, то блокирование таблицы при необходимости осуществляется самой базой. У нас база данных далеко не основной источник данных, поэтому оптимизацией особо не занимались.   

Если я правильно понял, то конечно "дублирование" неизбежно. В том смысле, что если сделать два независимых приложения "account" и "payment", то обоим требуется описание обьекта account. Но, возможно, для "payment" нужен не полный обьект account, а только его некоторые свойства. Оба приложения загружают нужные обьекты account из одной таблицы. Если приложение "payment"  делает успешную транзакцию, то надо освежить копии обьектов на клиенте и в серверном кеше (если таковой есть). Тот, кто инициирует изменение, т.е. транзакцию (это клиент наверное), тому и удобнее инициировать обновление копий.     

Это сообщение отредактировал(а) COVD - 25.8.2009, 17:54

Я вот только в упор не понял почему account и payment являются компонентами.  Давайте уж тогда определятся с терминологией или подробнее расскажите что такой account и payment.

Хм.. я думал модуль == компонент.

ок, тогда что же компонент в твоём понятии? дело в том, что можно тут ещё несколько "модулей" назвать и приложение готово. тогда всё приложение - это монолитный один компонент. что-то он слишком большой получается.  я с этим не согласен  




вот, и я об этом. хр*нова получается.. "я не согласен. а может быть мы поищем другие варианты?" (с) Гришковец  


-----

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

тогда ищите  


компонент приложения - это плагин (Эклипс) или модуль (Нетбинс)
компонент системы (распределенного приложения) - приложение .

Это сообщение отредактировал(а) COVD - 26.8.2009, 12:33

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

Нет уж, давай порисуем (с)

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

•  Компонент - часть приложения (для простоты), легко идентифицируемая и обладающая конкретным функционалом и границами ответственности.
•  Связанность частей компонента (high cohesion) гораздо сильнее чем связь между компонентами (low coupling). Зависимости между компонентами осуществляются через малый набор четко определенных интерфейсов.
•  Компонент предполагает независимый жизненный цикл: сборку (с учетом разрешения зависимостей между компонентами), тестирование (как правило через мокирование других компонентов) и деплоймент (в идеале).

Не надо путать компонент и слой/уровень/layer.
Портлет может быть компонентом на уровне представления в портале. Слой - это функциональное назначение всех компонентов, которые в нем находятся. Это все равно, что рассуждать чай более горячий, чем сладкий.
Компонент позволяет просто решать некоторую задачу. Он имеет некоторую функциональность. Слой позволяет разбить систему на разные зоны ответственности, гед работают компоненты для решения конкретных задач этого слоя. Один слой занимается сохранением данных используя определенные компоненты. Другой слой - бизнес-логика. И он использует другие компоненты.

AntonSaburov, так как я понял, проблема в том что при нарезке по слоям (layer), когда мы вносим новую функциональность нам приходится проводить изменения в каждом из слоев. А хотелось бы, чтобы новый функционал приходил единым "куском". Ежели нарезать поперек, по функционалу, то, во-первых, в каждом "куске" мы повторяем структуру всех слоев, во-вторых, "куски" начинают обрастать перекрестными зависимостями друг с другом. Как уже ранее предлагалось, можно скомбинировать "нарезку". Низкий уровень порезать по-layer'но сформировав некие base-компоненты. А высокоуровневые резать по функционалу.

всё, что сказано, мне понятно.. но нет конкретики, а есть, если то это, а вот если так то то.. у нас приложение, например, делется на следующие модули:

вся структура построена на мавене:

- parent            // parent мавен
- base               // некая часть, модуль, что не вошёл ни в один другой модуль не обязан лежать в "корне" дерева
- category        // "компонент" для работы с категориями
- entity              // entity
- dao                 // слой DAO
- manager        // слой manager-ов
- html                // js, images, css, html для верстальщика
- spring             // настройка спринга, контроллеры и т.д.
- install             // инсталяция приложения и т.п. вещей
- selenium       // тесты на основе selenium
- view               // собирает view для верстальщика
- web                // собирает полностью приложение

с запусом различных профилей имеем различные приложения. как видно, из такой структуры невозможно ничего выдернуть. каждая новая "страница" размазывается по практически по всем модулям. потом она обрастает перекрёсными ссылками и "навеки" в системе. а какую структуру приложения избрали вы?   поделитесь своими best practices   

Продолжу свои рассуждения   

Из цитаты  следует, что разделять приложение на компоненты можно в двух направлениях. Выделяем фрагмент приложения, решающий определенную задачу (подробнее выше в посте fixxer'a) и оформляем его в виде или отдельного приложения или в виде плагина-модуля. В первом случае строим распределенную архитектуру. Во втором - плагинно-модульную.

Если разделяемое приложение - клиент, то для него имеет смысл только второй вариант. Клиентское приложение работает на одном компьютере. Развертывание распределенной системы на одном компьютере не дает преимуществ. Скорее, недостатки.

Если разделяемое приложение - сервер, то формально для него годятся оба варианта. Однако первый вариант (распределенная архитектура) на мой взгляд предпочтительнее. И вот почему. Серверное приложение работает в условиях, когда нормальным является наличие несколько компьютеров, обьединенных в локальной сети. Поэтому распределенная архитектура здесь проявит все свои достоинства, особенно ценные для режима работы 7/24, типичном для серверов. С другой стороны, серверное приложение обычно создается и контролируется только владельцем. Трудно представить, что внешние команды по собственной инициативе создают компоненты для серверного приложения. Это является обычной практикой, например, для открытых IDE. И плагинно-модульная архитектура, на мой взгляд, разработана именно под такой сценарий. 

Плагинно-модульные платформы формализуют (а следовательно, автоматизируют) процесс подключения, т.е. поиск модулей и проверки соответствия версий, интерфейсов.  Серверное приложение тоже может создаваться усилиями нескольких коллективов, но создаваемые ими компоненты в условиях сервера наверное практичнее развертывать как отдельные приложения. Универсальным средством интеграции приложений на сервере являются системы или шины сообщений (messaging). Они позволяют обьединять решения от независимых производителей без привязки к платформе. Не имеет смысла создавать плагины, когда есть перспектива необходимости масштабирования приложения - в случае успешного развития бизнеса нагрузка на сервер возрастает, покупаются дополнительные компьютеры. Распределенное приложение проще масштабировать чем монолитное.      

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

Не-не-не. Так мы за деревьями леса не увидим. Давай вернемся к нашим баранам (account и payment) и на их примере попробуем разобраться. Расскажи на их примере, какая будет архитектура. Поподробнее только, с классами и т.п.

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

хорошо, когда отдельный компонент представляет, например, отдельный сервис - вызываем его, он что-то делает (не зависимо от других) и сё.. как быть с интернет страницами в одном приложении? допустим есть две интернетстраницы для одного приложения с одинаковым (!) дизайном (например), темплатами и т.д. каким образом тогда делить само приложение? получается, что само приложение делить надо именно в вызовах Controller-ов, что уже само по себе проблематично (например, нельзя перестартовать часть приложения).. и в контроллерах уже идёт вызов на некий сервис..   чётко сделать сервисы из уже монолитного приложения наврядли получится чисто  

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


следуя архитектуре которая у нас есть сейчас, account и payment "размажется" по пакетам base, entity, dao, manager, html, spring, selenium

А поподробнее?

Добавлено через 1 минуту и 52 секунды
Ты ж сам хотел конкретики, вот и давай простейшее приложение, будем его всем миром "компонентизировать" 

По-моему понимание компонентов и уровней "размазано" 

Уровень - это набор интерфейсов, контрактов. Вроде стека протоколов HTTP/TCP/IP. Каждый знает, что он может попросить у нижнего слоя и что он должен отдавать верхнему. Внутри уровня действует определенный компонент.

А по поводу Maven и компонентной модели - по-моему Maven и компонентная модель слабо совместимы. Maven - это тул, который позволяет удобно собирать, тестировать проект, следить за актуальностью библиотек. Все. Какие там компоненты - я не очень понимаю.

Если же говорить о разбивке слоев на отдельные JAR, то мы делали следующим образом:
- JAR с PersistenceLayer (DAO, Entity)
- JAR с Business-Layer (бизнес-логика - manager)

fixxer, по конкретнее я не могу, иначе мне придётся тут выкладывать 50-60 классов..   надо подумать о каком-то конкретном примере.. 

AntonSaburov, тогда у вас тоже, получается, монолитная система..

Добавлено через 5 минут и 42 секунды
fixxer, вот по конкретнее:

payment:

- страница (.html, .css, .js)
- спринг конфигурация
- i18n
- manager-ы
- dao
- entity
- тесты selenium на страницу
- зависит от account (entity, manager, utils)
- utils

account:

- страница (.html, .css, .js)
- спринг конфигурация
- i18n
- manager-ы
- dao
- entity
- тесты selenium на страницу
- utils

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