akakunin
0
Самая печальная новость. Это что же, теперь все, кто не на томкате, должны энтерпрайз лицензию покупать?


Те кто не на томкате, wildfly и глассфише. Считается что если у вас есть деньги на WebSphere/WebLogic — то глупо экономить на «спичках» (лиценизциях на Liferay). Аналогично с базами — если есть деньги на Oracle — то ожидается что и на портал найдутся.

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


Понял, согласен! Как вы и писали выше — Liferay использует ehcache и как только возникает кластер — встает задача синхронизации кешей на нодах. Ну и 100 нод щелчком мыши не запустишь — сразу уткнешься в вопросы синхронизации. В платной версии есть плагин который оптимизирует синхронизацию данных между нодами — но все равно на больших кластерах это будет бутылочное корлышко.
akakunin
0
Но 800 req/s — неплохо!
akakunin
0
Про масштабируемость: у вас получается все-таки чуть-чуть другой подход чем у нас — у вас liferay — чисто фронт-енд (вся бизнес-логика на back-end серверах) и управлением контента самого портала (страницы, конфигурация портлетов, контент и пр.) как понимаю занимаются сами программисты (если я правильно понял — у вас «версия» — это набор версий портлетов плюс определенная конфигурация- набор страниц, размещения портлетов, контенты) — соотвественно все собирает команда разработки, ставит — и потом это стоит и не меняется. Правильно понял? Тогда да — такой подход «независимых» порталов у вас сработает.

В нашем случае мы даем в первую очередь набор инструментов (портлеты) — проводим первичную установку, настройку — а дальше уже админы и бизнес-пользователи клиента по необходимости управляют всем этим. В этом случае — сам Liferay настраивается в кластер (и тут не со всем понял что имеется в виду под «масштабируется слабо») — и да — все сервера Liferay используют одну базу (дальше если требуется — база кластеризуется своими средствами).

Про поддержку веб-серверов — да, почти так — может работать на любом сервере — но есть небольшие нюансы. При старте портал в частности определяет тип сервера, определяет поведение при хот-деплое и прочее. Вот поддержку нюансов для коммерческих серверов из Liferay CE 7 и удалили.
Аналогично с базами данных — да, Liferay использует Hibernate — но не все что поддерживает Hibernate — поддерживается в Liferay — так как для каждой базы есть свои небольшие «допилы». Их тоже удалили.

Хотя это лукавство — код из истории github не удалишь — так что все легко возвращается. Другое дело что развитие этой поддержки будет уже только в платной версии.
akakunin
+1
Liferay 6.x поддерживает кластеризацию — проблем нет. Есть возможность выноса контента на CDN (но для нормальной работы требует допила). Небольшим допилом можно реализовать кеширование портлетов для анонимных пользователей.
То есть из коробки поддерживается кластеризация и базовые вещи для поддержки высокой нагрузки — но не всегда оптимально — и там где я писал про «допилы» — это то что мы сами «наработали» за годы внедрения.

А вот с Liferay 7 (новой версией) все немного хуже — из бесплатной версии убрали поддержку кластеризации (тут подробней: http://www.emdev.ru/-/ogranicenia-liferay-7-0-ce
akakunin
0
XML есть в PortletProperties/PortalProperties. И в контенте (например контент JournalArticle). Так же через XML хранятся локализуемые строки (например заголовок страницы будет идти в XML так как это локализуемый атрибут). В целом все (хотя если мог пропустить что-то важное).

Хотя стоп — Dynamic Data Mapping (кастомные формы и доп поля к веб-контенам и документам) — там тоже все в XML — тут да — проблема — это делает невозможным использовать эти формы для чего-то более-менее серьезного.

Но в целом база Liferay вполне себе реляционная :)
akakunin
+1
По поводу стоимости — смотря с чем сравнивать. Если с WebSphere или SharePoint — то Liferay очень и очень дешев.
Кстати — по моим наблюдениям бесплатность зачастую играет злую шутку с Liferay — люди его берут — раз бесплатный — но не учитывают что это достаточно сложный продукт — и что это на самом деле не что-то готовое — а конструктор — и что потом надо очень серьезно вложиться чтобы из этого конструктора что-то собрать. А особенно учитывая что JEE разработчики ( а тем более с опытом Liferay) стоят намного дороще PHP + какой-нибудь Битрикс — то «бесплатность» оборачивается для клиента высокими костами — и если он не был к этому готов — то проект в итоге вообще не достигает цели а клиент убеждается что «г… ваш этот Liferay».

