C#/.NET의 원격 포틀릿 용 웹 서비스 - 옵션?

Question

저는 최근에 새로운 개념, 즉 Web Services for Remote Portlets 또는 WSRP로 마음을 확장 시켰습니다. 나는 우리가 직장에서 구입을 고려하고있는 자바 기반 웹 포털에 대한 프리젠 테이션에서 그것을 배웠다. 우리는 .NET 상점이고 WSRP는 우리가이 포털을 확장 할 수있는 수단이 될 것입니다.

제품 구매 여부에 대한 최종 결정을 제어 할 수는 없지만 WSRP 준수 포틀릿을 작성하는 것이 얼마나 어려운지에 대한 정보를 제공 할 수 있습니다. 불행히도, 주제에 대한 나의 최근의 질문은 거의 알려지지 않았다.

그래서 SO 커뮤니티에서 다음과 같은 질문을 던집니다. C#/.NET에서 WSRP 호환 포틀릿을 작성하기위한 라이브러리 또는 프레임 워크는 무엇입니까? 일반적으로 WSRP를 사용하는 장단점은 무엇입니까?

여기에 정답이 없으므로 커뮤니티 위키에 올리겠습니다. 마이크로 소프트

• WSRP Toolkit for Sharepoint (그러나 셰어을 필요로) :
  지금까지, 나는 단지 다음과 같은 발견했다.
• WSRP Portal and WSRP .NET Framework NetUnity로 작성.

WSRP가 SOAP 위에 있다는 점을 감안할 때 WCF 바인딩 및 채널을위한 완벽한 후보인 것처럼 보이지만 아직 주제에 대해서는 아무 것도 볼 수 없습니다.

Answer 1

WSRP 사양을주의 깊게 읽는다면, Java Portlet Specification의 원격 버전임을 알 수 있습니다 (필자의 철자가 맞다면). 즉, Java 포틀릿을 통합하는 데 유용합니다. 다른 것은 Java 포틀릿처럼 보일 것입니다. Java 포틀릿은 매우 일반적이지 않습니다.

Answer 2

NetUnit의 최신 릴리스는 "이 최신 릴리스는 Visual Studio 2005 및 .NET 2.0에 대한 지원을 추가했습니다."라고해서 인기/채택을 추측 할 수 있다고 생각합니다.

Answer 3

WSRP는 매우 반대입니다. 지금까지 세계는 데이터 모델과 프리젠 테이션 모델 간의 긴밀한 결합이 차선 적이라는 것을 알게되었습니다. RSS, REST, MVC 및 웹 서비스의 성공은 일반적으로이를 보여줍니다. WSRP라는 이름에도 불구하고 WSRP는 웹 서비스의 핵심 원칙에 위배됩니다. WSRP 사양은 데이터와 프레젠테이션을 별도로 유지하는 건전한 조언을 무시하고 엄격하게 결합합니다.

WSRP는 UI 수준에서 통합을 약속합니다. 이것은 해결해야 할 잘못된 문제처럼 보입니다.

그것은이 물건이 가지고있는만큼 오래 살았다는 것을 당황하게합니다.
해결하려고 시도하는 문제는 종종 이이어야한다는 문제가 아닙니다.

Answer 4

나는 Cheeso와 동의해야 할 것입니다. UI와 데이터를 통합하는 것은 포틀릿 소비자에게만 서비스를 제공하고 크고 불필요한 위험한 계층을 포틀릿 제작자에게 추가합니다. 우리의 .NET 상점은 최근에 이었고 WSRP를 고려하기 위해을 사용했으며 지원과 경험이 부족합니다. 제가 토론 한 최고의 MS 중심 접근법은 here입니다. 그러나 특정 WCF 구현/지원을 찾지 못했습니다. 모든 리드 크게 감사!

Answer 5

