Servizi Web per portlet remoti in C # / .NET & # 8212; Opzioni?

Question

Di recente ho ampliato la mia mente con un nuovo concetto: Servizi Web per portlet remoti , o WSRP. Ne ho saputo durante una presentazione su un portale Web basato su Java che stiamo valutando di acquistare sul posto di lavoro; siamo un negozio .NET e WSRP sarebbe il mezzo con cui estenderemmo questo portale.

Anche se non riesco a controllare la decisione finale sull'opportunità o meno di acquistare il prodotto, posso fornire input su quanto sarebbe difficile costruire portlet conformi a WSRP. Sfortunatamente, le mie recenti domande sull'argomento sono diventate quasi nulle.

Quindi chiedo a voi, la comunità SO, quanto segue: quali librerie o framework sono disponibili per la creazione di portlet conformi a WSRP in C # /. NET? Quali sono alcuni dei pro e contro dell'utilizzo del WSRP in generale?

Poiché non esiste una risposta corretta qui, farò di questo un post wiki della community.

Finora ho trovato solo quanto segue:

• WSRP Toolkit per Sharepoint di Microsoft (ma che richiede Sharepoint).
• WSRP Portal e WSRP .NET Framework di NetUnity.

Dato che WSRP è in cima a SOAP, questo sembra un candidato perfetto per un binding e canale WCF, eppure non vedo nulla sull'argomento, ovunque.

Answer 1

Se leggi attentamente le specifiche WSRP, scoprirai che si tratta di una versione remota delle specifiche del portlet Java (se lo scrivo in modo corretto). Ciò significa che è utile per l'integrazione di portlet Java. Qualsiasi altra cosa dovrà apparire come un portlet Java, che non è molto generico.

Answer 2

WSRP è molto contrarian. Ormai il mondo ha visto che l'accoppiamento stretto tra il modello di dati e il modello di presentazione non è ottimale. Il successo di RSS, REST, MVC e servizi web in generale lo dimostra. Nonostante il nome WS nel nome, WSRP è in contrasto con i principi fondamentali dei servizi Web. Le specifiche WSRP ignorano i solidi consigli per mantenere separati i dati e la presentazione e li accoppiano strettamente.

WSRP promette l'integrazione, a livello di UI. Questo sembra il problema sbagliato da risolvere.

Mi sorprende che questa cosa sia vissuta tanto quanto ha fatto.
Il problema che tenta di risolvere spesso non è il problema che dovrebbe essere risolto .

Answer 3

Penso che la sua popolarità / adozione possa essere dedotta dal fatto che l'ultima versione di NetUnit era " Quest'ultima versione aggiunge il supporto per Visual Studio 2005 e .NET 2.0. "

Answer 4

Dovrei essere d'accordo con Cheeso. L'integrazione dell'interfaccia utente con i dati serve solo agli utenti del portlet e aggiunge un livello elevato, non necessario e rischioso ai produttori di portlet. Il nostro negozio .NET è stato recentemente costretto a considerare WSRP e ho riscontrato mancanza di supporto ed esperienza. Il miglior approccio incentrato sulla SM che ho visto discusso è qui . Ma non ho trovato alcun supporto / implementazione WCF specifico. Tutti i lead sono molto apprezzati!

Answer 5

WSRP è essenzialmente uno standard di servizio Web da portale a portlet. Quali sono i dati primari scambiati tra portale e portlet? È markup e in gran parte perché la maggior parte dei portali utilizza un'interfaccia utente Web. Tutta questa idea che non si tratti di dati puri rispetto all'interfaccia utente è il punto controverso. È pensato per essere un servizio web per il rilevamento di portlet, metadati, markup, interazioni, memorizzazione nella cache, comunicazione da portlet a portlet, ecc. Questo è ciò che fa un portale anche se non WSRP. WSRP è tuttavia uno standard aperto e multipiattaforma.

Che cos'è un portale che integra solo portlet dai propri prodotti e / o piattaforma? Hai PeopleSoft HR basato su Java e vorresti fornire ai tuoi dipendenti l'accesso ai loro portlet da SharePoint? In bocca al lupo. Perché questo non può essere uno scenario realizzabile per la maggior parte dei software aziendali? E sì, mi rendo conto che è l'integrazione relativa all'interfaccia utente. Questo è uno dei motivi principali per cui sto usando un portale. Non è che mi aspetto di integrare PeopleSoft con SharePoint al "puro" livello di dati e in qualche modo una web part di benefici per i dipendenti si apre magicamente in SharePoint pronta per l'uso. Tuttavia, è quello che mi aspetto se l'integrazione da portlet a portlet si basa su WSRP.

WSRP, anche se non perfetto, è una soluzione superiore secondo me. Oltre alla facile integrazione del portlet all'interno di un portale, separa il portale dall'applicazione. Nessuna distribuzione di file binari sul server portale o persino in esecuzione sullo stesso server. Questo ha senso. Non eseguire mai applicazioni sullo stesso server del portal server: nessuno dei due verrà mai aggiornato. Sono giunto alla conclusione che è insano mettere i file binari delle applicazioni sullo stesso server del server portale. " Ti preghiamo di distribuire questa applicazione sul server del portale e far sì che influisca sulla sicurezza, stabilità, prestazioni e tutto il resto e vorrei creare quante più dipendenze possibili e far cadere l'intero server del portale ogni volta che aggiorno l'applicazione " ;. È un incubo di dipendenza. Meglio convincere un paio di consulenti di venditori di portale a tenersi per mano durante l'aggiornamento e di avere qualcuno da incolpare.

È necessario bilanciare il carico di un'intera piattaforma del portale quando viene colpito maggiormente solo un numero selezionato di portlet? I venditori del portale vorrebbero che la pensassi così. Molte volte, il portale non sta facendo altro che attendere che i portlet finiscano l'elaborazione. Con WSRP, hai la flessibilità di caricare portlet di bilanciamento indipendentemente dalla piattaforma del portale. Si suddivide sempre in alcuni portlet più colpiti. Perché non bilanciare il carico solo quei portlet? Pertanto, anziché eseguire inutilmente il bilanciamento del carico del portale su 80 CPU, è possibile bilanciare il carico di quei pochi portlet su 10 CPU. WSRP è anche assolutamente perfetto per il cloud computing.

WSRP è uno standard da portale a portlet. Se si desidera scrivere un portlet che funziona su più portali e potenzialmente su più piattaforme, WSRP lo è. Se si sta valutando in remoto l'integrazione di portlet di terze parti, WSRP lo è. È l'unico standard. Tuttavia, presenta anche alcuni vantaggi significativi rispetto ad altre interfacce da portale a portlet locali proprietarie e dovrebbe essere preso in considerazione anche per tali vantaggi.