Про замечания — Liferay не идеален — вопрос в том — для чего его использовать.
Если нужен просто сайт (просто CMS) — ну да, можно использовать Liferay, можно его фичи именно в плане построения сайтов (версионирование и варианты страниц, remote staging, согласование публикации контента, asset publisher и прочее и прочее). Но, уверен что тут есть и другие решения, скорей всего более удобные и более дешевые.
Внутренний портал… ну скажем так — если речь идет о сотнях сотрудников — то 1С Битрикс в руки и вперед.
Реализовать приложение которое решает какую-то конкретную задачу? Зачастую проще сделать сделать самим с нуля (благо framework-ов сейчас много). Не хотите с нуля — берем туже Cuba Platform и вперед — куча всего что есть «из коробки».

Из нашего опыта — Liferay имеет смысл:
1. Когда круг решаемых задач заранее неопределен и может быстро меняться. Тут Liferay реализовал по сути дела модель микросервисов — только на стороне UI — можно реализовать набор инструментов (сервисов — портлетов) и дальше на ходу комбинировать их в том виде в котором это требуется. И тут нет зачастую задач release management-а конфигурации о которых говорилось выше и решения для которых у Liferay нет — по сути дела мы имеет конструктор который уже средствами content manager-а собирается в ту или иную конфигурацию (грубо говоря — если вы делаете просто как-йто сайт — вы же не будете делать релиз для каждой новой новости? это же просто контент — так и тут — страницы и размещение портлетов — это просто «контент»).
2. B2B платформы — в отличие от той же CUBA в Liferay можно завести пользователей разных организаций, каждому пользователю в зависимости от типа организации и его роли настроить свое рабочее простарнство (из тех кубиков-микросервисов-портлетов что есть в заготовке) и дать всем возможность совместно работать.

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

И тут я альтернатив для Liferay не вижу (если говорить про стек технологий JEE) Но я не являюсь ярым фанатиком — буду благодарен за указание на продукты которые так же могут решать данные задачи.
akakunin
0
Не совсем так: все данные Liferay хранит в базе в реляционной модели. Вне базы (в папке /data) хранятся только:
* Бинарный контент файлов (и именно его можно перенести в хранилище JCR — что на самом деле лишено смысла)
* Поисковые индексы lucene (в случае если не используется solr).

Так что само хранение данных — оно вполне реляционное.
LAR-файл с «непонятной структурой» о котором вы говорили выше — это только формат переноса данных между серверами.

По поводу мержа конфигурации — решения нет. Обычно как у нас устроено:
1. Разработка портлетов идет в отдельных фиче-бранчах — по мере готовности сливается в мастер — тут ничего, что отличалось бы обычной разработки
2. CI сервер с автоматическим деплоем на dev-среду. Там разработчик, если требуется проводит необходимую конфигурацию (документируя ее) — предварительное тестрование.
3. По мере готовности перенос на qa-env — там настройка уже осуществляется одним человеком (вручную)
4. По мере готовности так же в ручном режиме перенос на прод (опять-таки перенос настройки вручную).

