Какая альтернатива стратегии корпоративного портала в пространстве Java?

Разочарование портальным пространством

Я вижу тревожное число крупных корпоративных клиентов, которые разочаровались в своем опыте работы с корпоративным порталом, особенно в пространстве WebSphere Portal Server (WPS). Миллионы были вложены, но обещание персонализированного контента с агрегированием и интегрированными инструментами для совместной работы так и не осуществилось. Переход на WPS 7.x - это большой шаг назад и замены, и клиенты задаются вопросом, должны ли они полностью перейти куда-то еще.

Программное обеспечение портала: ужасный вариант, но какова альтернатива

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

Работать с порталами не всегда так весело, как с Tomcat или JBoss AS, но когда дело доходит до интеграции нескольких приложений, управления контентом, обновления отдельных приложений, развертываемых в виде отдельных военных файлов, управления безопасностью вплоть до уровня портлета, подтверждения определенного количество персонализации для пользователей и помощь в решении огромной задачи по управлению тысячами страниц, которые есть у крупных предприятий в рамках внутренних и внешних веб-сайтов, есть ли лучшая технология?

Собирая понимание сообщества и обратную связь

Я пытался собрать как можно больше информации. Я написал небольшую статью на TSS о проблеме:

Какие еще альтернативы порталу существуют на рынке?

Я также возрождаю тему в CodeRanch, чтобы узнать, смогу ли я получить какую-либо информацию от этой красивой команды.

Обновленная тема, запрашивающая альтернативу программному обеспечению портала. Около 2012

Я также ищу некоторое понимание от twitterati (@potemcam).

Это не столько кросс-постинг, сколько попытка по-настоящему собрать острое понимание сообщества. Если бы я мог получить твердые ответы и опыт, я хотел бы объединить их в статью с рекомендациями в TSS.

Какова правильная альтернатива корпоративному порталу в пространстве Java?

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

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

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

Тогда как вы унифицируете информацию? Одна из проблем, решаемых порталом, заключалась в том, как перенести эти разрозненные элементы на одну страницу и заставить их загружаться независимо. С тех пор AJAX вырос, и тот же эффект потенциально может быть обработан с использованием вызовов XMLHttpRequest для различных (RESTful?) Сервисов для получения ваших данных, а затем с помощью общего набора таблиц стилей.

Будет ли это работать? Это может и делает. Это более управляемо, чем серверы портала JSR286? Наверное. Есть ли еще куча проблем, которые нужно преодолеть? Определенно. Но это жизнеспособная альтернатива.

Я недавно был глубоко вовлечен в сцену сервера портала Java. Он был выбран в качестве недорогой альтернативы SharePoint, поскольку нам удалось найти поставщика портала, обладающего сопоставимыми функциями. Мы использовали eXo Platform, и хотя она в основном рекламируется для социальных функций, она полностью совместима с сервером портала JSR286.

Портал Java может быть невероятно мощным, но, естественно, за счет этого он кажется чрезмерно сложным и излишне сложным. Общий ответ клиента, который мы получили, заключался в том, что базовая конфигурация и нагрузка на сервер могут быть слишком большими. Мне еще предстоит найти платформу или альтернативу портала, которая могла бы предложить подробный набор функций, но при этом оставаться достаточно компактной для набора эксплуатационных требований. Годы раздувания функций между конкурирующими портальными платформами серьезно заполонили рынок.

Рост в мире порталов Java был мучительно медленным. Вы найдете устаревшие интерфейсы, архаичный UX, и каждое действие оставит неприятный вкус во рту. Здесь мало новаторов, и eXo Platform является одной из немногих, которые, как мы обнаружили, предпринимают согласованные усилия по модернизации.

Учитывая все это, вы все еще можете создать разумный продукт в мире JSR268 с определенной степенью успеха. Мы смогли сделать это, используя сервисы JAX-RS для каждого портлета, в основном функции и функции выбора портлета. Весь доступ к базе данных выполняется с веб-сервера отдельными службами RESTful для оптимизации операций CRUD. Это требует внушительного усердия с чрезмерными усилиями, которые не многие готовы совершить.

Вы также можете полностью подготовиться и создать себе «портал» с сервлетами и JAX-RS. Это можно сделать намного быстрее, чем стандартная разработка портала. Однако вам не удастся поддерживать полный набор функций конфигурации, которые можно найти на стандартном веб-портале.

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

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

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

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

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

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