в этой книге я не нашёл кучи вопросов по построении архитектуры не монолитного приложения.
кто-то применяет OSGi на практике? может рассказать общую структуру построения и впечатление от OSGi?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java EE (J2EE) и Spring > OSGi в JEE приложении |
| Автор: polosatij 18.11.2009, 17:31 |
| примерно с три месяца назад я лежал на пляже (тут подумалось, нифигова было) и читал книгу в этой книге я не нашёл кучи вопросов по построении архитектуры не монолитного приложения. кто-то применяет OSGi на практике? может рассказать общую структуру построения и впечатление от OSGi? |
| Автор: serger 19.11.2009, 15:37 |
| Вот, начало... и далее в блоге много об "этом".. http://samolisov.blogspot.com/2009/03/osgi.html |
| Автор: polosatij 19.11.2009, 16:02 | ||
1). только основы в статье 2). ни слова нет об архитектуре JEE приложения |
| Автор: COVD 19.11.2009, 16:47 |
| Предполагаю, что плагины на сервере не очень актуальны, потому что на сервере выгоднее реализовать распределенную архитектуру - набор самостоятельных приложений (сервисов). Возможно поэтому плагинно-модульные платформы обычно называют RichClient ... , т.е. применяется к клиентскому приложению. |
| Автор: polosatij 19.11.2009, 17:00 | ||
мне очень тяжело понять, как достичь нескольких сервисов, которые "должны иметь общие классы", например, для базы данных. |
| Автор: COVD 19.11.2009, 17:06 |
| Ничего нового, использовать библиотеки. Так же как используют log4j например. Плагинно-модульная архитектура интегрирует несколько независимых компонентов в одно приложение, работающее под одной виртуальной машиной. Термин embedded мелькает там поэтому. И платформа обеспечивает возможности динамического подключения\отключения компонентов, как если бы они были независимыми приложениями. На серверной стороне нет нужды имитировать это средствами платформы. Можно физически запустить компоненты под разными JVM, а еще лучше и на разных компьютерах, а еще лучше и в нескольких экземплярах (кластеризация), т.е. построить нормальное распределенное приложение (а не имитировать его в "одном флаконе"). |
| Автор: polosatij 20.11.2009, 15:02 | ||||||
так не получится. ты не можешь в runtime вытащить библиотеку и вставить новую на это место, например.
у тебя получится несколько "глупых" флаконов
быть того не может, т.к. новый jboss5 и кое-какие сервера уже переходят на концепт OSGi |
| Автор: COVD 20.11.2009, 17:45 | ||||
Надобности в смене библиотек "на лету" не возникает, если приложение состоит из набора "глупых" флаконов. Просто перезапускается "флакон"(можно мысль развить до абсурда и допустить, что "флакон", т.е. небольшое приложение, выполняющее одну задачу, состоит из одного класса). Это проще и , следовательно, безопаснее, чем заменять классы в рантайме. Это как ремонтировать движущийся автомобиль. Умеющие это делать заслуживают восхищения, но надежнее все же в гараже.
А интересно, заденет ли это пользователей jboss5 ? . Не разработчиков компонентов jboss5, а программистов, которые пишут приложения для работы под jboss5. Сама - то концепция, как готовый сценарий, наверное много где может быть полезна. Я высказывал мнение, что на серверной стороне держать все в одном "флаконе" нет смысла. А платформы Нетбинс и Эклипс вроде заточены под одно приложение (и потому они RichClient). Мне они представляются как реализация SOA внутри приложения. |
| Автор: polosatij 20.11.2009, 18:34 | ||||||
http://www.osgi.org/About/WhyOSGi
причём тут пользователи?
естественно.. там, наверняка, есть уже какие-то интерфейсы -------------- хочу тебе объяснить, зачем я хочу достигнуть такой архитектуры. тут есть очень много причин, многие из них, наверно, не имеет смысла тут объяснять, но 1). в runtime на одной машине было бы очень не плохо поменять части, нежели перезапускать приложение полностью 2). если приложение будет такое модульное, что можно будет менять части, то можно давать людям какие-то определённые части на разработку программного обеспечения, открыв часть svn 3). посмотри apple телефон. если падает какое-то приложение, то не падает сам телефон. и т.д. меня интересует реализация архитектуры не монолитного приложения  |
| Автор: COVD 20.11.2009, 18:50 |
| В моем понимании: 1. не монолитное = распределенное. 2. приложение, построенное на плагинной ( модульной ) архитектуре - монолитное, если оно бегает в одной виртуальной машине (отсюда и необходимость "update bundles on the fly" , успешной реализацией которой так гордятся (заслуженно, конечно) авторы ). |
| Автор: polosatij 20.11.2009, 19:33 | ||||
имея базу, не важно где запускать модуль. отсюда и распределённое.
так.. терь с этого места, по подробнее  |
| Автор: COVD 20.11.2009, 19:43 | ||||
Так что, OSGi допускает, что модули или плагины запускаются удаленно? Тогда замечательно и привлекательно для "серверостроения".
? PS. Процитировал текст, слово "bundle" застряло в голове и пришло просветление . OSGi обновляет "на лету" не отдельно взятый класс, а "bundle", т.е. модуль целиком. И может это делать потому, что общение модуля с остальным окружением контролируется OSGi платформой. Точно также, например, Томкат умеет обновлять "на лету" страницу JSP, которая в контексте OSGi может рассматриваться как bundle, т.е. отдельный модуль. Эта "фича" OSGi конечно удобна для любого приложения независимо от его размера. Для монстра jboss5 тем более.В общем, спасибо, polosatij, за топик. Мне кажется, до меня стало доходить, что такое OSGi . |
| Автор: COVD 22.11.2009, 19:09 |
| Кроме реализаций OSGi существует также модульная платформа Нетбинс. Она появилась до OSGi и на ее основе было написано много корпоративных приложений до того, как ее стали популяризировать. В сравнениях с OSGi обычно отмечают, что они практически идентичны. И только в русскоязычных источниках типа rsdn я встречал высказывания, что OSGi - круто, а Нетбинс - "ацтой". Обьективно OSGi более популярен. Существует много имплементаций. Cамая популярная, наверное, Equinox. Spring конечно же подсуетился со Spring OSGi. Поэтому Нетбинс предпринимает усилия по сближению. Меня модульная архитектура интересует применительно к клиентскому приложению. Наша серверная часть уже и так функционирует, как распределенный набор компонентов и сервисов. На нашем клиенте это более актуально потому, что постоянно добавляются новые возможности для разных категорий пользователей и приложение "распухает". Разнообразие клиентских компонентов богаче серверных. Естественно, новые возможности удобно добавлять в виде модулей. Поэтому предстоит перевод клиентского GUI Swing приложения на модульную архитектуру. Однако я пока не определился с платформой. Используемый нами Нетбинс привлекателен тем, что платформа уже включена в JDK6 и IDE "заточено" под разработку. |
| Автор: polosatij 23.11.2009, 13:55 | ||||
меня она интересует по многим причинам.. хотелось бы отдатъ например, на разработку, только часть приложения на оффшоринг, а не полностью, например или же время деплоя приложения и разработки хотелось бы начать двигать в сторону времени с отметкой 0, иначе, чем дальше, тем больше и больше
ню, если что накопаешь, свисти "а то эти, ни болта не рубят" (с) мама не горюй |
| Автор: COVD 23.11.2009, 17:26 | ||
Я подозреваю, что модульность тут не главное. Фреймворк не поможет разработать интерфейс взаимодействия, который необходим стороннему разработчику компонента. Фреймворк лишь берет на себя хлопоты подключения - поиск плагина, формальную проверку соответствия интерфейсов, версии, и возможность подключения "on the fly". Использование фреймворка остро необходимо для массовых продуктов типа IDE, для которых все кому не лень желают писать плагины. Обуздать эту творческую активность масс можно только формализовав процедуру подключения, которая и возложена на фреймворк. А в небольшом проекте с ограниченным количеством исполнителей фреймворк является удобным инструментом, но не абсолютной необходимостью. По крайней мере, наверное можно начать проект с разработки интерфейсов компонентов, а "менеджмент" в лице фреймворка, добавить позднее. PS. Конечно, это общая "розовая" мечта - творить интерфейсы и ... раздавать их на реализацию сторонним разработчикам. А еще лучше - рисовать прямоугольнички со стрелочками и ... раздавать их исполнителям. А еще лучше сформулировать идею на словах и ... А еще лучше ..... |
| Автор: polosatij 23.11.2009, 18:08 | ||||
да.. посему придётся, или отдать base тоже из svn (что, конечно, чревато ошибками, как только кто-то туда залезит), или же, как ты написал, модульная какая-то структура. но в модульной структуре я очень плохо себе представляю, как выдержать общий дизайн приложения, если даже далеко не ходить, а взять просто DAO. наверно, мне надо почитать как строятся плагины для еклипсе. мне кажется это может оказаться далеко не плохим примером.
тут хочу с тобой поспорить. вот пример: мы пишем приложение спустя год и успели туда забабахать оооооооочень много технологий. при подключении нового человека следует учитывать: 1. чистоту написания кода, понимание его программировать и уровень должен быть не минимум: понимание патернов, умение их реализовывать, понимание затруднительных ситуаций, не только на словах, но и умение обходить их. этот фактор никогда не понять по человеку и его резюме, это видно только тогда, когда он немного попрограммирует в проекте. и тут всплывает тот фактор, что он может успеть натворить ерунды, с которой придётся что-то делать 2. умение и знание технологий, а если нет, ему нужно дать мин. 2 недели на быстрый разгон + 2 недели на написание чего-нибудь. "а время летит, время..." (с) 3. конечно, нуна нанимать профи. но бюджет, к сожалению, пока не резиновый и приходится работать с "авось повезёт". причём многие их них вылетают и редкие единицы лишь остаются.. твоё понимание плагина похоже на частичное моё представление модульности. почему частичное? потому как модульность может это и ещё ... в придачу. наверно, мне надо ещё посмотреть, как строятся плагины eclipse. мне почему-то кажется я расчищу для себя определённые не понимания в моей голове. вот только, было бы время  |
| Автор: polosatij 23.11.2009, 19:39 |
| нашёл сегодня такую презентацию: http://www.google.de/url?sa=t&source=web&ct=res&cd=5&ved=0CCAQFjAE&url=http%3A%2F%2Fwww.toedter.com%2Fblog%2Fwp-content%2Fuploads%2F2009%2F01%2FPatterns%2520and%2520Best%2520Practices%2520for%2520dynamic%2520OSGi%2520Applications.pdf&ei=HbcKS9CzB4qJ4Qaiu6nNCw&usg=AFQjCNE7ERQf85gASNvbR4tX5jqK8NvFYQ&sig2=UXCdTLOaNoMcg6iIw2uk9A в двух слова обламывают представления и рассказывают, что и как |
| Автор: COVD 23.11.2009, 20:24 | ||||
да, в условиях "текучки" кадров плагинно-модульная архитектура наверное хорошее средство дисциплинирования. Но для серверных приложений все же я бы , повторюсь, по возможности предпочел разрабатывать самостоятельные приложения, нежели модули, которые "втыкаются" в очередного монстра. Тем более, что
ну конечно это все напоминает "Вот возьмем Hibernate ( подставьте любой фреймворк ) и легко и быстро получим на профессиональном уровне ... проблемы с lazy ( подставьте свое)" |
| Автор: polosatij 23.11.2009, 20:54 | ||
а как выдержать общую архитектуру и сделать легковесным приложение, без дупликатов и мостров типа JBoss? у нас "небольшой" сайтик из 20-30 страниц (ню и две их них генерируются на лету), где 5 из них занимаются сложной (очень!) логикой а с остальными всё совсем просто. мы пишем небольшую поисковую систему, где между первой страницой и второй, натыкано очень много логики |
| Автор: COVD 23.11.2009, 22:07 |
| У вас же наверное взаимодействие клиента с сервером обычные синхронные запрос-ответ. Превращаете "сайтик" в 20-30 сайтиков, состоящих из одной index.jsp и считаете, что реализуете REST сервисы. Логику всю выносите в отдельные консольные приложения, с которыми сервлеты могут общаться по локальной сети через, к примеру, RMI . И вот эти приложения (не веб) уже при желании можно дробить на модули, т.е. строить по плагинно-модульной архитектуре. Если они достаточно большие. А где тут место для жбоссов я не знаю. |