Ну и бекапы.
LAR-файлы, как обсуждали выше — к сожалению не гарантируют 100% перенос — в итоге если их использовать — то после переноса LAR-ником все равно надо пройти и ручками все проверить что правильно перенеслось — проще сразу делать перенос конфигурации руками.
akakunin
+1
Вы чуть-чуть не правы. JCR — один из возможных способов хранения контента файлов (наряду с собственным файловых хранилищем, базой и Amazon S3). Причем JackRabbit (как реализация JCR) используется только для контентов файлов из портлета Documents & Library. Все остальные Asset-ы (веб-контент и прочее) хранится в базе.

В нашей практике мы JCR не использовали ни разу (если честно — просто не понимаю профита). Из общения с IT-специалистами одной из компаний, где был внедрен BackBase — который тоже базируется на JCR — люди огребли с ним бооооольшие проблемы по производительности.
akakunin
+2
Спасибо за статью.

Поправочка — JUG.ru уже «спрыгнул» с Liferay (для нас, как компании которая занимается внедрением Liferay — факт печальный — но увы и ах).

На предмет шаблонизации — в Liferay 6.2 есть штатное средство — Application Display Templates — позволяет задать для портлетов шаблоны (поддерживается velocity & freemaker — это конечно не Google Closure Templates — но зато штатное и из коробки).

Вопрос хранения конфигурации — да, отдельная больная тема — тут вы совершенно правы. Как результат — версионность можно добиться только полным бекапом (и всех вар-ников, и базы, и папки data). Поведение импорта-экспорта (а так же stage-инга — так как он основан на том же импорте-экспорте) как вы правильно заметили совершенно непредсказуемо (особенно если вы используете бесплатную версию CE)

Ну и про «черную магию с подменой класслоадеров» — отдельные аплодисменты :) Только тот, кто до конца раскопал, как работает BeanFactoryLocator — тот поймет. Успокаивает одно — в 7-ой версии с переходом на OSGI это шаманство должно уйти в прошлое.
akakunin
0
на самом деле WSO2 DSS умеет и REST (если вы это имели в виду). Но как бы то ни было — если речь идет об интеграции информационных систем внутри компании — то SOAP никто не отменял и я думаю вряд ли в ближайшее время отменит.
akakunin
0
Коллега — поддерживаю вас в ваших опасениях — сам не раз сталкивался когда «покупались» на красивые маркетинговое демки и потом огребали по полной. Но тот же Liferay я выбирал в свое время именно как программист, и за практически 7 лет в выборе не разочаровался. Да — есть минусы и органичения. Да — есть моменты когда Liferay просто выбешивает — но идеальных решений не бывает — всегда идет компромис между плюсами и минусами — и для меня плюсы Liferay перевешивают его минусы.
Спасибо за jhipster — я как раз хотел посмотреть что есть сейчас из высокоуровневых framework-ов способных решать близкие по сложности задачи (в списке были Entando и Cuba, добавлю еще и jhipster).
Но — это все таки не совсем то. Просто пример — модель безопасности. Да — есть Spring Security — но в плане ролевой безопасности его возможности по реализации (насколько я помню) ограничены. Есть задача — назначать на любые сущности разрешение для любой роли на «Просмотр» (ну и другие разрешения). Возникают объекты (в разных системах они называются по разному — но смысл примерно один и тот же): User, Role, Resource, Permission — и соотвественно возможность назначать на определенный Resource Permission «View» для определенной Role.
А теперь ситуация — таблица с миллионами записей (Resource-ы) и надо для конкретного пользователя User который входит в несколько Role-ей показать таблицу (с шагом записей 20 штук) только тех объектов которые он может смотреть…
jhispter даст нам решение этой задачи? Сомневаюсь. Писать самому модель безопасности — можно. Но я например наблюдаю прогресс в реализации модели в Liferay и вижу что если 6 лет назад там делалась выборка из базы и фильтрация средствами Java — то сейчас уже формируются 10-ти этажные sql-запросы, но фильтрация объектов с учетом прав доступа осуществляется на уровне базы с соотвествующей производительностью. И вот сколько времени займет такое реализовывать самому — я даже затрудняюсь ответить.

