Annak a kérdése, hogy portál keretrendszert használunk-e vagy sem, sokszor felmerül. Néhányan mindent a portál kategóriája alá akarnak venni, míg mások mindenáron elkerülik a portálokat, beleértve a saját monolitikus infrastruktúrájuk kialakításának költségét is.
A portál JSR-168 szerinti definíciója
„A portál egy olyan webes alapú alkalmazás, ami általában személyreszabási lehetőséget, egypontos bejelentkezést (SSO), a különböző forrásokból származó tartalom aggregálását nyújtja, valamint az információs rendszerek prezentációs rétegét valósítja meg.”
Aggregáció
A portál leginkább a tartalom aggregálásáról szól, ami nem hangzik túl nehéz feladatnak. Mindenki használt már sablon mechanizmust, ami végül is a tartalom aggregálása. Ugyanakkor az ilyen naiv aggregáció használata során is találkozhatunk néhány problémával.
Az aggregált alkalmazásokat ugyanazzal a technológiával kell fejleszteni. Így a JSF portál csak JSF alkalmazásokat aggregálna, a Struts portál csak Struts alkalmazásokat stb.
A portálok több modularitást nyújtanak az architektúra számára, mivel együtt használhatunk több, különböző technológiával tervezett alkalmazást: például megvásárolunk egy portletet (egy webes alkalmazást), ami Struts technológiával készült, megcsináljuk a sajátunkat JSF-fel, rábukkanunk egy portletre, ami szokványos JSP-t használ és egy portlet API-t a partnerünktől, és mindezt ugyanazon a portálon alkalmazhatjuk, és arra is lehetőség nyílik, hogy mind ugyanazon az oldalon legyen. Adjunk WSRP-t mindezekhez, és akkor más portál gyártó által, vagy más szerveren létrehozott tartalmat is tudunk aggregálni. A vállalati alkalmazások világában nemsokára többféle technológiával kell szembenéznünk, és a régi alkalmazások újraírásának költsége – azért, hogy használhatók legyenek az újonnan fejlesztett komponensekkel együtt – a legtöbb esetben nagyon magas lenne.
Több portlet vizuális állapotának kezelése egy portál oldalon nem egy triviális feladat és a portálokat arra tervezték, hogy hatékonyan és megfelelő módon aggregálják több alkalmazás megjelenését ugyanazon az oldalon.
WSRP
A távoli portletek webszolgáltatásait gyakran használják nagy vállalatok, hogy a felelősséget transzparensen megosszák a végfelhasználóval.
Példaként, egy torontói iroda a humán erőforrással kapcsolatos portletekért felel, és saját szerverekkel rendelkezik, egy párizsi iroda a könyvelői portletekért felel, és egy harmadik fél szerverének kliense, ami Sydney-ben található, és ami tőzsdei és időjárás portleteket nyújtj egy olyan platformon, ami egy másik gyártótól származik.
Végfelhasználóként transzparensen megoszthatnánk az oldalunkat egy Torontóból jövő portlettel, egy másikkal Párizsból, és kettő másikkal Syndey-ből, ha a Sydney-i szerver nem működne, még mindig hozzáférnénk a másik két portlethez, és a humánpolitikai portleten tudnánk szabadságért folyamodni, habár egy másik portlettel kellene az időjárás előrejelzést megnéznünk a vakációnkhoz.
A folyamatosan fejlődő portálok előnyei
Amíg az alkalmazás üzleti részére tudunk koncentrálni, addig az a portál keretrendszer is fejlődik, amin dolgozunk. Nem találhatunk olyan portál gyártót, aki hajlandó lenne a JSR-168 és a rákövetkező JSR-286 támogatását abbahagyni, mialatt ezek folyamatosan fejlődnek.
Ha pontosan ragaszkodunk a specifikációhoz (ez nem könnyű, mivel a JSR-168-ból hiányzik néhány fontos jellemző, mint például a hírhedt, portletek közötti kommunikáció) nemcsak a portálgyártók között tudunk majd váltani, hanem, amennyiben egy gyártóhoz ragaszkodunk, élvezhetjük a portál új jellemzőit. Például amíg valaki azon dolgozik, hogy az üzletének portált nyújtson, addig a JBoss portál csapata a drag and drop ablakokon és a részleges ablak frissítéseken dolgozik.
Szeparáció és felelősség
Amíg egy csapat a portletek tervezésével foglalkozik, addig egy másik csapat magán a portálon dolgozhat, a portál keretrendszert a saját szükségeleteikre szabva.
Mialatt az első csapat az üzleti portleten dolgozik, megbizonyosodik arról, hogy a specifikus portletek minden akcióját és renderelési eljárását implementálja.
A második csapat azt biztosítja, hogy a portál jól integrálódjon a személyazonosság menedzserrel, illetve az oldal navigációja az elvárt módon legyen megtervezve, valamint a portletek, oldalak, portálok úgy legyenek biztonságilag beállítva, ahogy azt ők kívánják.
A JSR-168 a CSS stíluslapok használatát is meghatározza, így egy harmadik csoport – függetlenül– a grafikus megjelenésen is dolgozhat.