Services Web pour les portlets distants en C # / .NET - Options?

Question

J'ai récemment eu un nouveau concept: Services Web pour les portlets distants , ou WSRP. Je l'ai appris lors d'une présentation sur un portail Web basé sur Java que nous envisageons d'acheter au travail; nous sommes une boutique .NET et WSRP serait le moyen par lequel nous étendrions ce portail.

Bien que je ne puisse pas contrôler la décision finale quant à l'achat ou non du produit, je peux toutefois indiquer à quel point il serait difficile de créer des portlets conformes à WSRP. Malheureusement, mes interrogations récentes sur le sujet se sont avérées presque nulles.

Je vous demande donc, à la communauté SO, ce qui suit: quelles bibliothèques ou quels frameworks existe-t-il pour la construction de portlets conformes à WSRP en C # / .NET? Quels sont certains des avantages et des inconvénients de l'utilisation de WSRP en général?

Comme il n'y a pas de réponse correcte ici, je vais en faire un post de wiki de communauté.

Jusqu'à présent, je n'ai trouvé que les éléments suivants:

• WSRP Boîte à outils pour Sharepoint de Microsoft (mais nécessitant Sharepoint).
• portail WSRP et WSRP .NET Framework par NetUnity.

Étant donné que WSRP est au-dessus de SOAP, cela semble être un candidat idéal pour une liaison et un canal WCF, et pourtant je ne vois rien sur le sujet, nulle part.

Answer 1

Si vous lisez attentivement les spécifications WSRP, vous constaterez qu’il s’agit d’une version distante de la spécification de portlet Java (si j’épelle correctement). Cela signifie que c'est utile pour intégrer des portlets Java. Tout le reste devra ressembler à un portlet Java, ce qui n’est pas très générique.

Answer 2

WSRP est très contrarian. Le monde a déjà constaté que le couplage étroit entre le modèle de données et le modèle de présentation est sous-optimal. Le succès de RSS, REST, MVC et des services Web en général le montre bien. En dépit de la désignation WS, WSRP s'oppose aux principes fondamentaux des services Web. La spécification WSRP ignore le conseil judicieux de garder les données et la présentation séparées, et les couple étroitement.

WSRP promet l'intégration, au niveau de l'interface utilisateur. Cela semble être le mauvais problème à résoudre.

Cela me déconcerte que cette chose a vécu aussi longtemps qu'elle a.
Le problème qu’elle tente de résoudre n’est souvent pas le problème que devrait être résolu .

Answer 3

Je pense que sa popularité / adoption peut être déduite du fait que la dernière version de NetUnit était "Cette dernière version prend en charge Visual Studio 2005 et .NET 2.0".

Answer 4

Je suis d’accord avec Cheeso. L'intégration de l'interface utilisateur aux données sert uniquement les utilisateurs de portlets et ajoute une couche importante, inutile et risquée aux producteurs de portlets. Notre boutique .NET a récemment été obligée à considérer WSRP et j’ai constaté un manque de support et d’expérience. La meilleure approche centrée sur la SP dont j'ai discuté est ici . Mais je n'ai trouvé aucune implémentation / assistance spécifique de la WCF. Toute piste grandement appréciée!

Answer 5

WSRP est essentiellement une norme de service Web de portail à portlet. Quelles sont les données principales échangées entre le portail et le portlet? C'est du balisage et en grande partie parce que la plupart des portails utilisent une interface utilisateur Web. Toute cette idée qu'il ne s'agit pas de données pures par rapport à l'interface utilisateur est un point discutable. Il s'agit d'un service Web destiné à la découverte de portlets, aux métadonnées, aux balises, aux interactions, à la mise en cache, à la communication de portlet à portlet, etc. C'est ce que fait un portail, même si ce n'est pas WSRP. WSRP est cependant un standard ouvert et multi-plateformes.

Qu'est-ce qu'un portail qui intègre uniquement des portlets à partir de ses propres produits et / ou plate-forme? Vous disposez de PeopleSoft HR basé sur Java et souhaitez donner à vos employés l’accès à leurs portlets à partir de SharePoint? Bonne chance. Pourquoi ce scénario ne peut-il pas être réalisé pour la plupart des logiciels d'entreprise? Et oui, je me rends compte que c'est l'intégration liée à l'interface utilisateur. C'est l'une des principales raisons pour lesquelles j'utilise un portail. Ce n'est pas comme si je m'attendais à ce que PeopleSoft soit intégré à SharePoint au niveau "pur". niveau de données et en quelque sorte un composant WebPart Avantages sociaux s’ouvre comme par magie dans SharePoint, prêt à être utilisé. Toutefois, c’est ce à quoi je me suis attendu si l’intégration de portlet à portlet est basée sur WSRP.

WSRP, bien que pas parfait, est une solution supérieure à mon avis. Outre l'intégration facile du portlet dans un portail, il sépare le portail de l'application. Pas de déploiement de fichiers binaires sur le serveur de portail ni même sur le même serveur. C'est logique. N'exécutez jamais d'applications sur le même serveur que le serveur de portail: elles ne seront jamais mises à niveau. Je suis parvenu à la conclusion qu'il est insensé de placer des fichiers binaires d'application sur le même serveur que le serveur de portail. "Déployez cette application sur le serveur de portail et affectez-la à la sécurité, à la stabilité, aux performances, etc. Je souhaite créer autant de dépendances que possible et supprimer l'ensemble du serveur du portail chaque fois que je mets à niveau l'application". C'est un cauchemar de dépendance. Mieux vaut demander à quelques consultants de fournisseurs de portail de tenir la main lors de la mise à niveau et de blâmer quelqu'un.

Avez-vous besoin d'équilibrer la charge d'une plate-forme de portail entière lorsque seul un nombre restreint de portlets est touché? Les vendeurs de portail aimeraient que vous le pensiez. Très souvent, le portail ne fait rien d’attendre que d’attendre que les portlets terminent leur traitement. Avec WSRP, vous avez la possibilité de charger des portlets d'équilibrage indépendamment de la plate-forme du portail. Il se compose toujours de quelques portlets les plus touchés. Pourquoi ne pas équilibrer la charge uniquement avec ces portlets? Ainsi, au lieu d'équilibrer inutilement la charge du portail sur 80 processeurs, vous pouvez équilibrer ces quelques portlets sur 10 processeurs. WSRP est également absolument parfait pour le cloud computing.

WSRP est une norme de portail à portlet. WSRP est ce que vous voulez écrire un portlet qui fonctionne sur plusieurs portails et potentiellement sur plusieurs plates-formes. Si vous envisagez d'intégrer à distance des portlets tiers, c'est WSRP. C'est la seule norme. Cependant, il présente également des avantages significatifs par rapport aux autres interfaces propriétaires locales de portail à portlet et devrait également être pris en compte pour ces avantages.