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.
|
