C# / .NET의 원격 포틀릿 용 웹 서비스 - 옵션?
https://stackoverflow.com/questions/640560
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
나는 최근에 새로운 개념으로 내 마음을 확장했습니다. 원격 포틀릿을위한 웹 서비스, 또는 WSRP. 나는 직장에서 구매를 고려하고있는 Java 기반 웹 포털에서 프레젠테이션 중에 그것을 배웠습니다. 우리는 .NET 상점이며 WSRP는이 포털을 확장 할 수단이 될 것입니다.
제품 구매 여부에 대한 최종 결정을 통제 할 수는 없지만 WSRP 호환 포틀릿을 구축하는 것이 얼마나 어려운지에 대한 입력을 제공 할 수 있습니다. 불행히도, 최근 주제에 대한 나의 최근 질문은 거의 멍청 해졌다.
그래서 나는 당신에게 SO 커뮤니티, 다음을 묻습니다. c#/. net에 WSRP 호환 포틀릿을 구축하기 위해 어떤 라이브러리 또는 프레임 워크가 있습니까? 일반적으로 WSRP를 사용하는 장단점은 무엇입니까?
여기에는 정답이 없기 때문에 커뮤니티 위키 게시물로 만들 것입니다.
지금까지 나는 다음을 발견했다.
- SharePoint 용 WSRP 툴킷 Microsoft에 의해 (그러나 SharePoint가 필요).
- WSRP 포털 및 WSRP .NET 프레임 워크 Netunity에 의해.
WSRP가 비누 위에 있다는 점을 감안할 때, 이것은 WCF 바인딩 및 채널의 완벽한 후보처럼 보이지만 어디서나 주제에 대해서는 아무것도 보이지 않습니다.
해결책
WSRP 사양을주의 깊게 읽으면 Java Portlet 사양의 원격 버전입니다 (해당 권리를 철자하는 경우). 즉, Java 포틀릿을 통합하는 데 유용하다는 것을 의미합니다. 다른 것은 Java 포틀릿처럼 보일 것입니다.
다른 팁
WSRP는 매우 반대입니다. 이제 세계는 데이터 모델과 프레젠테이션 모델 사이의 단단한 결합이 차선책이라는 것을 보았습니다. RSS, REST, MVC 및 웹 서비스의 성공은 일반적으로이를 보여줍니다. 이름의 WS에도 불구하고 WSRP는 웹 서비스의 핵심 원칙에 위배됩니다. WSRP 사양은 데이터와 프리젠 테이션을 별도로 유지하기위한 사운드 조언을 무시하고 단단히 연결합니다.
WSRP는 UI 수준에서 통합을 약속합니다. 이것은 해결해야 할 잘못된 문제처럼 보입니다.
이 것이 오랫동안 살았다는 것은 저를 당황하게합니다.
해결하려는 문제는 종종 문제가 아닙니다. 해야한다 해결되었습니다.
Netunit의 마지막 릴리스가 "이 최신 릴리스는 Visual Studio 2005 및 .NET 2.0에 대한 지원을 추가한다"는 사실로 인기 / 채택이 추론 될 수 있다고 생각합니다.
치즈에 동의해야 할 것입니다. UI를 데이터와 통합하면 포틀릿 소비자 만 제공하며 포틀릿 생산자에게 크고 불필요한 위험한 계층을 추가합니다. 우리의 .NET 상점은 최근에있었습니다 강요된 WSRP를 고려하고 지원과 경험이 부족하다는 것을 알았습니다. 내가 논의한 최고의 MS 중심 접근법은 다음과 같습니다 여기. 그러나 특정 WCF 구현/지원을 찾지 못했습니다. 모든 리드가 크게 감사합니다!
WSRP는 본질적으로 포털 투 포트 웹 서비스 표준입니다. 포털과 포틀릿간에 교환 된 기본 데이터는 무엇입니까? 대부분의 포털이 웹 UI를 사용하기 때문에 마크 업이며 주로 마크 업입니다. 순수한 데이터와 UI가 아니라는이 전체 아이디어는 무의미합니다. 포틀릿 검색, 메타 데이터, 마크 업, 상호 작용, 캐싱, 포트 투 포트 커뮤니케이션 등을위한 웹 서비스가되어야합니다. 이것이 바로 WSRP가 아니더라도 포털이하는 일입니다. 그러나 WSRP는 개방형 크로스 플랫폼 표준입니다.
자체 제품 및/또는 플랫폼에서 포틀릿 만 통합하는 포털은 무엇입니까? Java 기반 PeopleSoft HR을 받았으며 SharePoint에서 직원에게 포틀릿에 대한 액세스를 제공하고 싶습니까? 행운을 빕니다. 왜 이것이 대부분의 엔터프라이즈 소프트웨어에서 달성 가능한 시나리오가 될 수 없습니까? 그렇습니다. UI와 관련된 통합이라는 것을 알고 있습니다. 이것이 제가 포털을 사용하는 주된 이유 중 하나입니다. "순수한"데이터 수준에서 PeopleSoft가 SharePoint와 통합 될 것으로 기대하는 것은 아니며, 직원이 웹 파트가 SharePoint에서 마술처럼 팝업되는 혜택을받을 준비가되었습니다. 그러나 이것이 포트-포트 틀트 통합이 WSRP를 기반으로한다면 내가 기대하는 것입니다.
WSRP는 완벽하지는 않지만 제 생각에는 우수한 솔루션입니다. 포털 내에서 포틀릿을 쉽게 통합하는 것 외에도 포털을 응용 프로그램과 분리합니다. 바이너리를 포털 서버에 배포하거나 동일한 서버에서 실행되지 않습니다. 이것은 의미가 있습니다. 포털 서버와 동일한 서버에서 응용 프로그램을 실행하지 마십시오. 업그레이드되지 않습니다. 나는 포털 서버와 동일한 서버에 응용 프로그램 바이너리를 배치하는 것이 미쳤다는 결론에 도달했습니다. "이 애플리케이션을 포털 서버에 배포하고 보안, 안정성, 성능 및 그 사이의 모든 것에 영향을 미치며 가능한 한 많은 종속성을 생성하고 응용 프로그램을 업그레이드 할 때마다 전체 포털을 중단하고 싶습니다." 의존성 악몽입니다. 포털 공급 업체 컨설턴트 몇 명을 업그레이드 할 때 손을 잡고 누군가를 비난 할 수 있도록하는 것이 좋습니다.
선택된 수의 포틀릿 만 가장 많이 쳤을 때 전체 포털 플랫폼의 균형을로드해야합니까? 포털 공급 업체는 당신이 그렇게 생각하기를 원합니다. 많은 시간 동안 포털은 포틀릿을 기다리는 것 이상으로 처리를 완료하기 위해 아무것도하지 않습니다. WSRP를 사용하면 포털 플랫폼과 독립적으로 균형 포틀릿을로드 할 수있는 유연성이 있습니다. 그것은 항상 가장 많이 쳤던 몇 개의 포틀로 분해됩니다. 포틀릿 만로드하지 않겠습니까? 따라서 80 CPU의 포털을 불필요하게로드 밸런싱하는 대신 10 CPU의 포틀릿을 균형 잡을 수 있습니다. WSRP는 또한 클라우드 컴퓨팅에 완벽합니다.
WSRP는 포털 투 포트 레틀 표준입니다. 여러 포털과 잠재적으로 플랫폼에서 작동하는 포틀릿을 작성하려면 WSRP입니다. 제 3 자 포틀릿 통합을 원격으로 고려하고 있다면 WSRP가 있습니다. 유일한 표준입니다. 그러나 다른 독점적 인 로컬 포털-포트 틀 인터페이스에 비해 상당한 이점이 있으며 이러한 혜택에 대해서도 고려해야합니다.
