Portalurile, indiferent de tipul acestora, au īn esenta aceleasi functionalitati, variatia perceputa īntre diferitele tipuri fiind doar de suprafata. Desi continutul, structura si prezentarea portalurilor poate sa varieze īn mod drastic, īn functie de design si de necesitati, infrastructura si mecanismele portalurilor sunt aceleasi pentru un portal la nivel de organizatie, pentru un Internet call center, un portal intranet de tip b2b, un portal extranet sau un portal de tip self-service.
Īn comparatie cu paginile de web statice 151g64b , portalurile trebuie sa ofere functii de baza cum ar fi agregare, personalizare, cautare, colaborare si securitate. Nivelul exact al functionalitatii acestor servicii de baza necesare pentru un anumit portal poate varia īn functie de tipul portalului, mai ales cānd este vorba de securitate, autentificare, colaborare sau personalizare. Un portal intranet sau extranet poate necesita mai multa securitate si personalizare decāt un portal de tip self-service care ofera informatii publice. Pe de alta parte, un portal self-service, care gestioneaza date financiare personale si permite persoanelor sa-si plateasca facturile prin intermediul lui, poate necesita la fel de multa personalizate si securitate ca si un portal intranet utilizat doar de angajati.
Ceea ce subliniem aici este faptul ca portalurile vor oferi īntotdeauna functionalitati unificate, unitare, indiferent care este numele acestora. De asemenea, este importat de apreciat aceasta unitate, deoarece portalurile corporative, mai ales cele de noua generatie bazate pe XML si pe servicii Web, vor īncepe sa consolideze diferite tipuri de portaluri īntr-o singura entitate unificata, pe baza personalizarii bazate pe autentificare.
Functiile cu valoare adaugata asociate cu un anumit portal pot avea aplicabilitate mai larga, indiferent de tipul de portal. Spre exemplu, functionalitatea familiara de tip "shopping-cart" oferita de site-urile de comert electronic, īn acceptiunea clasica, ar putea fi restrictionata la portalurile de comert electronic de tip b2c sau portaluri de afaceri de tip b2b.
Figura : Cosul de cumparaturi (shopping cart).
De obicei persoanele nu asociaza aceasta functionalitate cu un portal intranet, utilizat numai de angajati. Īn acest tip de portal, managementul si administrarea asigurarilor angajatilor este una din cele mai populare si productive aplicatii. Orice companie cu mai mult de 250 angajati care mentine un portal intranet poate sa ofere angajatilor optiuni diferite īn ceea ce priveste tipurile de asigurare oferite angajatilor (scheme de asigurare, asigurare stomatologica sau de sanatate). Angajatii aleg aceste tipuri de asigurari prin intermediul cosului de cumparaturi, la fel ca si alegerea produselor dintr-un site de comert electronic.
Acceptarea si procesarea cartilor de credit este o alta functionalitate care este īn mod normal asociata cu site-urile de comert electronic. Din ce īn ce mai multe organizatii īncurajeaza angajatii sa achizitioneze produse cu sigla companiei sau chiar produse ale companiei prin intermediul portalului intern, unele companii oferind chiar discount-uri sau promotii speciale. Aceasta facilitate interna este īn cele din urma oferita angajatilor pe baza operatiunilor de comert electronic, chiar daca functioneaza īntr-un portal de tip business-to-employee.
Cele de mai sus īncearca sa demonstreze faptul ca linia care demarca portalurile pe baza functionalitatii īncepe sa se estompeze, portalurile devenind multifunctionale si multiscop. Noua generatie de portaluri la nivel de organizatie va deveni centrul acestor portaluri totul-īn-unul, astfel īncāt, īn loc sa se mentina portaluri separate, cu continut si functionalitati duplicat pentru diferite comunitati de utilizatori (parteneri, clienti, investitori etc.) se pot reduce costurile si complexitatea prin crearea unui singur portal consolidat, dar totusi partitionat. Īn cele din urma conteaza ca pentru o companie nu exista imperative tehnice sau de implementare īn ceea ce priveste mentinerea mai multor tipuri de portalului. Tehnologiile care si-au dovedit stabilitatea, sub forma cadrelor de lucru de tip portal ale IBM, SAP, BEA, Oracle, Plumtree sau Microsoft, ca sa enumeram numai cāteva, sunt disponibile pentru construirea de portaluri atāt pentru comunitati Internet de utilizatori, cāt si pentru cele externe.
Cea mai mare problema care apare īn diferentierea tipurilor de portaluri provine din definitii si perceptii diferite asupra acestora. Pentru a evita aceste confuzii, cel mai sigur drum pe care-l putem urma este de a defini tipurile de portal diferite pe masura ce īnaintam īn explicatii. Astfel, cea mai semnificativa distinctie este īntre portaluri publice si portaluri interne sau portaluri publice si la nivel de organizatie.
Īn cazul īn care utilizatorul are o experienta semnificativa cu site-urile Internet de tip Yahoo!, MSN sau AOL, aceste site-uri pot fi considerate portaluri publice. Portalurile publice sunt echivalentul bibliotecilor publice, īn care oricine poate veni si viziona datele pe ecran. Īn zilele noastre toate aceste portaluri publice mari ofera, continut si servicii personalizate membrilor sau utilizatorilor īnregistrati, pentru a promova loialitatea utilizatorilor.
Spre deosebire de portalurile publice, deschise tuturor utilizatorilor, exista si portaluri intranet, adica portaluri ale organizatiilor cu interfata de tip web, care sunt accesibile publicului larg. Dupa acest criteriu, portalul FedEx.com, de exemplu, este un portal public.
Figura : Portalul public "my.yahoo.com".
Aceasta caracterizare este totusi logica, iar pentru rezolvarea problemei īn privinta definitiei portalurilor la nivel de organizatie, aceasta poate fi extinsa conform figurii urmatoare. Figura defineste taxonomia de baza īn ceea ce priveste portalurile si scoate īn evidenta diferentele dintre portaluri Internet si portaluri la nivel de organizatie cu interfete externe.
Īntre portalurile publice si cele la nivel de organizatie, dar care sunt accesibile din Internet, exista o demarcatie semnificativa, īn functie de tipul de model de afacere. Astfel, īn cazul unui portal precum Yahoo!, afacerea principala a organizatiei este portalul īnsusi.
Un portal la nivelul unei organizatii īn sine nu este scopul principal al organizatiei respective, indiferent ca acesta este accesibil publicului larg sau nu. Portalul FedEx.com, īn ciuda popularitatii sale, nu este partea principala din spatele FedEx. Acelasi lucru este valabil si pentru Amazon.com: chiar daca prezenta sa pe web este realizata prin intermediul unui portal de comert electronic cu o multime de legaturi de publicitate, partea principala a afacerii este vānzarea de carti, electronice sau altele. Pe de alta parte, afacerea principala a Yahoo! sau Excite este a vinde publicitate, sindicalizare si afiliere la portalurile respective.
Pentru diferentierea portalurilor Internet publice de cele la nivelul organizatiilor, pot fi aplicate si alte criterii. Astfel, portalurile la nivel de organizatie sunt specifice organizatiei respective si evolueaza īn jurul organizatiei pe care o reprezinta. Misiunea principala a unui portal corporativ care este deschis catre public este de a promova produsele, serviciile, imaginea si cultura organizatiei respective. Īn contrast, scopul expres al unui portal Internet este de a transmite cāt mai mult continut posibil īn vederea atragerii si retinerii unui numar cāt mai mare de utilizatori web.
Deoarece portalurile Internet publice acopera o asemenea gama larga de subiecte si servicii de interes general, acestea mai sunt denumite si portaluri orizontale. Prin aceasta definitie, portalurile corporative devenind portaluri verticale sau vortaluri, deoarece scopul este īngustat si restrictionat de scopul specific al afacerii. Cu toate acestea, definitiile de tip orizontal-vs.-vertical nu sunt la fel de clare ca si cele care fac demarcarea īntre portalurile publice si cele private. Motivul este acela ca exista anumite portaluri Internet publice care au ca tinta numite constituente. iVillage.com, un portal de succes destinat femeilor, poate fi un bun exemplu īn acest scop. iVillage este considerat de catre unele persoane ca fiind un portal vertical, date fiind adāncimea si gama larga de continut, ne mai luānd īn consideratie si modelul de afaceri. Alte persoane pot sa īl considere si portal orizontal, īn ciuda specializarii īnguste a continutului.
Figura urmatoare este bazata pe imaginea de mai sus, pentru a introduce conceptele de portal vertical si portal orizontal. Alte exemple de portaluri verticale pot fi considerate guru.com, cars.com, boats.com etc.
Figura : portaluri verticale si orizontale
Astazi exista o multime de portaluri al caror scop pe termen mediu si lung este consolidarea, precum am mentionat si mai sus. Aceasta diversitate de tehnologii reflecta īn esenta evolutia tehnologica cu adoptarea cu grija a tehnologiei. Principala problema a portalurilor corporative a fost accesul public prin Internet. Deci, primele doua generatii de portaluri la nivel de organizatii, din intervalul de timp 1995-1999, au fost portaluri intranet care puteau fi utilizate doar de catre angajati. Portalurile intranet de astazi pot fi caracterizate ca portaluri business-to-employee, acest termen cāstigānd teren dupa larga raspāndire a unor termeni precum business-to-business sau business-to-consumer.
Restrictionarea portalurilor corporative la utilizatorii interni si, posibil, la anumiti parteneri selectati, avea sens īn zilele de īnceput ale acestei tehnologii. Mai mult, aceasta era si perioada īn care intraneturile, īn general, erau la mare moda, iar corporatiile au adoptat rapid retelele locale bazate pe IP. Deoarece portalurile intranet dominau cultura organizationala, aceste portaluri au fost numite īn mod natural portaluri de īntreprindere sau portaluri corporative.
Prima generatie de portaluri intranet s-a concentrat pe asigurarea conectivitatii universale īn organizatie si pe oferirea accesului la continutul web din ce īn cel mai bogat. Functionalitatea tranzactionala era initial limitata la operatii simple, precum cautarea īn agende de telefon sau transmiterea cererilor pentru concedii. Mai apoi, au fost descoperite potentialul portalurile īn ceea ce priveste functiile legate de resurse umane sau administrative.
Nu a trecut mult timp pāna ce portalurile au devenit baza pontajului electronic de mare acuratete, administrarea asigurarilor angajatilor, completarea rapoartelor, publicarea de locuri de munca īn interiorul organizatiei, monitorizarea si aplicatii de gestiunea a resurselor. Īn cazul companiilor hi-tech care au oferit optiuni de stocuri sau actiuni angajatilor, o alta aplicatie larg utilizata a fost aplicatia de management si schimb a actiunilor sau hārtiilor de valoare emise de catre companie prin intermediul portalului. De asemenea, unele companii care s-au bazat pe mainframe-urile IBM sau pe sistemele din seria IBM AS/400 (acum zSeries) pentru gestiunea aplicatiilor, au oferit acces la acele aplicatii prin intermediul portalului intranet cu ajutorul diverselor solutii de tip web-to-host. Solutiile initiale de tip web-to-host, care se bazau īn totalitate pe o solutie de acces prin intermediul browser-ului, s-au dezvoltat initial īn doua varietati:
emulatoare de tip thin-client bazate pe Java sau ActiveX, care puteau fi mentinute pe masina client dupa ce erau initial descarcate de pe serverul web odata cu crearea unei noi versiuni (figura urmatoare);
solutii de tip "zero footprint", prin care nu se instala nici o aplicatie prin intermediul browser-ului, fiind īn totalitate bazate pe HTML. Aceste solutii converteau stream-urile de date de la nivelul terminalelor īn HTML si invers, astfel īncāt utilizatorii portalurilor sa interactioneze īn mod direct cu aplicatiile host direct prin fereastra browser-ului.
Pe lānga cele doua solutii de mai sus, exista astazi si o a treia optiune īn ceea ce priveste accesul la calculatoare mainframe prin intermediul portalurilor. Aceasta este integrarea host-urilor sau integrarea aplicatiilor de īntreprindere (enterprise application integration sau EAI), īn care orientarile de tip thin-client sau zero-footprint sunt īnca utilizate, dar solutia se concentreaza pe reutilizarea logicii aplicatiilor din calculatoarele de tip host īn e-aplicatii sau servicii web.
Cea de-a doua generatie de portaluri business-to-employee, construita pe baza expertizei si asteptarilor din ce īn ce mai mari ale prime generatii, a īnceput sa ofere functii specializate. Cele doua tipuri de portaluri care au cāstigat suprematia acestei perioade sunt portalurilor colaborative si portalurile de tip business intelligence. Tot acum, termenul de "enterprise information portals (EIP)" cāstiga popularitate, fiind conceput sub forma unei umbrele colective pentru aceste doua noi tipuri de portaluri.
Portalurile colaborative sunt specializate īn sprijinirea angajatilor organizatiei īn gasirea, organizarea, partajarea si actualizarea informatiilor, uneori nestructurate, din diverse surse, precum e-mail, documente de birou, foi de calcul tabelar, calendare, specificatii de produs sau informatii de contact.
Figura : Solutie de tip web-to-host folosind OnWeb de la NetManage pentru conversia host-to-HTML, īmpreuna cu plug-in pentru FrontPage.
Instrumentele de colaborare sunt componente integrante ale portalurilor corporative. Astazi, pentru activarea facilitatilor de colaborare, se poate implementa un portal corporativ cu scopuri multiple, īn care instrumentele de colaborare sunt incluse, fiind baza īntregului portal. Aceste instrumente de colaborare nu vor fi folosite numai de angajati ci si de parteneri, colaboratori sau investitori, care vor avea acces selectiv la anumite instrumente, dintre care e-mail-ul devine mediul de comunicare omniprezent.
Scopul portalurilor de tip business intelligence este de a permite managerilor si directorilor organizatiilor īn care sunt implementate sa ia decizii īn timp util, pe baza accesului la cele mai pertinente date existente īn organizatie. Īn consecinta, aceste tipuri de portaluri sunt specializate īn suport pentru o gama larga de tipuri de informatii, bazate pe indexarea continutului, cross-linking si facilitati de cautare īn vederea facilitarii accesului si analizei datelor. Datele de tip business intelligence disponibile īn aceste tipuri de portalului cuprind date financiare analizate deja, performante ale lantului de aprovizionare, rapoarte de vānzari, analize de piata, statistici de productie, starea stocurilor, trenduri ale relatiilor cu clientii sau analize de suport pentru produse. Īn plus, pentru luarea deciziilor si analiza, aceste portaluri cuprind o serie de instrumente de tip business intelligence pentru analiza analitica online (OLAP), generarea rapoartelor si data mining.
Ca si portalurile colaborative, portalurile business intelligence nu vor ramāne portaluri strict specializate, deoarece corporatiile se īndreapta din ce īn ce mai mult spre portaluri cu facilitati XML. Instrumentele de tip business intelligence, ca si instrumentele de colaborare, vor deveni servicii de baza īn aceste portaluri, servicii care vor fi disponibile unei game largi de utilizatori, pe baza de personalizare si drepturi obtinute īn urma autorizarii.
Abilitatea de a converge catre un singur portal, consolidat si orientat catre mai multe scopuri, care sa fie utilizat atāt de utilizatorii interni, cāt si de cei externi organizatiei depinde īn mod evident de capacitatea organizatiei de a mentine o compartimentare stricta īntre comunitatile de utilizatori. Figura urmatoare extinde taxonomia tipurilor de portal dezvoltata mai sus pentru a arata convergenta portalurilor corporative catre un portal partitionat si cu scopuri multiple.
Figura : Trendul catre portaluri corporative consolidate, dar partitionate.
Partitionarea eficienta a portalurilor corporative se realizeaza cel mai bine prin intermediul autentificarii si personalizarii, utilizate īn tandem.
Toate solutiile actuale de tip portal ofera personalizare si functii de securitate, īntre care autentificarea este una din optiunile de securitate. Pe līnga acestea, nume respectate īn securitatea retelelor, precum RSA Security, Tivoli sau CheckPoint, ofera sisteme de autentificare bazate pe politici care pot fi utilizate īmpreuna cu serverele de tip portal. Cele mai multe sisteme de autentificare, mai ales cele create de specialisti īn securitate, ofera mai multe optiuni pentru identificarea si validarea utilizatorilor, printre care enumeram scheme de tip username/parola, certificate digitale la nivel de client sau autentificarea bazata pe jetoane SecurID de la RSA.
Certificatele digitale sunt "documente" oficiale electronice emise de o organizatie sau de catre o entitate care se ocupa special de securitate (VeriSign, Tivole SecureWay Trust Authority etc.), care permit identitatilor indivizilor sau afacerilor sa īndeplineasca tranzactii securizate prin web. Ele sunt īn esenta un īnlocuitor al combinatiei username/parola. Baza certificatelor digitatele este infrastructura de chei publice (PKI), care a devenit rapid standardul acceptat pe Internet pentru securitate si criptare.
La īnceputul anului 2002, autentificarea SecurID de la RSA era deja utilizata de peste 10 milioane utilizatori ai web-ului din īntreaga lume. Aceasta autentificare mai este cunoscuta si sub numele de autentificare cu doi factori, deoarece necesita ca utilizatorul sa se autentifice folosind doi factori unici, unul deasupra celuilalt. Unul din factori ar fi un element cunoscut de utilizator (parola sau PIN, de exemplu), iar celalalt ceva detinut de utilizator. Cardurile ATM, desi nu sunt bazate pe tehnologia SecurID de la RSA, sunt un exemplu de autentificare cu doi factori: PIN-ul este cunoscut de utilizator, iar cardul ATM este cel de-al doilea factor, detinut de utilizator. Īn realitate, RSA ofera si un sistem bazat pe carduri ATM care contin un chip (smart-card-uri), carduri utilizate īntr-un cititor conectat la calculatorul utilizatorului. Desi acest sistem ofera o securitate exceptionala, este complicat si scump, fiind utilizat doar selectiv, pentru pastrarea celor mai importante informatii.
Sistemul SecurID de la RSA functioneaza īn general pe baza unei parole definite de utilizator (factorul cunoscut) si a unui jeton (factorul detinut). Jetonul este un cod sincronizat īn functie de timp, care este generat periodic (la cāteva minute, de obicei) si care īncepe cu un cod unic oferit de RSA. RSA poate determina validitatea unui jeton pe baza codului temporar introdus de utilizator. Un jeton valid dovedeste ca utilizatorul detine factorul pe care ar trebui sa-l detina, acesta devenind echivalentul benzii magnetice de pe un card ATM. Pentru a fi autentificat cu succes, utilizatorul trebuie sa introduca codul actualizat (jetonul, adica) si parola specifica. Jetoanele RSA pot fi generate prin utilizarea unui dispozitiv (figura) oferit de RSA sau a unui software care poate fi rulat pe PC-uri, PDA-uri sau chiar pe telefoane inteligente.
Figura : Dispozitive pentru generarea jetoanelor.
Fiind o extensie normala a schemei de securitate bazata pe parola, utilizatorii pot fi instruiti cu usurinta pentru utilizarea autentificarii cu doi factori. Īn cazul unei scheme care cuprinde o aplicatie pentru generarea jetoanelor, utilizatorii ar putea sa introduca numai parola personala sau PIN-ul, deoarece software-ul de securitate de la nivel de client va genera īn mod automat jetonul, adaugāndu-l la parola introdusa de utilizator si transmitāndu-le catre serverul de securitate, criptate, īn vederea realizarii autentificarii. Īn ciuda simplitatii mecanismului, din punct de vedere al utilizatorului final, autentificarea bazata pe doi factori este o schema mult mai puternica decāt cea bazata pe un singur factor (cea care foloseste doar parola). Companii precum Cisco au implementat deja o astfel de schema īn vederea autentificarii utilizatorilor īn portalul intranet pentru angajati al organizatiei.
Din cele de mai sus reiese faptul ca exista pe piata diverse tehnologii de securitate prin care se poate accesa un portal partitionat īn vederea utilizarii de catre utilizatorii cu privilegii de acces si afilieri diferite. Mai trebuie notat si faptul ca exista posibilitatea utilizarii unui sistem de autentificare īn mai multe trepte, care foloseste mecanisme de autentificare diferite, īn vederea accesului la date sensibile.
Pentru accesul securizat la portalul organizatiei prin intermediul Internet, se pot utiliza si retelele private virtuale, care ofera atāt o securitate deja stabilita cāt si tunnelling de protocoale.
Personalizarea este cealalta tehnica utilizata pentru partitionarea efectiva si creativa a unui portal. Odata ce s-a utilizat autentificarea pentru determinarea fara echivoc a identitatii utilizatorului, personalizarea poate fi utilizata atāt pentru a īmbogati experienta utilizatorului īn portal cāt si pentru a stabili o afinitate cu portalul, continutul si serviciile pe care le ofera. Īn cazul utilizatorilor publici neprivilegiati, care viziteaza ariile publice ale portalului, tehnologia simpla a cookie-urilor poate fi utilizata pentru a identifica utilizatorul la vizite repetate, oferindu-le o experienta semipersonalizata, bazata pe informatiile īnregistrate la vizita anterioara.
Personalizarea nu reprezinta decāt faptul ca utilizatorii au acces la informatii autorizate, servicii si aplicatii care au o relevanta mare pentru acestia. Portalurile publice precum Yahoo! sau Excite au facut din personalizare o arta, cu conditia ca utilizatorii sa activeze optiunile sau pe baza preferintei acestora. Tehnologia cookie-urilor este utilizata pentru a identifica utilizatorii si, īn unele cazuri, pentru a mentine preferintele acestora.
si unele portaluri de comert electronic, precum Amazon.com, exceleaza īn personalizare; personalizarea de la Amazon este creata pe baza urmaririi si analizarii intereselor, comportamentelor si sabloanelor de cumparare ale vizitelor anterioare. Īn cazul cumpararii de DVD-uri, CD-uri sau carti de la Amazon.com, portalul va asigura ca utilizatorul este constient de alte oferte asemanatoare la vizitele urmatoare. Tipul de automatizare si urmarirea transparenta a comportamentului utilizatorului pentru personalizarea se numeste "profilare implicita", deoarece utilizatorul nu este angajat implicit īn alegerea preferintelor, iar informatia adunata īn acest fel este utilizata pentru data mining sau pentru "filtrare colaborativa" (collaborative filtring). Īn consecinta, metoda Yahoo! sau Excite prin care utilizatorii specifica preferintele prin intermediul unui chestionar, este cunoscuta sub denumirea de profilare explicita (explicit profiling).
Exista alte doua tipuri de profilare care pot fi utilizate pentru personalizarea portalurilor corporative. Una din metodele evidente si obligatorii este de a personaliza portalul pe baza tipului utilizatorului si a relatiei dintre acesta si companie. Cealalta metoda este personalizarea pe baza datelor istorice si specifice utilizatorului. Īn mod normal, ambele metode ar putea fi utilizate īmpreuna pentru a se completa una pe cealalta. Deci, clientii, de exemplu, ca grup, vor avea īn mod automat o personalizare diferita de a furnizorilor sau a investitorilor, de exemplu. Apoi datele istorice pot fi utilizate pentru o personalizare mai aprofundata a acestor categorii mai largi. De exemplu, clientii sau furnizorii ar putea avea o personalizare īn functie de regiunea geografica sau tipul de industrie de care apartin. Īn acest sens exista o multime de optiuni care sa realizeze personalizarea rapid, usor si fara sa īncetineasca experienta cu portalul.
Aceeasi personalizare bazata pe tipul utilizatorilor si a datelor istorice se aplica, chiar mai mult, angajatilor organizatiei. Angajatii din departamentul de resurse umane vor īncepe cu o "categorie" de personalizare diferita de cea a angajatilor din departamentele de marketing sau vānzari. Personalizarea poate fi mai apoi īmbunatatita, dupa autentificare, īn functie de nivelul de responsabilitate, titlu, grad sau altceva. Figura urmatoare contine o schema īn care se observa cum pot fi utilizate personalizarea si autentificarea pentru partitionarea unui portal corporativ.
Figura : Autentificarea si personalizarea utilizatorilor īntr-un portal.
Cel mai mare pericol din punct de vedere al personalizarii este acela de intimidare a utilizatorilor prin impresia care se poate face acestora īn ceea ce priveste īncalcarea confidentialitatii. Toate organizatiile mari care au implementat portaluri au sectiuni speciale pentru explicarea politicilor de confidentialitate sau chiar a unor tehnici utilizate pentru urmarirea si profilarea utilizatorilor.
Produsele de personalizare ale portalurilor sau facilitatile acestora sunt bazate pe reguli si orientate catre scopuri. Exista de obicei un "motor de reguli", care determina si gestioneaza continutul si serviciile oferite fiecarui utilizator īn functie de profile si reguli. Īn cazul īn care se utilizeaza profilul implicit, "motorul de reguli" va fi complementat de un "motor de recomandari", care va urmari comportamentul utilizatorilor pe baza de tehnici statistice sofisticate, actualizānd mai apoi regulile de personalizare, astfel īncāt utilizatorul poate influenta experienta cu portalul pe baza vizitelor anterioare.
Portalurile de tip business-to-employee permit angajatilor sa fie informati, simplifica multe din sarcinile pe care ar trebui sa le execute si, īn plus, da angajatilor, un puternic sentiment de afiliere. Portalurile business-to-employee pot implanta identitatea organizatiei īn angajati, īmbunatatind astfel loialitatea. Un portal business-to-employee bine creat si mentinut devine o comunitate cu propriile drepturi, de care angajatii se pot atasa si chiar pot invoca unele drepturi de proprietate, chiar daca nu sunt direct asociati cu mentinerea portalului. Un portal business-to-employee poate fi deci un bun puternic si valoros al organizatiei, neputānd sa fie ignorat sau sa i se dea un grad mic de prioritate.
Odata implementat, un portal business-to-employee mentinut la zi are potentialul de a deveni chiar un "spirit" al organizatiei respective, putānd fi utilizat pentru mentinerea tonusului organizatiei si putānd īn acest fel reflecta, īn mod subtil, aspiratiile si valorile organizatiei. Un portal business-to-employee este unul din cele mai importante instrumente de "conditionare a angajatilor", unele organizatii utilizānd, de exemplu, video-over-IP pentru anumite īntālniri cu managementul sau pentru a permite contactul "direct" cu angajatii sau cu managerii prin video conferinta. Un portal business-to-employee este de asemenea si un bun legat de resursele umane, cu conditia ca managementul resurselor umane sa fie implicat īntr-o initiativa de tip business-to-employee īnca din prima zi.
Motivatia existentei portalurilor business-to-employee este aceea ca portalurile vor īmbunatati productivitatea angajatilor si vor facilita o luare a deciziilor mai buna si mai rapida. Desi sunt greu de gasit date empirice care sa valideze aceste afirmatii, toate informatiile de la companiile mari care au adoptat portaluri business-to-employee indica succesul investitiei facute. Se poate totusi aprecia, īn mod intuitiv, cum un portal business-to-employee, mai ales cu instrumentele de rigoare, poate moderniza accesul la informatie, facilita colaborarea, elimina munca pe hārtie sau accelera procesarea tranzactiilor. Īn mod evident, aceste beneficii sunt mai mari pentru organizatiile mari, care au angajati dispersati pe īntregul glob, un portal business-to-employee asigurānd prezenta organizatiei respective 24/7.
Accesul la Internet maximizeaza eficienta portalului business-to-employee si asigura costuri minime de acces la acesta pentru toti angajatii, oriunde s-ar gasi acestia. Securitatea este, desigur, o problema, iar raspunsul este o autentificare puternica. Un portal competitiv si cooperativ, cu o interfata web prietenoasa se poate obtine si munca suplimentara, cu costuri zero, mai ales īn ceea ce priveste sarcinile colaborative sau legate de e-mail. Acest lucru īnseamna si ca portalul trebuie monitorizat si sustinut 24/7, devenind astfel o alta resursa critica pentru organizatie.
Desi un portal accesibil din Internet poate conduce si īncuraja la munca suplimentara, exista si un revers al medaliei: angajatii vor petrece mai mult timp decāt este necesar navigānd prin portal, motivānd acest timp ca fiind legat de munca depusa. Un portal business-to-employee poate fi distractiv si poate aduce diversitate, dar scopul sau este de a economisi timp pretios prin functionalitatile pe care le pune angajatilor la dispozitie.
Īn ceea ce priveste serviciile care vor fi oferite de portalurile business-to-employee, exista, din fericire, o regula care poate fi utilizata: tot ceea ce necesita completari de formulare pe hārtie, apeluri telefonice īn interiorul organizatiei sau oameni care se plimba pe coridoare, pot fi considerate buni candidati pentru automatizarea prin intermediul portalului. Functiile colaborative, precum calendare de grup, e-mail sau forumuri de discutii vor fi primite cu entuziasm.
Termenul "b2c" este acronimul de la "business-to-consumer", termen asociat de cele mai multe ori cu portaluri de comert electronic precum Amazon.com, buy.com etc. Cu toate acestea, nu exista nici un motiv pentru a restrictiona b2c doar la portaluri de comert electronic. O apropiere mai realista si reprezentativa ar fi aceea de a asocia portalurile b2c cu toate tipurile de portaluri business-to-consumer, īn care consumatorii ar fi atāt clientii/consumatorii existenti cāt si cei potentiali. Aceasta ar īnsemna ca portalurile b2c ar acoperi si portalurile publice de tip self-service sau call-center-urile. De asemenea, tot aici s-ar putea lua īn considerare posibilitatile acestor portaluri īn ceea ce priveste bancile, serviciile financiare, rezervarile pentru calatorie, companiile de utilitati etc.
Īn comparatie cu alte metode de marketing sau vānzari directe, obtinerea de avantaje competitive prin intermediul unui portal b2c sofisticat este relativ mai ieftina, mai ales cīnd un portal b2c va permite justificarea diminuarii operatiunilor dintr-un call-center fara diminuarea satisfactiei consumatorilor. Totul depinde aici numai de inovatia si creativitatea companiilor.
Īn aproape toate cazurile, o organizatie care doreste un portal b2c detine deja o pagina web cu informatii. Un portal b2c va evolua din aceasta prima pagina prin introducerea tranzactiilor si a functiilor de tip self-service. Nevoia de autentificare va depinde de vulnerabilitatea informatiilor care fac obiectul tranzactiilor sau care sunt utilizate pentru tranzactii. Īn cazul unui catalog electronic standard de tip "gaseste un obiect", precum bilete de avion, carti sau diverse alte lucruri, nu e nevoie de autentificare. Totusi, īn cazul īn care cautarea īn catalog conduce la o tranzactie de tip comert electronic, va fi nevoie de un cont (si deci de autentificare) care va fi utilizat si īn vizitele urmatoare.
Īn unele cazuri se pot impune anumite niveluri de īnregistrare cu username/parola sau alte modalitati de autentificare pentru urmarirea sabloanelor, atāt pentru īncurajarea unui simt al comunitatii cāt si pentru colectarea de date statistice. Spre exemplu, multe portaluri de presa sau alte media online favorizeaza aceasta metoda. Desi informatia pe care o colecteaza nu este, īn mod evident, confidentiala, necesitatea autentificarii adauga un anumit prestigiu tranzactiei din punct de vedere al consumatorului, oferind īn acelasi timp producatorului sau distribuitorului de continut anumite statistici legate de utilizatori. Aceasta nevoie de autentificare, daca nu este realizata automat printr-un cookie, nu permite utilizatorilor sa "sara" peste portal, direct īn categoria pe care o doresc (īn acest caz - stirile). Īn acest fel, schema de logon poate servi ca o modalitate complicata dar eficienta de a obtine loialitatea īn portal.
Portalurile b2b ar trebui sa fie baza viitorului comert electronic. Portalurile b2b pot fi utilizate pentru doua scopuri diferite:
interactiunea cu partenerii existenti, distribuitori sau furnizori, īn toate aspectele mutuale ale managementului lantului de aprovizionare si a managementului relatiilor cu clientii;
identificarea si localizarea noilor oportunitati de afaceri, īmpreuna cu noi parteneri, distribuitori sau furnizori de afaceri.
Identificarea si localizarea noilor proiecte sau scheme de afaceri nu ar trebui confundata cu īncercarea de a identifica si atrage parteneri, distribuitori sau furnizori aditionali. Orice portal b2b sau portal de organizatie contine informatii de contact, care pot fi utilizate cu scopul devenirii de partener acreditat. Acest aspect de "noua afacere" ar trebui sa gaseasca noi contracte, noi piete, noi teritorii sau noi tehnologii. Este posibil ca aceste doua obiective sa fie obtinute īntr-un singur portal b2b, dar exista o demarcatie stricta a modalitatii de rezolvare a acestor probleme. Īn cele din urma se va ajunge la:
portaluri b2b specifice companiilor sau regiuni b2b cu un portal de organizatie;
portaluri "publice" b2b specifice industriei sau afacerii.
Conceptul de portal b2b specific companiilor, utilizate pentru managementul partenerilor existenti sau al lantului de aprovizionare este īnteles repede, cele mai multe din marile companii (Cisco, Disney, Boeing) se bazeaza deja pe portaluri b2b ca mijloace de executie rapida, eficienta si ieftina a tranzactiilor de afaceri.
Portalurile publice b2b specifice unei industrii sau afaceri sunt, spre deosebire de cele de mai sus, echivalentul b2b al portalurilor Internet. Afacerea lor, la fel ca Yahoo! sau Excite, este a rula si īntretine un portal b2b, scopul acestor portaluri fiind acela de a actiona sub forma unei piete comune sau clearinghouse pentru companiile angajate īntr-o piata sau industrie specifica (automobile, aluminiu etc.)
Dat fiind interesul īn ceea ce priveste b2b, exista portaluri index de tip b2b, precum b2btoday.com sau b2byellowpages.com. Desi b2b trebuie sa ajunga la asteptarile create īn era "dot-com" īn ceea ce priveste volumul afacerilor, portalurile b2b specifice anumitor industrii sau portalurile index b2b continua sa prolifereze si sa se dezvolte.
Exista de asemenea si portaluri b2b īnchise, destinate unui grup restrāns de utilizatori din anumite industrii. Consumatori mari de componente, precum producatorii de automobile, companiile din industria chimica, firmele de electronice sau companiile de telecomunicatii genereaza portaluri b2b special pentru furnizorii lor. Unele din aceste site-uri sunt site-uri de licitatii īn vederea obtinerii celui mai bun aranjament īn ceea ce priveste bunurile oferite spre licitatii. Site-urile de licitatii publice precum eBay ofera un bun model pentru structurarea si operarea acestor grupuri īnchise de portaluri de licitatie.
Figura : Portalul "b2bToday.com".
Un portal b2b specific unei companii va fi un subset cu acces controlat al portalului business-to-employee al organizatiei, cu posibilitatea de includere a unor functionalitati precum cataloage electronice, asociate portalurilor b2c.
Autentificarea este de o importanta covārsitoare īn portalurile b2b, avānd ca scop securitatea, urmarirea utilizatorilor si personalizarea. Datorita autentificarii si personalizarii, continutul si serviciile pot fi partitionate si oferite pe baza de necesitate de cunoastere sau pe baza de nevoie de utilizare.
Figura : Portalul "b2bYellowPages.com".
Portalurile b2b sunt utilizate din ce īn ce mai mult pentru oferirea accesului controlat la aplicatii de tip ERP selectate, astfel īncīt partenerii pot partaja īn mod direct si dinamic informatii actualizate (īnregistrari despre facturare, nivelul stocurilor, limite de creditare, planificari ale productiei etc.) fara a fi necesara contactarea unui reprezentant din organizatia care pune aceste date la dispozitie. Accesul direct la aplicatii ERP īmbunatateste productivitatea de ambele parti si grabeste schimbul de informatii.
Portalurile de tip wireless nu mai sunt la fel de importante astazi precum erau la un moment dat, acest lucru nedatorāndu-se cresterii continue a pietei de acces la Internet prin wireless ci, mai ales, datorita faptului ca oamenii au realizat ca dispozitivele wireless, data fiind cresterea importantei acestora, sunt cel mai bine gestionate ca parte a portalului organizatiei si nu prin portaluri specifice. Acest fapt elimina nevoia de a mentine si actualiza continut separat īn cele doua tipuri de portaluri. Cea mai mare problema cu dispozitivele mobile este ca acestea nu au īnca latimea de banda necesara, aria de prezentare sau capacitatile de navigare necesare portalurilor din ce īn ce mai sofisticate sau pline de grafica.
Solutiile populare de tip portal de astazi īnteleg necesitatea suportului pentru clientii wireless si ofera pentru acestia instrumente pentru conversie si filtrarea continutului pentru a asigura faptul ca acelasi continut sau servicii pot fi accesate atāt de clientii legati prin retele clasice cāt si pentru cei wireless. Pe lānga acestea exista instrumente puternice precum WebSpere Transcoding Publisher (WSTP) de la IBM sau MobileSys MX pentru simplificarea integrarii dispozitivelor wireless, promovānd īn acest fel accesul universal la portal.
WSTP faciliteaza suportul noilor tipuri de dispozitive si limbaje de marcare (WML, de exemplu), permitānd administratorilor de portal concentrarea pe promovarea si mentinerea unui singur portal consolidat, independent de tipul de client. WSPT adapteaza īn mod dinamic continutul cerut pentru a raspunde cerintelor dispozitivelor wireless. Deoarece continutul web actual este scris īn HTML si nu īntr-un limbaj specific anumitor dispozitive sau clienti, WSTP rezolva problema integrarii dispozitivelor wireless prin legarea dinamica a diferitelor structuri HTML la structuri dependente de dispozitiv, transmitānd astfel continutul īn formatul necesar.
WSTP contine transformari de continut standard (transcoderi) pentru urmatoarele limbaje:
HTML catre WML;
HTML catre iMode
HTML catre HDML
XML catre XSLT;
Imagini JPEG catre bitmap si GIF specific dispozitivelor mobile;
Imagini GIF catre bitmap si JPEG specific dispozitivelor mobile.
Toate semnele curente indica faptul ca XML si XSLT vor reprezenta modalitatea strategica si acceptata de gestionare a dispozitivelor mobile de catre portalul organizatiilor. Astfel, pot exista transformari XSLT care sa gestioneze tipuri de dispozitive diferite sau chiar grupuri de dispozitive, īn functie de necesitati. Īn mod evident, utilizarea XML pentru integrarea wireless presupune existenta continutului īn format XML, format care se poate obtine extrem de usor.
La momentul actual nu exista īnca vreun standard industrial pentru arhitectura portalurilor la nivel de organizatie. Cu toate acestea, toate portalurile, indiferent de tipul acestora sau de orientarea companiei producatoare, partajeaza un set de functionalitati de baza obligatorii. La nivel minim, aceste functionalitati de baza pentru un portal cuprind:
interfata catre web;
managementul interfetei cu utilizatorul (servicii de prezentare, de exemplu);
mecanisme de acces la date externe;
servicii de management al datelor;
securitate, autentificare si personalizare;
instrumente de dezvoltare a portalului;
instrumente de administrate si management ale portalului.
Necesitatea acestor componente de functionalitate discrete, īn care fiecare componenta are o legatura logica si foarte specifica cu celelalte componente, asigura o structura comuna pentru portalurile corporative. Acest cadru de lucru de baza, comun pentru toate portalurilor, poate fi extins cu usurinta pentru a servi ca fundatie de referinta pentru viitoarele portaluri corporative. Figura urmatoare ilustreaza aceasta arhitectura de referinta pentru toate portalurile corporative contemporane, construite pe functiile obligatorii de mai sus, īn vederea realizarii unor portaluri credibile.
Functiile de agregare, cautare, colaborare, sindicalizarea, managementul documentelor, workflow management pot fi adaugate sub forma de componente sau servicii de management a datelor, pentru a completa si mai mult aceasta arhitectura. Īn mod similar, componenta de interfata web, care īn practica este realizata printr-un server de aplicatii web, poate fi extinsa pentru a cuprinde servicii web care sa utilizeze protocoalele uzuale SOAP, WSDL si UDD. Flexibilitatea si extensibilitatea incrementala a acestei arhitecturi este reflectata cu acuratete īn cele mai puternice solutii portal de astazi. Implementarea unui portal de succes la nivelul unei organizatii nu trebuie sa fie de tip "totul-sau-nimic", la serviciile interactive de baza adaugate paginii web existente putāndu-se adauga īn mod sistematic si gradual diverse componente, īn functie de bugetul si timpul alocat.
La ora actuala se poate implementa un portal la nivel de organizatie īn doua moduri diferite: prin crearea de programe/aplicatii necesare, scripturi customizate si servicii individuale peste un server web; sau prin utilizarea unui portal "gata facut". Īnainte de 1997, utilizarea scripturilor Perl sau a aplicatiilor CGI era singura solutie, īn timp ce astazi exista o multime de servere portal "totul īn unul", pentru diferite bugete.
Figura : Arhitectura de baza a portalurilor contemporane.
Optarea pentru o solutie portal de baza nu implica o schema rigida. Īn schimb, majoritatea serverelor de tip portal, anticipānd necesitatile clientilor, ofera o multitudine de optiuni pentru customizarea, īmbunatatirea si cresterea implementarii portalului prin plug-in-uri sau API-uri. Serviciile web sunt o alta modalitate moderna de extindere a functionalitatii si īmbunatatirii functionalitatilor unui portal.
Īn zilele noastre, cea mai buna solutie pentru ca o organizatie sa aiba propriul portal este ca unul gata facut (off-the-shelf) sa fie achizitionat, construindu-se mai apoi alte componente, pe masura ce echipa de dezvoltare/implementare capata mai multa experienta cu portal achizitionat. Printre cele mai importante portaluri la nivel mondial se numara (ordinea este aleatorie): mySAP Enterprise Portal, IBM WebSphere Portal, Oracle Application Server (cu portal inclus), Plumtree Corporate Portal, Microsoft SharePoint, iPlanet Portal Server, Hummingbird EIP, Ione Netegrity Interaction Server, CA CleverPath Portal, Epicentric Foundation Server, Corechange Coreport, Verity K2 Enterprise, BroadVision InfoExchange Portal, Brio Portal etc. Nu trebuie, de asemenea, sa uitam nici portalurile open-source, care ar putea fi implementate la nivel de organizatii (mai mici).
Un numar din ce īn ce mai mare de producatori de portaluri scot īn evidenta rolul serviciilor web īn viitorul portalurilor, aproape toti producatorii oferind suport pentru acestea. Īn timp ce rolul IBM, BEA, Oracle sau Microsoft este binecunoscut īn promovarea serviciilor web si ceilalti jucatori īncep sa realizeze importanta acestor servicii web īn produsele pe care le creeaza, indiferent ca au la baza aplicatii Java sau aplicatii bazate pe Microsoft .NET. Utilizarea unui server portal va facilita si accelera adoptarea acestor noi si promitatoare metodologii pentru aplicati web.
Serverele portal, īntr-un efort pentru a simplifica dezvoltarea si mentinerea portalului, ca si pentru a obtine anumite avantaje competitive unele fata de altele, au introdus īn ultimii ani noi si inovative concepte. Printre acestea notam portlet-urile, digital dashboard cu web parts, gadgets, breadcrumbs, skin-uri, roluri, domenii, sau iView-uri. Dintre acestea, conceptul de "portlet" (sau alte concepte īnrudite precum "pagelet") sunt cele mai importante. Portlet-urile sunt create si suportate de IBM, BEA, Oracle, Sybase, Viador, Verity si altii.
Īn cazul unei solutii portal care le suporta, portlet-urile devin blocurile de constructie sau caramizie portalului. Portlet-urile sunt, īn esenta, componentele active vizibile pe care utilizatorul final le vede īn pagina web a portalului. Figura urmatoare ilustreaza conceptul de portlet-uri relativ la pagina unui portal.
Figura : Portle-uri īn pagina unui portal.
Dupa cum se poate observa si īn figura, portlet-ul detine o parte din fereastra browser-ului sau a ecranului dispozitivului mobil īn care este afisata pagina curenta portalului. Din perspectiva unui utilizator, un portlet este o "fereastra" sau un canal de continut, completata cu controalele necesare.
Functiile de publicare a continutului, managementul continutului, cautare, colaborare, sindicalizare si functiile legate de workflow fac parte din categoria serviciilor pentru managementul datelor, chiar daca nu sunt enumerate explicit īn figura respectiva. Functiile care vor fi incluse īn mod obligatoriu īn aceasta arhitectura sunt urmatoarele:
managementul continutului:
o publicarea continutului: includerea manuala si automata a datelor īn formulare diferite, accesate de utilizatorii autorizati ai portalului;
o structurarea continutului: mecanisme de tip portlet sau sabloane;
o sindicalizarea continutului: abilitatea de a subscrie la furnizori de date externi prin intermediul standardelor RSS, OCS, PRISM, NITF, xmlnews etc.;
o agregarea continutului: asimilarea si sinteza datelor din diverse surse, īn functie de regulile de personalizare ale unui anumit utilizator si prezentarea acestor date;
o transmiterea continutului: cuprinde gestionarea automata a schemelor de tip "push" sau a serviciilor de subscriptie, care permit utilizatorilor sa ceara actualizari periodice sau sa fie notificati īn cazul aparitiei unui anumit eveniment;
o director de continut: index care unifica si mapeaza toate datele, serviciile si aplicatiile disponibile īn portal;
o categorii de continut: clasificarea automata si continua a continutului portalului īn categorii pertinente, cunoscute si sub numele de taxonomii, utilizānd tehnologii de tip "web crawler", care indexeaza automat continutul, luānd īn calcul si meta-datele asociate unui anumit tip de continut, adaugāndu-le īn directorul de continut;
Cautarea, care cuprinde cautari īn mai multe surse si tipuri de continut;
Colaborarea;
Managementul fluxului de lucru, care permite utilizatorilor sa monitorizeze si sa controleze fluxul tranzactiilor multi-pas necesare pentru executia unui anumit proces al afacerii (exemple: acceptarea unui ordin, expeditia unui produs, facturarea unui client, receptionarea platii de la clienti etc.).
Figura urmatoare extinde arhitectura de baza din figura de mai sus pentru a reflecta functionalitatea discutata īn paragraful anterior. Cu toate ca este o arhitectura functionala, mai trebuie incluse anumite functii pentru a asigura o autenticitate totala. De exemplu, regulile joaca un rol din ce īn ce mai important īn managementul si operatiunile unui portal. Personalizarea bazata pe reguli este unul din exemplele discutate mai sus. Directoarele de reguli, care contin motoare de "fortare" a acestora, pot fi utilizate pentru transmiterea continutului, managementul subscriptiilor, īmpartirea pe categorii a continutului sau managementul fluxurilor de lucru.
Figura : Arhitectura portalurilor, cu detalierea serviciilor de acces la date.
Īn cazul transmiterii continutului sau a managementului subscriptiilor, regulile pot fi utilizate pentru a customiza si actualiza toate datele de tip "push" ca si declansatoarele de alertare automata. Alertarea bazata pe reguli poate fi extinsa pentru a acoperi si procesarea fluxurilor de lucru. De exemplu, un reprezentant de vānzari poate fi alertat automat cānd organizatia primeste plata pentru un ordin primit de acel reprezentant, īn acest fel reprezentantul putānd determina data obtinerii comisionului. Regulile pot fi utilizate de asemenea pentru īmpartirea īn categorii a continutului, cu avantajul ca se pot face schimbari rapide īntre categorii prin simpla schimbare a regulilor. Aceste componente de reguli vor avea, cum este si normal, interfete catre componentele de administrare a portalului, de personalizare si catre componenta de management a datelor.
O alta capacitate importanta a unui portal modern este posibilitatea reutilizarii informatiilor deja continute si mentinute īn directoarele utilizatorilor, asigurānd īn acest fel faptul ca aceste informatii, inclusiv drepturile de acces, pot fi administrate si controlate īn mod centralizat. Pe lānga simplificarea si reducerea volumului de munca necesar īntretinerii directorului, lucrul dintr-un director centralizat previne problemele de sincronizare sau actualizare a acestuia.
O componenta director a unui portal permite īn mod normal existenta mai multor subdirectoare, īntr-o schema federativa, acest lucru asigurānd ca un portal poate lucra īntr-o schema a unui director care este largita de catre informatiile specifice portalului, mentinute īntr-un alt director. Interfata catre aceste directoare poate fi unul din uzualele LDAP (Lightweigh Directory Access Protocol), Microsoft Active Directory sau Novell NDS eDirectory.
Componenta de acces la date externe a unui portal se concentreaza pe oferirea unui numar cīt mai mare de adaptoare pentru diverse surse de date externe, precum baze de date diferite sau accesul la date mentinute īn mainframe-uri.
Avānd īn vedere popularitatea pachetelor ERP, CRM, SCM, de management al cunostintelor si a aplicatiilor de control al procesului, cele mai multe servere portal ofera de asemenea adaptoare specifice aplicatiilor.
Figura urmatoare contine arhitectura actualizata a unui portal cu functiile discutate mai sus.
Figura : Arhitectura portalului SAP.
Figura : Arhitectura actualizata a portalului.
Figura : Portalul SAP si Portal Content Directory de la SAP.
Portlet-urile sau alte mecanisme similare sunt facilitati de profil ale multor servere de tip portal īn sensul ca simplifica design-ul si īntretinerea portalului si accelereaza disponibilitatea continutului. Exista numeroase cai īn care portlet-urile simplifica design-ul si micsoreaza timpul necesar activarii continutului; astfel portlet-urile ofera functii de modularizare si izolare. Fiecare aplicatie portal va fi asociata unui portlet specific, deci fiecare aplicatie īmpreuna cu portlet-ul corespunzator poate fi dezvoltata, īntretinuta si actualizata īn mod independent. Īn consecinta, fiecare portlet este o entitate autonoma independenta. De exemplu, inbox-ul e-mail-ului va fi un portlet, aplicatia de tip calendar un alt portlet iar agenda de contacte a organizatiei va fi un alt portlet. Functia de agregare a portalului va afisa īn timp real diferite portlet-uri, corespunzatoare diferitelor aplicatii ale portalului.
Un alt factor cheie care face portlet-urile atāt de atractive este disponibilitatea portlet-urile gata construite atāt de producatorul serverului de tip portal cāt si de la alti producatori.
Printre cele mai utilizate portlet-uri gata construite, disponibile īn pachetul de instalare al portal-ului sau care pot fi instalate separat se numara:
Portlet XSL, care va afisa continutul de tip XML prin utilizarea transformarilor XSL (XSLT);
Portlet WML, care va converti HTML catre WML pentru ca portalul sa suporte dispozitive mobile;
Portlet de stiri, cu suport pentru RSS sau alt protocol, astfel īncīt continutul sindicalizat sa fie direct integrat īn pagina portalului;
Portlet-uri de colaborare, specifice Microsoft Exchange, Microsoft Outlook sau Lotus Notes, cu optiuni pentru e-mail, agenda de contacte, calendar si functie de tip "to-do list";
Portlet pentru acces la baze de date;
Portlet pentru mesagerie instantanee;
Portlet de cautare, oferit īn combinatie cu motoare de cautare cunoscute precum Google;
Portlet-uri specifice aplicatiilor, cu suport pentru aplicatii populare precum ERP, resurse umane, CRM sau SCM, care simplifica integrarea acestor aplicatii larg utilizate īn cadrul de lucru al portalului.
Producatorii de servere portal care suporta portlet-uri ofera pe Internet cataloage cu toate portlet-urile disponibile pentru serverel produs de ei. De asemenea, mai sunt oferite si kit-uri de dezvoltare sau API-uri, astfel īncāt se pot construi propriile portlet-uri.
Conceptul natural si intuitiv de portlet, īn ceea ce priveste facilitarea dezvoltarii portalului, are, īn mod evident, propriile corespondente īn piata portalurilor actuale. Īn cele mai multe cazuri, diferenta este doar de terminologie, conceptul care sta la baza acestor componente sau module care se pot atasa portalurilor, fiind acelasi. Microsoft, de exemplu, a adoptat conceptul de digital dashboard.
Un digital dashboard este o pagina a portalului compuna din diferite componente web numite web parts, componente care pot fi combinate si customizate pentru a īndeplini cerintele individuale ale utilizatorilor. Fiecare digital dashboard este o pagina web separata care contine una sau mai multe web parts, īn care fiecare web part este un obiect reutilizabil care contine date sau script-uri, utilizate īn vederea prezentarii de informatii catre utilizatori. Microsoft SharePoint, promovat ca si "portal īntr-o cutie" este centrat īn totalitate pe digital dashboard, astfel īncāt serverul SharePoint face referire la portaluri sub forma site-urilor digital dashboard. Pe lānga componentele (web parts) gata create, exista posibilitatea implementarii digital dashboard cu alte produse Microsoft, mai ales cu Microsoft Office, Microsoft SQL Server sau Microsoft Exchange. Īn contextul unui digital dashboard, web parts devin echivalentul portlet-urilor.
Microsoft ofera, de asemenea, la fel ca si producatorii de portlet-uri, galerii cu web parts, care contin, de exemplu si plug-in-uri catre aplicatii precum SAP sau Sibel. Microsoft ofera de asemenea web parts pentru business intelligence, CRM, ERP, transmiterea informatiilor (receptionarea de stiri), knowledge management si colaborare, managementul proiectelor si, īn general, catre toate aplicatiile Microsoft. Exista, de asemenea, un kit pentru construirea de web parts, pe baza ASP.NET.
iView, acronimul de la Integrated View, este echivalentul SAP al unui portal. Arhitectura SAP a unui portal din figura de mai sus contine un "Server iView", īn care Java si .NET pot fi utilizate pentru afisarea/utilizarea mai multor iView-uri. Un iView permite continutului si aplicatiilor sa fie integrate īntr-un portal SAP. SAP defineste un iView sub forma unui element de prezentare autonom, bazat pe XML. Faptul ca un iView este bazat pe XML este singurul lucru care-l diferentiaza de celelalte modalitati de afisare a continutului precum portlet-uri sau web parts, care, desi suporta XML, nu necesita ca toate datele sa fie bazate pe XML. iView de la SAP se pot conecta la diferite tipuri de date si aplicatii prin intermediul constructiilor cunoscute sub numele de "conectori iView" (iView Connectors).
Skin-urile, un termen popularizat de BEA, nu sunt echivalentul portlet-urilor, web part-urilor sau iView-urilor, desi sunt utilizate de portlet-urile BEA. Skin-urile mai pot fi asemuite si temelor disponibile īn Microsoft FrontPage, PowerPoint sau oricare aplicatie desktop din Windows. Un skin defineste modalitatea de afisare (look and feel) a fiecarei ferestre sau pagini a portalului. Deoarece un portal BEA este alcatuit din portlet-uri, un skin specifica fonturile, culorile si icoanele utilizate de un anumit portlet, de aici venind si asemanarea cu conceptul de "tema". La fel ca si īn cazul temelor, modalitatea de afisare a paginii unui portal se poate schimba īn totalitate prin alegerea unui nou skin.
Domeniile si rolurile sunt combinate de obicei si sunt legate de personalizarea unui portal. Conceptul de domeniu a fost utilizat īn retele pentru a indica o retea autonoma. Pe Internet termenul este īntālnit īn numele de domeniu, utilizat pentru identificarea prezentei pe Internet a unei organizatii (cisco.com, w3.org etc.). Īn contextul unui server de tip portal, un domeniu defineste cel mai īnalt nivel al unui anumit portal.
Īn cazul īn care o organizatie doreste un singur portal consolidat, atunci īntregul portal poate fi un singur domeniu din punct de vedere al serverului care gazduieste portalul. Daca organizatia respectiva detine mai multe portaluri, fiecare din acestea va fi un domeniu separat daca sunt implementate pe acelasi server portal. Dintr-un alt unghi, tot ceea ce este reunit sub aceeasi adresa web apartine unui singur domeniu; deci, utilizarea de adrese web diferite (nume de domenii si URL-uri) pentru portaluri diferite dintr-o organizatie conduce la domenii portal diferite. Domeniile sunt importante pentru portaluri īn cazul īn care se doreste executia mai multor portaluri pe acelasi server, permitānd identificarea portalurilor pe de-o parte, iar pe de alta defineste apartenenta la o comunitate de utilizatori.
Personalizarea este implementata de obicei īn servere portal prin intermediul unui mecanism bazat pe roluri. Īn esenta, fiecare utilizator autentificat primeste unul sau mai multe roluri īn cadrul portalului, īn timp ce utilizatorii neautentificati primesc doar un rol implicit. Rolurile utilizatorilor definesc experienta utilizatorului cu portalul respectiv, ceea ce cuprinde modalitatea de afisare, controlul continutului si serviciilor precum si accesul la aplicatii.
Rolurile ar trebui definite ierarhic, īntr-o structura arborescenta, care sa oglindeasca structura organizatiei, cel putin din punct de vedere al organigramei, permitānd asignarea usoara catre grupuri īnrudite de oameni. De exemplu, se poate defini un rol pentru toti angajatii din departamentul de resurse umane, alt rol pentru cei din departamentul de marketing si un altul pentru departamentul IT. Urmeaza apoi asignarea de roluri specifice fiecarui departament catre persoanele care au drepturi de acces diferite la continut. Ca si orice schema ierarhica, rolurile pot mosteni proprietatile rolurilor de deasupra lor, existānd si mecanisme pentru modificarea si restrictionarea proprietatilor mostenite. Rolurile ierarhice au marele avantaj de a simplifica si accelera procesul de personalizare si administrare a portalurilor.
Gadget-urile, termen popularizat de Plumtree, este foarte asemanator unui portlet sau web part, cu o singura mare diferenta: un gadget este o componenta a unui portal care opereaza pe un alt calculator. Gadget-urile sunt utilizate pentru integrarea resurselor din aplicatii si plug-in-ul surselor de continut, ambele externe. Īn acest context, resursele aplicatiilor existente pot cuprinde instrumente de colaborare precum e-mail, calendar sau directoare la nivel de organizatie.
Numele īntreg si formal al unui gadget este "gadget web service". Potrivit Plumtree, gadget-urile sunt "servicii web" grafice disponibile utilizatorilor portalurilor, care interactioneaza direct cu acestea prin intermediul unui interfete cu utilizatorul specifica gadget-urilor.
Figura : Conceptul de gadget de la Plumtree, utilizat pentru integrarea aplicatiilor si continutului extern.
Ca si īn cazul portlet-urilor sau web part-urilor, mai multe gadget-uri pot si combinate pentru a obtine o pagina a unui portal, īn vederea oferirii utilizatorilor de continut si servicii personalizate. Figura de mai sus desemneaza o vedere de ansamblu a unui portal din punctul de vedere al Plumtree.
Breadcrumb, nume inventat de PeopleSoft, descrie o facilitate foarte utila prin care se poate face navigarea ierarhica, categorie cu categorie, pe masura ce utilizatorul navigheaza īn portal urmarind link-urile oferite.
Figura : Breadcrumbs īn portalul PeopleSoft.
|
