Веб-службы для удаленных портлетов в C#/.NET — варианты?

Question

Недавно мой разум расширился новой концепцией: Веб-службы для удаленных портлетов, или WSRP.Я узнал об этом во время презентации веб-портала на базе Java, который мы собираемся приобрести на работе;мы являемся магазином .NET, и WSRP будет средством расширения этого портала.

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

Поэтому я прошу вас, сообщество SO, о следующем:какие библиотеки или платформы существуют для создания WSRP-совместимых портлетов на C#/.NET?Каковы плюсы и минусы использования WSRP в целом?

Поскольку здесь нет правильного ответа, я сделаю это сообщение в вики-сообществе.

Пока что нашел только следующее:

• Набор инструментов WSRP для Sharepoint от Microsoft (но требует Sharepoint).
• Портал WSRP и WSRP .NET Framework Автор NetUnity.

Учитывая, что WSRP работает поверх SOAP, это кажется идеальным кандидатом на привязку и канал WCF, но, тем не менее, я нигде не вижу ничего по этому поводу.

Answer 1

Если вы внимательно прочитаете спецификацию WSRP, вы обнаружите, что это удаленная версия спецификации портлета Java (если я правильно пишу).Это означает, что он полезен для интеграции портлетов Java.Все остальное должно выглядеть как портлет Java, который не является очень универсальным.

Answer 2

WSRP очень противоречив.К настоящему времени мир увидел, что тесная связь между моделью данных и моделью представления неоптимальна.Об этом свидетельствует успех RSS, REST, MVC и веб-сервисов в целом.Несмотря на присутствие WS в названии, WSRP противоречит основным принципам веб-сервисов.Спецификация WSRP игнорирует здравый совет хранить данные и представление отдельно и жестко связывает их.

WSRP обещает интеграцию на уровне пользовательского интерфейса.Кажется, это не та проблема, которую нужно решать.

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

Answer 3

Я думаю, что о его популярности/принятии можно судить по тому факту, что последний выпуск NetUnit был «В этом последнем выпуске добавлена ​​поддержка Visual Studio 2005 и .NET 2.0».

Answer 4

Я бы согласился с Чисо.Интеграция пользовательского интерфейса с данными служит только потребителям портлетов и добавляет большой, ненужный и рискованный уровень для производителей портлетов.Наш .NET-магазин недавно был принужденный рассмотреть вопрос о WSRP, и я обнаружил недостаток поддержки и опыта.Лучший подход, ориентированный на MS, который я видел, обсуждался: здесь.Но я не нашел какой-либо конкретной реализации/поддержки WCF.Любые рекомендации очень ценятся!

Answer 5

WSRP — это, по сути, стандарт веб-службы «портал-портлет».Каковы основные данные, которыми обмениваются портал и портлет?Это разметка, во многом потому, что большинство порталов используют веб-интерфейс.Сама идея о том, что это не чистые данные по сравнению с пользовательским интерфейсом, является спорным вопросом.Предполагается, что это веб-служба для обнаружения портлетов, метаданных, разметки, взаимодействия, кэширования, связи между портлетами и т. д.Это то, что делает портал, даже если это не WSRP.Однако WSRP является открытым кроссплатформенным стандартом.

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

WSRP, хотя и не идеален, на мой взгляд, является лучшим решением.Помимо простой интеграции портлета в портал, он отделяет портал от приложения.Никакого развертывания двоичных файлов на сервере портала или даже запуска на том же сервере.Это имеет смысл.Никогда не запускайте приложения на том же сервере, что и сервер портала:ни один из них никогда не будет обновлен.Я пришел к выводу, что размещать двоичные файлы приложений на одном сервере с сервером портала — это безумие.«Пожалуйста, разверните это приложение на сервере портала и повлияйте на безопасность, стабильность, производительность и все, что между ними, и я хотел бы создать как можно больше зависимостей и отключать весь сервер портала всякий раз, когда я обновляю приложение».Это кошмар зависимости.Лучше наймите пару консультантов поставщиков порталов, чтобы они держались за руки при обновлении и чтобы было кого винить.

Вам нужно сбалансировать нагрузку на всю платформу портала, если больше всего задействовано только определенное количество портлетов?Поставщики порталов хотели бы, чтобы вы так думали.Большую часть времени портал не делает ничего, кроме ожидания завершения обработки портлетов.Благодаря WSRP у вас есть возможность распределять нагрузку портлетов независимо от платформы портала.Он всегда разбивается на несколько портлетов, которые подвергаются наибольшему воздействию.Почему бы не сбалансировать нагрузку только на эти портлеты?Таким образом, вместо ненужной балансировки нагрузки портала на 80 ЦП, вы можете сбалансировать нагрузку этих нескольких портлетов на 10 ЦП.WSRP также идеально подходит для облачных вычислений.

WSRP — это стандарт «портал-портлет».Если вы хотите написать портлет, который будет работать на нескольких порталах и, возможно, на разных платформах, WSRP — это то, что вам нужно.Если вы планируете удаленно интегрировать портлеты сторонних производителей, вам подойдет WSRP.Это единственный стандарт.Однако он также имеет некоторые существенные преимущества по сравнению с другими проприетарными локальными интерфейсами «портал-портлет», и эти преимущества также следует учитывать.