W języku WSRP "Consumer" to dla użytkownika końcowego portal, w szczególności ośrodek webowy prezentujący zbiór interaktywnych części lub portletów. Natomiast "Producer" to dostawca portletów.

Dostawca portletów JSR 168 może być adaptowany jako WSRP Producer, a zasobnik portletów JSR 168 (np. serwer portalowy Javy) - jako WSRP Consumer. Tak więc WSRP może być używane do agregacji i rekombinacji zdalnych portletów JSR 168. Lecz nie jest to w żaden sposób powiązane z API Javy, który rządzi interakcjami pomiędzy portletami w serwerach portali Javy. JSR 168, poprzez standaryzację tych interakcji, ma zapewnić, że portlet Javy napisany na WebSphere Portal Server będzie także pracował na serwerach portalowych Oracle, BEA czy Suna.

Z kolei znaczenie WSRP jest szersze. Serwer portalowy Javy może być konsumentem WSRP, ale może być też serwerem SharePoint lub aplikacją napisaną przy użyciu struktury portalowej w ASP.Net 2.0.

WSRP rozszerza rolę web services w dość istotny sposób, ponieważ celem jest umożliwienie aplikacjom, a nie tylko surowym danym i metodom, przepływu przez sieci usług webowych.

Problemy implementacyjne

Portale przedsiębiorstwa są atrakcyjne głównie z powodu użytecznego i elastycznego modelu obejmującego całość procesów i danych w przedsiębiorstwie. Ale ich funkcjonalna atrakcyjność nie powinna przysłaniać krytycznych spraw technicznych związanych z formowaniem planu implementacji portalu.

Bezpieczeństwo i zarządzanie tożsamością. Użytkownicy końcowi i administratorzy powinni być uwierzytelniani, identyfikowani i autoryzowani w kontekście akcji i danych. Dlatego jedna z podstawowych kwestii na etapie planowania portalu brzmi: czy serwer portalowy może być włączony w istniejący system katalogowy (LDAP, Active Directory, eDirectory), czy też wymusi używanie własnych, zintegrowanych komponentów autoryzacji, uwierzytelniania i zarządzania tożsamością? I tak Sun Java System Portal Server wymaga używania do zarządzania bezpieczeństwem i tożsamością wbudowanego Sun Java System Identity Server and Directory Server. Office SharePoint Server Microsoftu zdaje się na ISS w sprawach zarządzania bezpieczeństwem, co w praktyce oznacza używanie do zarządzania tożsamością Active Directory lub usług Passport oraz modelu uprawnień stosowanego w ISS.

Zagadnienia te powinny być starannie rozpatrzone przed wyborem ostatecznego rozwiązania, ponieważ konieczność dopisywania na etapie realizacji różnego rodzaju interfejsów może spowodować znaczne zwiększenie kosztów i co gorsza fragmentację modelu ochrony przedsiębiorstwa.

Interfejsy infrastruktury. Interfejsy są równie ważne jak pozostałe elementy infrastruktury. Mogą one obejmować istniejące już wcześniej systemy zarządzania zawartością, zarządzania własnością intelektualną, zarządzania dokumentami, motory workflow itp. W zależności od stopnia modularności środowiska portalowego może czasami istnieć potrzeba wykonania tradycyjnych (i drogich) prac projektowych w zakresie oprogramowania mających na celu wpasowanie portalu w infrastrukturę IT przedsiębiorstwa.

Implementacja logiki biznesowej. Wiele środowisk portalowych oferuje narzędzia niskiego poziomu do implementacji zintegrowanej logiki biznesowej, takie jak języki skryptowe i wizualne środowiska projektowania. Narzędzia te mają zapewniać szybką implementację (często kosztem architektonicznej spójności i długofalowego utrzymywania portalu) - poprzez dodawanie tej logiki bezpośrednio do komponentów interfejsu użytkownika. Tradycyjne, warstwowe projektowanie aplikacji zakłada, że logika biznesowa powinna być wydzielona i zarządzana w warstwie pośredniej, umożliwiając niezależną ewolucję interfejsów użytkownika. Może więc okazać się konieczne zaniechanie używania narzędzi niskiego poziomu i przejście na tradycyjne metody projektowania oprogramowania na poziomie serwera aplikacyjnego.

Technologia portalowa oparta na standardach. Standardowe formaty zawartości pozwalają na włączanie do portalu zawartości zewnętrznej przy minimalnych kosztach. Należy więc odpowiedzieć sobie na pytanie, czy standardowe API portalowe pozwala na włączanie portletów dostawców niezależnych przy minimalnych kosztach i, w tym kontekście, czy serwer portalowy obsługuje protokół WSRP? Jeżeli środowisko portalowe jest oparte na J2EE, to czy także obsługuje specyfikację JSR 168? Wielu dostawców - m.in. Sun, Oracle, Novell - zaimplementowało obie te specyfikacje w swoich ofertach portalowych, zapewniając zdolność integracji portletów, opracowanych przez innych, w różnorodnych środowiskach. Standardowe protokoły sfederowanej ochrony, takie jak SAML (Security Assertion Markup Language), i powiązanie z nim standardy, obejmujące profile Liberty Alliance i Microsoft Passport, pozwalają na integrowanie rozproszonych ośrodków ochrony i tożsamości w środowisku portalowym. Tak więc istotne jest pytanie, czy wybrany produkt portalowy obsługuje te specyfikacje.