Все началось в теме про Grails - http://forum.vingrad.ru/forum/topic-355827.html
В ней мы затронули тему порталов. Мне действительно хотелось бы услышать мнение по этому вопросы - нафига порталы нужны. Я достаточно долго работаю с порталами и считаю, что они предоставляют достаточно интересные возможности.

Года 2-3 назад я заинтересовался порталами. Мой интерес был связан с возможностью их применения для создания публичных web-проектов.

Идея выглядела замечательно - есть портал (созданный согласно спецификации) обеспечивающий базовый функционал. Есть портлеты (можно назвать их другими терминами, более понятными web-разработчикам "модули" или "виджеты"), которые разрабатываются согласно спецификации, работают (в теории) на любом портале - будь то LifeRay, IBM WebSphere Portal, JBoss или иной удовлетворяющий спецификации.

В теории все выглядело красиво. На практике же.....

Если говорить о web разработке - есть ряд требований предъявляемых к web-сайту (которым очень многие Java фреймворки не удовлетворяют):
- соответствие URL контенту
- стандартная реакция на стандартные действия (обновить страницу, кнопки назад, вперед...)
- желательна возможность управления видом URL

Так вот, 2 года назад этому требованию в той или иной степени удовлетворял только LifeRay (чем они очень гордились). Хотя и он имел проблемы.

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

Это был 2 года назад. На данный момент возможно что-то изменилось.



AntonSaburov, компания в которой Вы работаете активно продвигает IBM WebSphere Portal. На его базе вы предлагаете ряд решений. В том числе создаете порталы для Гос Служб. Несколько вопросов Вам:

- Чем применение портала для реализации, скажем портала Воронежской области  http://www.govvrn.ru/wps/portal/AVO  (кстати, редирект с govvrn.ru на govvrn.ru/wps/portal/AVO  можно было бы и убрать, с точки зрения SEO это плохо) лучше реализации этого портала на базе Joomla или другой более легковесной CMS ? 

- Какая посещаемость у этого портала и какое железо требуется для ее поддержания?

- Во сколько обошлась государству покупка IBM WebSphere Portal ?

- Вы знаете, что некоторые страницы сайта недоступны с выключенным JS, а следовательно, недоступны поисковым ботам, например эта: http://www.govvrn.ru/wps/portal/!ut/p/c5/0...xOVThRUzBITTE!/?  

- почему сайт Вашей фирмы переехал с IBM WebSphere Portal на Joomla ?

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

Это сообщение отредактировал(а) Vasay - 5.9.2012, 20:43

Сначала о личном 

Мы уже пришли на готовый сайт, на котором уже крутилась WebSphere Portal. То, что есть редирект - это сложилось исторически.
Что же касается просто CMS - сам портал не является ТОЛЬКО хранилищем контента. Там много внутренних служб, которые скрыты для рядового пользователя. Реализовать электронные формы, бизнес-процессы, доп. приложения для обработки запросов - это был бы тяжелый труд.


По нашей статистике на пике порядка 100-150 запросов в секунду. Железо точно не могу сказать - у нас виртуальные машины крутятся. Но на портал порядка 8Гб памяти, процессор 4-6 ядер. Еще база для CMS, форм, заявок, СМЭВ и много другой информации - там порядка 50 баз. Это вторая подобная машина.


Это тоже унаследованное решение - нам с него просто не слезть.
 

Основной сайт американского офиса на портале. У нас из-за ограничений безопасности приходится использовать внешний хостинг.


Мне сложно сказать - цены IBM устанавливает. Но мы делали сравнение цен приблизительно равного набора продуктов от MS и IBM - MS стоит дороже. Бесплатность SharePoint "сильно преувеличена"  В поставку портала входит очень много продуктов - там более 30 наименований и если правильно ими распорядиться, то этого хватает для большого круга корпоративных задач.
Что касается продвижения продуктов IBM нашей компанией - стоимость именно софта в наших решениях приносит на самом деле мало денежков - подавляющая часть занимает непосредственно разработка. Просто IBM наш партнер и мы должны с этим считаться.


Я не имел в виду, что это г в красивой упаковке - просто я сталкивался много раз с нетипизированными языками и пришел к выводу, что для них есть определенный круг задач. Проекты в сотни тысяч строк с большим количеством межмодульных взаимодействий не для них - слишком велика вероятность ошибки при интерфейсах с непонятными типами. Это относится не только к Grails. По моему опыту получается, что либо используются очень универсальные механизмы, в которых можно контролировать очень много, либо узко заточенные пакеты, которые позволяют очень хорошо решать очень конкретные задачи. Большие системы обычно состоят как из "точечных" систем, так и из вручную выписанных модулей. И вот эти ручные модули нужно уметь контролировать от и до. Для сгенеренных кусков приходится править очень много и в результате получается, что их проще написать чуть ли не на голом Java.


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

URL это действительно больное место порталов - там мало вариантов, хотя можно привязать конкретную страницу к точному URL. Для публичных сайтов с возможностью индексирования в поисковых системах это большая проблема.
Но идеологически портал именно с портлетами предназначен совсем не для паблик-сайтов. Публичный контент IMHO нужно публиковать в WCM (CMS от WebSphere Portal) и использовать только ее с вполне читабельными ссылками. Как это сделано на http://teachforamerica.com.
WCM необычайно расширяемая и мощная CMS, если в ней хорошо покопаться, и для паблик сайта ее вполне хватает.
Можно посмотреть еще тут - http://www.economy.gov.ru. Четкий WCM с четкими ссылками.

