Подтвердить что ты не робот

Java-порталы и портлеты

В мире Java есть стандарт JSR-286 для взаимодействия порталов и портлетов: программные компоненты, совместно использующие единую веб-страницу.

Кажется, что существует ряд реализаций портала. Но есть ли "базар" взаимозаменяемых портлетов, которые будут работать в них? Из того, что я могу найти в Интернете, он выглядит очень однобоко - все порталы и портлеты. Это было, если бы были десятки Android-телефонов и приложений.

Если продукт должен был основываться на JSR-286 (или какой-либо его реализации), какова вероятность того, что корпоративный клиент имеет кучу портлетов, которые он может захотеть добавить в портал?

Мне кажется, что большинство корпораций уже будут иметь портал-подобную страницу, основанную на их выборе продукта ERP или CRM, на котором работает их бизнес, или, может быть, даже на странице MS Outlook "Сегодня". Поэтому, если я отправляю новый продукт, предназначенный для корпоративных клиентов, и я делаю его порталом (а не набором портлетов), какова вероятность того, что мои клиенты откажутся от своего существующего портала IBM/SAP/Oracle и используют мой портал в качестве своей новой домашней страницы? (Я предполагаю: не очень.) И если я сделаю это набор портлетов, совместимых с JSR-286, будут ли мои клиенты иметь способ размещения хостов-хостов? (Я предполагаю: тоже не очень).

Наконец, JSR-286 кажется довольно немым о HTML + JavaScript, то есть как порталы и портлеты будут взаимодействовать внутри браузера. Все дело в Java-серверных материалах, определяющих способ взаимодействия в использовании URL-адресов, чтобы каждое полностраничное обновление могло быть перенаправлено в правильный портлет. Он, похоже, не признает современный, богатый подход AJAX. Он упоминает AJAX только мимоходом.

Это сообщение в блоге (и комментарии по нему) предоставило много пищи для размышлений и, похоже, подтверждает мои подозрения:

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

Итак, чтобы обобщить это как более согласованный вопрос: какую фактическую ценность я получу, построив JSR-286 на этом этапе?

4b9b3361

Ответ 1

Единственное преимущество, которое я знаю из рук в руки, заключается в том, что, когда поставщики корпоративного программного обеспечения имеют "интеграцию портала" в своем контрольном списке функций, обычно это означает, что они написали портлеты в соответствии со стандартами JSR-168 или JSR-286. SAP, Banner и Magnolia - некоторые из систем, которые мы используем здесь, которые работают таким образом, и некоторые организации находят ценность в рамках портала.

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

FWIW, если вы решите распространять свою работу как коллекцию портлетов, существуют существующие системы портала, которые являются бесплатными/открытыми исходными кодами, которые вы могли бы предоставить людям, у которых еще не было контейнера портлетов:

http://java-source.net/open-source/portals

Надеюсь, что все это немного помогает.