Web Services for Remote Portlets em C # / .NET - opções?

Question

Recentemente, tive minha mente expandida por um novo conceito: Web Services para portlets remotos , ou WSRP. Eu aprendi isso durante uma apresentação em um portal web baseado em Java que está considerando comprar no trabalho; somos uma loja de .NET e WSRP seria o meio pelo qual nós estender este portal.

Embora eu não possa controlar a decisão final sobre se vamos ou não comprar o produto, posso fornecer entrada como para o quão difícil seria a construção de portlets WSRP-compliant. Infelizmente, minhas recentes consultas sobre o assunto apareceram quase nula.

Então eu lhe pergunto, a comunidade isso, a seguinte: o que as bibliotecas ou os quadros estão lá fora, para a construção de portlets WSRP conforme em C # / NET.? Quais são alguns dos prós e contras do uso de WSRP em geral?

Porque não há resposta correta aqui, vou fazer isso um post wiki comunidade.

Até agora, eu só encontrei o seguinte:

• WSRP Toolkit para Sharepoint pela Microsoft (mas exigindo Sharepoint).
• WSRP Portal e WSRP .NET Framework por NetUnity.

Dado que WSRP está no topo da SOAP, este parece ser um candidato perfeito para uma ligação WCF e canal, e ainda assim não vejo nada sobre o assunto, em qualquer lugar.

Answer 1

Se você ler a especificação WSRP com cuidado, você vai encontrá-lo é uma versão remota do Java Portlet Specification (se ESTOU soletração que à direita). Isso significa que é útil para integrar Java Portlets. Qualquer outra coisa que terá que olhar como um Java Portlet, que não é muito genérico.

Answer 2

WSRP é muito contrária. Até agora o mundo tem visto que o acoplamento apertado entre o modelo de dados eo modelo de apresentação é abaixo do ideal. O sucesso de RSS, REST, MVC, e serviços web em geral mostra isso. Apesar do WS no nome, WSRP está contra os princípios fundamentais de serviços da Web. A especificação WSRP ignora o conselho de som para manter os dados e apresentação separar, e os casais-los firmemente.

promessas WSRP integração, ao nível da interface do usuário. Este parece ser o problema errado estar resolvendo.

Confunde-me que esta coisa tem vivido, desde que ele tem.
O problema que tenta resolver muitas vezes não é o problema que deve ser resolvido.

Answer 3

Eu acho que sua popularidade / adoção pode ser inferido pelo fato de que a última versão de NetUnit era "Esta última versão adiciona suporte para Visual Studio 2005 e .NET 2.0."

Answer 4

Eu teria que concordar com Cheeso. Integrando a interface do usuário com os dados só serve os consumidores de portlets e adiciona um grande, camada desnecessária, arriscada para produtores de portlets. Nossa loja .NET foi recentemente forçada para considerar WSRP e eu encontrei uma falta de apoio e experiência. Os melhores MS-centric abordagem que tenho visto discutidos é aqui . Mas eu não encontrei nenhuma implementação específica WCF / support. Alguma pista muito apreciada!

Answer 5

WSRP é essencialmente um padrão de serviço web portal-a-portlet. O que é os dados primários trocados entre portal e portlet? É marcação e, em grande parte porque a maioria dos portais de usar uma interface web. Essa idéia toda de que não é de dados puro contra UI é ponto discutível. Era para ser um serviço web para a descoberta portlet, meta dados, marcação, interações, caching, comunicação portlet-to-portlet, etc. Isso é o que um portal faz mesmo se não WSRP. WSRP, porém, é um padrão de plataforma aberta, cruz.

O que é um portal que só integra portlets a partir de seus próprios produtos e / ou plataforma? Got Java baseado em PeopleSoft HR e gostaria de fornecer acesso a seus portlets do SharePoint para seus funcionários? Boa sorte. Por que isso não pode ser um cenário possível para a maioria dos softwares da empresa? E sim, eu percebo que é a integração relacionada à UI. Esse é um dos a principal razão por que eu estou usando um portal. Não é como eu estou esperando para começar PeopleSoft integrada com o SharePoint no nível dos dados "puros" e de alguma forma um Employee Benefits Web Part magicamente aparece no SharePoint pronto para uso. No entanto, isso é o que eu espero se a integração portlet-to-portlet é baseado em WSRP.

WSRP, embora não seja perfeito, é uma solução superior em minha opinião. Além de fácil integração de portlet em um portal, ele separa o portal da aplicação. Sem a implantação de binários para o servidor de portal ou mesmo em execução no mesmo servidor. Isso faz sentido. aplicações no mesmo servidor que o servidor portal Nunca execute: nem sempre será atualizado. Eu vim à conclusão de que é insano para colocar binários de aplicativos no mesmo servidor como o servidor de portal. "Por favor, implantar esse aplicativo para o servidor de portal e tê-lo afetam a segurança, estabilidade, performance, e tudo entre e gostaria criar quantas dependências quanto possível e derrubar toda a Sever portal sempre que eu atualizar o aplicativo". É um pesadelo dependência. Melhor pegar um par de consultores fornecedores portal de mãos dadas com quando modernização e ter alguém para culpar.

Você precisa de equilíbrio de carga de uma plataforma portal inteiro quando apenas um número seleto de portlets são atingidos mais? fornecedores portal gostaria que você pense assim. Uma grande parte do tempo, o portal está fazendo nada mais do que à espera de portlets para processamento de acabamento. Com WSRP, você tem a flexibilidade de balanceamento de carga portlets de forma independente da plataforma de portal. Ele sempre quebra para baixo a alguns portlets que são atingidas o mais. Por que não balanceamento de carga apenas os portlets? Então, ao invés de carga desnecessariamente equilibrar o portal em 80 CPU, você pode balancear esses poucos portlets em 10 CPUs. WSRP também é absolutamente perfeito para a computação em nuvem.

WSRP é um padrão de portal-a-portlet. Se você quer escrever um portlet que funciona em vários portais e potencialmente entre plataformas, WSRP é isso. Se você está contemplando remotamente integrando portlets de terceiros, WSRP é isso. É o único padrão. No entanto, também tem algumas vantagens significativas sobre outras interfaces locais proprietários portal-a-portlet e deve ser considerado para aqueles benefícios também.