Потому — для каждой задачи — свой инструмент. Где-то да — проще самому разработать систему (не с нуля — а используя в качестве отправной точки какой-то framework или стек — будь то jhispter, entando, cuba и так далее — список можно продолжить) — а где-то (для более сложных задач) проще все-таки взять готовый продукт и допиливать его (благо open source и исходники есть).
akakunin
0
Ну не соглашусь с вами.

Да — приложение достаточно сложное. По моим прикидкам время «входа» — до полугода. 300 метров — ну так это приложение Enterprise уровня. Сравните с другими лидерами гантера (SharePoint, WebSphere Portal, SAP, Oracle) — те еще больше и монструозней — на их фоне Liferay супер легкость и простота.

Документация — dev.liferay.com — сейчас вполне вменяемая. Форумы — www.liferay.com/community/forums/-/message_boards/recent-posts — практически нет постов без ответов.

Код — вполне вменяемый.
akakunin
0
А каких решений не опасаетесь?
Ну и — не знаю что у вас произошло с Альфреской — но были негативные отзывы о Liferay. Мне кажется общая проблема в следующем — системы (что Alfresco, что Liferay) достаточно сложные — для реализации более-менее сложных задач требуется опыт. Зачастую же складывается как — берут (потому что бесплатно) — сажают админа или unior-разработчика — мол «поковыряйся — что там и как», потом кое-как решают поставленную задачу — она нифига не решается, все работает плохо и криво, а итоге решают что продукт «отстой» и все выкидывают.
Мне конечно обидно такое наблюдать — так как проблема в данном случае не в продукте — а в умении с ним обращаться — но такие ситуации встречал не раз.
akakunin
+2
Ну и еще про сложность — каждый инструмент для своего типа задач. Я когда с клиентом встречаюсь — первым делом выясняю зачем им портал, какие у них стоят задачи — чтобы понять, а нужен ли им Liferay в принципе.
Если им надо промо сайт на 5 страниц — не нужен Liferay — любая CMS на PHP сделает его проще и быстрее чем это будет на Liferay.
Если им надо чисто внутренний портал на 10-100 человек — не нужен Liferay — это будет дорого и неэффективно — есть более дешевые и простые решения
Если нужно реализовать какой-то процесс с тремя типами участников — не нужен Liferay — любой программист с прямыми руками напишет систему с требуемым функционалом с нуля или на базе top-level framework-а значительно быстрее.
Ну а если задача реально сложная — очевидно что для ее решения требуются сложные системы.
akakunin
+2
Я старался быть объективен — но действительно это может не всегда получаться.
Liferay — сложен так как реализует сложный функционал. То что точно ему в минус — это что «из коробки» идет куча мусора — в ядро системы входит куча портлетов (функционала) который может быть и не нужен. И тут я как раз и отметил — что вариант использования JBoss в том случае если требуется чистый Portlet Container — без лишнего функционала.
akakunin
0
В очереди — я не планирую на этом останавливаться, но из списка — IBM WebSphere портал — не open-source, Jetspeed-2 и Pluto еще большие «поделки» чем JBoss (по крайней мере на то время когда я их смотрел — может конечно что-то изменилось за последние пару лет)
akakunin
+2
Как я понял — они его не покупали — а развивали достаточно давно — но сил развить что бы из проекта это превратилось в ПРОДУКТ (ценный сам по себе — без привязки к производителю и его стеку продуктов) уже не хватило.
akakunin
0
И как издевка мне справа вылез огромный банер «Узнайте о новом подходе к созданию кодов — разумные приложения созданы с IBM» :)
akakunin
0
В тексте явно упоминается что разработчик IBM — думаю что разработка полностью велась на их стеке.
akakunin
0
Напишите нам на www.emdev.ru/order-demo свои координаты — перешлем информацию по доступу к демо-стенду
akakunin
0
Добавлю от себя пять копеек — полгода как перешел с мегафона на йоту. Очень доволен. Основное — у Мегафона (да и у большинства других) постоянно надо играть разными опциями что бы не «вылететь». Едешь из СПБ в новгород — не забудь подключить опцию, на следующий день вернулся — не забудь выключить. летишь в отпуск — не забудь включить бесплатные входящие — потом не забудь выключить. Я обычно забывал — потом еще переплачивал на неиспользуемые опции.

