Веб-сервисы для удаленных портлетов в C# / .NET - Опции?
Недавно мой разум был расширен новой концепцией: веб-сервисами для удаленных портлетов или WSRP. Я узнал об этом во время презентации на веб-портале на основе Java, мы рассматриваем возможность покупки на работе; мы являемся магазином.NET, и WSRP был бы средством расширения этого портала.
Хотя я не могу контролировать окончательное решение относительно того, приобретаем ли мы продукт или нет, я могу предоставить информацию о том, насколько сложно будет создавать портлеты, совместимые с WSRP. К сожалению, мои недавние запросы на эту тему оказались почти нулевыми.
Итак, я спрашиваю вас, сообщество SO, о следующем: какие библиотеки или инфраструктуры существуют для создания WSRP-совместимых портлетов в C#/.NET? Каковы некоторые плюсы и минусы использования WSRP в целом?
Поскольку здесь нет правильного ответа, я сделаю это вики-постом сообщества.
До сих пор я нашел только следующее:
- WSRP Toolkit для Sharepoint от Microsoft (но требующий Sharepoint).
- Портал WSRP и WSRP .NET Framework от NetUnity.
Учитывая, что WSRP находится поверх SOAP, это кажется идеальным кандидатом для привязки и канала WCF, и все же я нигде ничего не вижу по этому вопросу.
5 ответов
Если вы внимательно прочитаете спецификацию WSRP, то обнаружите, что это удаленная версия спецификации портлета Java (если я правильно это пишу). Это означает, что это полезно для интеграции портлетов Java. Все остальное должно выглядеть как портлет Java, который не очень универсален.
WSRP очень противоречит. К настоящему времени мир увидел, что тесная связь между моделью данных и моделью представления является неоптимальной. Успех RSS, REST, MVC и веб-сервисов в целом показывает это. Несмотря на название WS, WSRP выступает против основных принципов Web-сервисов. Спецификация WSRP игнорирует разумные рекомендации по разделению данных и представления и тесно связывает их.
WSRP обещает интеграцию на уровне пользовательского интерфейса. Это кажется неправильной проблемой для решения.
Меня сбивает с толку, что эта вещь живет так же долго, как и раньше.
Проблема, которую он пытается решить, часто не является проблемой, которая должна быть решена.
Я думаю, что его популярность / принятие могут быть выведены из-за того факта, что последний выпуск от NetUnit был "В этом последнем выпуске добавлена поддержка Visual Studio 2005 и.NET 2.0".
WSRP по сути является стандартом веб-службы от портала к портлету. Каковы первичные данные, которыми обмениваются портал и портлет? Это разметка и во многом потому, что большинство порталов используют веб-интерфейс. Вся эта идея, что это не чистые данные по сравнению с пользовательским интерфейсом, является спорным вопросом. Он предназначен для веб-службы обнаружения портлетов, метаданных, разметки, взаимодействий, кэширования, связи портлетов с портлетами и т. Д. Это то, что делает портал, даже если не WSRP. WSRP, однако, является открытым кроссплатформенным стандартом.
Что такое портал, который интегрирует только портлеты из собственных продуктов и / или платформ? У вас есть PeopleSoft HR на основе Java и вы хотели бы предоставить своим сотрудникам доступ к своим портлетам из SharePoint? Удачи. Почему это не может быть достижимым сценарием для большинства корпоративных программ? И да, я понимаю, что это интеграция, связанная с пользовательским интерфейсом. Это одна из основных причин, почему я использую портал. Не то чтобы я ожидал интеграции PeopleSoft с SharePoint на "чистом" уровне данных, и каким-то образом веб-часть "Преимущества для сотрудников" волшебным образом появляется в SharePoint, готовой к использованию. Однако именно этого я и ожидаю, если интеграция портлетов в портлеты основана на WSRP.
WSRP, хотя и не идеальный, на мой взгляд, является превосходным решением. Помимо простой интеграции портлета в портале, он отделяет портал от приложения. Нет развертывания двоичных файлов на сервере портала или даже на том же сервере. Это имеет смысл. Никогда не запускайте приложения на одном сервере с сервером портала: ни один из них не будет обновлен. Я пришел к выводу, что безумно размещать двоичные файлы приложений на одном сервере с сервером портала. "Пожалуйста, разверните это приложение на сервере портала и сделайте так, чтобы оно влияло на безопасность, стабильность, производительность и все промежуточное, и я хотел бы создать как можно больше зависимостей и отключить весь сервер портала при каждом обновлении приложения". Это кошмар зависимости. Лучше получить пару консультантов поставщика портала, чтобы они держались за руки при обновлении и чтобы кто-то был виноват.
Нужно ли балансировать нагрузку на всю платформу портала, когда больше всего поражено только определенное количество портлетов? Поставщики порталов хотели бы, чтобы вы так думали. В большинстве случаев портал делает только ожидание завершения обработки портлетами. С WSRP вы можете гибко настраивать портлеты балансировки нагрузки независимо от платформы портала. Он всегда разбивается на несколько портлетов, которые больше всего поражены. Почему бы не распределить нагрузку только по этим портлетам? Таким образом, вместо излишней балансировки нагрузки портала на 80 ЦП, вы можете распределить нагрузку этих нескольких портлетов на 10 ЦП. WSRP также идеально подходит для облачных вычислений.
WSRP - это стандарт от портала к портлету. Если вы хотите написать портлет, который работает на нескольких порталах и, возможно, на разных платформах, то WSRP - это он. Если вы планируете интегрировать сторонние портлеты, то WSRP - это то, что вам нужно. Это единственный стандарт. Тем не менее, он также имеет некоторые существенные преимущества по сравнению с другими проприетарными локальными интерфейсами портал-портлетов и должен учитываться и для этих преимуществ.
Я должен был бы согласиться с Cheeso. Интеграция пользовательского интерфейса с данными служит только потребителям портлетов и добавляет большой, ненужный, рискованный уровень для производителей портлетов. Наш магазин.NET недавно был вынужден рассмотреть WSRP, и я обнаружил отсутствие поддержки и опыта. Лучший MS-ориентированный подход, который я видел, обсуждался здесь. Но я не нашел какой-либо конкретной реализации / поддержки WCF. Любая приводит с благодарностью!