WSRP는 본질적으로 포털 - 포틀릿 웹 서비스 표준입니다. 포털과 포틀릿간에 교환되는 기본 데이터는 무엇입니까? 이것은 대부분의 포털이 웹 UI를 사용하기 때문에 마크 업입니다. 순수한 데이터 대 UI가 아니라는 전체적인 생각은 논점입니다.이는 포틀릿 검색, 메타 데이터, 마크 업, 상호 작용, 캐싱, 포틀릿 간 포틀릿 통신 등을위한 웹 서비스를 의미합니다. WSRP가 아니더라도 포털이 수행하는 기능입니다. WSRP는 개방형 크로스 플랫폼 표준입니다.

자체 제품 및/또는 플랫폼의 포틀릿 만 통합하는 포털은 무엇입니까? Java 기반 PeopleSoft HR을 얻었으며 SharePoint에서 직원까지 포틀릿에 대한 액세스를 제공하고 싶습니까? 행운을 빕니다. 왜 이것이 대부분의 엔터프라이즈 소프트웨어에서 달성 가능한 시나리오가 될 수 있습니까? 그리고 네, UI와 관련된 통합이라고 생각합니다. 그것이 내가 포털을 사용하는 주된 이유 중 하나입니다. PeopleSoft가 SharePoint와 "순수한"데이터 수준으로 통합 될 것으로 기대하고있는 것처럼 아니며, 어떻게 든 Employee Benefits Web Part가 마술처럼 SharePoint에서 사용할 준비가되었습니다. 그러나 포틀릿과 포틀릿 간의 통합이 WSRP를 기반으로하는 경우 이것이 예상됩니다.

WSRP는 완벽하지는 않지만 내 의견으로는 훌륭한 솔루션입니다. 포털 내에 포틀릿을 쉽게 통합 할 수있을뿐 아니라 포털과 애플리케이션을 분리 할 수 ​​있습니다. 포털 서버에 바이너리를 배포하거나 동일한 서버에서 실행하지 않습니다. 이것은 의미가 있습니다. 포털 서버와 같은 서버에서 응용 프로그램을 실행하지 마십시오. 둘 다 업그레이드되지 않습니다. 응용 프로그램 바이너리를 포털 서버와 동일한 서버에 두는 것이 미친다고 결론을 내 렸습니다. "이 응용 프로그램을 포털 서버에 배포하고 그 사이에 보안, 안정성, 성능 및 모든 것에 영향을 미치고 가능하면 많은 종속성을 만들고 응용 프로그램을 업그레이드 할 때마다 전체 포털 서버를 종료하십시오." 그것은 의존성의 악몽입니다. 업그레이드 할 때 손을 잡고 다른 사람을 비난하게하는 데 필요한 몇 가지 포털 공급 업체 컨설턴트를 얻는 것이 좋습니다.

선택한 포틀릿 만 가장 많이 사용하는 경우 전체 포털 플랫폼의로드 균형을 조정해야합니까? 포털 공급 업체는 귀하가 그렇게 생각하기를 바랍니다. 많은 경우, 포털은 포틀릿에서 처리를 마치기를 기다리는 것 이상의 일을하지 않습니다. WSRP를 사용하면 포털 플랫폼과 독립적으로 포틀릿의로드 균형을 조정할 수 있습니다. 항상 가장 많은 공격을받는 몇 개의 포틀릿으로 나뉩니다. 왜 그 포틀릿 만로드 밸런싱하지 않습니까? 따라서 불필요하게 80 CPU에서 포털로드를로드하는 대신 10 개의 CPU에서 소수의 포틀릿을로드 밸런싱 할 수 있습니다. WSRP는 또한 클라우드 컴퓨팅에 절대적으로 적합합니다.

WSRP는 포털 - 포틀릿 표준입니다. 여러 포털 및 잠재적으로 여러 플랫폼에서 작동하는 포틀릿을 작성하려면 WSRP가 필요합니다. 타사 포틀릿을 통합하는 것을 원격으로 고려하고 있다면 WSRP가됩니다. 그것은 유일한 표준입니다. 그러나 다른 독점적 인 로컬 포털 - 포틀릿 인터페이스보다 몇 가지 중요한 이점이 있으며 이러한 이점을 고려해야합니다.