тут все просто — заплатил 520 р. и все — по всей стране (и роуминг и междугородние звонки). Роуминг? не надо никаких опций — 19 р исходящие и 9р. входящие на наиболее популярных направлениях — что еще надо?

Из минусов — в роуминге не всегда переключатся автоматом — надо играть с сим-меню. Поддержка через чат — (ну тут об этом много писали) -мне пришлось обращаться один раз. Не могу сказать что было комфортно — но проблему решили (как раз с роумингом). В целом отсутствие личного кабинета — чаще всего и не нужен — но например получить отчет по расходам — уже фиг знает как — видимо надо как-то отдельно просить.
akakunin
0
А жаль на самом деле что за жалобами на саппорт прошли незамеченными технические подробности данного проекта. Мы внедряем Liferay уже несколько лет — и могу сказать что этот проект был уникальным в плане реализации на Liferay — причем не только для России но и для Европы.
akakunin
+3
Еще будет JavaOne в москве — в апреле.
А если взять чуть-чуть пошире России — то очень рекомендую JEEConf в Киеве — в прошлом году была просто супер-конференция — надеюсь в этом будет не хуже. Дата насколько я знаю уточняется — где-то середина мая (Киев в мае — это отдельная песня!)

Основной плюс JEEConf — это не конференция одного вендора — получается не так однобоко
akakunin
0
А мне как раз нравится Spring MVC — за то что он не прячет детали коммуникации (собственно сам протокол http, используемые урлы и передачу параметров) — а просто упрощает их обработку.
Объясню на примере — долго использовал JSF (с RichFaces) — там вообще все в шоколаде — пишешь #{controlled.callSomeMethod()} — и не паришься — как там это все передается, какие урлы регерятся, как параметры передаются, как они попадают в контроллер — вообщем все происходит автоматом.
Только когда у тебя страница вдруг начинает весить под 2 метра — потому что во всех урлах передается state, либо когда начинаются танцы с бубном, потому что надо SEO Friendly URL-ы, либо когда вдруг сильно упираешься в перфоманс…
SpringMVC — по сути дела практически голый JSP API — просто с набором вещей которые упрощают его использование — в итоге ты всегда контролируешь что и как работает.
akakunin
+7
«говорит — настроить как надо, потом забыть» — поставить Убунту, настроить — и забыт про апдейты на новые версии — только секюрити апдейты текущего релиза и установка (ручками или из PPA если есть) новых версий продуктов что вам надо

Будет все стабильно.
По большому счету — основной набор фич в новой убунте (причем начиная с 11.04) — это Unity. Если вы продолжаете использовать (как и я) старый Gnome — то и нафига обновляться?

В остальном Убунта очень нравится — все просто и понятно — даже после перехода на Мак (сейчас паралельно использую и Мак и Убунту на разных ноутах) первой реакцией было — о — тут все как на Убунте — только неудобней :)
akakunin
0
О! То есть вы его уже запускали? Здорово! А как тогда получилось запустить в класетере без «общей папки»? JackRabbit + MySQL для хранения файлов — или еще что-то?

