WSRP по сути является стандартом веб-службы от портала к портлету. Каковы первичные данные, которыми обмениваются портал и портлет? Это разметка и во многом потому, что большинство порталов используют веб-интерфейс. Вся эта идея, что это не чистые данные по сравнению с пользовательским интерфейсом, является спорным вопросом. Он предназначен для веб-службы обнаружения портлетов, метаданных, разметки, взаимодействий, кэширования, связи портлетов с портлетами и т. Д. Именно этим и занимается портал, даже если не WSRP. WSRP, однако, является открытым кроссплатформенным стандартом.
Что такое портал, который интегрирует портлеты только из своих продуктов и / или платформ? У вас есть PeopleSoft HR на основе Java и вы хотели бы предоставить своим сотрудникам доступ к своим портлетам из SharePoint? Удачи. Почему это не может быть достижимым сценарием для большинства корпоративных программ? И да, я понимаю, что это интеграция, связанная с пользовательским интерфейсом. Это одна из основных причин, почему я использую портал. Не то чтобы я ожидал интеграции PeopleSoft с SharePoint на «чистом» уровне данных, и каким-то образом веб-часть «Преимущества для сотрудников» волшебным образом появляется в SharePoint, готовой к использованию. Однако именно этого я и ожидаю, если интеграция портлетов в портлеты основана на WSRP.
WSRP, хотя и не идеальный, на мой взгляд, является превосходным решением. Помимо простой интеграции портлета в портале, он отделяет портал от приложения. Нет развертывания двоичных файлов на сервере портала или даже на том же сервере. Это имеет смысл. Никогда не запускайте приложения на одном сервере с сервером портала: ни один из них никогда не будет обновлен. Я пришел к выводу, что безумно размещать двоичные файлы приложений на одном сервере с сервером портала. «Пожалуйста, разверните это приложение на сервере портала и сделайте так, чтобы оно влияло на безопасность, стабильность, производительность и все промежуточное, и я хотел бы создать как можно больше зависимостей и отключить весь сервер портала при каждом обновлении приложения». Это кошмар зависимости. Лучше получить пару консультантов поставщика портала, чтобы они держались за руки при обновлении и чтобы кто-то был виноват.
Нужно ли балансировать нагрузку на всю платформу портала, когда больше всего поражено только определенное количество портлетов? Продавцы портала хотели бы, чтобы вы так думали. В большинстве случаев портал делает только ожидание завершения обработки портлетами. С помощью WSRP вы можете гибко настраивать портлеты балансировки нагрузки независимо от платформы портала. Он всегда разбивается на несколько портлетов, которые больше всего поражены. Почему бы не распределить нагрузку только по этим портлетам? Таким образом, вместо излишней балансировки нагрузки портала на 80 ЦП, вы можете распределить нагрузку этих нескольких портлетов на 10 ЦП. WSRP также идеально подходит для облачных вычислений.
WSRP - это стандарт от портала к портлету. Если вы хотите написать портлет, который работает на нескольких порталах и, возможно, на разных платформах, WSRP - это он. Если вы дистанционно рассматриваете возможность интеграции сторонних портлетов, WSRP - это оно. Это единственный стандарт. Тем не менее, он также имеет некоторые существенные преимущества по сравнению с другими проприетарными локальными интерфейсами портал-портлетов и должен учитываться и для этих преимуществ.