Сила портлетов проявляется именно во внутрикорпоративном или личном пространстве. Здесь вряд ли кого-то интересует URL и индексация в паблик поисковиках. Скорее это даже нельзя делать.
Портлет по сути - это небольшое приложение, которое решает очень конкретную задачу. И что для меня важно - контент портлета не для поисковых систем. Ты же не публикуешь свою почту в интернете - это было бы странно.

Также здесь появляется много чего хорошего:
1. Очень удобная настройка доступа - установка доступа к страницам и портлетам на странице делается очень просто. 
2. Персонализация настроек для портлета - вы входите в режим настройки и устанавливаете параметры ЛИЧНО для себя.
3. Структура страниц и их содержимое - личное дело админов. Программист совсем не вовлечен в процесс настройки чего там на странице валяется.
4. Вся мощь J2EE серверов - там много чего есть, сам можешь представить.
5. Всякие вкусности типа разных тем, максимизация, минимизация портлетов и прочая.

Т.е портал становится контейнером для набора инструментов, которые настраиваются под каждого пользователя, распределяются по страницам - и это не требует усилий программистов.
Идеология на мой взгляд вот куда должна идти - есть большой набор нужных и ЛИЧНЫХ инструментов. Они распределены по страницам, настроены для тебя любимого, могут сворачиваться, разворачиваться и дают доступ к нужным ресурсам с ПЕРСОНАЛЬНЫМ контентом.
Ты представляешь, когда тебе говорят: "вот на эту страничку надо пускать только Семен Семеновича и Веронику Павловну, а остальным нельзя", что надо сделать в веб-приложении ? Вот только за это я люблю портал. Есть четкая маленькая функциональность и кому ее давать и где ее размещать - да мне по барабану.

AntonSaburov,  спасибо за ответы. 



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


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

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


Наш спор с Вами зародился в теме про Grails, фреймворке для создания публичных web-сайтов.  О порталах я говорил в том же ключе.  Обоснованность их применения для систем внутреннего документооборота мне сложно оценить. 



Я согласен, что переходя с типизированного ЯП на язык с динамической типизацией поначалу сильно плюешься. Но все же у этой медали 2 стороны: больше свобод - больше возможностей, но и больше ответственность. Если говорить про Groovy, то, в отличии от других динамических языков мы имеем огромный плюс - Groovy это java технология. Мы можем его использовать только там, где важны возможности динамического языка. Смотрим на тот же Grails (сам фреймворк) - там не так много Groovy, основные вещи написаны на Java. Те по сути мы имеем надежность Java с ее статической типизацией и гибкость Groovy с его динамической типизацией. И создавая проекты на Grails Вы можете использовать Java сведя применение Groovy к минимуму. 

 
п.с. теперь в теме про порталы Мы стали говорить о Groovy и Grails.





Это сообщение отредактировал(а) Vasay - 6.9.2012, 00:41

Сам портал скрыт за прокси-сервером, который в случае кластера используется как балансер. Так что портал наружу сам не смотрит. Там всего около десятка виртуальных машин для работы. Если говорить о безопасности как об отказоустойчивости, то конечно лучше иметь кластер из нескольких машин. В среднем перезапуск потала происходит раз в месяц. Было и полгода никто не подходил. Но тут уже не все от нас зависит - вопросы железа, лицензий и прочего.


Я бы не назвал это спором - для меня это дискуссия и возможность узнать чужое мнение и высказать свое. Иногда правда грубовато получается  Есть у меня такой грешок.
По поводу портлетов - я высказал лично свое отношение. Информация из портлета не должна быть статической и думать. что она будет индексироваться в поисковиках - это не о них. IMHO конечно.

К сожалению, за мной такой грех тоже водится - приношу свои извинения. Местами я был неуместно резок.




Я имел ввиду, что раз любой пользователь интернета может зайти на страницы портала, то нет ли вероятности, что злоумышленник сможет, воспользовавшись какими-либо уязвиммостями в софте или настройках, получить доступ к документообороту администрации Воронежской области ?

Или, что будет, если злоумышленник получит пароль кого-нибудь из работников администрации с широкими правами доступа и зайдет на портал через форму логина на сайте - сможет ли он получить доступ к какому-либо внутреннему контенту, или это форма даст ему только возможность "нагадить" в рамках web-сайта ?  

Когда-то я читал про то, как набирали тестеров в команду и одного взяли за фразу (не дословно конечно) : "Я могу взломать любую систему, если на машине с ней открыт хотя бы один порт".
Вообщем-то к каким-то дополнительным функциям - да, получит. Но там не очень много - только информация из WCM. Основная функциональность доступна через админку gj HTTPS и она видна только во внутренней сети.

Еще несколько слов про URL потала. Я уже упоминал - если использовать именно страницы со статическим контентом, то проблема достаточно нормально решается использованием friendly URL - во всяком случае в WebSphere такое есть - можно на целую страницу сделать удобный URL. Но если на странице появлется интерактив внутри портлета, то там все гораздо сложнее, хотя и такое тоже возможно - надо возиться. Я правда не пробовал, но про механизмы мне рассказывали.

Механизм формирования правильных URL  я видел у LifeRay. В комплекте шел набор портлетов его реализующий. К сожалению, качество портлетов и качество кода оставляло желать лучшего. Было это 2 года назад. 

Если я не ошибаюсь, то портлеты из LifeRay использующие функционал сохранения состояния в URL не работали на других порталах.