Скажем так — на ElasticBeans амазоновском без бубна не заводится — да и то, как заводится — нельзя сказать что можно нормально использовать — если у вас работает — это хороший плюс
akakunin
0
Ну то есть сразу хочи объяснить — хочу попробовать запустить такую штуку как Liferay в вашей среде — приложение достаточно большое и сложное — в кластерном варианте есть ряд дополнительных требований — если запуститься — напишу отчет :)
akakunin
0
да, пока ничего не попросил. Еще вопрос — приложению необходимо где-то хранить файлы. Причем в кластерном варианте необходимо общий доступ к папке со всех нод (по одному и тому же пути — что бы конфигурация на каждой ноде была одинаковая) — такое возможно?
akakunin
+2
На сайте jelastic.com не нашел ничего про стоимость — плохо смотрел?
akakunin
+1
Ну в более сложном случае и конфигурация будет сложней — вам надо будет задать свой Trigger, сконфигурировать его из properties-файла и потом дергать задачи используя этот триггер
В этому случае как раз придется писать много xml — и аннотацией не получится воспользоваться

Все подробно написано в спринговой доке — я тут намеренно привел простейний пример
akakunin
+1
Точные даты не назывались — как появятся — я сообщу

Кстати — мне кажется у организаторов такой выставки должны быть аккаунты на хабре — если у кого-то есть пара инвайтов — поделитесь (я свои все растратил)
akakunin
+1
Да, точно — выложить презентацию!
Моя презентация доступна как всегда на русском сообществе Liferay
akakunin
+1
Тут вспоминается история про одну крупную компанию, которая пока была маленькой внедрила самописную ERP. А потом компания быстро и сильно выросла. В итоге, пока шло внедрение SAP (а компания выросла так что потребовались решения уровня SAP) руководством к программисту-автору была приставлена охрана — если бы с ним что-то случилось — работа всей компании просто бы встало.

С точки зрения внедряющего человека — велосипед это хорошо — можно при удачном стечении обстоятельств обеспечить себя булочкой не только с маслом — но и икоркой. А вот с точки зрения руководства — фиг знает, фиг знает.
akakunin
0
По поводу прожорливости — у меня проект на amazon small instance (1.7Gb RAM, проц порядка 1GGz) выдерживал хабраэффект. Так что простенькой машинки с двумя гигами на 600 пользователей (подозреваю 50 одновременных это максимум у вас) вполне бы потянула. Java хочет больше ресурсов для запуска чем PHP — но зато потом ее прожорливость растет медленней (имхо).

«обращаться физически не к кому» — согласен что это причина — если нет возмодности допилить самому — заказывать разработку на java (а тем более с опытом в какой-то системе) будет отностительно дорого — ЗП программиста на Java сильно отличается от ЗП программиста на PHP

Но все равно не могу поверить что на PHP не было ничего адекватного — если не секрет (и дял общего развития) — какие средства рассматривали (из бесплатных)?
akakunin
0
«Разумеется под решение данных задач уже существовало множество готовых решений, указанных в начале топика, но либо они решали вышеперечисленные задачи лишь частично, либо их стоимость вызывала крайнее недовольство у руководства.» — я как то пропустил «готовые решения указанные выше» — или плохо читал.
Мы используем Liferay — это конечно не LAMP а java — но в принципе есть все что надо — и CMS, и простейший документооборот, и социальные сети — и все бесплатно. Хотя конечно не зная Java «допиливать» его сложно. Но наверняка и на PHP есть адекватные решения.
Если честно — все-таки сомневаюсь в эффективности писания нового велосипеда — наверняка при дальнейшем развитии проекта встанет вопрос реализовывать новые и новые фичи, которые есть в готовых продуктах заточенных под создание корпоративных порталов.
akakunin
0
Получил ответ от организаторов, что студентам 50% скидка — но для студентов конференция может быть сложновата — так как уровень докладов расчитан на Senior Developer или близко к этому (по крайней мере сужу по своему докладу или по тем что мне интересны).
akakunin
0
Я не в курсе организации — но очень надеюсь что будет видео запись докладов (как это сделали ребята на ADDConf)
akakunin
0
Странно почему организаторы не «подсуетились» сделать анонс на хабре раньше. Хотя судя по всему проблем с заполняемостью у них нет и так.
akakunin
+1
Спасибо — исправил
akakunin
0
блин — аж как на 10 лет назад вернулся пока читал — почему то был уверен что под убунту gcc уже не нужен