WP1-2 RA - 2 - Anexa 3 PDF

Studiu de caz in domeniul
Servicii administratia publica

- versiunea 2 -
1
CUPRINS
1 Tipuri de servicii in administratia publica date generale ..................................... 4

1.1. Introducere ........................................................................................................... 4
1.2 Tipuri de servicii in administratia publica ......................................................... 5
1.3. e-Guvernare ....................................................................................................... 10
1.3.1. Descrierea domeniului de servicii e-Guvernare ............................................ 10
1.3.2. e-Participare si e-Incluziune ......................................................................... 15
1.3.3. e-Guvernare in Romania .............................................................................. 16
1.3.4. Metrici de performanta in e-Guvernare ......................................................... 19
1.4. Servicii publice de consultanta si asistenta pentru mediul de afaceri ......... 21
1.5. Servicii publice de consultanta si asistenta pentru accesarea de fonduri
nerambursabile............................................................................................................. 24
1.6. Servicii publice de consultanta si asistenta la implementarea proiectelor
finantate din fonduri nerambursabile ......................................................................... 25
2. Tehnologii software pentru serviciile din administratia publica ....................... 25
2.1. Servicii Web ....................................................................................................... 26
2.1.1. Tipuri de arhitecturi ....................................................................................... 26
2.1.2. Arhitectura de tip RPC .................................................................................. 27
2.1.3. Arhitectura de tip REST ................................................................................ 29
2.2. Arhitectura orientata spre servicii ................................................................... 35
2.2.1. Principiile SOA ............................................................................................. 37
2.2.2. Rolurile serviciilor Web intr-o SOA ............................................................... 37
2.2.3. Interactiunea si compunerea serviciilor ........................................................ 38
2.2.4. Limbajul XML ................................................................................................ 38
2.2.5. SOAP ........................................................................................................... 39
2.2.6. WSDL ........................................................................................................... 40
2.2.7. UDDI............................................................................................................. 41
2.2.8. WSRF ........................................................................................................... 41
2.2.9. Arhitectura orientata pe servicii in sistemele Grid......................................... 43
2.3. Web-ul semantic ................................................................................................ 44
2.3.1. Sintaxa OWL ................................................................................................ 45
2.3.2. Cazuri de utilizare......................................................................................... 51
2.3.3. Concluzii Web semantic ............................................................................... 55
2
2.4. Potential de inovare .......................................................................................... 56
2.4.1. Noi capabilitati ale serviciilor publice electronice .......................................... 56
2.4.2. Dezvoltarea interactiunii cu utilizatorii........................................................... 56
2.4.3. Managementul identitatii electronice ............................................................ 57
2.4.4. Interoperabilitatea serviciilor publice electronice .......................................... 58
2.4.5. Managementul cunostintelor ........................................................................ 58
2.5. Descrierea serviciului Servicii publice de rezolvare a cererilor clientilor in
varianta actuala ............................................................................................................ 59
2.5.1. Procesul actual ............................................................................................. 59
2.5.2. Prezentarea potentialului de inovare a serviciului Servicii publice de
rezolvare a cererilor clientilor..................................................................................... 62
2.6 Descrierea serviciului public de consultan i asisten pentru afaceri ......... 64
2.6.1 Procesul actual .................................................................................................. 64
2.6.2 Prezentarea potentialului de inovare a serviciului publice de consultan i
asisten pentru afaceri .............................................................................................. 66
3. Concluzii ................................................................................................................ 69
3.1. Tendinte si inovare in serviciile software pentru administratia publica ....... 69
3.2. Rezumat servicii ................................................................................................ 70
3.3. Implicatii asupra necesitatii calificarii si pregatirii de personal implicat in
servicii ........................................................................................................................... 70
4. Bibliografie ............................................................................................................ 72
3
1 Tipuri de servicii in administratia publica date generale
1.1. Introducere
Administratia publica reprezinta domeniul care se ocupa de implementarea politicilor
guvernamentale, avand drept principal scop realizarea unui avans in managementul si
politicile guvernamentale pentru ca acesta sa functioneze cat mai bine. In contextul
prezentului studiu, cea mai relevanta definitie a administratiei publice o reprezinta procesul
de transpunere a politicilor guvernamentale in realitatea pe care cetatenii o vad in fiecare
zi. In acest context, se poate vedea clar legatura intre administratia publica si organizarea
politicilor si programelor guvernamentale in folosul tuturor cetatenilor, dar si a companiilor.
Datorita cresterii birocratiei din administratia publica, cauzata atat de cresterea politicilor
guvernamentale, cit si de cresterea populatiei, a aparut o noua teorie numita Noul
Management Public (NMP) la sfarsitul anilor 1980. Acest nou model propune o orientare
spre servicii a sectorului public, porning de la ideea folosirii modelelor existente pentru
sectorul privat, inclusiv a valorilor organizationale, pentru a creste eficienta sectorului
public. La inceputul anilor 1990, administratia publica a tarilor dezvoltate s-a reformat
adoptand principiile acestei noi teorii, care s-a extins apoi in toata lumea. NMP se bazeaza
pe impartirea birocratiilor mari in agentii mai mici si mai fragmentate, incurajand astfel
competitia intre diferitele agentii publice. O observatie importanta este ca NMP trateaza
indivizii ca pe clienti (termen specific sectorului privat), mai degraba decat ca cetateni.
Aceasta reprezinta si principala critica adusa acestui model intrucat cetatenii nu mai sunt
proprietarii (patronii) sistemului de guvernamant, ci doar ca un mijloc de a face profit. La
inceputul secolului 21, guvernarea digitala (e-Guvernare) a fost propusa ca nou model
pentru serviciile publice, venind si ca un raspuns pentru NMP. Principiile e-Guvernarii se
axeaza pe reintegrarea responsabilitatilor procesului de guvernare, profitand de epoca
digitala pentru a oferi un holism in serviciile publice, mergand pe ideea ca cetatenii trebuie
sa aiba posibilitatea sa isi indeplineasca obligatiile fasa de stat intr-un mod cat mai usor si
mai cursiv.
Guvernarea orientata pe servicii reprezinta insa o tehnica de guvernare moderna ce poate
fi folosita chiar impreuna cu e-Guvernarea, daca o privim doar ca o modalitate de a
indeplini nevoile cetatenilor, oferind bunuri si servicii publice de inalta calitate. Cele mai
importante doua trasaturi ale guvernarii bazate pe servicii ar trebui sa fie: oferirea de
bunuri si servicii publice fara a se implica in producerea de bunuri si servicii private si
incurajarea dezvoltarii serviciilor publice orientate spre piata. Astfel, Guvernul nu trebuie
sa aiba monopolul in oferirea de bunuri si servicii publice, permitand astfel funizarea de
servicii publice si sectorului privat pentru a creste competitia in toate domeniile
administratiei publice. Rezultatul final va fi minimizarea defectelor din serviciile publice
oferite cetatenilor si cresterea productivitatii in administratia publica. Guvernarea bazata
pe servicii scoate in evidenta faptul ca principalul rol al Guvernului este acela de a oferi
functiile baza necesare serviciilor publice si ca valorile cele mai importante sunt orientarea
spre oameni si centrele de servicii. Astfel, rolul Guvernului nu mai este de a regulariza
piata serviciilor si bunurilor publice, ci de a se concentra pe imbunatatirea reglementarilor
si controlului macroeconomic, de a standardiza piata, de a creea un mediu de piata corect
si de a imbunatati calitatea si abilitatea serviciilor publice.
4
Indiferent de modelul de organizare al administratiei publice (orientat pe servicii sau
clasic), dezvoltarea serviciilor software si a tehnologiilor Web a oferit o modalitate de
imbunatatire a eficientei si eficacitatii organizatiilor birocratice de dimensiuni mari. Astfel,
termeni precum e-Comert, e-Guvernare, e-Organizare, e-Participare, etc. au devenit din
ce in ce mai utlizati in ultimii 10-15 ani. Conceptele de e-Guvernare si e-Guvernamant au
cunoscut o evolutie vasta in aceasta perioada, pornind de la folosirea site-urile Web pentru
informarea cetatenilor, a comunicarii prin posta electronica si mergand pana la sisteme IT,
atat hardware, cat si software, foarte avansate pentru a oferi e-cetatenilor acess la
informatiile si serviciile publice. E-Guvernarea, prescurtare de la guvernare electronica,
cunoscuta si ca e-gov, guvernare digitala, guvernare online sau guvernare conectata,
reprezinta orice forma de interactiune digitala intre Guvern si cetatenii sai (G2C), Guvern
si companii, organizatii comerciale sau eCommerce (G2B), intre diversele agentii
guvernamentale, eventual din state diferite (G2G). Acestea sunt doar principalele ramuri
ale e-gov, intrucat exista si interactiunea intre Guvern si organizatiile religioase (G2R), etc.
Astfel, e-Guvernarea se afla la confluenta dintre administratie publica, tehnologia
informatiei si comunicatii, ingineria proceselor de afaceri, precum si e-cetatenii care
trebuie sa foloseasca servicii publice oferite de orice forma de administratie publica (la
nivel de oras, provincie, national sau international).
In continuarea acestui capitol vor fi prezentate principalele tipuri de servicii necesare in
administratia publica pentru cetateni si companii. Apoi, se va face o scurta trecere in
revista a principalelor aspecte ale e-Guvernarii, scotandu-se in evidenta ultimele evolutii si
servicii folosite. Astfel, se ajunge la definirea notiunilor de e-Participare si e-Incluziune ale
cetatenilor la e-Guvernare. Vom discuta apoi serviciile de e-Guvernare oferite in Romania,
precum li principalele directii de evolutie din perioada imediat urmatoare. Tot in cadrul
acestui capitol va fi prezentata o scurta comparatie cu serviciile de aministratie publica
oferite prin e-Guvernare de catre alte tari europene. Capitolul curent se termina cu
prezentarea principalelor metrici de performanta in e-gov si prezentarea statisticilor ce
reflecta pozitia Romaniei la nivel mondial si european.
1.2 Tipuri de servicii in administratia publica
Exista o gama larga de servicii oferite in administratia publica, atat la nivel local, cat si
national. Scopul acestei sectiuni nu este de a furniza informatii despre toate aceste
servicii, ci de a delimita clar serviciile care sunt o prioritate in acest moment pentru e-
Guvernare. Astfel, exista un set de 20 de servicii monitorizate la nivel european (12 pentru
cetateni si 8 pentru operatorii economici), si pentru care se urmareste cresterea calitatii
furnizarii acestora, cresterea numarului de utilizatori, cresterea gradului de acoperire
pentru diferite categorii si a nivelului de dezvoltare. Serviciile adresate cetatenilor din lista
aceasta sunt urmatoarele:
1. Serviciile pentru colectarea impozitului pe venit al cetatenilor;
2. Cautarea unui loc de munca;
3. Serviciu pentru urmarirea beneficiilor asistentei sociale;
4. Eliberarea documentelor personale;
5. Serviciu pentru inmatricularea autovehiculelor;
6. Eliberarea autorizatiilor de constructie;
5
7. Serviciu pentru monitorizarea declaratiilor la politie;
8. Serviciu pentru librariile publice;
9. Eliberarea certificatele personale;
10. Inscrierea in universitati;
11. Serviciu pentru anuntarea schimbarii de domiciliu;
12. Servicii de sanatate pentru cetateni;
Serviciile adresate companiilor sunt cele de mai jos:
13. Plata si monitorizarea contributiile sociale;
14. Serviciu pentru plata impozitului pe profit;
15. Serviciu pentru plata TVA;
16. Inregistrarea operatorilor economici noi si modificarea datelor operatorilor
economici existenti;
17. Date statistice ale operatorilor economici;
18. Serviciu pentru gestiunea declaratiilor vamale;
19. Eliberarea autorizatiilor de mediu;
20. Serviciu pentru achizitiile publice.
Dupa cum se poate observa, aceste servicii sunt esentiale in administratia publica, fiind
folosite de catre aproape toti cetatenii si toate companiile. Acestea au fost si motivele
pentru care au fost incluse de catre Comisia Europeana in lista serviciilor fundamentale
pentru procesul de guvernanta, fiind monitorizata oferirea acestor servicii online, in cadrul
programelor de e-Guvernare. Dupa cum se poate observa si din figura 1, toate tarile
membre ale Uniunii Europene au cunoscut o crestere accelerata a disponibilitatii in
varianta online acestor servicii in ultimii 10 ani [4]. Mai mult, se constata ca exista o
disponibilitate online mai mare a serviciilor publice adresate companiilor, decat cele
adresate cetatenilor.
6
1
Figura 1. Evolutia serviciilor publice fundamentale complet disponibile online in tarile EU27+
Din punct de vedere al evaluarii prezentei online a acestor servicii publice, Comisia
Europeana a stabilit sa foloseasca un model al maturitatii serviciului impartit in 5 etape [4],
care sunt prezentate in tabelul 1. In figura 2 (preluta tot din [4]), sunt prezentate aceste
etape ca etape in maturizarea serviciului public online, in acest context etapele mai fiind
numite si stagii de sofisticare. In cadrul acestui model, este esential sa se atinga cel putin
nivelul 3, care de altfel este un standard in majoritatea tarilor europene in acest moment.
Formularele electronice sunt disponibile pentru cele mai multe servicii din lista celor 20 de
servicii publice esentiale monitorizate. De asemenea, nivelul tranzactional, numit si
manipularea integral electronica a cazului, in care utilizatorul aplica pentru folosirea
serviciului online si il poate folosi fara a fi nevoie de birocratie suplimentara devine in
ultima perioada un standard pentru oferirea serviciilor publice online. Ultimul nivel din
modelul maturitatii serviciului, targetizarea, este folosit pentru a identifica gradul de
integrare a datelor din front- si back-office, daca aceste date sunt reutilizate, iar serviciile
oferite sa fie proactive. Doar serviciile care sunt in nivelul 4 sau 5 sunt considerate a fi
complet disponibile online.
Tabelul 1. Stagiile de sofisticare folosite pentru masurarea maturitatii serviciilor publice online
Etapa Descriere etapa

1 Sa existe materiale de informare online pentru serviciul public.
2 Existenta interactiunii cu cetateanul intr-un singur sens (de exemplu: download de formulare)
3 Existenta interactiunii cu cetateanul ambele sensuri (de exemplu: completarea formularelor
online)
4 Existenta tranzactiilor pentru folosirea serviciului public online. Trebuie sa fie incluse
modalitati de decizie, notificare, livrare si plata a serviciilor publice
5 Automatizare, personalizare target-izare (targetization)
Figura 2. Masurarea maturitatii serviciilor publice online, model definit de C.E.
1
EU27+ include toate rile membre ale Uniunii Europene, precum i Croaia, Elveia, Islanda i Norvegia.
7
Folosind acest model, se poate masura maturitatea sau sofisticarea serviciilor publice
online oferite de fiecare tara. In figura 3 este prezentat nivelul mediu de sofisticare al
serviciilor publice fundamentale din tarile EU27+, inclusive evolutia acestui indicator intre
2007 si 2009 cand au fost facute ultimele 2 evaluari. Din aceste date, se observa ca
Romania ocupa ultimul loc intre tarile membre ale Uniunii Europene cu un nivel mediu al
sofisticarii doar un pic peste 60%. Aceasta inseamna ca in Romania sunt foarte putine
servicii care sa poata fi considerate complet disponibile online. Din figura se poate observa
ca tarile care alcatuiesc top 10 au un nivel de sofisticare de peste 90%, printre acestea
existand si tari din EU12 (Slovenia si Estonia). Totusi, singurele tari care au un nivel de
maturitate de 100% sunt Malta si Portugalia.
Figura 3. Nivelul mediu al sofisticarii serviciilor publice online in tarile EU27+

La nivel european, serviciile publice adresate companiilor sunt mai mature decat cele
adresate cetatenilor. Acest lucru confirma un trend global: Guvernele continua prioritizarea
dezvoltarii serviciilor pentru companii intrucat acestea au o rata de adoptare mai mare
(unele fiind obligatorii de folosit in anumite tari) si un impact mai important asupra
performantelor economice ale tarii. Nivelul mediu de sofisticare al serviciilor publice online
oferite companiilor era in 2009 de 90% la nivelul EU27+, in timp ce serviciile adresate
cetatenilor se situa doar la 78%.
Cele 20 de servicii publice fundamentale pot fi grupate in 4 categorii:
servicii generatoare de venituri pentru administratia publica (taxe, contributii sociale,
TVA, taxe vamale);
servicii de registratura (pentru masini, companii, nasteri si casatorii, domiciliere,
date statistice despre companii si cetateni);
servicii utile publicului (sanatate, biblioteci publice, licitatii publice, stabilirea
politicilor, cautarea de slujbe);
servicii pentru permise si licente (pentru autovehicule, cladiri, carti de identitate,
pasapoarte, eliberarea diplomelor de studii, avize de mediu).
8
Desigur ca nivelul de sofisticare este diferit pentru fiecare grup de servicii, dupa cum este
evidentiat in figura urmatoare (preluata din [4]). Serviciile publice online cele mai mature in
Uniunea Europeana sunt cele din prima categorie, care genereaza venituri directe
administratiei publice, iar cele mai putin mature servicii sunt cele pentru eliberarea de
permise si licente, care nu aduc nici un beneficiu direct statelor.
Figura 4. Gradul de sofisticare al serviciilor publice online in EU27+, in functie de categoria serviciului
Intrucat pentru o e-Guvernare eficienta este absolut necesar ca aceste 20 de servicii
fundamentale sa fie complet disponibile online (deci sa se afle pe nivelul 4 sau 5 de
maturitate), are sens o analiza mai atenta a datelor din EU27+ asupra progresului facut de
fiecare stat in parte si a procentului de servicii care sunt complet disponibile online. Aceste
date sunt prezentate in figura 5 [4].
Tot in [4] a fost facuta o analiza suplimentara asupra ratei de atingere a tuturor cerintelor
necesare pentru indeplinirea perfecta a nivelul de sofisticare 5. Dupa cum se poate
observa, din acest punct de vedere rezultatele sunt mediocre, media la nivel EU27+ fiind
de doar 50%, cu toate avantajele oferite de potentialul utilizarii tehnologiei pentru
restructurarea proceselor administrative. Astfel doar jumatate din serviciile care ar putea fi
livrate complet automatizat (de exemplu, serviciile de plata a taxelor) sau personalizat (de
exemplu, serviciile pentru documente personale sau biblioteci publice) au atins acest nivel
de maturitate.
9
Figura 5. Rata de disponibilitate online completa a serviciilor publice din fiecare stat
Figura 6. Rata de sofisticare de nivel 5 (targetizare sau serviciu proactiv)
1.3. e-Guvernare
1.3.1. Descrierea domeniului de servicii e-Guvernare
Dupa cum a fost mentionat si in introducere, termenul de e-Guvernare, provenind de la

guvernare digitala, se refera la toate modalitatile folosite de Guvernare (administratia
publica locala sau nationala) de a utiliza tehnologiile oferite de tehnologia informatiei si
telecomunicatii, pentru a imbunatati eficienta si eficacitatea sectorului public. In afara celor
20 de servicii publice fundamentale identificate de catre Comisia Europeana, conceptul de
e-Guvernare merge mult mai departe. De exemplu, folosind e-gov este posibil ca vizitand
site-ul web al unui oras sa fie permisa comunicarea cu angajatii administratiei locale prin
interfete grafice incorporate in site, prin mesagerie instanta, conversatii audio-video si
orice alte tehnologii mai avansate. Mai mult decat atat, pot fi introduse noi metode
10
colaborative de propunere de legi si alte initiative legislative locale venite din partea
cetatenilor, daca acestia reusesc sa acumuleze un numar suficient de mare de semnaturi
digitale de la alti concetateni, folosind site-uri web specializate pentru aceste activitati
administrate de administratiile publice. Aceleasi metode colaborative pot fi folosite pentru
discutarea propunerilor legislative cu societatea civila, asigurand accesul fiecarui cetatean
la a fi de acord sau in dezacord cu anumite prevederi ale acestor propuneri.
Sumarizand, e-Guvernarea implica folosirea tehnologiilor IT&C pentru a imbunatati
accesul la serviciile publice, modalitatea de livrare a acestora catre contribuabili, pentru a
aduce beneficii cetatenilor, companiilor si angajatilor. Principalele obiective ale e-
Guvernarii sunt:
Folosirea tehnologiilor IT&C, in special a Internetului, pentru a oferi servicii publice
mai calitative si a atinge o guvernanta mai buna;
Folosirea tehnologiilor IT&C in toate aspectele operationale ale organismelor
administratiei publice locale si centrale;
Optimizarea continua a livrarii serviciilor publice si a procesului de guvernanta prin
transformarea relatiilor interne si externe prin intermediul tehnologiei, a Internetului
si a conceptului de new-media (sau media online).
Doua directii de evolutie sunt foarte importante pentru conceptul de e-Guvernare. In primul
rand, desi e-Guvernarea este inteleasa, in mod traditional, ca fiind axata in jurul
operatiunilor administratiilor publice locale si centrale, e-Guvernanta are are o definitie
extinsa, incercand sa includa si implicarea si participarea cetatenilor la actul de guvernare,
an scopul de a ambunatati deciziile luate de guvernare in folosul majoritatii cetatenilor.
Exact in acest context, au sens notiunile de e-Participare si e-Incluziune a cetatenilor la
procesul de e-Guvernanta, notiuni ce sunt prezentate in detaliu in sectiunea urmatoare.
A doua directie, o reprezinta faptul ca desi e-Guvernarea este definita de multe ori ca
Guvernare online sau Guvernare folosind Internetul, exista multe tehnologii de
Guvernare electronica care nu folosesc Internetul ca mediu de comunicatie cu cetatenii si
companiilor. Printre acestea se numara: folosirea SMS-urilor si a MMS-urilor, folosirea
retelelor si a serviciilor mobile, Bluetooth, CCTV, RFID, identificarea biometrica a
persoanelor, sisteme de management a traficului rutier, cardurile destepte, metode de
livrare a serviciilor publice prin TV si radio, folosirea comunitatilor online (inclusiv a
retelelor sociale), mesagerie instanta si chat, etc.
Strategia nationala de creare a platformei e-Romania, reprezinta ultimul si cel mai complex
proiect pentru e-Guvernare in Romania. Din [3], reiese ca semnificatia si importanta e-
Guvernarii este datorata faptului ca guvernarea electronica reprezinta simplificarea
modurilor de lucru prin aplicarea unor tehnologii ale informatiei si ale comunicatiilor in
zonele de administrare a informatiilor, de comunicare si de tranzactii in cadrul si intre
institutiile de stat, precum si intre stat si cetateni sau operatorii economici. Tot in aceasta
strategie se observa ca nu sunt definite decat primele patru nivele de sofisticare ape
serviciilor publice, rezultand faptul ca nivelul al 5-lea, cel al serviciilor publice online
proactive, complet mature, nu a fost luat in considerare. Astfel, scopurile e-Guvernarii sunt
definite doar de (date preluate tot din [3]):
Informare: informatiile vor fi disponibile on-line, prin publicarea lor pe site-ul web al
unei autoritati publice (nivelurile 1 si 2 de sofisticare);
11
Comunicare: capacitatea de a avea acces interactiv si de a face schimb de
informatii (nivelul 3 de sofisticare);
Tranzactie: realizarea efectiva de servicii, inclusiv semnarea de formulare de cerere
si livrari electronice ale documentelor oficiale si notificarilor (nivelul 4 de sofisticare).
Printre beneficiile aduse de e-Guvernare, cele mai importante se refera la:

Usurinta de acces si accesul non-stop la serviciile publice: mediile de comunicatie
electronice sunt disponibile oricand, nu implica costuri suplimentare (timp, energie
si bani) din partea contribuabililor.
Eliminarea necesitatii deplasarii contribuabililor la oficiile administratiei publice,
rezultand in economia de timp pentru cetateni si companii, ceea ce se traduce in
cresterea productivitatii economice.
Cresterea participarii si implicarii cetatenilor in procesul de guvernare. Folosind
servicile de e-Guvernare, orice cetatean poate sa isi comunice punctul de vedere
atat catre autoritatile publice, dar si catre concetateni. Astfel, votantii pot avea un
impact direct si pot influenta procesul de guvernare.
Pastrarea datelor in format digital permite autoritatilor sa reevalueze si sa simplifice
procedurile si formularele care sunt considerate prea complicate de catre public.
E-Guvernarea ofera doar o alternativa pentru interactiunea clasica (la ghiseu) cu
autoritatile publice, dar acest lucru nu inseamna ca acestea sunt eliminate, ci ele
functioneaza in paralel, astfel incat fiecare cetatean poate alege modalitatea de
interactiune cu serviciile publice (online sau la ghiseu).
E-Guvernarea asigura o transparenta suplimentara procesului de guvernare,
datorita faptului ca datele de interes public pot fi accesate online, rapid si fara efort,
de oricine. Se pot verifica astfel discrepante in declaratiile de avere, voturile alesilor,
etc.
Exista si un avantaj ecologic pentru folosirea e-Guvernarii, prin renuntarea la
folosirea hartiei pentru actele publice.
Viteza, eficacitatea si comoditatea folosirii serviciilor publice online de catre cetateni
si companii.
Avantaje pentru salvarea si indexarea datelor in baze de date electronice spre
deosebire de folosirea fisetelor pentru hartii.
Aprobarea publicului: peste tot unde au fost introduce, opinia publica a avut o
reactie pozitiva fata de serviciile publice electronice. De exemplu, in statul Alabama
s-au vandut peste 140.000 de autorizatiile electronice de vanatoare si pescuit doar
in primul sezon cand s-a introdus aceasta modalitate de eliberare a autorizatiilor.
Exista totusi si o serie de dezavantaje in utilizarea e-Guvernarii, care sunt insa sensibil mai
putine decat avantajele:
Principalul dezavantaj si risc il reprezinta hiper-supravegherea contribuabililor. Daca
se doreste, prin folosirea diverselor tehnologii pentru e-Guvernare (online, dar si
offline de exemplu retelele mobile, camere de luat vederi, etc.) autoritatile publice
pot avea o evidenta foarte buna asupra activitatilor contribuabililor. Daca acest lucru
prezinta un avantaj in anumite situatii (de exemplu, supravegherea activitatilor
teroriste sau criminale), poate fi si o incalcare a libertatilor cetatenilor.
Exista costuri financiare din ce in ce mai ridicate pentru implementarea si
mentenanta serviciilor de guvernare electronica.
12
Inaccesibilitatea serviciilor de guvernare electronica pentru anumite categorii de
cetateni: aflati in locatii fara conexiune la Internet, cetatenii cu deficiente de vedere
sau cei care nu isi pot permite utilizarea calculatoarelor din diverse motive.
Sentimentul fals de transparenta: intrucat autoritatile au acces la date, acestea pot
sa fie alterate sau eliminate, fara ca publicul sa constientizeze acest lucru.
Serviciile de guvernare electronica pot fi tintele unor atacuri electronice si acesta
reprezinta un risc constant.
Pentru ca serviciile de guvernare electronica sa fie folosite cu succes si adoptate de catre

utilizatori, acestea trebuie sa satisfaca niste cerinte [3]:
Sa ofere incredere si securitate: Cetatenii trebuie sa aiba incredere in autoritatea
publica electronica la fel de mult cum au in cea traditionala. Cetateanul trebuie sa
poata verifica faptul ca versiunile electronice ale documentelor oficiale pe care le
primesc nu au fost modificate si au fost trimise de catre autoritati.
Posibilitatea de autentificare si semnatura electronica: Autoritatile publice trebuie sa
poata verifica daca documentele primite de la cetateni ajung in starea lor originala
si daca acestea sunt cu adevarat trimise de catre o anumita persoana.
Transparenta: Schimbarile tehnice vor fi acceptate doar daca ele vor fi acceptate de
toti cei vizati si daca aceste schimbari vor fi facute intr-un mod transparent.
Accesibilitatea: Serviciile publice electronice trebuie sa fie accesibile tuturor, fara
discriminare. Solutiile oferite, precum si site-urile web trebuie sa fie fara bariere si
accesibile tuturor.
Usurinta de folosire: Gama de servicii electronice oferite trebuie sa fie structurata
intr-un mod usor de inteles, simplu si clar. In plus, formularele si portalurile vor
trebui sa aiba un design consistent. Navigarea si meniurile trebuie sa fie intuitive si
logice, cu o structura familiara, astfel incat utilizatorii sa poata gasi rapid ceea ce
cauta.
Securizarea datelor: Cetatenii acorda un grad ridicat de incredere administratiei in
ceea ce priveste protectia datelor. Sectoarele specifice de identificare personala vor
fi special concepute pentru a fi in conformitate cu standardele de protectie a datelor.
Cooperarea intre autoritati: e-Guvernarea functioneaza cel mai bine atunci cand
toate nivelurile de guvernare lucreaza impreuna, de la autoritatile locale pana la
ministere. Aplicatiile si infrastructurile existente vor trebui sa lucreze impreuna
pentru a se putea ajunge la nivelul dorit de eficienta.
Modularitate: e-Guvernarea are o structura modulara, care permite integrarea
imediata a noilor componente in sistem pentru a tine pasul cu cele mai recente
tehnologii.
Interoperabilitatea: Tipuri diferite de sisteme vor trebui sa fie capabile sa comunice
unul cu celalalt.
Totusi, in special in contextul proiectului INSEED este important de remarcat ca e-

Guvernarea nu inseamna doar tehnologii IT&C, ci include de asemenea cunostinte si
educatie2. Astfel, guvernarea electronica este strans legata de:
2
Mai multe detalii despre legtura ntre e-Guvernare si educatie la adresa (wiki al Unviersitii din Haga):
http://wiki.triastelematica.org/index.php/Education:EGovernment_-_a_holistic_approach_%28II%29
13
Capitalul uman: e-gov imbuatateste experienta tuturor participantilor la acest
proces, crescand astfel valoarea sistemelor informatice;
Sistemele de management a cunostintelor;
Incurajarea si sprijinirea impartasirii de experiente: informatie + experienta +
rezultate = cunostinte;
Sprijinirea si diseminarea normelor celor mai bune practici pentru folosirea cat mai
eficienta si dezvoltarea serviciilor publice electronice;
Inovarea in e-gov aduce beneficii atat cetatenilor, cat si angajatilor din administratia
publica;
Aplicatiile pentru managementul relatiilor cu cetatenii sunt niste unelte software utile
pentru a imbunatati comunicarea intre administratia publica si utilizatori;
Sprijinirea invatarii pe tot parcursul vietii: regulamentele, legile si organizatiile se
schimba, iar oamenii trebuie sa fie sprijiniti sa se adapteze la ele;
Servicii de e-learning pentru a oferi training pentru folosirea tehnologiilor relevante
pentru e-Guvernare.
In plus, o analiza atenta asupra e-Guvernarii si potentialului de inovare in acest domeniu
trebuie sa tina cont ca e-gov nu inseamna numai tehnologie, ci trebuie sa includa si
elemente de strategie politica. Astfel, de multe ori exista tendinta de a uita ca modelele din
e-Comert nu se transfera pur si simplu catre e-Guvernare intrucat guvernanta in
administratia publica nu este acelasi lucru cu guvernanta din corporatii. Astfel, suplimentar
fata de elementele strategice, tactice si operationale care se gasesc in companii, e-
Guvernarea trebuie sa includa si procesele politice. Nivelul politic influenteaza toate
politicile si actiunile guvernamentale aflate pe un nivel inferior in figura 7. Totusi, dupa cum
se poate observa din aceeasi figura, satisfactia cetatenilor poate influenta aceasta
strategie politica prin bucla de feedback (sageata cu numarul 9).
Astfel, inovarea in serviciile din administratia publica trebuie sa tina cont de o multitudine
de factori diferiti:
Legislatie, reguli si practici;
Detalii despre organizatiile si procesele guvernamentale;
Tehnologie si continutul serviciilor;
Cunostinte si capital uman;
Comunicare si accesabilitate.
Numai lucrand cu toti acesti factori intr-o maniera holista, poate fi posibil sa fie evitate
erorile facute de e-Comert. E-Guvernarea efectiva necesita integrarea informatiilor de pe
toate aceste nivele, ceea ce inseamna inclusiv integrarea proceselor si modelelor
organizationale.
14
Figura 7 . Complexitatea procesului de e-Guvernanta in care aplicatiile inglobeaza foarte multe cunostinte
de pe niveluri diferite: politic, administrativ, strategic, birocratic (figura preluata din [6]).
1.3.2. e-Participare si e-Incluziune

Dupa cum s-a mentionat si in sectiunea anterioara, unul dintre rolurile principale ale e-
Guvernarii este de a oferi putere si de a include cetatenii in procesul de luare a deciziilor.
Atat cetatenii, cat si sistemele democratice de guvernare pot beneficia din imbunatatirea
accesului la informatiile si serviciile publice. Studiul Organizatiei Natiunilor Unite despre e-
Guvernare [10] masoara canalele oferite de administratiile publice pentru participarea
online a cetatenilor si modul in care le sunt ascultate opiniile, masurand astfel puterea
oferita cetatenilor si includerea lor in luarea deciziilor. Astfel este definit un index pentru e-
participare ce tine cont de mecanismele pentru consultarea si luarea deciziilor folosind
opinia cetatenilor. Exista trei teste pentru evaluarea acestui index:
Daca Guvernul publica online informatiile necesare pentru luarea deciziilor
guvernamentale.
Daca sunt oferite publicului oportunitati de a participa la consultari cu oficialii
guvernamentali si institutiile care sunt responsabile de politicile guvernamentale.
Daca cetatenii pot influenta direct deciziile, de exemplu prin vot online sau prin vot
folosind telefoanele mobile.
Modalitatile prin care publicul poate fi implicat in luarea deciziilor si care sunt utile pentru
stimularea e-participarii sunt foarte diverse, folosind principalul avantaj al Internertului:
chiar si vocile marginalizate pot fi auzite online, mai ales cu aparitia si dezvoltarea Web-
ului social. Cele mai frecvente modalitati de stimulare a e-participarii sunt:
Folosirea chestionarelor de feedback si consultarea acestor rezultate;
15
Folosirea sondajelor si votarii online si publicarea rezultatelor pe site-urile
institutiilor publice si utilizarea acestor date in elaborarea politicilor publice;
Folosirea Web2.0 si a retelelor sociale pentru comunicarea mesajelor importante;
Integrarea uneltelor colaborative in site-urile ministeriale (de exemplu, wiki-uri si
blog-uri);
Utilizarea camerelor de chat;
Utilizarea consultarii populatiei prin SMS;
Monitorizare blog-urilor si grupurilor de pe retele sociale relevante pentru actul de
guvernare;
Creearea de catre administratia publica de pagini si grupuri in site-urile celor mai
importante retele sociale;
Oferirea cetatenilor a posibilitatii de a face propriile propuneri, care apoi sunt e-
deliberate si folosite de administratiile centrale si locale in luarea deciziilor;
Folosirea forumurilor de discutii, la care sa participe nu doar cetatenii, dar si oficiali
guvernamentali seniori, cu putere de decizie;
Oferirea de date suplimentare despre evenimentele de e-participare si e-incluziune
viitoare (de exemplu, calendare, etc.).
E-participarea este la randul sau divizata in trei criterii diferite: e-infomare, e-consulare si
e-luarea deciziilor. E-informarea masoara daca administratia publica ofera acele informatii
care incurajeaza si stimuleaza e-participarea. Aceasta include publicarea online a
politicilor despre e-participare, a calendarului discutiilor si consultarilor, precum si utilizarea
de unelte electronice pentru notificarea automata a cetatenilor care si-au manifestat
interesul de a participa la aceste consultari. Principalele metode de e-consulare includ:
sondaje online, voturi online, formulare de feedback, camere de chat, blog-uri, liste de stiri.
Utilizarea uneltelor specifice Web2.0 este inca in faza incipienta. Indicatorul de e-luare a
deciziilor masoara nivelul la care tarile sunt dedicate includerii opiniilor cetatenilor in
elaborarea politicilor guvernamentale. Cele mai populare tehnologii sunt: utilizarea
forumurilor de discutii, folosirea arhivelor discutiilor anterioare, oficialii guvernamentali
raspund intrebarilor cetatenilor, oficialii modereaza e-consultari, folosirea petitiilor online si
a voturilor online. Doar 9% dintre tarile monitorizate permit creearea, semnarea electronica
de catre mai multi cetateni si trimiterea de petitii online catre autoritati in 2010.
1.3.3. e-Guvernare in Romania

In raportul e-Government in Romania al Comisiei Europene [5] este prezentata starea
actuala a serviciilor publice electronice din Romania. Desi este evidenta inapoierea
acestor servicii fata de media europeana, este important de observat ca atat proiectul
anterior, e-guvernare.ro, cat si noul proiect propus in 2010, e-Romania, sunt inca intr-o
faza incerta de realizare, in special datorita lipsei finantarii si a problemelor cauzate de
licitatiile publice. Totusi, acest raport prezinta starea de fapt a disponibilitatii serviciilor de
e-Guvernare in Romania anului 2010, pe care le-am sintetizat in acest subcapitol. Fiind un
raport al Comisiei Europene, accentul s-a pus pe gradul de maturitate al celor 20 de
servicii publice fundamentale prezentate in sectiunea 1.2.
16
Serviciile publice electronice pentru cetateni care au fost analizate sunt urmatoarele.
1. Serviciile pentru colectarea impozitului pe venit al cetatenilor
- Adresa web: http://formulare.e-guvernare.ro/Forms/default.aspx
- Nivel de sofisticare: 2, 3 sau 4 (depinzand de orasul de resedinta)
- Formularele pot fi semnate electronic, iar in 50% din municipalitati impozitele pe
venit pot fi platite online
2. Cautarea unui loc de munca

- http://www.anofm.ro; http://www.semm.ro
- Nivel de sofisticare: 3
- Locurile de munca pot fi cautate inca din 2002
3. Serviciu pentru urmarirea beneficiilor asistentei sociale

- Ajutorul pentru somaj: http://www.mmssf.ro; http://www.anofm.ro , nivel de
sofisticare: 2 (informatii online si formulare pentru download)
- Alocatiile pentru copii: http://www.mmuncii.ro/ro/; http://sas.mmssf.ro , nivel de
sofisticare: 1 (infomare)
- Asigurari medicale: http://formulare.e-guvernare.ro/Forms/default.aspx , nivel de
- Burse scolare: http://www.edu.ro , nivel de sofisticare: 1 (infomare)
4. Eliberarea documentelor personale

- Pasaport: http://www.pasapoarte.mai.gov.ro/; http://www.mai.gov.ro/ , nivel de
- Carnet de conducere: http://www.mira.gov.ro/Home/index.htm , nivel de
5. Serviciu pentru inmatricularea autovehiculelor

- http://www.mira.gov.ro/Home/index.htm
6. Eliberarea autorizatiilor de constructie

- Nu exista
7. Serviciu pentru monitorizarea declaratiilor la politie
17
- http://www.politiaromana.ro
- Nivel de sofiticare: 1
8. Serviciu pentru librariile publice

- http://www.cultura.ro
9. Eliberarea certificatele personale

- Nu exista
10. Inscrierea in universitati

- http://www.edu.ro
- Nu exista serviciu centralizat, posibilitatea de inscriere online depinde in functie de
unviersitate
11. Serviciu pentru anuntarea schimbarii de domiciliu

- http://www.mai.gov.ro
12. Servicii de sanatate pentru cetateni

- www.ms.ro
Serviciile adresate au un grad de sofisticare un pic mai bun decat cele adresate
cetatenilor:
13. Plata si monitorizarea contributiile sociale
- https://formularunic.e-guvernare.ro/ , http://www.anaf.ro/public/wps/portal/ANAF
14. Serviciu pentru plata impozitului pe profit

15. Serviciu pentru plata TVA
18
16. Inregistrarea operatorilor economici noi si modificarea datelor operatorilor

economici existenti
- http://www.onrc.ro/; http://recom.onrc.ro/index.htm
17. Date statistice ale operatorilor economici

- http://www.insse.ro/cms/rw/pages/index.ro.do
- Nivel de sofisticare: 3 sau 4
18. Serviciu pentru gestiunea declaratiilor vamale

- Nu exista
19. Eliberarea autorizatiilor de mediu

- http://www.mmediu.ro
20. Serviciu pentru achizitiile publice.

- www.e-licitatie.ro
- Nivel de sofisticare: 4 sau 5
Concluzia este ca in Romania exista un nivel mare de fragmentare al serviciilor de e-

Government si nu exista un one-stop shop (punct de contact unic, punct unic de
asistenta). De asemenea, serviciile sunt deconectate, majoritatea sunt in stagii de
dezvoltare incipienta, oferind doar informatii si comunicare intr-un singur sens, prin
oferirea formularelor utile spre download. Se observa insa un inceput de punct unic de
asistenta pentru companii, ceea ce este un lucru de laudat. In plus, serviciul de licitatii
publice din Romania este considerat unul dintre serviciile cu cel mai mare succes si grad
de sofisticare, fiind printre putinele servicii oferite la un nivel european.
1.3.4. Metrici de performanta in e-Guvernare
In prezent, exista mai multe metrici de evaluare a performantei in e-Guvernare, dar cele
mai importante sunt cele definite de catre Organizatia Natiunilor Unite [10] si de catre
Comisia Europeana [3]. Cei mai importanti indicatori din cele doua metodologii sunt:
19
Modelul sofisticarii serviciului, in 5 etape, definit de catre CE si discutat in sectiunea
1.2. Romania ocupa ultimul loc in UE conform acestui indicator si penultimul loc in
EU27+.
Modelul de dezvoltare al serviciului public electronic, definit de catre raportul ONU,
foloseste numai 4 etape, dar care sunt foarte similare cu cele ale modelului anterior:
etapa 1 servicii de informare emergente, etapa 2 servicii de informare avansate,
etapa 3 servicii transactionale si etapa 4 servicii conectate, proactive. Practic, in
acest model, etapa a doua de dezvoltare include nivelurile 2 si 3 din modelul propus
de CE.
Indicatorul pentru eProcurement ce masoara nivelul de dezvoltare al serviciilor
pentru licitatie publica, considerat foarte important de catre CE. Romania are un scor
de 36% pentru acest indicator, maximul fiind de 100%. Si acest indicator este format
din 2 scoruri diferite: pre-contract-award si post-award-transaction, care masoara
evolutia licitatiilor publice inainte de castigarea licitatiilor, respectiv modul in care se
desfasoara tranzactia dupa ce licitatia publica a fost adjudecata.
Metrica pe 5 axe pentru evaluarea experientei cu utilizatorul definita tot de CE. Cele
5 criterii de evaluare sunt: utilizabilitatea, accesibilitatea pentru crawlere web,
monitorizarea gradului de satisfacere a utilizatorilor, utilizarea unei abordari de tipul
one-stop-shop si design al unui portal axat pe utilizator. Din acest punct de vedere,
Romania sta foarte rau intrucat pe 3 axe scorul sau este zero dupa cum se poate
observa din figura 8.
Figura 8 . Indicatorul Romaniei pentru experienta utilizatorului in relatia cu serviciile publice electronice.
Indicatorul pentru e-participare definit de catre ONU, care este format din 3
componente discutate in sectiunea 1.4.
Indicatorul general pentru e-Guvernare utilizat de catre ONU, care combina scorul
pentru nivelul de dezvoltare al serviciilor cu scorul indicatorului pentru e-participare.
20
Romania ocupa locul 47 in clasamentul oferit de ONU pentru acest indicator in 2010,
cu un scor de 0.55/1.00.
1.4. Servicii publice de consultanta si asistenta pentru mediul de afaceri
Serviciul public de consultanta este un serviciu profesional de consiliere si, la cerere, de
implicare, realizat de catre specialisti din institutiile publice si avand ca scop sprijinirea
managerilor din mediul privat in realizarea obiectivelor de afaceri. Actiunile consultantilor
pot fi corective, progresive sau creative.
Serviciile publice de consultanta si asistenta in managementul financiar fac parte din
interventia publica pentru crearea unui mediu de afaceri favorabil dezvoltarii unei piete
libere, globalizate si competitive.
In Romania, in decursul timpului, serviciile de consultanta oferite de catre institutiile
publice s-au diversificat, acoperind o arie larga de activitati de consultanta la nivel national,
regional, judetean si local. Regula generala ar fi ca aceste servicii sa fie oferite in mod
gratuit, insa exista si exceptii in care institutiile publice regionale sau judetene pot oferi si
servicii pe baze contractuale, contra cost. Spre deosebire de sectorul privat, institutiile
publice ofera consultanta financiara, si de alta natura, alaturi de alte servicii publice
specifice, pentru care au fost create.
Serviciile publice de consultanta si asistenta financiara pentru mediul de afaceri sunt
oferite/ furnizate de urmatoarele categorii de institutii:
Institutii si organizatii internationale
Aceste servicii publice sunt adresate cu precadere sectorului IMM-urilor, dar nu numai.
Dintre principalele servicii amintim:
Enterprise Europe Network: o retea de peste 500 de organizatii din Europa ce
furnizeaza servicii de informare despre politicile, programele si legislatia comunitara,
cautare de parteneri de afaceri, brokeraj pentru transferul de tehnologii, evaluarea
nevoilor materiale, financiare, de know-how etc.;
Euro Info Centrale: acorda IMM-urilor servicii-suport in urmatoarele domenii
tematice: programe si surse de finantare, cooperare in afaceri si cautare de parteneri,
evaluarea calitatii si marcarea produselor, accesul pe noi piete, protectia mediului si
dezvoltarea durabila, achizitii publice, dezvoltare tehnologica, societate
informationala si e-business;
SOLVIT: este o retea on-line disponibila statelor membre UE unde se cauta
solutionarea problemelor transfrontaliere legate de: aplicarea impozitelor, libera
circulatie a capitalurilor si a platilor, accesul pe piata al produselor si serviciilor,
achizitiile publice etc.;
Portalul Europa voastra Intreprinderi: ofera informatii pentru societatile ce
desfasoara activitati economice in alt stat din UE. Portalul este oferit in comun de
catre Comisia Europeana si autoritatile nationale;
Programul de asistenta privind implementarea si respectarea legislatiei
mediului de catre IMM-uri: domeniile vizate in acest program sunt: reducerea
poverii administrative, integrarea in activitate a normelor de mediu, imbunatatirea
nivelului de know-how, cresterea gradului de comunicare intre organizatii etc.;
21
TechWeb destinat IMM-urilor: ofera servicii de informare si resurse IMM-urilor ce
doresc sa solicite finantare pentru cercetare in tehnologie;
InnovAccess: ofera servicii de informare in domeniul proprietatii intelectuale;
Altele: Reteaua Europeana a Centrelor de Afaceri si Inovare (C.A.I.); eMarket
Services; Lexelerator; Centrul de documentare privind responsabilitatea sociala
corporatista; Comert electronic (site); Grupul de consultare a intreprinderilor
europene (European Business Test Panel); Oficiul european pentru standardizare in
domeniul comertului, artizanatului si al IMM-urilor (N.O.R.M.A.P.M.E.).
Agentii publice romanesti
Agentia pentru Implementarea Proiectelor si Programelor pentru Intreprinderi
Mici si Mijlocii (A.I.P.P.I.M.M.) asigura implementarea tehnica si financiara a
proiectelor si programelor de sprijinire a infiintarii de noi intreprinderi si de sustinere
a dezvoltarii sectorului IMM. Agentia are 13 oficii teritoriale cu 195 de posturi.
Agentia Nationala pentru Ocuparea Fortei de Munca (A.N.O.F.M.), impreuna cu
cele 42 de agentii judetene si peste 180 de agentii locale, ofera servicii somerilor si
agentilor economici. Principalul sau obiectiv este cresterea gradului de ocupare a
fortei de munca si implicit scaderea ratei somajului. Pentru indeplinirea acestui
obiectiv organizeaza servicii de ocupare a fortei de munca, organizeaza, presteaza
si finanteaza servicii de formare profesionala, realizeaza propuneri privind
elaborarea proiectului de buget al asigurarilor pentru somaj, administreaza bugetul
asigurarilor pentru somaj si prezinta Ministerului Muncii, Familiei si Protectiei
Sociale rapoarte trimestriale si anuale privind executia bugetara, implementeaza
programe finantate din Fondul Social European. Consultanta si asistenta pentru
initierea unei activitati de intreprinzator se acorda, la cerere, persoanelor
neincadrate in munca, sub forma de servicii juridice, de marketing, financiare,
metode si tehnici eficiente de management etc.. Pentru someri si studenti,
consultanta si asistenta pentru inceperea unei activitati independente sau initierea
unei afaceri sunt gratuite.
Agentia Nationala de Consultanta Agricola (A.N.C.A.), aflata in subordinea
Ministerului Agriculturii si Dezvoltarii Rurale, are la nivel judetean 41 de Oficii
Judetene de Consultanta Agricola si, la nivel comunal, 546 de Centre Locale de
Consultanta Agricola si Casele Agronomului. A.N.C.A. ofera servicii de adaptare a
fortei de munca din mediul rural la economia de piata, de asistenta tehnica de
specialitate, de elaborare de proiecte de ferme-model, de modele tehnico-
economice cadru pentru culturi de plante si specii de animale, de proiecte de
accesare a fondurilor europene etc..
Oficiul de Stat pentru Inventii si Marci (O.S.I.M.) ofera servicii in domeniul
proprietatii industriale. La cerere, ofera si consultanta de specialitate si cursuri de
pregatire a specialistilor in domeniul proprietatii industriale. Centrele regionale
O.S.I.M. se gasesc in Galati, Constanta, Bacau, Suceava, Harghita, Brasov, Mures,
Maramures, Bistrita-Nasaud, Bihor, Timis, Dolj si Bucuresti.
Institutii publice descentralizate
Institutii regionale, agentii de dezvoltare regionala. A.D.R.-urile furnizeaza o
serie de servicii publice grupate in 4 categorii principale: Managementul
22
Programului Operational Regional 2007-2013; Programare regionala; Cooperare
externa; si Promovare regionala.
Institutii publice judetene. Aceste institutii au fost create pentru a furniza servicii
de planificare strategica si operativa pentru autoritatile publice locale, insa, in
subsidiar, ofera si consultanta mediului de afaceri. Dintre cele mai importante
enumeram: Agentia de Dezvoltare economico-sociala Timis (ADETIM) ce ofera
servicii de consultanta si management de proiect, cat si sprijin in accesarea
programelor de finantare, in vederea realizarii de obiective de investitii din sectorul
public si privat; Agentia de Dezvoltare Durabila a Judetului Brasov (ADDJB) ce
ofera servicii de consultanta pentru initiative de dezvoltare economica a judetului,
de dezvoltare a patrimoniului istoric, arheologic si cultural, de dezvoltare a
turismului zonal etc.; Agentia de Dezvoltare Judeteana Harghita ofera servicii de
consultanta financiara pentru dezvoltarea capitalului autohton si atragerea
capitalului strain, promovarea oportunitatilor de afaceri si cooperare la nivel
judetean, atragerea de fonduri europene s.a.; Agentia de Dezvoltare economico-
sociala Caras-Severin ofera servicii de asistenta tehnica si consultanta
intreprinderilor mici si mijlocii si investitorilor care prin activitatea lor imbunatatesc
mediul economic din judet; Agentia de Implementare a proiectelor de dezvoltare
a judetului Arges elaboreaza cereri de finantare si management de proiect,
pregateste documentatie pentru proiectele de accesare a fondurilor europene
nerambursabile; Agentia de dezvoltare economico-sociala a judetului
Hunedoara (ADEH) acorda consultanta in domeniul promovarii si sprijinirii initiativei
private si a ONG-urilor in vederea accesarii fondurilor structurale.
Structuri asociative, fundatii, ONG-uri
Serviciile de consultanta furnizate de structurile asociative sunt concentrate in
centre de asistenta antreprenoriala (CAA), se adreseaza de obicei IMM-urilor si
presupun informare, cercetare, organizare de evenimente, incubare, consultanta
financiara. Exista astazi mai multe categorii de CAA si anume: centre UNDP
(United Nations Development Programme) cu asistenta ONU, centre infiintate prin
fundatia CRIMM (Centrul Roman pentru IMM-uri) si centre PAEM (Programme of
Active Employment Measures) cu fonduri PHARE, centre finantate de British Know-
How Fund, centre romano-americane finantate initial de USAID (United States
Agency for International Development), centre finantate de guvernele Germaniei,
Olandei si altele.
Camerele de Comert sunt in tara noastra in numar de 42, cea mai mare fiind
Camera de Comert si Industrie a Romaniei si a Municipiului Bucuresti. Acestea
sprijina si promoveaza operatorii economici din industrie, agricultura, comert, turism
si servicii si acorda consultanta de afaceri, asistenta pentru constituirea si
functionarea societatilor comerciale, facilitare de contracte de afaceri de tip bi si
multiparteneriat, organizeaza misiuni de afaceri in strainatate etc.. De asemenea,
se organizeaza aici cursuri intensive pe probleme de organizare, conducere si
programare in afaceri.
Dintre organizatiile neguvernamentale care acorda consultanta mediului de
afaceri sunt de mentionat:
23
o Consiliul National al Intreprinderilor Private Mici si Mijlocii din Romania
(CNIPMMR) ofera servicii cu tarif preferential pentru membri, constand in
consultanta juridica, manageriala si de marketing, consultanta pentru
intocmirea planurilor de afaceri, intocmirea dosarelor pentru accesarea
diverselor surse de finantare, intocmirea formalitatilor pentru cumpararea
activelor disponibile ale statului etc..
o Reteaua CDIMM finantata din fonduri PHARE (Programul PHARE R9207)
din care au supravietuit si s-au dezvoltat CDIMM Braila, CDIMM Maramures
si CDIMM Arges. Centrele ofera consultanta pentru evaluarea ideilor de
afaceri, intocmirea planurilor de afaceri, finantarea afacerilor si management,
intocmirea studiilor de fezabilitate pentru investitori, analize si proiectii
financiare etc..
o Fundatia CRIMM, dependenta aproape integral de fondurile PHARE, a fost
nevoita sa isi restranga considerabil activitatea odata cu terminarea finantarii
europene.
o Fundatia Post-Privatizare (FPP) gestioneaza din februarie 2008 portalul
pentru IMM-uri www.esimplu.ro, cu cea mai vasta colectie de resurse on-line
pentru acestea. Portalul a facut parte din programul PHARE CES 2006 ce s-
a incheiat in februarie 2010. Din 2010 FPP se adreseaza antreprenorilor care
au deja o afacere si celor care sunt gata sa accepte provocarile unui demers
de infiintare a unei intreprinderi, atat in mod direct prin consultanta in
materie de fonduri structurale si surse de finantare, cat si indirect prin
intermediul Fondului Roman de Contragarantare, ce preia o parte din riscul
asumat de catre fondurile de garantare, la acordarea garantiilor pentru
creditele obtinute de IMM-uri.
1.5. Servicii publice de consultanta si asistenta pentru accesarea de fonduri
nerambursabile
Acestea constau in pregatirea accesarii fondurilor nerambursabile prin:
analiza eligibilitatii aplicantului si respectiv a proiectului acestuia;
asistenta in stabilirea grupului tinta in conformitate cu prevederile programului de
finantare;
stabilirea de solutii pentru incadrarea proiectului in conditiile programului de
finantare nerambursabila;
asistenta la identificarea de parteneri eligibili pentru proiect;
asistenta la stabilirea rolurilor si responsabilitatilor in cadrul parteneriatului incheiat
pentru implementarea proiectului;
consultanta la alocarea resurselor (materiale si umane) necesare si intocmirea
bugetului alocat pentru implementarea proiectului;
realizarea documentatiei de accesare a programului de finantare;
asistenta la pregatirea documentelor insotitoare cererii de finantare;
asistarea clientului in relatia cu Autoritatea Contractanta;
24
consultanta pentru pregatirea documentelor in vederea pre-contractarii finantarii
nerambursabile.
1.6. Servicii publice de consultanta si asistenta la implementarea proiectelor
finantate din fonduri nerambursabile
Se menioneaz aici trei categorii de servicii:
Servicii referitoare la managementul procedural al finantarii:
consultanta pentru insusirea de catre client a procedurilor (tehnice si financiare) de
lucru in cadrul programului/programelor de finantare nerambursabile;
asistarea clientului in relatia acestuia cu autoritatea contractanta in procesul de
implementare a proiectului;
asistarea clientului la gestionarea documentelor justificative aferente implementarii
activitatilor prevazute in proiect;
consultanta la intocmirea raportarilor periodice catre autoritatea contractanta in
vederea realizarii decontarilor cheltuielilor realizate pentru proiect.
Servicii referitoare la managementul de proiect:

consultanta la implementarea activitatilor proiectului printr-un management eficient
al timpului (grafic realizare activitati) si al resurselor (buget);
asistarea clientului la organizarea, gestionarea si monitorizarea activitatilor in
vederea atingerii obiectivelor asumate prin proiect.
Servicii referitoare la consultanta achizitii publice de servicii si bunuri:

pregatirea documentatiilor/dosarelor pentru atribuirea contractelor de achizitie
publica prin procedurile specifice legislatiei achizitiilor publice;
consultanta pentru pregatirea si desfasurarea procedurilor de achizitie;
asistarea clientului in vederea obtinerii avizelor Autoritatii Contractante pentru
procedurile de atribuire derulate;
asistarea clientului la desfasurarea contractelor de achizitie si la eligibilitatea
cheltuielilor efectuate.
2. Tehnologii software pentru serviciile din administratia publica
In cadrul acestui capitol sunt prezentate principalele tehnologii folosite pentru dezvoltarea
serviciilor electronice folosite in e-Guvernare, punandu-se accentul pe servicii Web,
arhitecturi orientate spre servicii si Web semantic. In ultima parte a capitolului este
prezentat potentialul de inovare in domeniul serviciilor software folosite in administratia
publica.
25
2.1. Servicii Web
Un serviciu web reprezinta orice serviciu disponibil pe Internet, care foloseste un sistem de
mesaje standardizat XML si care nu este legat de nici un sistem de operare sau de un
calculator.
Acum cativa ani serviciile web nu erau suficient de rapide pentru a fi considerate
interesante. Dar, datorita dezvoltarii majore a tehnologiilor din ultimii ani, cei mai multi
oameni si cele mai multe companii au conexiune broadband (in banda larga) si au folosit
web-ul din ce in ce mai mult. Cand platformele majore au putut accesa Web-ul folosind
browserele Web, diferite platforme au putut sa interactioneze. Pentru ca aceste platforme
sa interactioneze, au fost dezvolatate aplicatiile Web.
Serviciile web au dus aplicatiile Web la urmatorul nivel de dezvoltare. Folosind serviciile
web, aplicatia ta isi poate publica functiile sau mesajele catre toata lumea ce foloseste
Web-ul. Folsind serviciile web, departamentul economic bazat pe un server Windows se
poate conecta la un alt server ce ruleaza Unix.
Serviciile web au doua tipuri de utilizare. In primul rand componentele unui serviciu web
sunt reutilizabile. Sunt lucruri de care aplicatiile au nevoie foarte des. Deci de ce sa
construim aceste lucruri mereu cand putem sa le reutilizam? De aceea au fost create
serviciile web. Serviciile web pot oferi aplicatiilor componente precum conversia valutara,
rapoarte de vreme si chiar traducerea unui limbaj ca serviciu. In al doilea rand, serviciile
web conecteaza aplicatii existente deja. Ele ajuta sa rezolvi problema interoperabilitatii,
permitand schimbul datelor intre diferite aplicatii si diferite platforme. Aceste reprezinta 2
avantaje majore ale seviciilor web.
Avantajele serviciilor web sunt:
- interoperabilitatea intre aplicatii
- reutilizarea serviciilor existente
- distribuire usoara a informatiei intre consumatori
- dezvoltare rapida
2.1.1. Tipuri de arhitecturi
Exista numeroase standarde si protocoale, cel mai folosit fiind HTTP, destinate construirii
serviciilor web. Aceste standarde poarta numele de stiva WS-*. Printre acestea se
numara WS-Notification, WS-Security, WSDL, si SOAP. Insa acestea adauga o mare
complexitate serviciilor web . De aceea simplitatea tehnologiilor folosite pentru web
(protocolul HTTP, standardul de nume URI si protocolul XML) a dus la contruirea unor
altfel de servicii, arhitecturile serviciilor web impartindu-se in doua mari categorii:
- arhitectura de tip RPC ( Big Web Services-orientate pe servicii)
- arhitectura de tip REST ( orientate pe resurse)
Bazate pe un limbaj comun XML (eXtensible Markup Language) si un protocol comun de
transport HTTP (HyperText Transfer Protocol) in general, serviciile Web actioneaza ca un
intermediar intre cele dou entitati ce doresc sa comunice intre ele. XML constituie motorul
care face posibil transferul datelor prin intermediul Internetului, constituind totodata
fundamentul serviciilor Web.
26
Arhitectura de tip RPC permite trimiterea si primirea mesajului intr-un invelis. Acest invelis
poate fi de mai multe tipuri : SOAP, XML-RPC si chiar HTTP. Din cauza acestui invelis,
acest stil de serviciu web este unul complex. De ce sa folosim un tip complex cand putem
sa folosim o arhitectura la fel de usoara ca si ce a WEB-ului: arhitectura de tip REST.
2.1.2. Arhitectura de tip RPC

Arhitectura de tip RPC este cea mai complexa si cuprinde practic toate tehnologiile
necesare unei arhitecturi de tip REST. Asa cum am mai spus o arhitectura de tip REST
foloseste doar tehnologiile utilizate in web: HTTP, URI si XML .
Remote Procedure Call (Apelul Procedurilor la Distanta) este o tehnologie de comunicatie
inter-procese care permite unui program de pe un computer sa genereze o subrutina sau
unei proceduri sa se execute intr-un alt spatiu de adresa (de regula pe un alt computer sau
pe o retea partajata) fara ca programatorul sa codeze explicit detaliile aceste interactiuni la
distanta. Practic, programatorul scrie, in principiu, acelasi cod indiferent ca subrutina este
locala sau la distanta fata de programul executant. Cand soft-ul in cauza este scris
folosind principii orientate-obiect, se poate vorbi despre apelare la distanta sau apelarea
metodelor la distanta.
In general o arhitectura de tip RPC si in general protocolul SOAP este confundat cu
notiunea de serviciu web, desi exista si alte stiluri de construire a unui serviciu web
precum REST.
Diagrama ce descrie functionarea unei serviciu web de tip RPC este prezentata in figura
de mai jos:
Figura 9. Functionarea unei serviciu web de tip RPC

O arhitectura a serviciului web poate fi analizata din doua puncte de vedere: din punctul de
vedere al rolurilor in cadrul serviciului web si din punctul de vedere al stivei de protocoale
folosite.
Acest tip de serviciu web necesita mai multe componente de baza pentru a putea fi
realizat:
- furnizorul de servicii: reprezinta un nod in Internet care asigura printr-o interfata
accesul la un serviciu software care executa un anumit set de operatii;
- consumatorul de Servicii:reprezinta un nod in retea care se leaga la furnizorul de
servicii, si foloseste functionalitatea oferita de acesta, construind solutia de afacere ;
- registru de servicii reprezinta un software care gazduieste servicii publicate,
acestea putand fi furnizate la cererea solicitantului. Registrul implementeaza
descoperirea de servicii si functii prin care solicitantul poate cere un anumit
serviciu;
27
Figura 10. Rolurile din cadrul unui serviciu de tip RPC si interactiunea dintre acestea
Arhitectura orientata spre servicii Web de tip RPC trebuie sa implementeze trei operatii
care definesc contractele dintre rolurile principale (furnizor, solicitant, registru): (1)
publicare: inregistrarea (sau promovarea) serviciului de catre furnizorul serviciului in
registrul de servicii; (2) descoperire: operatie complementara operatiei de conectare
(binding), deoarece serviciile publicate trebuie regasite. Solicitantul descopera serviciul in
registrul servicii conform unor criterii de cautare specificate de solicitant. Criteriile de
cautare pot fi, de exemplu, tipul serviciului, caracteristicile furnizorului, caracteristicile de
calitate a serviciului etc.; (3) conectare: conecteaza furnizorul de servicii cu solicitantul de
servicii intr-o relatie de tip clientserver. Aceasta relatie poate fi dinamica (de exemplu,
generarea dinamica a proxy-ului solicitantului) sau statica (cand dezvoltatorul poate
predefini si codifica modul de asociere a serviciului cu orice solicitant).
O alta modalitate de a examina arhitectura serviciilor web se realizeaza prin studierea
stivei de protocoale a serviciului. Stiva este in continua dezvoltare dar in prezent contine
patru niveluri:
nivelul transport al serviciului : nivelul este responsabil de transportul mesajului
dintre consumator si furnizor. In prezent acest nivel contine protocoale precum
HTTP (hypertext transfer protocol), Simple Mail Transfer Protocol (SMTP), file
transfer protocol (FTP), si protocoale mai noi precumprecum Blocks Extensible
Exchange Protocol (BEEP).
nivelul de mesaje XML: acest nivel este responsabil de codarea mesajelor intr-un
format XML astfel incat mesajele sa poata fi intelese la celalalt capat. In prezent
acest nivel este descris de protocoalele XML-RPC si SOAP.
nivelul de descriere a serviciului : este responsabil cu descrierea interfetei
publice a serviciului. Descrierea serviciului este realizata prin Web Service
Description Language (WSDL), acesta urmand a fi prezentat mai tarziu
nivelul de descoperire a serviciului : acest nivel este responsabil de
centralizarea serviciilor intr-un registru comun si furnizeaza functionalitati de
publicare a serviciului. Descoperirea serviciului se realizeaza in prezent prin :
Universal Description, Discovery, and Integration (UDDI).
28
Serviciile web evolueaza permanent, de aceea pot aparea noi niveluri in cadrul stivei.
Figura de mai jos sintetizeaza nivelurile actuale din cadrul stivei serviciului web.
Figura 11. Stiva serviciului web de tip RPC

In figura urmatoare este prezentata modalitatea de interactiune a serviciilor web folosind
protocoale de tip RPC.
Figura 12. Interactiunea serviciilor web folosind protocoalele de tip RPC
2.1.3. Arhitectura de tip REST

REST este acronimul de la Representational State Transfer si reprezinta un model
architectural pentru crearea serviciilor web. REST descrie o arhitectura orientata pe
resurse, aceasta fiind prezentata in detaliu prima data in teza de doctorat a lui Roy
Fieldings. Motivul realizarii unei astfel de arhitecturi a pornit de la faptul ca serviciile de tip
RPC si cele care in general folosesc SOAP aduc o oarecare complexitate. Simplitatea
WEB a reprezentat sursa de inspiratie a serviciilor web de tip REST. Serviciile WEB de tip
REST folosesc toate componentele ce au facut web-ul un mare success. REST aplica
arhitectura web-ului asupra serviciilor web. Desi REST nu este un standard, el se
foloseste de standarde:
HTTP ( Hypertext Transfer Protocol)
URI ( Uniform Resource Identifier)
29
XML/HTML/GIF/JPEG
Practic REST presupunea construirea unui serviciu web folosind HTTP, XML si URI asa
cum a fost construit si web-ul. Pentru a putea intelege mai bine modul in care se
realizeaza un serviciu de tip REST mai intai va fi prezentata o abordare simpla, pe
intelesul tuturor iar apoi o descriere tehnica a acestuia. De unde a pornit construirea unui
serviciu de tip REST? O multime de teorii complexe plutesc in jurul conceptului REST, dar
ce este practic REST?
In lumea software vorbim de design si vorbim despre arhitectura. Uneori, incercam sa
facem o distinctie formala intre aceste doua concepte, alteori, ne rezumam la a face o
distincitie instinctuala. Instinctual ar trebui sa observam ca arhitectura REST este la fel cu
interactiunile de tip web-style intre clienti si servere - care sunt arhitectura.
Comportamentul intern al software-ului clientului si serverului se poate numi design.
REST nu este despre design. Este despre arhitectura. REST este un set de reguli la care
o arhitectura ar trebui sa se conformeze. Pentru ca nu este suficient de detaliat pentru a
defini o arhitectura reala vom spune despre REST ca este un stil arhitectural. Web-ul este
un exemplu real de arhitectura care urmeaza in linii mari regulile REST. Pentru a intelege
aceste reguli trebuie sa avem o imagine a unei arhitecturi fara constrangeri.
Arhitectura fara constrangeri: o arhitectura este construita din diferite componente
proiectate (design pieces). Aceste componente interactioneaza unele cu altele, in diverse
moduri. Imaginati-va o arhitectura fara constrangeri care permite trimiterea de mesaje intre
oricare componente. Orice componenta poate trimite un mesaj la orice alta componenta
iar regulile referitoare la semnificatia mesajului sau felul in care mesajul este tratat sa
ramana la latitudinea emitatorului si receptorului.
Intr-o arhitectura REST se deosebesc doua trasaturi importante :
- datele asupra careia clientul ii spune serverului sa opereze se afla in URI
- operatia pe care serverul o face asupra datelor este descrisa direct de metoda
HTTP
REST este o alta abordare a serviciilor web. Din punct de vedere tehnic, arhitectura de tip
REST se descrie prin cateva notiuni de baza : resursa, URI, reprezentare, interfata
uniforma. Legarea acestor componente intr-un mod cat mai eficient duce la crearea unei
arhitecturi REST. O imagine de ansamblu asupra serviciilor de tip REST este prezentata in
diagrama de mai jos:
In REST totul este o resursa
Intr-o arhitectura de tip REST totul este o resursa. Orice poate fi referit ca un obiect este o
resursa. In general tot ce poate fi stocat in calculator si reprezentat ca un flux de octeti
este o resursa. O resursa poate fi un obiect concret precum un mar sau un obiect abstract
precum notiunea de curaj.
Posibile resurse pot fi :
- Versiunea 1.0.3 a unui soft
- O harta a unei tari
- Urmatorul numar prim dupa 1024
30
- Numarul de cumparatori pentru un anumit produs
- O lista de bug-uri dintr-o baza de date
URI
Ce anume defineste o resursa ? Fiecare resursa are asociat cate un URI. URI reprezinta
numele si adresa unei resurse. URI este prescurtarea termenului englez Uniform
Resource Identifier, un identificator alfanumeric univoc si unic pe lume al unei resurse din
Internet, cum ar fi un document sau un site web. Deseori URI-ul unei resurse este identic
cu URL-ul ei, URL fiind prescurtarea de la Uniform Resource Locator, o forma timpurie a
identificatorului. Daca o anumita informatie nu are un URI atunci nu este o resursa si nu
este practic pe Web.
Un URI al unei resurse trebuie sa fie descriptive. Exemple de URI sunt prezentate mai jos:
http://www.example.com/software/releases/1.0.3.tar.gz
http://www.example.com/software/releases/latest.tar.gz
http://www.example.com/weblog/2006/10/24/0
http://www.example.com/map/roads/USA/AR/Little_Rock
http://www.example.com/wiki/Jellyfish
http://www.example.com/search/Jellyfish
http://www.example.com/nextprime/1024
http://www.example.com/next-5-primes/1024
http://www.example.com/sales/2004/Q4
http://www.example.com/relationships/Alice;Bob
http://www.example.com/bugs/by-state/open
O resursa poate avea mai multe URI . Numarul de vanzari ale unui produs se poate gasi si
la URI http://www.example.com/sales/2004/Q4 dar in acelasi timp se poate gasi si la
http://www.example.com/sales/Q42004.
Interfata uniforma
"Interfata uniforma" este principiul de baza al REST. In tot web-ul exista doar cateva
operatii care se pot face asupra unei resurse. HTTP furnizeaza patru metode de baza ce
descriu operatiile cele mai comune :
- Primirea unei reprezentatii a unei resurse : HTTP GET
- Crearea unei noi resurse HTTP PUT pentru un URI nou sau HTTP POST
pentru un URI deja existent
- Modificarea unei resurse existente: HTTP PUT
- Stregerea unei resurse existente : HTTP DELETE
Toate aceste operatii sunt suficiente in realizarea unei arhitecturi de tip REST.
31
Asa cum am mai spus arhitectura REST este una fara constrangeri. Arhitectura fara
constrangeri permite apeluri la functii, invocari de metode, apelul procedurilor la distanta,
precum si alte mesaje care sunt intelese de catre un anumit server sau de catre un mic
subset de componente din arhitectura. REST elimina ad-hoc mesaje si schimba radical
axa de dezvoltare API spre definirea componentelor informationale care pot fi regasite si
manipulate. In loc de a adauga in arhitectura apeluri speciale la functii sau interfete,
servicii noi, adauga noi informatii care pot fi manipulate utilizand cereri standard.
Un exemplu: in loc de o cerere de tipul "aprindeBec" la un obiect-server, putem folosi PUT
"true" la obiectul http://exemplu.com/Bec/aprinde furnizat de catre server. Obiectul
http://exemplu.com/Bec/aprinde poate raspunde, de asemenea, la o cerere de tip GET
care va returna adevarat sau fals. POST este o cerere de tipul "adaugati informatii" care
nu are sens pentru bec, de fapt nu are sens nici sa stergi un bec. Deci, aceste solicitari ar
esua cu un raspuns care indica acest fapt.
Reprezentari
Asa cum rezulta si din titlu, intr-o arhitectura REST exista si notiunea de reprezentare.
Resursele nu reprezinta date, ci reprezinta doar ideea creatorului de serviciu web despre
cum sa structureze datele. Un server de web nu poate trimite o ide. Poate trimite un flux
de octeti, intr-un format specific si intr-un limbaj specific. Astfel putem descrie o
reprezentare a unei resurse.
Legatura dintre o resursa, URI si reprezentarea resursei este prezentata in figura de mai
jos:
Figura 13. Resursa, URI, Reprezentare -> REST

Am descris pana acum toate componentele unui stil arhitectural REST. Dar care este
legatura intre acestea si de unde numele de REST? Diagrama de mai jos descrie modul
in care se realizeaza un serviciu web de tip REST :
32
Figura 14. Interactiunea pentru un serviciu de tip REST
In imaginea de mai sus clientul refera o resursa web. Reprezentarea resursei este
returnata (documentul .html). Reprezentarea plaseza clientul intr-o anumita stare. Apoi
clientul acceseaza o alta resursa prin apasarea unui link din documentul Boein747.html.
Reprezentarea acestei resurse plaseaza clientul intr-o alta stare. Ca urmare aplicatia
client realizeaza un transfer de stari -> REST!.
Comparatie REST vs SOAP
Pentru a intelege si mai bine conceptul de REST vom face o comparatie intre arhitectura
REST si arhitectura de tip RPC si in special protocolul SOAP.
Asa cum am mai spus, un serviciu de tip REST foloseste 4 verbe HTTP: PUT, POST,
GET, DELETE. Exemplu de utilizare a acestora pentru un serviciu web REST:
- GET /weatherforecast/02110 HTTP/1.1
Se obtine vremea dintr-o localitate
- POST /weatherforecast HTTP/1.1
Se trimite catre server prognoza meteo sub format XML
Un nou URI este creat
- PUT /weatherforecast/95101 HTTP/1.1
Se actualizeaza o reprezentare a resursei deja
existenta
- DELETE /weatherforecast/02110 HTTP/1.1
Se sterge reprezentarea resursei
In contrast, un serviciu web ce foloseste SOAP are urmatorul exemplu de utilizare:
- POST /weatherforecast.asmx HTTP/1.1
Se trimite un mesaj SOAP pentru a obtine vremea dintr-
un oras
Se trimite un mesaj SOAP pentru a crea prognoza
meteo pentru un oras
33
Raspunsul este un mesaj SOAP

Se trimite un alt mesaj SOAP pentru a actualiza
prognoza meteo
o Se trimite un alt tip de mesaj pentru a sterge prognoza meteo
Se observa ca toate metodele HTTP folosite sunt POST. Operatia ce se executa asupra
resursei se trimite in cadrul mesajului. In REST nu s-a dorit implementarea de alte
protocoale, nu s-a dorit reinventarea rotii de aceea s-a folosit un protocol deja existent
:HTTP si metodele sale in timp ce in arhitectura de tip RPC s-au creat protocoale precum
XML-RPC sau SOAP.
In SOAP informatia este in mesajul SOAP:
POST /weatherforecast.asmx HTTP/1.1
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<SOAP-ENV:Envelope xmlns:SOAPENV="
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<SOAP-ENV:Body>
<wns:getWeather xmlns:wns="urn:weather" SOAPENV:
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<zipCode xsi:type="xsd:string">02110</zipCode>
</wns:getWeather>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Diferenta dintre REST si SOAP (reprezentantul arhitecturii RPC) este prezentata mai jos:
34
Figura 15 Servicii Web REST
Figura 16
Servicii
Web RPC
folosind
SOAP
2.2. Arhitectura orientata spre servicii

Conceptul de arhitectura orientata pe servicii a inceput sa se contureze recent si a avut o
evolutie rapida, fiind adoptat in tot multe sisteme informatice in ultimii ani. Totusi,
majoritatea ideilor care stau la baza arhitecturilor orientate pe servicii nu sunt neaparat noi:
structurarea aplicatiilor in componente independente, care sa functioneze ca servicii,
oferind anumite functionalitati, a fost introdusa cu peste 20 de ani in urma prin
programarea orientata pe obiecte. De asemenea, comunicarea intre aplicatii/servicii, pe
baza unui anumit protocol, a fost implementata prin mecanisme ca DCOM si CORBA inca
de cand a inceput evolutia sistemelor distribuite.
Arhitecturile orientate pe servicii au introdus insa si o serie de caracteristici noi, rezultate
din experienta obtinuta cu aplicatiile traditionale pana la inceputul anilor 2000. O astfel de
caracteristica este autonomia completa a unui serviciu fata de celelalte. In acest mod
unitatile functionale create sunt responsabile doar pentru domeniul propriu, executand un
set specific de functii in cadrul unei anumite entitati (care de obicei reprezinta unul dintre
participantii la un proces comercial). Aceasta abordare are avantajul realizarii unei cuplari
slabe intre componente, ceea ce permite o dezvoltare complet independenta a acestora.
O alta caracteristica noua introdusa de arhitecturile orientate pe servicii este
interoperabilitatea. Aceasta a fost de fapt principala motivatie care a dus la aparitia ideii de
orientare pe servicii: la inceputul anilor 2000, companii ca Microsoft si IBM au sustinut
adoptarea unui standard de comunicatie intre aplicatii/servicii (SOAP Simple Object
Access Protocol), care sa fie independent de platforma pe care acestea au fost dezvoltate.
Initiativa a fost cauzata de dezvoltarea rapida a aplicatiilor distribuite, atat in mediul
comercial cat si in cel academic, ceea ce a dus la nevoia de standardiza modul de
comunicare in medii eterogene. Astfel au aparut o serie de tehnologii noi, dintre care
impactul cel mai important l-au avut serviciile web, dar s-a dezvoltat si conceptul abstract
de arhitectura orientata pe servicii. Prezentam in continuare o definitie si un set de principii
generale pentru arhitecturi orientate pe servicii.
O SOA (Arhitectura Orientata pe Servicii) este o schema, un model de design unde un rol
important il joaca incapsularea ideii de aplicatie in servicii care interactioneaza printr-un
35
protocol de comunicatie comun. Cand pentru stabilirea cadrului de comunicatie se
folosesc servicii Web, acestea reprezinta implementarea bazata pe Web (Web-based) a
unei arhitecturi orientate pe servicii. Arhitectura rezultata stabileste in esenta o paradigma
de modelare in care fiecare serviciu Web este un bloc functional. Aceasta inseamna ca
pentra a migra o arhitectura de aplicatii catre o SOA, principiile de design pentru servicii
Web si tehnologiile aferente vr fi o componente importante din noul model.
Un serviciu web este o interfata de comunicare oferita de un server, prin care clientii
(programe aflate pe alte sisteme) pot solicita diverse informatii. Este o metoda prin care
aplicatiile pot comunica intre ele prin mesaje asincrone sau prin apeluri de procedura la
distanta (RPC: Remote Procedure Call). Dar acesta este doar un concept. Si pentru a nu
sfarsi ca alte tehnologii care au pornit de la o idee buna dar s-au extins in tot mai multe
directii fara a se focaliza catre anumite probleme centrale, a fost nevoie de un standard pe
baza cariua sa se construiasca serviciile Web. Altfel zis un set de reguli care sa fie strict
respectate de produsele dedicate acestei arii. Serviciile Web folosite in arhitecturi bazate
pe servicii, trebuie sa se supuna principiilor SOA descrise in sectiunea urmatoare.
Pentru a stabili clar ce inseamna o arhitectura bazata pe servicii, sa incepem prin a face
distinctia dintre aceasta notiune si o aplicatie care foloseste servicii Web. Este destul de
simpla adaugarea catorva servicii Web unei aplicatii. Aceasta integrarea limitata e
folositoare ca exemplu didactic, sau pentru a completa o aplicatie existenta cu o
functionalitate bazata pe servicii, care se preteaza scopului unui anumit proiect. Insa nu
avem de-a face cu o arhitectura orientata pe servicii.
Arhitectura SOA presupune asadar:
- un standard pentru expunerea si accesarea aplicatiilor sub forma de
servicii ;
- infrastructura pentru comunicare si gestiunea serviciilor;
- un limbaj specializat pentru compunerea functionalitatilor simple in unele
complexe care sa modeleze procese economice.
O SOA bazata pe servicii Web XML are la baza tehnologiile XML, axandu-se pe
expunerea logicii de aplicatie existente ca servicii slab cuplate. In sprijinul acestui model,
principiile SOA (principiile de orientare pe servicii) au in vedere reutilizarea, independenta
de stare, autonomia, gradul sporit de abstractie, "descoperirea" serviciilor, cuplarea slaba
a serviciilor si gradul in care se pot combina/compune. Folosirea principiilor SOA altereaza
arhitectura multistrat existenta, adaugand un strat logic, prin folosirea unor interfete de de
implementare(oferite de serviciile Web), stabilind astfel un punct comun de integrare a
serviciilor.
Acest nivel de integrare a serviciilor sta la baza noului model care poate fi extins dincolo
de scopul unei singure aplicatii, pentru a unifica platforme diferite intr-un cadru
interoperabil. Cand serviciile Web sunt si ele parte a infrastructurii, ele sunt folosite pentru
integrarea aplicatiilor. Este important sa se inteleaga complexitatile de modelare pe care le
introduce SOA. In platformele multistrat, cei care se ocupa de design trebuie sa
constientizeze pe deplin faptul ca introducerea serviciilor va afecta datele si modelul
economic existent.
36
In masura in care serviciile se diversifica, creste importanta securitatii si a scalabilitatii.
Platformele orientate pe servicii vor trebui sa satisfaca aceste nevoi folosind o
infrastructura adecvata, specifica fiecarei aplicatii.
2.2.1. Principiile SOA
Ceea ce face ca serviciile Web pentru SOA sa difere de serviciile Web create pentru alte
platforme de aplicatii distribuite, este faptul ca in primul caz, ele trebuie sa se supuna unor
conventii. Mai jos sunt prezentate cateva principii ale orientarii pe servicii, care stabilesc
un cadru distinct pentru dezvoltarea serviciilor Web intr-o SOA. Aplicarea acestor principii
duce la standardizarea serviciilor Web, pastrandu-le slab cuplate:
- Componentele reutilizabile sunt grupate in servicii distincte. Nu exista o limita
teoretica intre logica componentei reprezentata de un serviciu.
- Intre servicii exista un contract formal. Pentru ca serviciile sa interactioneze, ele
trebuie sa fie conectate doar de un contract formal, care defineste termenii schimbului de
informatii si orice descriere suplimentara a serviciilor.
- Serviciile sunt slab cuplate. Serviciile trebuie sa interactioneze slab cuplat, si
trebuie sa pastreze aceasta stare de cuplare slaba. Acest principiu e strans legat de
abstractizarea si autonomia serviciilor.
- Serviciile abstractizeaza logica de implementare. Singura parte a serviciului care
este vizibila in exterior este ceea ce se expune prin descrierea serviciului. In afara acestei
descrieri, natura si forma logicii interioare serviciului sunt invizibile si irelevante pentru
celelalte servicii.
- Serviciile se pot compune/integra. Acest lucru presupune ca logica de
implementare a unui serviciu are mai multe nivele de granularitate si promoveaza
reutilizarea si crearea straturilor de abstractizare.
- Serviciile sunt autonome. Logica unui serviciu nu trebuie sa contina informatie de
stare, deoarece poate micsora capacitatea serviciilor de a ramane slab cuplate. Serviciile
trebuie sa maximizeze independenta de stare, chiar daca asta inseamna ca
managementul starii sa fie rezolvat in alta parte.
- Serviciile se pot descoperi. Serviciile trebuie sa permita descrierilor sa fie
descoperite si intelese atat de oameni cat si de clienti softaware(service requestors).
2.2.2. Rolurile serviciilor Web intr-o SOA
Serviciile Web pot avea diferite roluri, depinzand de scenariul de utilizare, contextul in care
sunt vazute si starea curenta a programului pe care-l ruleaza. Un acelasi serviciu Web
poate schimba rolurile, dar poate sa aiba si roluri multiple in acelasi timp.
1.Furnizorul de serviciu(service provider) - expune o interfata publica prin care
se poate invoca acel serviciu de catre utilizatorii de serviciu. Furnizorul de serviciu
promoveaza aceasta interfata publicand o descrierea a serviciului. Intr-un model client-
server, furnizorul de serviciu are rolul serverului.
2.Utilizatorul/consumatorul de serviciu(service requester) este cel care trimite
un mesaj printr-un serviciu Web, sau un program care cere un anumit serviciu. Utilizatorul
de serviciu joaca rolul de client in modelui client-server.
37
Serverele ofera o metoda prin care clientii pot solicita utilizarea unora dintre serviciile
oferite de server. La baza, aceasta metoda poate corespunde unui apel de procedura la
distanta, unui apel al unei metode a unui obiect sau transmiterii unor mesaje, insa, din
punct de vedere al aplicatiei, ea reprezinta o modalitate de a accesa serviciul pus la
dispozitie. Rolurile de server si client se pot interschimba pe parcursul executiei aplicatiilor.
3.Intermediarul(brokerul) este un serviciu Web care primeste un mesaj de la
utilizatorul de serviciu si trimite mesajul catre furnizor, apoi poate intermedia si raspunsul
de la furnizor catre utilizator. Intermediarii pot fi pasivi(ei doar ruteaza mesajele in sistem)
sau activi(modifica headere de mesaje, dar nu si continutul util).
2.2.3. Interactiunea si compunerea serviciilor
Componentele unei arhitecturi orientate pe servicii pot fi organizate dupa mai multe
modele:
Orchestrare: exista un proces central cu rol de coordonare explicita a serviciilor; acestea
nu sunt consiente ca sunt implicate intr-un serviciu compus.
Coregrafie: nu exista un coordonator central; fiecare serviciu web stie cand sa se execute
si cu cine interactioneaza - efort colaborativ bazat pe sincronizare si schimbarea de
mesaje. Acest concept e strans legat de acela de activitate(task).
Activitate: modelele bazate pe schimb de mesaje stau la baza activitatilor serviciilor. O
activitate presupune un grup de servicii Web care interactioneaza si colaboreaza pentru a
realiza o functie sau un grup logic de functii.
Diferenta dintre coregrafie si activitate consta in faptul ca, in general, o activitate este
asociata unei anumite functii a aplicatiei.
2.2.4. Limbajul XML
Popularitatea sistemului Internet a inceput sa creasca exploziv odata cu aparitia si
dezvoltarea World Wide Web. Brusc o mare de informatie era disponibila folosind un
browser web si o legatura la Internet. Fara continutul foarte variat insa interesul pentru
World Wide Web ar fi fost mult mai redus; acest continut variat a si scos la iveala limitarile
HTML.
Numarul mare de editoare HTML(Hypertext Markup Language) si usurinta in folosire a
permis multor oameni cu putine cunostinte tehnice sa publice continut pe web. Proliferarea
site-urilor web personale cu continut variat este o dovada in plus ca HTML este un limbaj
excelent pentru definirea prezentarii datelor. Totusi HTML nu este prea folositor atunci
cand vine vorba de descrierea datelor. Odata cu maturizarea webului a devenit evident
faptul ca este de dorit separarea prezentarii de continut. Acest lucru a permis unor
specialisti cum ar fi artistii grafici sa se concentreze pe prezentare, iar alti specialisti cum
sunt programatorii sa se concentreze pe crearea si manipularea datelor de continut.
XML(Extensible Markup Language) a aparut ca un standard web pentru reprezentarea si
transmiterea datelor pe Internet. XML este un metalimbaj generic, independent de
platforma, de descriere a datelor. World Wide Web Consortium(W3C) a produs standarde
pentru mai multe tehnologii legate de XML.
XML este text structurat. Simplitatea XML este ceea ce il face atat de bun pentru multe
scopuri. Textul este suportat de toate platformele de calcul. Deci daca se pot reprezenta
38
datele ca text utilizatorii oricarei alte platforme de calcul pot accesa datele fara conversii
specializate dintr-un format in altul.
2.2.5. SOAP
Simple Object Access Protocol (SOAP) este un protocol bazat pe XML, folosit pentru
transmiterea informatiei in sisteme distribuite. Cuvantul simplu explica intentia creatorilor
SOAP. Un mesaj SOAP s-a dorit a fi un document XML bine format, cu alte cuvinte text
pur. SOAP a depasit proiectul initial si este considerat mai mult decat un protocol si
anume un framework pentru schimbul mesajelor intre clienti si servicii web. Diferenta
dintre un protocol si un framework poate fi observata daca ne gandim la protocolul HTTP
care a revolutionat schimbul de date intre browsere si serverele web. HTTP este folosit la
conectarea a milioane de oameni la web dar nu ofera o platforma pentru schimbul liber de
date. SOAP rezolva acesta problema prin folosirea protocoalelor existente(ca HTTP, sau
SMTP) pentru a permite mesajelor SOAP sa fie trimise ca parte a mesajelor acestor
protocoale.
Majoritatea retelelor au instalate o multitudine de firewall-uri, proxy-uri, si alte elemente de
securitate pentru a bloca orice comunicatie inafara de datele HTTP. Din acest motiv,
mesajele SOAP sunt trimise ca parte a mesajelor HTTP, intr-un proces numit transmiterea
SOAP peste HTTP. Se presupune ca aplicatiile care comunica folosind SOAP trebuie sa
verifice validitatea textului XML care contine mesajele SOAP. Deoarece pe drumul dintre
client si serviciul web pot interveni si alte aplicatii numite intermediari, acestea pot lua
decizii de prelucrare folosind informatia continuta in headerul mesajului SOAP. Folosind
acest header optional, SOAP este un protocol extensibil.
Un mesaj SOAP este alcatuit din 2 sectiuni obligatorii <Envelope> si <Body>, la care se
poate adauga o sectiune optionala <Header>.
Fiecare element din mesaj este prefixat de spatiul de nume soap: . Acest spatiu de nume
este definit in elementul <Envelope> (plic) si se aplica tuturor elementelor continute in
spatiul de nume SOAP.
Spatiile de nume au un rol important in SOAP. Acestea sunt folosite pemtru a combate
problemele de ambiguitate intre 2 sau mai multe documente XML impiedicand aparitia de
elemente si atribute cu nume identice dar cu semnificatii diferite. Acest lucru este realizat
prin prefixarea fiecarui element si atribut cu un sir de caractere asa cum este prefixul
soap: folosit anterior(de exemplu <soap:Body>). Spatiile de nume ele insele sunt URI-uri
arbitrare(pot fi si stringuri oarecare) care trebuie specificate cand se defineste o
mapare(un alt nume mai scurt) pentru un spatiu de nume;
exemplu:
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope .
Elementul <Envelope> este nodul radacina al documentului XML care reprezinta mesajul
SOAP. Contine elementele <Header> si <Body> si este obligatoriu. Elementul <Header>
este primul element fiu al elementului <Envelope> si este facultativ. Toti fii imediati ai
elementului header se numesc inregistrari header sau headere. Elementul Header asigura
o metoda generala de a adauga caracteristici noi unui mesaj SOAP intr-o maniera
descentralizata fara o intelegere anterioara intre cei care comunica. Headerele permit
extinderea informatiei despre un mesaj. Utilizarile tipice ale inregistrarilor header sunt:
autentificare, managementul tranzactiilor etc.
39
Daca elementul <Envelope> nu contine elementul <Header> atunci elementul <Body>
trebuie sa fie primul fiu imediat al elementului <Envelope>. Daca elementul <Header>
este prezent atunci elementul <Body> trebuie sa urmeze imediat dupa acesta. Toti fii
imediati ai elementului Body se numesc inregistrari body , si fiecare inregistrare este un
element separat in cadrul lui Body.
In contextul serviciilor web elementul body contine date specifice unui anumit apel de
metoda, cum ar fi numele metodei, parametrii ei si valorile de return de dupa apel.
2.2.6. WSDL
WSDL este un limbaj bazat pe XML care ofera un model pentru descrierea si definirea
serviciilor web. WSDL defineste serviciile ca fiind o colectie de noduri in retea, sau porturi,
care comunica intre ele prin mesaje. WSDL specifica un format XML pentru documentele
ce contin definitia unui serviciu web. Definitia abstracta a porturilor si mesajelor este
separata de utilizarea lor concreta, permitand reutilizarea acestor definitii. Un port este
definit prin asocierea unei adrese de retea cu o legatura reutilizabila, iar o colectie de
porturi definesc un serviciu. Mesajele sunt descrieri abstracte ale datelor care se transmit,
iar tipurile porturilor sunt colectii abstracte de operatii suportate. Protocolul concret si
specificatia formatului datelor pentru un anumit tip de port constituie o legatura
reutilizabila, unde mesajele si operatiile sunt legate la un protocol de retea si la un format
de mesaj concret.
WSDL este folosit adesea in combinatie cu SOAP si cu XML Schema pentru a oferi
servicii web in Internet. Un program client care se conecteaza la un serviciu web poate citi
descrierea WSDL pentru a determina ce fel de functii sunt disponibile pe server. Orice
tipuri speciale de date sunt incluse in WSDL folosind XML Schema.
Un document WSDL este o lista de definitii. Intr-un document WSDL elementul radacina
se numeste definitions. Acest element contine 5 fii imediati folositi pentru a defini un
serviciu web. Urmatoarele 5 elemente apar in cadrul elementului definitions, intr-un fisier
WSDL in ordinea specificata:
- elementul <types> defineste tipurile de date folosite pentru schimbul de mesaje;
- elementul <message> descrie mesajele folosite in comunicatie;
- elementul <portType> identifica un set de operatii si mesajele atasate fiecareia
dintre acestea; este de fapt o interfata a serviciului.
- elementul <binding> specifica detaliile de protocol folosite de operatiile
serviciului si descrie cum se traduce continutul abstract al acestor mesaje intr-un format
concret;
- elementul <service> grupeaza un set de port-uri corelate.
Daca un serviciu web poate fi accesat folosind mai multe protocoale, atunci documentul
WSDL pentru acel serviciu web va contine mai multe elemente port(in elementul service)
fiecare referindu-se la un binding specific pentru un anumit protocol. De asemenea fiecare
dintre elementele binding specifice unui protocol se va referi la randul lui la un anumit
portType. Elementul portType respectiv se va referi la randul lui la un anumit set de
elemente message input si output, care la randul lor se vor referi la tipuri definite de
elementul types.
40
2.2.7. UDDI
Initiativa UDDI (Universal Description, Discovery and Integration) este sustinuta de catre
OASIS. UDDI este numele dat unui grup de registre din internet ce expun informatii legate
de companii, organizatii sau alte entitati si de interfetele (API-urile) pe care acestea le pun
la dispozitie. Registrele ruleaza pe asa numite Situri Operatoare si pot fi folosite de catre
oricine pentru a publica sau gasi informatii legate de aceste entitati. Serviciile UDDI sunt
independente de platforma bazandu-se pe standarde XML.
Prin accesarea Siturilor Operatoare se pot cauta serviciile web puse la dispozitie de catre
o anumita organizatie. Se doreste astfel creearea unui mecanism de descoperire a API-
urilor existente pentru a interactiona cu serviciile de comert electronic ale organizatiei.
Aceasta, la randul ei, are avantajul unei expunerii crescute in lumea comertului electronic.
O inregistrare UDDI a unei organizatii contine urmatoarele 3 componente:
- Pagini albe: adresa, informatii de contact, identificatori
- Pagini aurii: categorizari industriale bazate taxonomii standard
- Pagini verzi: informatii tehnice referitoare la serviciile expuse de catre organizatie
UDDI a fost proiectat pentru a fi interogat prin intermediul mesajelor SOAP si pentru a
asigura accesul la documente WSDL care sa descrie protocoalele si formatele de mesaje
necesare pentru a interactiona cu serviciul web expus.
2.2.8. WSRF
WSRF (Web Services Resource Framework) reprezinta o serie de specificatii pentru
servicii web publicate de OASIS (Organization for the Advancement of Structured
Information Standards este un consortiu global ce se ocupa cu dezvoltarea si adoptarea
pe scara larga a standardelor pentru e-business si servicii web). La dezvoltarea acestor
specificatii au mai contribuit Globus Alliance si IBM.
O limitare serioasa a serviciilor web o constituie faptul ca acestea nu stocheaza in mod
normal informatii legate de stare. Desigur, exista diferite modalitati de a depasi acest
neajuns, cum ar fi salvarea explicita a acestor informatii si folosirea unor metode de
identificare a sesiunii (in mod asemanator cu aplicatiile web).
WSRF pune la dispozitie diferite specificatii pe care un serviciu web le poate implementa
pentru a pastra informatiile de stare. In acest sens, clientii trebuie sa includa in cererea lor
un identificator care sa descrie in mod unic o anumita resursa. Acest identificator poate
varia de la un simplu sir de caractere URI pana la elemente XML complexe. Pe langa
posibilitatea de a specifica o anumita resursa standardul permite si operatii de tipul get/set
asupra proprietatiilor resursei. Asadar acestea pot fi folosite pentru a citi si respective scrie
starea resursei.
Acest model este in principal folosit de unelte de management pentru ca acestea sa poata
vedea si lista resursele fara a avea alte informatii despre acestea. Un exemplu in acest
sens este folosirea unui serviciu web pentru monitorizarea statusului altor serviciilor
(WSDM - Web Services Distributed Management).
Principalele componente ale acestei specificatii sunt:
41
- WS-Resource: defineste o resursa de serviciu web ca fiind perechea formata din
resursa propriu-zisa si serviciul web prin care aceasta poate fi accesata.
- WS-ResourceProperties: descrie o interfata folosita pentru asocierea unui set de
valori avand tipurile specificate cu o resursa de serviciu web (WS-Resource).
- WS-ResourceLifetime: reprezinta o interfata pentru managementul duratei de
viata a unei resurse.
- WS-BaseFaults.
- WS-ServiceGroup: este o interfata pentru lucrul cu colectii de resurse
WS-ResourceProperties
O resursa este compusa din punctul de vedere al utilizatorului din mai multe proprietati
(resource properties). De exemplu in figura anterioara fiecare WS-Resource are 3
proprietati (resource property): Fisier, Dimensiune si Descriptori. Ws-ResourceProperties
specifica cum sunt definite si accesate resource property. Acestea sunt definite in fisierul
WSDL.
WS-ResourceLifecycle
O resursa are ceea ce se numeste ciclu de viata. Cu alte cuvinte o resursa nu este o
entitate statica care este creata atunci cand se porneste serverul si distrusa atunci cand
acesta este oprit. Resursele pot fi create si distruse la orice moment de timp. Specificatia
WS-ResourceLifecycle asigura niste mecanisme de baza pentru managementul ciclului de
viata al resurselor.
WS-RenewableReferences
Odata ce un client dispune de referinta endpoint a unei WS-Resource, pot exista cazuri
cand apare nevoia de a reinoi acea referinta daca devine invalida. Specifiatia WS-
RenewableReferences defineste mecanismele pentru a face acest lucru.
WS-ServiceGroup
Deseori este nevoie de managementul unor grupuri de servicii web sau grupuri de resurse
WS-Resource si de a realiza operatii ca adaugarea unui serviciu la un grup, eliminarea
unui serviciu dintr-un grup si, mai important, gasirea unui serviciu intr-un grup care
indeplineste o anumita conditie. Specificatia WS-ServiceGroup defineste modalitatile prin
care se poate realiza aceasta grupare.
WS-BaseFaults
Aceasta specificatie are rolul de a asigura o metoda standard de a returna erorile care pot
apare in timpul invocarii unui serviciu web.
Prezentam mai jos alte specificatii strans legate de WSRF.
WS-Notification
WS-Notification este o colectie de specificatii, care desi nu fac parte din WSRF, sunt in
stransa legatura cu acesta. Aceasta specificatie permite serviciilor web sa fie configurate
ca producator de notificari, si unor clienti sa fie consumatori de notificari(inscrisi). Aceasta
inseamna ca daca apare o schimbare intr-un serviciu web (adica intr-una dintre WS-
42
Resources) se transmite o notificare tuturor consumatorilor inscrisi(nu toate schimbarile
produc notificari ci doar cele dorite de producatorul serviciului web).
WS-Addressing
Aceasta specificatie ofera un mecanism de a adresa serviciile web mult mai flexibil decat
simple URI-uri. Cel mai important este faptul ca se poate folosi WS-Addressing pentru a
adresa un serviciu web + o resursa pereche( care formeaza o WS-Resource).
2.2.9. Arhitectura orientata pe servicii in sistemele Grid

Avantajele arhitecturii orientate pe servicii au determinat adoptarea acesteia si in
sistemele Grid, intr-un moment in care acest concept era inca nou.
Orientarea pe servicii a fost o evolutie fata de primul model arhitectural al Grid-ului, propus
de Ian Foster, Carl Kesselman si Steven Tuecke in [11]. Acest model implica existenta mai
multor niveluri, aranjate in mod asemanator unei clepsidre: partea ingusta a clepsidrei
corespunde unui set mic de protocoale si abstractii de baza; deasupra acesteia pot fi
mapate o multime larga de comportamente, iar dedesubt pot exista tehnologii de nivel jos
foarte diverse.
De la acest model bazat pe protocoale s-a fact trecere la unul orientat pe servicii. Astfel,
[12] descrie Grid-ul ca fiind un set extensibil de servicii care raspund la mesaje specifice
protocoalelor. Serviciile Grid pot fi agregate pentru a indeplini cerintele organizatiilor
virtuale. Acest model nou, denumit Arhitectura Deschisa pentru Servicii Grid (Open Grid
Services Architecture OGSA), si-a propus sa alinieze tehnologiile Grid cu standardele
serviciilor web. Astfel, se pot valorifica avantajele care rezulta din utilizarea limbajului
WSDL (Web Services Description Language) si din separarea descrierii abstracte a
interfetei pe care serviciul o ofera utilizatorilor, de specificarea concreta a adresei unde
serviciul este disponibil si a modului in care acesta va comunica cu clientii. Printre aceste
avantaje mentionam generarea automata a codului pentru client si pentru server pornind
de la descrierea WSDL, posibilitatea de a descoperi servicii prin intermediul cataloagelor
publice, asocierea descrierii serviciilor cu protocoale de retea interoperabile,
compatibilitatea cu servicii de nivel mai inalt [12]. Modelul OGSA a a fost implementat in
Globus Toolkit versiunea 3.
OGSA descrie mecanisme standard pentru crearea, denumirea si descoperirea instantelor
de servicii Grid. In acest model, resursele computationale, legaturile de retea, resursele de
stocare, bazele de date etc. sunt reprezentate de servicii; un serviciu poate fi definit ca o
entitate care ofera anumite capabilitati, comunicand cu clientii prin intermedil retelei.
Perspectiva orientata pe servicii simplifica virtualizarea (incapsularea diverselor
implementari in spatele unei interfete comune) si raspunde la nevoia de a avea
mecanisme standard de definire a interfetelor.
In 2003, [13] introduce un prim set de specificatii pentru conceptele OGSA, denumit
Infrastructura Deschisa pentru Servicii Grid (Open Grid Service Infrastructure OGSI).
Autorii au definit modalitati pentru crearea, denumirea si gestionarea instantelor de
servicii, pentru declararea si inspectarea datelor de stare ale serviciilor, pentru notificarea
in cazul schimbarii starii etc. Definitiile sunt date ca tipuri WSDL, si pot fi combinate pentru
a crea servicii Grid complexe.
Versiunea urmatoare a Globus Toolkit (GT4) are in continuare la baza arhitectura orientata
pe servicii, dar a adoptat o paradigma noua pentru dezvoltarea serviciilor Grid: Web
43
Services Resource Framework (WSRF). Noua abordare ofera o compatibilitate mai buna
cu instrumentele existente pentru dezvoltarea serviciilor web, inclusiv cele comerciale.
Globus Toolkit nu este singurul middleware pentru Grid in care s-a adoptat arhitectura
orientata pe servicii. Un alt exemplu este Condor, un instrument pentru planificare de
aplicatii si pentru gestiunea resurselor utilizat pe scara larga de mai mult de 20 de ani. La
Condor a fost adaugata recent un modul numit BirdBath, care expune o parte din
functionalitatile instrumentului ca servicii web. Arhitectura orientata pe servicii a fost
introdusa si in instrumentele de planificare comerciale, cum ar fi Tivoli Dynamic Workload
Broker de la IBM.
2.3. Web-ul semantic
OWL Web Ontology Language a fost creat pentru a fi folosit atunci cand informatiile
continute in diverse documente trebuie sa fie procesate de aplicatii software, si nu doar
prezentata in diverse forme utilizatorului. OWL poate fi folosit pentru a reprezenta intelesul
termenilor dintr-un vocabular, percum si relatiile intre acesti termeni. Reprezentarea
termenilor si a relatiilor dintre ei se numeste o ontologie. OWL ofera mai multe facilitati
pentru exprimarea sensurilor si a semanticii decat XML, RDF si RDF-S, rezultand inalta
abilitate a acestui limbaj de a reprezenta pe Web continut interpretabil de o aplicatie. OWL
este o revizuire a primului limbaj semantic numit DAML+OIL, lansat in 2000, si
incorporeaza invatamintele trase din designul si aplicarea acestuia.
De ce a aparut OWL ? Din cauza abundentei informatiilor de pe Web, viitorul acestuia este
strans legat de asocierea informatiilor cu un sens explicit, facand astfel mai usor procesul
de precesare si integrare automata a informatiilor disponibile pe Web. Acest Web al
viitorului se numeste Semantic Web si este bazat pe abilitatea de a defini scheme de
marcare customizate folosind XML si pe modalitatea flexibila reprezentare a datelor oferita
de RDF. Primul lucru care este necesar pentru Semantic Web este un limbaj al ontologiilor
(de definire a ontologiilor) care sa poata descrie formal sensul terminilogiei (informatiilor)
folosite in cadrul documentelor Web. Pentru ca o aplicatie sa poata intelege aceste
documente este necesar un limbaj mai puternic decat RDF Schema.
Un exemplu demonstreaza clar utilitatea unui astfel de limbaj. Pe Web exista o gramada
de site-uri ce prezinta spre comercializare diverse sortimente de vin. Sa presupunem ca
dorim sa realizam o aplicatie care sa ne furnizeze o lista de vinuri sau o cautare a unui
sortiment de vin. In acest moment, o astfel de aplicatie este foarte greu de realizat. Pentru
a facilita realizarea unei astfel de aplicatii, nu este suficienta efectuarea unei cautari
folosind niste cuvinte cheie, ci este necesara specificarea sensurilor (intelesurilor)
resurselor descrise de un document (pagina) Web. Acest strat suplimentar capteaza
semantica informatiilor prezente intr-un document.
OWL este un limbaj pesntru definirea si instantierea ontologiilor Web. Termenul ontologie
a fost preluat din filosofie si se refera la stiinta descrierii entitatilor ce alcatuiesc lumea si a
legaturilor dintre ele. O ontologie OWL poate include descriptori de clase, proprietati si
instante ale acestora. Fiind data o astfel de ontologie, semantica formala a OWL specifica
cum se deriva consecintele logice, de exemplu fapte care nu sunt specificate literal in
ontologie, dar sunt determinate de semantica.
44
Oare pentru a rezolva problemele evidentiante anterior era neaparat necesar un alt
standard XML/Web ? Nu erau suficiente XML si XML Schema ? Exista doua raspunsuri la
aceste intrebari:
- O ontologie difera de o schema XML prin faptul ca este o reprezentare a
cunostintelor, nu un format de mesaj. Majoritatea standardelor Web sunt compuse dintr-o
combinatie de formate de mesaje si specificatii ale protocoalelor. Aceste formate au o
semantica operationala; dar specificatia nu a fost gandita pentru a suporta gandire in afara
contextului tranzactie. De exemplu, cand se primeste un mesaj de efectuare a unei
tranzactii, se transfera o suma de bani din contul cumparatorului in cel al vanzatorului si se
livreaza produsul cumparat, dar nu exista nici un mecanism prin care sa concluzionam ca
daca produsul este un Chardonnaz, atunci el este, de asemenea, un vin alb.
- Un avantaj al ontologiilor OWL va fi existenta unor unelte ce vor putea sa
gandeasca pe baza ontologiilor. Aceste unelte vor oferi suport generic, ce nu este specific
nici unui domeniu particular, ceea ce nu s-ar putea putea face daca s-ar defini pentru
fiecare domeniu, scheme XML specifice acestuia.
2.3.1. Sintaxa OWL
Inainte de a trece la discutia propriu-zisa despre sintaxa OWL, trebuie mentionat ca
limbajul OWL ofera trei sublimbaje, ce ofera diferite facilitati conforme cu nevoile
comunitatilor specifice de implementatori si utilizatori:
- OWL Lite este cel mai simplu dintre cele trei sublimbaje, si a fost creat pentru a
fi folosit de catre acei utilizatori ce au nevoie, in principal, de o ierarhie de clasificare si
constrangeri simple. De exemplu, desi suporta constrangeri de cardinalitate, OWL Lite
permite pentru cardinalitate numai valorile de 0 si 1. De asemenea, uneltele folosite sunt
mai simplu de dezvoltat si mai ieftine si se ofera o modalitate usoara de migrare catre
OWL Lite a diverselor taxonomii existente.
- OWL DL destinat utilizatorilor care vor expresivitate maxima fara pierderea
completitudinii (toate determinarile sunt calculate garantat) si decidabilitatii (toate calculele
dureaza un timp finit) computationale ale sistemelor de inferente. Acest sublimbaj include
toate elementele de limbaj OWL cu restrictii precum separarea tipurilor (o clasa nu poate fi
in acelasi timp si o instanta sau o proprietate, o proprietate nu poate fi si instanta sau
clasa). Numele acestui sublimbaj provine de la descriptive logics (DL), domeniu in care se
studiaza logica cu predicate de ordinul I, ce sunt decidabile. De asemenea, OWL DL
suporta limbajele comerciale ce folosesc logica descriptiva.
- OWL Full este indicat utilizatorilor ce cauta exprisivitate maxima si libertatea
sintactica a RDF, dar fara garantii computationale. De exemplu, o clasa poate fi tratata ca
o colectie de instante sau ca o instanta in sine. Este improbabil sa existe un software de
inferente care sa suporte toate facilitatile lui OWL Full.
OWL DL este o extensie a OWL Lite, iar OWL Full este o extensie a OWL DL. Alegerea
intre cele trei sublimbaje depinde de necesitatile utilizatorului, fiind vorba de o alegere intre
performante mai bune sau un limbaj mai puternic (mai dezvoltat). Desi e decidabil, OWL
DL ofera rezultate proaste in cazul cel mai defavorabil, dar ofera restrictii expresive mai
puternice. OWL Full este ales in loc de OWL DL cand se doreste ca OWL sa suporte
facilitatile de meta-modelare oferite de RDF Schema (de exemplu, definirea claselor de
clase).
45
OWL fiind o extensie a vocabularului RDF, sintaxa OWL este compatibila cu sintaxa
RDF/XML. Astfel, o ontologie OWL este un graf RDF [9], care la randul sau este un set de
tripleti RDF. Ca orice graf RDF, si o ontologie OWL poate fi scrisa in diverse forme
sintactice [10]. Orice forma sintactica aleasa pentru reprezentarea unei ontologii este
valida, atata timp cat rezulta acelasi set de tripleti. De exemplu, urmatoarele reprezentari
au acelasi inteles, deoarece codifica acelasi set de tripleti RDF:
<owl:Class rdf:ID="Continent"/>
si
<rdf:Description rdf:about="#Continent">
<rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
</rdf:Description>
In continuare, este prezentat un scurt exemplu de definire a unei ontologii folosind OWL,
folosit ulterior pentru a explica elementele de sintaxa de baza:
<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF
xmlns=http://www.example.com/owl#
xmlns:othex="http://www.otherexample.com/owl#"
xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#
xmlns:owl=http://www.w3.org/2002/07/owl#>
<owl:Ontology rdf:about="">
<rdfs:comment>
Exemplu de ontologie definita folosind OWL. Aici se poate specifica
definitia DAML de la care s-a pornit, daca exista asa ceva.
</rdfs:comment>
<rdfs:label>Bird Ontology</rdfs:label>
<owl:imports rdf:resource=" http://www.otherexample.com/owl"/>
</owl:Ontology>
<owl:Class rdf:ID="OrganicThing" />
<owl:Class rdf:ID="AnorganicThing">
<owl:complementOf rdf:resource="#OrganicThing " />
</owl:Class>
<owl:Class rdf:ID="Animal">
<rdfs:subClassOf rdf:resource="#OrganicThing" />
</owl:Class>
46
<owl:Class rdf:ID="Plant">
<owl:disjointWith rdf:resource="#Animal" />
</owl:Class>
<owl:ObjectProperty rdf:ID="hasMaker">
<rdf:type
rdf:resource="http://www.w3.org/2002/07/owl#FunctionalProperty" />
</owl:ObjectProperty>
<owl:Class rdf:ID="Continent" />
<owl:ObjectProperty rdf:ID="livesInContinent">
<rdf:type
rdf:resource="http://www.w3.org/2002/07/owl/#TransitiveProperty" />
<rdfs:domain rdf:resource="#Bird" />
<rdfs:range rdf:resource="#Continent" />
<owl:Class rdf:ID="Bird">
<rdfs:subClassOf rdf:resource="#Animal" />
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#canFly" />
<owl:cardinality
rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">
1
</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#livesInContinent"/>
<owl:someValuesFrom rdf:resource="#Continent"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:label xml:lang="en">bird</rdfs:label>
<rdfs:label xml:lang="fr">oiseau</rdfs:label>
</owl:Class>
47
<owl:Class rdf:ID="Fish">
</owl:Class>
<owl:Class rdf:ID="Mamel">
</owl:Class>
<Continent rdf:ID="Europe" />
<Continent rdf:ID="Africa" />
<Continent rdf:ID="Asia" />
<Continent rdf:ID="NorthAmerica" />
<Continent rdf:ID="SouthAmerica" />
<Continent rdf:ID="Australia" />
<Continent rdf:ID="Antarctica" />
<Bird rdf:ID="ImperialPenguin">
<livesInContinent rdf:resource="#Antarctica" />
<canFly
rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">0</canFly>
</Bird>
<Bird rdf:ID="Vulture">
<owl:differentFrom rdf:resource="#ImperialPenguin"/>
<livesInContinent rdf:resource="#NorthAmerica" />
<canFly
rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</canFly>
</Bird>
</rdf:RDF>
Cum OWL face parte din eforturile pentru dezvoltarea Web-ului Semantic, iar acesta este
inerent distribuit, OWL trebuie sa permita ca informatia sa poate fi adunata de la diverse
surse. Astfel, ontologiile pot fi legate intre ele, inclusiv prin importarea informatiilor din alte
ontologii.
a. Spatiile de nume
Primul spatiu de nume este cel asociat ontologiei declarate in acest exemplu. Apoi este un
spatiu de nume, al unei alte ontologii, care este folosita (poate fi folosita) in definirea
ontologiei exemplu. Al treilea spatiu de nume specifica calea catre vocabularul definit de
48
OWL, aflat la http://www.w3.org/2002/07/owl#. Aceasta declaratie trebuie inclusa in toate
definitiile de ontologii. Ultimele spatii de nume sunt cele catre vocabularele RDF si RDFS,
deoarece OWL depinde de aceastea. Alt spatiu de nume folosit foarte des in definirea
ontologiilor este cel catre XML-Schema, dar, in exemplul de sus, desi este folosit nu este
declarat un prefix pentru el.
b. Header-ul ontologiei
Dupa stabilirea spatiilor de nume, de obicei, se include un tag owl:Ontology ce contine
informatii despre ontologia definita, putandu-se specifica comentarii, numarul de versiune, precum
si includerea altor ontologii in definirea celei curente.
In cadrul acestui tag se afla alte tag-uri ce colecteaza metadate despre document. Printre
aceste tag-uri se afla: rdf:about unde se specifica numele sau referinta ontologiei,
rdfs:comment, owl:priorVersion, owl:imports ce specifica alte ontologii de care este
dependenta ontologia definita, si rdfs:label unde se poate da un nume in limbaj natural
ontologiei.
c. Definirea claselor simple cu nume
OWL are o clasa de baza, numita owl:Thing, si orice superclasa definita de utilizator este o
subclasa a acesteia. De asemenea, exista si clasa vida owl:Nothing.
Definirea unei superclase cu nume se face asignand atributului rdf:ID numele clasei,
conform exemplului urmator:
<owl:Class rdf:ID="OrganicThing" />
Definirea unei clase poate fi facuta incremental, precum si distribuita. Odata definita o
clasa cu nume, alte definitii de ontologii pot referi aceasta clasa prin URI#className.
Pentru a crea o subclasa, se foloseste constructorul rdfs:subClassOf, dupa cum se poate
vedea mai jos:
<owl:Class rdf:ID="Animal">
</owl:Class>
Tag-ul rdfs:label poate fi folosit pentru a atribui un nume in limbaj natural clasei definite.
Numele poate diferi in functie de limba folosind atributul lang.
d. Definirea indivizilor (instantelor)

Un individ este introdus declarandu-l ca fiind membrul unei clase (apartinand unei clase)
astfel (aceasta este varianta minimala, pentru o clasa fara atribute):
<Continent rdf:ID="Europe" />
Aceasta constructie este echivalenta cu urmatoarele:
<owl:Thing rdf:ID="Europe" />
<owl:Thing rdf:about="#Europe">
<rdf:type rdf:resource="#Continent"/>
49
</owl:Thing>
In exemplul de mai sus, intai se defineste o clasa cu nume, iar apoi se modifica tipul
acesteia folosind rdf:about si tag-ul rdf:type.
e. Definirea proprietatilor simple

Clasele si indivizii permit numai definirea taxonomiilor. Proprietatile sunt cele ce ne permit
sa inferam fapte generice despre toti membrii unei clase si faate dpecifice despre fiecare
individ in parte.
O proprietate este o relatie binara si se disting doua tipuri de proprietati:
- proprietati tip de date care sunt relatii intre instantele unei clase si literali RDF
sau tipuri de date definite in XML Schema.
- proprietati obiectuale care sunt relatii intre instantele a doua clase.
O proprietate poate fi restrictionata specificand domeniul de definire si cel de valori pentru
care este valida. Acest lucru se face precum in exemplul urmator:
<owl:ObjectProperty rdf:ID="livesInContinent">
<rdfs:domain rdf:resource="#Bird" />
<rdfs:range rdf:resource="#Continent" />
Precum clasele, si proprietatile pot fi ierarhizate, modificand domeniul de definire sau cel
de valori, folosind tag-ul rdfs:subPropertyOf in definitia subproprietatii.
f. Clase anonime
OWL permite definirea claselor anonime (fara nume). De exemplu, mai jos se defineste o
clasa anonima, ce restrictioneaza definirea clasei Bird:
<owl:Class rdf:ID="Bird">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#canFly" />
<owl:cardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">
1
</owl:cardinality>
</owl:Restriction>
</rdfs:subClassOf>
g. Mai multe despre proprietati
La definirea indivizilor proprietatile clasei trebuie instantiate (exemple in cod).
In plus, proprietatile pot avea urmatoarele tipuri:
- proprietati tranzitive: P(x,y) and P(y,z) implies P(x,z)
50
- proprietati simetrice: P(x,y) daca P(y,x)
- proprietati functionale: P(x,y) si P(x,z) implica y = z
- proprietati inversOf: P1(x,y) daca P2(y,x)
Proprietatile pot fi restrictionate si mai mult folosind cardinalitatea, precum si tag-urile
allValuesFrom, someValuesFrom. Tag-ul hasValue poate obliga toate instantele unei
clase sa aiba aceasi valoare pentru o proprietate.
h. Mai multe despre clase
OWL DL este foarte puternic in definirea claselor, putandu-se defini clase complexe ca
reunini, intersectii sau complemente ale altor clase.
g.Tipurile de date
OWL foloseste tipurile de date definite in XML Schema, precum si rdfs:Literal.
2.3.2. Cazuri de utilizare

Folosirea ontologiilor va imbunatati aplicatiile web existente si va largi gama activitatilor
desfasurate pe Web. OWL a fost creat special pentru indeplinirea acestor obiective.
In continuare, sunt prezentate cinci exemple de utilizare.
a. Portal web
Un portal web este un site web ce prezinta diverse informatii despre un domeniu de
interes specific, permitand utilizatorilor interesati primirea de stiri, schimbarea de opinii,
construirea unei comunitati si legarea de alte resurse web de interes comun.
Pentru ca un portal sa aiba succes, cel mai important lucru este gasirea unui continut
interesant. Aceste informatii sunt, de obicei, postate, de utilizatori. Pentru ca aceste
informatii sa fie bine structurate si usor de minat, este foarte utila definirea unei ontologii
pentru acea comunitate. Inferentele oferite de ontologie permit o cautare mult mai exacta
decat minarea textelor bazata numai pe cuvinte cheie.
Un exemplu de astfel de portal este OntoWeb, ce serveste comunitatii interesate de
cercetarea in domeniul ontologiilor. Alte exemple de portale dezvoltate folosind OWL:
AIFB SEmantic PortAL al Universitatii din Karlsruhe si AKT Portal al Universitatii din
Southampton.
b. Colectii multimedia
Ontologiile se pot dovedi foarte folositoare in a pastra continut semantic despre imagini,
audio sau alte obiecte netextuale, intrucat aceste obiecte sunt de obicei indexate dupa
metataguri spre a oferi un inteles despre continutul lor. Aceste ontologii se pot imparti in
doua categorii: specifice formatului media sau specifice continutului. A doua categorie este
mult mai interesanta, pentru ca este independenta de format.
c. Managementul site-urilor web ale corporatiilor
Corporatiile au adesea site-uri web cu o multitudine de pagini, majoritatea pentru utilizare
interna de catre angajatii acestora. Pentru o mai buna utilizare a informatiei de pe aceste
pagini nu este suficienta o taxonomie, ci ar fi mult mai utila folosirea unei suite de ontologii
specifice fiecarui tip de utilizator (fiecarui rol), ontologii ce pot fi dependente intre ele.
51
Managementul si cautarea informatiilor folosind ontologii ar deveni mult mai usoare si mai
flexibile.
d. Crearea documentatiilor
Ontologiile pot fi folosite cu succes si pentru descrierea documentatiilor create pentru un
anumit domeniu, in special in inginerie. Documentele pot fi de mai multe tipuri, fiecare tip
fiind destinat unei anumite categorii de utilizatori. Ontologiile pot fi folosite pentru a
construi un model informational care sa permite o cautare in spatiul informatiilor
reprezentate dupa articole, legaturi intre articole, alte documente care sunt necesare sau
utile. Folosind inferentele si constrangerile de care dispune OWL, se pot cauta articole
care indeplinesc anumite conditii (de exemplu daca folosesc o piesa de anumite
dimensiuni, atunci am constrangeri ale celorlalte piese folosite).
e. Agenti si servicii web
Web-ul semantic poate oferi agenti web cu capabilitatea de a intelege si de a integra
informatii preluate din diverse surse. Un exemplu poate fi un agent ce planifica activitatile
din timpul liber. Aceasta planificare depinde de sursele informationale si de preferintele
utilizatorului. Pentru aceasta trebuie sa existe ontologii care sa descrie termeni precum
hoteluri, restaurante, cinematografe, etc. Astfel de informatii pot fi preluate din diverse
surse, precum portaluri, site-uri de rezervare, etc.
Un astfel de exemplu este AgentCities, care ofera o serie de servicii business to customer
precum hoteluri, restaurante, cinematografe, clasificate in functieorasul in care sunt
disponibile.
Ontologiile pot fi folosite in orice domeniu unde este necesara adaugarea de sensuri
informatiilor pastrate. De aceea, OWL va fi folosit in special pentru prezentarea si cautarea
informatiilor. Permitand distribuirea surselor de informatii, OWL este cu atat mai puternic
cu cat permite si definirea constrangerilor de integritate a informatiilor.
Un alt exemplu de utilizare a OWL este Swoogle, un motor de cautare pentru documente
apartinand web-ului semantic, inclusiv ontologii, construit de Universitatea din Maryland.
In continuare voi prezenta doua exemple didactice de ontologii, plus niste link-uri catre
niste exemple de ontologii folosite in viata reala, dar care sunt mult prea stufoase pentru a
fi folosite in aceasta prezentare.
Exemplul 1 este foarte simplu si defineste clasa Airport si niste proprietati asociate
acesteia.
<rdf:RDF
xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xmlns:owl="http://www.w3.org/2002/07/owl#"
xml:base="http://www.daml.org/2001/10/html/airport-ont">
<owl:versionInfo>$Id: airport-ont.daml,v 1.1 2002/03/14 06:24:16 mdean Exp
$</owl:versionInfo>
<rdfs:comment>Airport</rdfs:comment>
52
</owl:Ontology>
<rdfs:Class rdf:ID="Airport">
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#name"/>
<owl:allValuesFrom
rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#iataCode"/>
<owl:allValuesFrom
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#icaoCode"/>
<owl:allValuesFrom
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#location"/>
<owl:allValuesFrom
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#latitude"/>
<owl:allValuesFrom
rdf:resource="http://www.w3.org/2001/XMLSchema#double"/>
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
53
<owl:onProperty rdf:resource="#longitude"/>
<owl:allValuesFrom
</owl:Restriction>
</rdfs:subClassOf>
<rdfs:subClassOf>
<owl:Restriction>
<owl:onProperty rdf:resource="#elevation"/>
<owl:allValuesFrom
</owl:Restriction>
</rdfs:subClassOf>
</rdfs:Class>
<owl:DatatypeProperty rdf:ID="elevation"/>
<owl:DatatypeProperty rdf:ID="iataCode"/>
<owl:DatatypeProperty rdf:ID="icaoCode"/>
<owl:DatatypeProperty rdf:ID="latitude"/>
<owl:DatatypeProperty rdf:ID="location"/>
<owl:DatatypeProperty rdf:ID="longitude"/>
<owl:DatatypeProperty rdf:ID="name"/>
</rdf:RDF>
Exemplul 2 defineste clasa Person, cu subclasele Man si Woman, pecum si proprietatile
isWifeOf, isHusbandOf. Intrucat foloseste elementul disjointWith acest exemplu este scris
in OWL DL.
<rdf:RDF
xmlns=http://owl.protege.stanford.edu#
xmlns:protege=http://protege.stanford.edu/plugins/owl/protege#
xmlns:rdf=http://www.w3.org/1999/02/22-rdf-syntax-ns#
xmlns:rdfs=http://www.w3.org/2000/01/rdf-schema#
xmlns:owl=http://www.w3.org/2002/07/owl#>
<owl:imports
rdf:resource="http://protege.stanford.edu/plugins/owl/protege"/>
</owl:Ontology>
<owl:Class rdf:ID="Person"/>
<owl:Class rdf:ID="Man">
54
<rdfs:subClassOf rdf:resource="#Person"/>
<owl:disjointWith>
<owl:Class rdf:about="#Woman"/>
</owl:disjointWith>
</owl:Class>
<owl:Class rdf:ID="Woman">
<owl:disjointWith rdf:resource="#Man"/>
<rdfs:subClassOf rdf:resource="#Person"/>
</owl:Class>
<owl:ObjectProperty rdf:ID="isHusbandOf"
rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty">
<rdfs:domain rdf:resource="#Man"/>
<rdfs:range rdf:resource="#Woman"/>
<owl:inverseOf rdf:resource="#isWifeOf"/>
<owl:minCardinality>0</owl:minCardinality>
<owl:maxCardinality>1</owl:maxCardinality>
<owl:ObjectProperty rdf:ID="isWifeOf"
rdf:type="http://www.w3.org/2002/07/owl#FunctionalProperty">
<rdfs:domain rdf:resource="#Woman"/>
<rdfs:range rdf:resource="#Man"/>
<owl:inverseOf rdf:resource="#isHusbandOf"/>
<owl:minCardinality>0</owl:minCardinality>
<owl:maxCardinality>1</owl:maxCardinality>
</rdf:RDF>
2.3.3. Concluzii Web semantic

Web-ul semantic devine tot mai necesar din cauza abundentei de informatii aflate pe Web,
informatii din domenii diverse. Daca se doreste ordine in informatie, atunci definirea unei
ontologii este neaparat necesara. In acest fel, se poate asocia sens unei bucati de text sau
de media.
Fiind gandit ca un limbaj distribuit, in care definirea ontologiilor poate fi facuta in diverse
locuri, OWL este va sta la baza Web-ului semantic. Permitand definirea de constrangeri
informationale si modelarea informatiilor pe baza de clase si proprietati, OWL este un
standard Web care are sanse mari de reusita.
55
Fiind inca la inceput, OWL este folosit, in mare parte parte, de mediul academic si de
cercetare. Succesul sau va depinde insa si de parerea marilor concerne din domeniul IT.
Daca va fi sustinut de un astfel de concern are sanse mari de reusita, altfel va ramane
doar un standard reusit.
Pentru a dezvolta ontologii folosind OWL exista o gama larga de instrumente, atat
comerciale, cat si gratis, care ofera facilitati diverse, de la editare vizuala pana la verificare
automata a corectitudinii sintactice si semantice a otologiilor generate.
Desi pare greoi de inteles, OWL este logic, iar pentru un programator obisnuit sa lucreze
orientat pe obiecte este chiar usor de utilizat. Posibilitatea de includere ale altor definitii,
clasele si instantele sunt toate cunoscute acestuia.
2.4. Potential de inovare
Datorita faptului ca definitia e-Guvernarii este foarte vasta si implica folosirea oricaror
tehnologii informatice si de telecomunicatii pentru imbunatatirea serviciilor administratiei
publice, inclusiv a implicarii si participarii active a cetatenilor la procesul de guvernare,
exista un potential imens de inovare din foarte multe de vedere. Cum tehnologiile IT&C
sunt in permanenta dezvoltare, si guvernarea electronica trebuie sa tina pasul cu acestea
si sa le foloseasca eficient, atat in folosul cetatenilor, cit si in folosul functionarilor publici.
De aceea, in cadrul acestei sectiuni sunt prezentate doar directiile principale de evolutie
ale e-Guvernarii in urmatoarea perioada, pentru a tine pasul cu ultimele avansuri
tehnologice si cu asteptarile utilizatorilor.
2.4.1. Noi capabilitati ale serviciilor publice electronice

Probabil cel mai important avantaj adus de catre serviciile de e-Guvernare, il reprezinta
deschiderea si transparenta in serviciile de administratie publica oferite cetateanului. Din
acest punct de vedere, toate tehnologiile care sprijina e-participarea si e-implicarea
cetatenilor in guvernare vor fi din ce in ce mai utilizate in viitorul apropiat: retele sociale,
forumuri de discutii moderate de oficiali, wiki-uri colaborative, propunerea de e-petitii de
catre e-cetateni si posibilitatea votarii/semnarii acestor e-petitii de catre alte persoane
pentru a ajunge sa fie discutate de administratia publica. In general, toate tehnoogiile
Web2.0 si cele ce vor permite si implica cetatenii in diverse forme de dezbatere cu
exprimarea acordurilor si dezacordurilor, vor fi folosite pentru a ajunge la ceea ce se
numeste e-democratie.
Un alt aspect important pe care serviciile publice electronice il vor aduce este reprezentat
de posibilitatea de definire si monitorizare stricta a fluxurilor de activitati. Astfel, se pot
aduce imbunatatiri chiar in productivitatea procesului legislativ prin urmaririrea si
modificarea acelor activitati care sunt deficiente sau introduc latente.
2.4.2. Dezvoltarea interactiunii cu utilizatorii

Interactiunea cu utilizatorii a serviciilor publice electronice reprezinta un capitol important
pentru a asigura usurinta navigarii, posibilitatea de acces la servicii in conditii cat mai
variate si a creste satisfactia clientilor. Din acest punct de vedere, un prim aspect care
trebuie luat in considerare datorita avansului tehnologic este acela al accesibilitatii
serviciilor publice in retelele si pe echipamentele mobile (precum telefoane mobile, tablete
mobile, PDA, etc.) Odata cu transformarea Web-ului spre acceptarea acestor noi
modalitati de interactiune, si serviciile publice trebuie sa urmeze aceeasi evolutie pentru a
56
fi cat mai utile clientilor sai. Legat de acest aspect, trebuie avute in vedere si noile forme
de interactiune ce sunt datorate atat tehnologiilor mobile, dar si avansului din alte domenii:
tehnologii colaborative, prelucrarea limbajului natural. Astfel, serviciile de e-Guvernare
trebuie sa se orienteze spre a folosi noile dezvoltari cauzate de Web-ul social si de
avansul din regasirea informatiei si mineritul textelor (cautari inteligente, etc.)
Un alt aspect important din aceasta categorie il reprezinta standardizarea serviciilor
publice electronice, a accesului la aceste servicii, a modului de interactiune cu serviciile,
precum si a datelor interschimbate intre servicii si utilizatori. Relevant din acest punct de
vedere este ideea aparitiei punctelor unice de acces (one-stop shop), care sa permita
accesul la toate serviciile publice din acelasi loc, folosind aceleasi date de autentificare si
urmarind aceleasi produri si aceiasi pasi.
Toate serviciile publice, trebuie sa beneficieze de modularitate si adaptabilitate pentru a
putea atinge al cincilea nivel de sofisticare definit de CE si sa devina servicii proactive,
complet automatizabile, care sa permita si personalizarea serviciilor pentru fiecare tip de
utilizator. Un aspect oarecum legat de personalizare, dar mai avansat, il reprezinta
accesibilitatea serviciilor publice electronice, in special pentru persoanele cu dizabilitati de
vedere.
In interactiunea cu utilizatorii nu trebuie neglijat nici aspectul important al securitatii datelor
si autentificarii. Utilizatorii trebuie sa aiba incredere ca datele comunicate de catre ei in
mod electronic vor fi disponibile numai autoritatilor statului si ca hiper-supravegherea de
catre anumiti angajati nu este posibila. Din acest punct de vedere, toate datele trebuie sa
fie comunicate incriptat si sa fie semnate electronic de catre utilizatori pentru a nu permite
repudierea acestora. Numai astfel se poate ajunge la o e-Guvernare sigura, care trebuie
sa fie dublata cu politici clare de acces la informatiile publice atat de catre cetateni, dar si
de catre functionarii publici.
De asemenea sunt foarte multe aspecte de interactiune om-calculator si design al
aplicatiilor care trebuie avute in vedere, precum ergonomie, utilizabilitate, navigabilitate,
etc.
2.4.3. Managementul identitatii electronice

Un element crucial al serviciilor publice electronice il reprezinta securitatea si
confidentialitatea datelor trimise de contribuabili catre autoritatile publice. Acestea sunt
asigurate cu ajutorul semnaturilor digitale, dar si a sistemelor de chei publice (PKI) cu care
se face incriptarea datelor comunicate. Insa utilizarea sistemelor de autentificare si
identificare digitala, aduc probleme la nivelul confidentialitatii datelor de identificare
digitala. In acest context, apar sisteme complexe de gestiune a identitatilor electronice,
multe dintre ele bazate pe ontologii si taxonomii care sa permita existenta diferitelor nivele
de identitate, roluri si acces la date. Aceste sisteme de management a semnaturilor
digitale si a eIdentitatii (eID) sunt esentiale nu doar pentru functionarea serviciilor publice
la nivel national, ci chiar european si transfrontalier, in general. Din acest punct de vedere,
Comisia Europeana finanteaza un proiect european complex numit STORK (Secure
idenTity acrOss boRders linKed) pentru a permite recunoasterea transfrontaliera a
sistemelor pentru eID si pentru a permite accesul oricarui cetatean european ce are un
eID la serviciile publice din 18 tari europene (pentru detalii, se poate consulta site-ul
proiectului https://www.eid-stork.eu/). Scopul proiectului este de a permite tuturor
cetatenilor din UE sa isi poata dovedi identitatea si sa foloseasca sistemele nationale de
57
identificare electronica (parole, carduri de identitate, chei publice, telefoane mobile, etc.) in
orice alta tara din UE.
Un rol important in asigurarea identificarii electronice il au si tehnologiile noi, precum cele
de identificare biometrica a cetatenilor. Acestea combina tehnologia cardurilor destepte
folosite pentru identificare si autentificare cu utilizarea datelor biometrice, precum:
recunoasterea amprentelor, recunoasterea irisului sau recunoastere faciala. Deja aceste
tehnologii sunt folosite pentru pasapoartele biometrice sau ePasapoarte in mai multe tari.
Chiar acolo unde nu sunt folosite date biometrice, cardurile destepte sunt folosite uzual
pentru identificarea si autentificarea persoanelor in realizarea tranzactiilor online cu
serviciile publice, dar cu servicii comerciale private.
Totusi, desi toate aceste tehnologii sunt folosite pentru a asigura securitatea datelor si a
evita fraudele, trebuie avuta in vedere si increderea publicului si acceptabilitatea lor de
catre cetateni si companii. In acest context, utilizarea datelor biometrice sunt privite cu
lipsa de incredere, atat de catre cetateni, care considera aceste dispozitive ca pe o
tentativa de invadare a dreptului lor la libertate, datorita posibilitatii urmaririi activitatilor lor
de catre stat, dar si de catre experti, care considera ca aceste tehnologii nu sunt sigure la
atacurile electronice, replicare si falsificare. Rezulta ca ultimul aspect care trebuie avut in
vedere la acest capitol este cel al prevenirii atacurilor asupra identitatii electronice, inclusiv
falsificarea dispozitivelor pentru identificare, dar si a datelor care sunt transmise.
2.4.4. Interoperabilitatea serviciilor publice electronice

Pentru ca serviciile publice electronice sa aiba o rata mare de adoptie si sa corespunda
necesitatilor, este necesar sa se asigure cooperarea si interoperabilitatea intre diversele
servicii publice si independenta de furnizori. Interoperabilitatea serviciilor publice este pe
cel putin trei nivele: tehnologica furnizarea serviciului sa nu depinda de folosirea unei
anumite tehnologii si schimbarea tehnologiei sa fie usor de realizat, organizationala
serviciile sa fie usor de adaptat in functie de schimbarile suferite de procesele si
organizarea administratiei publice, si semantica datele salvate trebuie sa fie usor de
interpretat si folosit in alte contexte. Pentru realizarea interoperabilitatii la nivel tehnologic
se pot folosi serviciile Web, arhitectura orientata pe servicii sau diverse software-uri si
tehnologii open-source, componente ce pot fi usor schimbate fara a afecta intregul sistem.
Pentru a asigura interoperabilitatea la nivel organizational, un rol foarte important at au
definirea politicilor si standardizarea serviciilor publice electronice, utlizarea de arhitecturi
de tip enterprise ce pot fi usor adaptate la modificarile organizationale (la nivel de resurse,
procese sau date). Ultimul aspect, cel al interoperabilitatii semantice a datelor se poate
atinge prin folosirea tehnologiilor si serviciilor specifice Web-ului semantic, utilizarea de
ontologii specifice proceselor, cu mapari intre diferitele ontologii folosite de organizatii
diferite. O alternativa la Web-ul semantic o reprezinta salvarea de metadate si folosirea
taxonomiilor. In orice caz, managementul cunostintelor folosite de serviciile publice
electronice devine o problema din ce in ce mai dificila.
2.4.5. Managementul cunostintelor
Odata cu evolutia si diversificarea serviciilor publice electronice, managementul
cunostintelor devine o problema din ce in ce mai dificil de rezolvat. Astfel, sursele de
cunostinte sunt fragmentate si eterogene, provenind de la diverse servicii, iar integrarea
58
lor este necesara pentru a folosi la maxim aceste date, atat de catre functionarii publici,
dar si de catre cetateni si companii.
Problema devine si mai dificila odata cu dezvoltarea mecanismelor de e-participare si e-
incluziune, prin care sunt introduse medii complexe, care de multe ori pot fi colaborative si
dinamice in timp. Oferirea de informatii in mod interactiv utilizatorilor va trebui si ea
rezolvata, putand aparea situatii in care acestia fac cereri ne-predictibile, care pot da
nastere chiar la situatii conflictuale din cauza cererilor mai multor utilizatori. Pentru a
rezolva cu succes astfel de probleme, serviciile trebuie sa fie gandite astfel incat sa fie
adaptabile la necesitatile fiecarui utilizator, mergand pana la servicii avansate, evolutive si
auto-extensibile.
Odata cu evolutia in timp, se va pune problema ca serviciile publice sa ofere asistenti
personali inteligenti pentru fiecare utilizator care sa foloseasca tehnici de regasirea
informatiilor, prelucrarea limbajului natural si invatare automata, mergand chiar la
dezvoltarea de agenti inteligenti care sa asiste utilizatorul in functie de profilul si de
istoricul acestora. Mai mult, se poate dovedi necesar ca in timp sa apara sisteme de
recomandare specifice pentru rezolvarea anumitor probleme ale utilizatorilor, in special
folosind tehnicile de filtrare si recomandare colaborativa, profitand astfel de volumul mare
de date si de utilizatori din sistem.
2.5. Descrierea serviciului Servicii publice de rezolvare a cererilor clientilor in
varianta actuala
2.5.1. Procesul actual

Persoanele fizice sau juridice se adreseaza unei persoane aflata la un ghiseu pentru a
inregistra o cerere adresata primarului.
O alta persoana din cadrul primariei foloseste o aplicatie pentru a introduce toate
informatiile necesare atat pentru persoanele vechi cat si pentru cele noi.
Cererea este transmisa unei alte persoane desemnata de catre primar, care va fi numita in
continuare director, pentru a fi analizata. In functie de continutul cererii si de propriile
consideratii, directorul triaza cererile pe care le trimite mai departe, catre primar, spre
aprobare si introduce in aplicatie toate elementele solicitate in cerere. Apoi, le marcheaza
in aplicatie pe cele respinse, si adauga o justificare.
Cererile aprobate sunt transmise catre primar care da o rezolutie, dupa care se trimit unui
functionar pentru a da un raspuns cu motivatie.
Cererile refuzate fac obiectul unei notificari transmise persoanelor prin e-mail.
Acest proces este lent, iar cei care depun cereri se plang de lipsa de promptitudine si de
accea trebuie elaborat un proces nou.
59
Figura 17. Procesul actual de rezolvare a cererilor clientilor
- Date de intrare :
Asa cum se observa din figura 17, datele folosite la intrare, respectiv iesire, sunt
manipulate cu ajutorul unor obiecte numite itemi. Itemii sunt alcatuiti din combinatii de
tipuri simple de date si tipuri de date complexe sau definite de utilizator. Fiecare metoda
primeste un obiect ca element de intrare trebuind sa intoarca un obiect ca element de
iesire. In cazul de fata se creeaza un obiect numit Cerere care are urmatoarea structura
folosita la modelarea procesului:
1. Cetatean care are tipul de data Record si este alcatuit din urmatoarele tipuri de date
simple:
a. IdentificatorC de tip Integer
b. NumeC de tip String
c. PrenumeC de tip String
d. Adresa de tip String
e. Oras de tip String
f. CodPostal de tip String
2. TemeCerere care are tipul de data Solicitare si este alcatuit din urmatoarele tipuri
de date simple:
a. NumeTema de tip String
b. NumarTema de tip Integer
c. Descriere
3. Tipurile de date simple:
a. NumarInregistrareCerere de tip Integer
b. SituatieCerere de tip Boolean
60
- Date de iesire :
Obiectul de iesire se prezinta sub forma unei copii a obiectului de intrare care are cateva
valori modificate. La iesire se vor obtine, in functie de rezolutie, doua obiecte, unul numit
Solutie, iar celalalt numit Notificare care au urmatoarea structura :
1. Solutie
a. NumarInregistrareCerere de tip Integer
b. Cetatean de tip Informatie, care are structura :
- IdentificatorC de tip Integer
- NumeC de tip String
- PrenumeC de tip String
- Adresa de tip String
- Oras de tip String
- CodPostal de tip String
c. TemeCerere care are tipul de data Solicitare si este alcatuit din urmatoarele
tipuri de date simple:
- NumeTema de tip String
- NumarTema de tip Integer
- Descriere
2. Notificare
a. email de tip String
3. text de tip String
- Functionalitati oferite:
- Organizare superioara a modului de solutionare a cererilor cetatenilor
- Colectarea, analizarea si compararea performantelor operationale pe baza
simularii. Cu ajutorul simularii se pot identifica (inainte de punerea in functiune a
aplicatiei in mediul real de executie) activitatile care au cea mai mare durata de
executie sau resursele care produc probleme de trafic. Tot cu ajutorul simularii
se poate determina timpul mediu de procesare a unei cereri
- Regulile utilizate in aplicatie se pot modifica dinamic, la executie. In momentul
executiei, managerul regulilor de domeniu afiseaza o lista de reguli. Fiecare
regula din lista poate fi modificata (inclusiv valorile parametrilor). Dupa salvarea
regulii modificate, regula poate fi publicata pentru a deveni activa.
- Pe baza analizei statice se pot efectua aprecieri ale eficientei procesului de
solutionare a cererilor inainte ca acesta sa fie pus in executie, pe baza simularii.
- Folosind rezultatele simularii se pot face aprecieri ale eficientei comparand
rezultatele mai multor simulari.
61
- Furnizori existenti ai serviciului
Primaria
- Procese aferente:
Cererile respinse de catre primar trebuie motivate de catre un functionar al primariei, prin
adaugarea unui text descriptiv, cu invocarea unor articole de lege, acolo unde este cazul.
- Indicatori ai calitatii serviciului
- Cost si eficienta
- Durata, timp maxim de asteptare
- Timpul mediu de solutionare a cererii
- Elemente de intrare: item introdus (minimum, maximum)
- Elemente de iesire: item obtinut (minimum, maximum)
- Intrare logica: conditii ce trebuie indeplinite inainte de inceperea activitatii
- Iesire logica: conditii ce trebuie indeplinite dupa ce datele de iesire sunt trimise
mai departe.
- Gradul actual de informatizare
In cadrul acestui proces exista prea multi operatori umani care fac ca procesul sa fie lent.
Procesul poate fi imbunatatit prin introducerea unei interfete grafice utilizator care sa
permita fiecarei persoane sa-si inregistreze singura cererea online. Clientii vor folosi o
aplicatie Web pentru a introduce si inregistra cereri. Clientii noi trebuie sa-si introduca
toate informatiile de identificare. Aplicatia Web declanseaza executia procesului.
- Gradul actual de automatizare
Procesul actual nu dispune de automatizare, ceea ce conduce la cresterea timpului de
operare. Se poate elabora un serviciu Web care sa preia datele despre client din cadrul
altor aplicatii ale primariei, cum ar fi de exemplu, sistemul de evidenta al populatiei.
Serviciul Web se modeleaza sub forma unui subproces separat. Parametrii pot fi obtinuti
din cadrul itemilor existenti si transferati in cadrul unei activitati reprezentata de serviciul
Web. Rezultatul obtinut de la serviciul Web poate fi folosit la actualizarea itemului din
cadrul procesului.
2.5.2. Prezentarea potentialului de inovare a serviciului Servicii publice de

rezolvare a cererilor clientilor
Calitatea serviciilor publice pentru cetateni poate creste substantial prin implementarea in
administratia publica a strategiei managementului relatiilor cu clientii/ cetatenii (Customer
Relationship Management CRM, respectiv Citizen Relationship Management CiRM),
recunoscuta ca un set de practici manageriale eficace.
Managementul relatiilor cu clientii (Customer Relationship Management CRM) reprezinta
o stategie care are la baza o serie de instrumente pentru dezvoltarea parteneriatelor pe
termen lung cu clientii, bazate pe cunoasterea cerintelor acestora (nevoi si asteptari) in
diferite etape ale relatiei cu clientii, livrand produse si furnizand servicii care sa
corespunda asteptarilor clientului.
62
Managementul relatiilor cu cetatenii (Citizen Relationship Management CiRM) reprezinta
o strategie si un set de practici de management, bazate pe tehnologie si focalizate asupra
cetateanului, pentru mentinerea si optimizarea relatiilor cu cetatenii si incurajarea de noi
forme de participare a acestora.
Obiectivul principal al CRM este de a ajuta organizatiile (inclusiv din administratia publica)
sa foloseasca resursele TIC si competentele angajatilor organizatiei pentru a intelege si a
capata noi perspective asupra comportamentului clientilor/ cetatenilor si a perceptiei
acestora privind conceptul de valoare (pentru un produs sau un serviciu). CRM permite
organizatiilor sa automatizeze, sa integreze si sa foloseasca inteligent instrumentele de
care dispun in relatiile cu clientii/ cetatenii, oferind posibilitatea realizarii unei legaturi
aproape personale intre acestia si organizatie.
Pentru scopul acestui studiu de caz ne referim la managementul relatiilor cu cetatenii in
administratia publica numai din perspectiva urmatoarelor procese: comunicare cu clientul/
cetateanul, crearea de valoare pentru client/ cetatean si rezolvarea cererilor depuse de
catre acestia.
2.5.2.1. Inovari tehnologice

Instrumentele folosite pentru lucrul cu procese permit:
Descrierea procesului urmata de modelarea grafica a acestuia, simularea timp de o
luna a operatiilor necesare, efectuarea de modificari. Avantajul folosirii unei arhitecturi
de tipul celei descrise este imens din acest punct de vedere, deoarece, pe de o parte,
prin modelare, se pot incerca mai multe variante ale aplicatiei realizate cu costuri
minime (instrumentele ajutatoare fac ca acest lucru sa fie foarte simplu si rapid), iar
pe de alta parte procesele care in realitate dureaza foarte mult (zile, saptamani, sau
chiar luni), in IT nu dureaza mai mult de cateva minute (simulare). In acest fel se
poate ajunge, prin incercari (mai putin costisitoare), la setul de reguli cel mai
avantajos, fiind posibila totodata adaptarea cu rapiditate la cererile de modificare
dictate de piata sau de cadrul legislativ.
Introducerea grafica a relatiilor dintre date, cetateni, sisteme si servicii
Identificarea si marcarea punctelor de masurare a indicatorilor de calitate
Personalizarea solutiei in functie de optiunile de punere in mediul real de executie
Testarea procesului si obtinerea asigurarii de functionare corecta
2.5.2.2. Inovari de management/organizationale

Pentru fiecare activitate se pot asocia resurse, cum ar fi, de exemplu, rolul necesar pentru
a efectua activitatea respectiva, resursele individuale sau de grup, durata necesara.
Rol: Specifica costul, disponibilitatea si scopul
Resursa: resursa individuala sau de grup, cost, disponibilitate, rol
Calendar: Specificarea duratei, perioadei de repetitie, datei de inceput, datei
posibile de incheiere.
Prin folosirea instrumentelor ajutatoare la elaborarea de aplicatii cu arhitectura orientata
pe servicii se pot face o serie de analize asupra datelor existente in sistem. Astfel, se
poate face o analiza dimensionala, prin care se analizeaza datele numerice agregate pe
63
baza unei dimensiuni. Pentru agreagre se folosesc functii totalizatoare (sum, count, avg
etc.). Folosind analiza dimensionala se pot face o serie de interpretari ale datelor cum ar fi:
provenienta cererilor: se determina cererile totale pe locatie (oras, cartier etc.)
media timpului de procesare a comenzilor pe locatie (oras, cartier etc.)
categoria de cetateni care depune cele mai multe cereri
Pe baza rezultatelor obtinute in urma analizelor si a simularilor se pot face aprecieri
referitoare la eficienta activitatilor din cadrul procesului, putandu-se lua masuri de
optimizare.
2.6 Descrierea serviciului public de consultan i asisten pentru afaceri
2.6.1 Procesul actual

Prin afaceri nelegem toi agenii economici care funcioneaz la un moment dat pe pia,
organizaii existente i nou nfiinate, indiferent de mrime, form de proprietate, profil i
domeniu de activitate, precum i persoane fizice autorizate. Toate aceste categorii de
organizaii sunt denumite generic n coninutul prezentului studiu de caz clieni. O
categorie aparte de clieni ai serviciilor publice de consultan i asisten, luat n
considerare n prezentul studiu de caz, o formeaz omerii. Furnizorul de servicii publice
pentru afaceri analizat n prezentul studiu de caz este Agenia Naional de Ocupare a
Forei de Munc. Ca servicii avem in vedere, printre altele, urmtoarele: formare
profesional, reorientare profesional i recalificare, elaborarea proiectului de buget al
asigurrilor pentru omaj i administrarea acestuia, asisten managerial i financiar
pentru afaceri etc.
- Date de intrare :
Nu exist o perspectiv clar asupra clienilor ageni economici i omeri
care au nevoie i solicit consultan i asisten n afaceri: cine sunt clienii?
Exist o nelegere limitat a cerinelor clienilor (n ceea ce privete nevoile i
ateptrile acestora): ce categorii de nevoi exist?
Companiile pierd clieni n favoarea competiiei; companiile mici sunt absorbite
de cele mari sau nu supravieuiesc.
Tot mai muli clieni sunt nemulumii.
Nr. omerilor i al persoanelor care necesit reorientare i recalificare
profesional este n cretere.
Potenialii clieni nu cunosc natura serviciilor publice de consultan i asisten
n afaceri puse la dispoziia lor i nici tipurile de organisme care ofer astfel de
servicii.
Competenele angajailor organizaiei furnizoare de servicii nu rspund cerinelor
clienilor.
- Date de ieire :
Baze de date privind clienii i categoriile de nevoi ale acestora referitoare la
consultan i asisten n afaceri, ntlnite n mod frecvent.
64
Procese operaionale i de comunicare defectuoase pentru client.
Preuri neatractive ale serviciilor, innd cont de calitatea acestora.
Clieni nemulumii sau nemotivai.
- Funcionaliti oferite:
Identificarea clienilor/ agenilor economici care au nevoie de suport, consultan
i asisten n afaceri.
Utilizarea TIC pentru organizarea, automatizarea i sincronizarea proceselor
organizaiei furnizoare de servicii.
Identificarea, atragerea i ctigarea de noi clieni.
mbuntirea/ creterea valorii furnizate clienilor existeni.
Reducerea costurilor cu activitile de marketing i serviciile oferite clienilor.
Reducerea nr. reclamaiilor.
- Furnizori existenti ai serviciului

Sunt prezentai la pct.1, subpct. 1.1.
- Procese aferente:
Orientarea clienilor: segmentarea clienilor, comunicarea cu clienii, retenia
clienilor.
Satisfacerea clienilor: crearea de valoare pentru client, rezolvarea reclamaiilor.
Loializarea clienilor: loializare tranzacional i loializare perceptual.
- Indicatori ai calitii serviciului

Nr. de clieni beneficiari ai serviciului de consultan i asisten oferit, precum i
rezultatele n afaceri ale acestora ca urmare a valorificrii serviciului oferit.
Soluii de afaceri oferite concretizate n nr. de contracte finanate, volumul
finanrii, crearea de noi companii etc.
Studii de fezabilitate realizate.
Nr. de reclamaii soluionate/ Nr. total de reclamaii nregistrate (frecvena de
monitorizare: lunar).
- Gradul actual de informatizare

Exist o serie de puncte de contact cu clienii pentru oferirea de consultan i
asisten financiar pentru mediul de afaceri.
65
Exist baze de date referitoare la clieni.
Modalitile de comunicare sunt cele clasice (comunicare direct, online) i de
multe ori defectuoase.
- Gradul actual de automatizare

Sporadic, companiile din mediul privat au implementat un program informatizat
pentru managementul relaiilor cu clienii. n instituiile publice acest obiectiv
reprezint n continuare o int greu de atins.
2.6.2 Prezentarea potentialului de inovare a serviciului publice de consultan i

asisten pentru afaceri
Calitatea serviciilor publice de consultan i asisten pentru mediul de afaceri, precum i
a serviciilor publice pentru ceteni poate crete substanial prin implementarea n
administraia public a strategiei managementului relaiilor cu clienii/ cetenii (Customer
Relationship Management CRM, respectiv Citizen Relationship Management CiRM),
recunoscut ca un set de practici manageriale eficace pentru mediul privat.
Managementul relaiilor cu clienii (Customer Relationship Management CRM) reprezint
o stategie care are la baz o serie de instrumente pentru dezvoltarea parteneriatelor pe
termen lung cu clienii, bazate pe cunoaterea cerinelor acestora (nevoi i ateptri) n
diferite etape ale relaiei cu clienii, livrnd produse i furniznd servicii care s
corespund ateptrilor clientului.
Managementul relaiilor cu cetenii (Citizen Relationship Management CiRM) reprezint
o strategie i un set de practici de management, bazate pe tehnologie i focalizate asupra
ceteanului, pentru meninerea i optimizarea relaiilor cu cetenii i ncurajarea de noi
forme de participare a acestora.
Obiectivul principal al CRM este de a ajuta organizaiile (inclusiv din administraia public)
s foloseasc resursele TIC i competenele angajailor organizaiei pentru a nelege i a
cpta noi perspective asupra comportamentului clienilor/ cetenilor i a percepiei
acestora privind conceptul de valoare (pentru un produs sau un serviciu). CRM permite
organizaiilor s automatizeze, s integreze i s foloseasc inteligent instrumentele de
care dispun n relaiile cu clienii/ cetenii, oferind posibilitatea realizrii unei legturi
aproape personale ntre acetia i organizaie.
Pentru scopul acestui studiu de caz concretizat n creterea gradului de inovare al
serviciilor publice pentru afaceri atenia ne este focalizat asupra implementrii n
administraia public a unui sistem de management al relaiilor cu cetenii i agenii
economici din perspectiva urmtoarelor procese: comunicare cu clientul (cetean sau
agent economic), crearea de valoare pentru client (cetean sau agent economic) i
rezolvarea reclamaiilor cu scopul evalurii satisfaciei clienilor (ceteni sau ageni
economici).
2.6.2.1 Comunicarea cu clientul

Comunicarea cu clientul se refer la procesul de transmitere de informaii, idei, dar i
decizii, instruciuni de lucru etc., n mod transparent i echitabil, clienilor organizaiei.
Pentru optimizarea relatiilor cu clientii, respectiv cresterea satisfactiei acestora, personalul
66
organizatiei cu responsabilitate, comunica permanent cu clientii referitor la: informatii
despre serviciile solicitate; formularea ofertelor tinand seama de cerintele si conditiile
specifice de afaceri ale fiecarui client; tratarea reclamatiilor primite de la clienti; informatii
referitoare la gradul de satisfactie al clientilor.
n vederea creterii eficacitii procesului de comunicare cu clientul, din perspectiva celor
dou pri implicate organizaia furnizoare de servicii-emitorul i beneficiarul
serviciului-receptorul acesta trebuie s conin urmtoarele etape:
Codificarea nelesului: selectarea limbajului care s exprime semnificaia unui
mesaj;
Transmiterea mesajului: de la emitor la receptor prin diverse ci de
comunicare (vizual, auditiv, electronic etc.);
Decodificarea i interpretarea: descrifrarea limbajului i explicarea sensului
mesajului de ctre receptor;
Filtrarea: deformarea sensului unui mesaj ca urmare a unor limite fiziologice sau
psihologice ale receptorului;
Feedback: verificarea de ctre emitent n ce msur mesajul transmis a fost
neles corect sau a suferit filtrri.
Principalele mijloace de comunicare vizeaz:
Comunicarea verbal;
Comunicarea nonverbal;
Comunicarea online;
Comunicarea telefonic;
Alte mijloace de comunicare: radio, Tv, fax etc.
2.6.2.2. Crearea de valoare pentru client

Valoarea adugat clientului se concretizeaz n beneficii obinute direct de ctre client ca
urmare a interaciunii cu furnizorul de servicii, precum i beneficii indirecte determinate de
mbuntirea calitii serviciului oferit. Beneficiile directe obinute ctre client sunt direct
determinate de competenele personalului organizaiei furnizoare de servicii cu
responsabilitate n domeniu. Beneficiile indirecte sunt influenate de gradul de
informatizare i automatizare a serviciului solicitat.
2.6.2.3 Rezolvarea reclamaiilor
Reclamaia este o expresie a unei insatisfacii sau nemulumiri a clientului fa de calitatea
produselor i a serviciilor furnizate, procedurile, tarifele i taxele aplicate, comportamentul
i competenele angajailor, la care este ateptat n mod explicit sau implicit un rspuns
sau o rezoluie. Sistemul de tratare a reclamaiilor trebuie s se caracterizeze prin:
accesibilitate uoar prin asigurarea canalelor multiple pentru exprimarea opiniilor;
investigarea profund i corect a reclamaiilor;
rezolvarea prompt i corect a reclamaiilor;
67
despgubirea pentru pagubele produse;
respectarea termenelor stabilite;
inerea la curent a clienilor privind stadiul de rezolvare;
pstrarea confidenialitii;
asigurarea tuturor resurselor umane i materiale adecvate;
furnizarea informaiilor ctre management n vederea mbuntirii serviciilor;
informarea clienilor despre mbuntirile adoptate n urma reclamaiilor.
ncurajarea reclamaiilor nseamn asigurarea unei accesibiliti uoare i bine
mediatizate, tratarea cu respect i seriozitate a fiecrui client, indiferent de obiectul
reclamaiei sau modalitatea de adresare a acestuia, optimizarea proceselor prin care sunt
tratate reclamaiile. Astfel, pe de o parte se obin informaii preioase pentru management,
iar pe de alt parte, clienii crora li s-au rezolvat prompt problemele, devin clieni cel puin
att de loiali ca i cei care nu au experimentat o problem. O reclamaie va trebui s
furnizeze urmtoarele informaii: obiectul reclamaiei, datele de identificare a persoanei,
care depune reclamaia, un numr de telefon pentru contactare ulterioar pe ct este
posibil i modul de soluionare, dac reclamantul are opiune n acest sens.
n ceea ce privete tratarea reclamaiilor, toate reclamaiile vor beneficia de aceeai
prioritate, indiferent de obiect, forma sau limba de prezentare. Reclamaiile clienilor vor fi
tratate pe trei nivele:
nivelul 1: operatorii de la Centrul de Relaii cu Clienii, pe ct posibil, rezolv
reclamaiile la primul contact cu clientul;
nivelul 2: reclamaiile care necesit luarea unor decizii, vor fi rezolvate de ctre
personalul de conducere desemnat n acest scop din cadrul organizaiei;
nivelul 3: reclamaiile ale cror rezolvare nu corespunde cu ateptrile clientului,
dup epuizarea tuturor posibilitilor interne, vor fi soluionate prin conciliere
extern.
O reclamaie se va considera rezolvat atunci cnd s-a reuit eliminarea obiectului
reclamaiei, adic restabilirea situaiei optime care ar fi existat dac defeciunea/ greeala
nu ar fi aprut i cnd reclamantul se declar mulumit de soluia adoptat. La orice tip de
reclamaie a clientului se va emite rspuns n scris, care se va expedia prin pot, la
adresa menionat de ctre client.
n cazul n care o reclamaie nu poate fi rezolvat n termenul prestabilit, clientul va fi
informat n scris asupra decalrii termenului i a stadiului n care se afl soluionarea
reclamaiei. Acest proces de informare se va repeta din 15 n 15 zile calendaristice, pn
la rezolvarea final.
2.6.2.4 Inovri tehnologice i organizaionale

Pornind de la cele trei procese descrise mai sus, prezentm n continuare cteva aciuni
concrete care conduc la mbuntirea eficacitii i eficienei acestor procese i sporesc
gradul de inovare al acestora.
68
Inovri tehnologice: crearea unor baze de date privind clienii i categoriile de nevoi
ale acestora referitoare la consultan i asisten n afaceri i actualizarea
permanent a acesteia; extinderea modalitilor de comunicare cu clientul inclusiv
prin posibilitatea adresrii solicitrii online i soluionrii acesteia n aceeai
modalitate; oferirea de informaii ct mai cuprinztoare (privind natura serviciilor,
soluii de afaceri oferite etc.) pe pagina web a furnizorului de servicii i asigurarea
transparenei acestora pentru toate prile interesate; implementarea unui program
informatizat de managementul relaiilor cu clienii i monitorizarea celor trei
componente ale acestuia: orientarea clienilor, satisfacerea clienilor i loializarea
clienilor (dup modelul companiilor private).
Inovri organizaionale: creterea calitii serviciilor publice de consultan i
asisten pentru afaceri, evaluat n termeni de ndeplinire a nevoilor i ateptrilor
(competen, promptitudine, responsabilitate); creterea eficacitii proceselor de
marketing prin realizarea unei comunicri relevante pentru client/ cetean;
creterea randamentului proceselor operaionale prin informatizarea acestora;
oferirea de preuri sczute ale serviciilor, competitive; simplificarea fluxurilor de
lucru i a procedurilor ncepnd cu adresarea solicitrii din partea clientului i pn
la rezolvarea reclamaiilor acestora, dup caz; eliminarea aprobrilor i avizrilor
inutile de ctre efii ierarhici superiori.
3. Concluzii
3.1. Tendinte si inovare in serviciile software pentru administratia publica
Serviciile software pentru administratia publica schimba deja modul de interactiune intre
cetateni si companii, pe de o parte, si organismele guvernamentale, de cealalta parte.
Nivelul mare de acceptare al acestor servicii de catre utilizatori dovedeste utilitatea acestor
servicii petnru cetateni si companii: economia de timp, energie si bani reprezinta
principalul avantaj, dar nu trebuie pierdute din vedere si celelalte castiguri: istoricul
tranzactiilor este mai usor de consultat, documentele nu se mai pierd fiind salvate digital,
etc. In plus, administratia publica are, de asemenea, o serie de avantaje: toate datele sunt
disponibile electronic, putandu-se explora foarte usor evolutiile si tendintele viitoare, se pot
face prognoze, se pot identifica serviciile mai putin folosite, etc. Nu in ultimul rand,
folosirea serviciilor de e-Guvernare reperzinta o solutie eficienta pentru combaterea
evaziunii si determinarea trisorilor sistemului public. Tocmai datorita acestor avantaje
multiple, serviciile publice electronice vor cunoaste o dezvoltare puternica si in perioada
urmatoare, preconizandu-se a reprezenta modalitatea cea mai importanta de interactiune
intre stat, cetateni, companii si alte organizatii in viitorul cel mai apropiat pentru majoritatea
problemelor.
Totusi, aceasta evolutie a sistemelor publice electronice nu poate fi facuta eficient fara
specialisti pe diferite niveluri: tehnologic, organizational, administrativ, legal si politic.
Tocmai din aceasta cauza este impresios necesara pregatirea specialistilor in sistemele
electronice pentru administratia publica si dezvoltarea de programe de formare
profesionala inca din ciclul universitar.
Din punct de vedere tehnologic, evolutia si inovarea in acest domeniu vor urma tendintele
generale din tehnologia informatiei si comunicatii, avand insa unele aspecte particulare. In
primul rand, e-Guvernarea va fi influentata de catre noile oportunitati pe care le deschide
cetatenilor: e-participarea si e-implicarea in procesele de decizie ale administratiei publice.
69
Apoi, va trebuie sa se concentreze pe dezvoltarea interactiunii cu utilizatorii, astfel incat
serviciile publice sa fie usor de folosit, accesibile tuturor persoanelor, ergonomice, intuitive,
etc. Un aspect important in perioada urmatoare il va consitui crearea unei modalitati de e-
identificare a cetatenilor si companiilor la nivel global astfel incat sa poata folosi orice
serviciu public din lume. Insa atingerea acetui obiectiv va ridica noi probleme de
scalabilitate, securitate si tehnologice.
Interoperabilitatea si cooperarea sistemelor electronice publice va fi un alt factor important
in dezvoltarea imediat urmatoare a acestui domeniu. Acest aspect va fi cu atat mai dificil
de realizat cu cat interoperabilitatea trebuie realizata atat la nivel tehnologic, dar si
organizational si de semantica a datelor. Mai mult, serviciile din tari diferite vor trebui sa
poata comunica eficient intre ele, de multe ori avand aspecte organizationale, legale si de
semantica a datelor diferite. Nu in ultimul rand, odata cu evolutia si cresterea numarului de
utilizatori si de servicii publice disponibile electronic, managementul eficient al
cunostintelor o sa aiba un rol important, putand aduce diferite aspecte noi, precum sisteme
publice de recomandare (de companii sau de actiuni de intreprins) sau chiar asistenti
personali care sa ghideze utilizatorii in functie de serviciile pe care trebuie sa le
foloseasca.
3.2. Rezumat servicii
In momentul de fata, exista o serie de servicii publice considerate fundamentale de catre
Comisia Europeana si care trebuie sa fie disponibile ca servicii electronice in perioada
imediat urmatoare. Primul pas important pentru aceste servicii este sa fie complet
disponibile online, tranzactionale, insa exista dezvoltari ulterioare pentru a face serviciile
proactive, adica complet automatizabile sau personalizabile in functie de necesitatile
utilizatorilor. In plus, exista o serie de alti indicatori care sunt relevanti pentru serviciile de
e-Guvernare: e-Procurement, care masoara avansul serviciilor electronice pentru
achizitiile publice, sau e-Participare, care maasoara nivelul in care cetatenii au
posibilitatea sa isi spuna opinia si sa se implice in actul de guvernare.
3.3. Implicatii asupra necesitatii calificarii si pregatirii de personal implicat in
servicii
Pentru a rezolva complexitatea serviciilor din administratia publica se impune formarea de
competente interdisciplinare care sa aiba in vedere domeniile: tehnologiile informatiei si
comunicatiilor, management, organizare si operare pe Internet, precum si legislatie,
psihologie si sociologie.
In domeniul tehnologiilor informatiei si comunicatiilor se urmareste formarea de
competente in proiectarea, implementarea, evaluarea si exploatarea tehnologiilor inovative
pentru administratie publica.
In domeniul managementului, organizarii si operarii pe Internet se urmareste formarea de
competente in ceea ce priveste capacitatea de gestiune eficienta, organizare flexibila si
usurinta de utilizare.
In domeniul legislatiei, psihologiei si sociologiei se urmareste formarea de competente in
ceea ce priveste intelegerea nevoilor cetateanului / firmelor, a abilitatii de a raspune
asteptarilor lor cu respectarea legalitatii.
70
In ceea ce priveste cunostintele, acestea trebuie sa aiba in vedere metode stiintifice de
analiza, proiectare si dezvoltare a serviciilor din administratia publica, eficientizarea
managementului, maximizarea productivitatii serviciilor
Programele de studiu pot fi adaptate diverselor profiluri de specialisti (administratie
publica, inginerie, management etc).
Din informaiile relevate mai sus reiese clar necesitatea pregtirii de personal calificat n
domeniul serviciilor pentru afaceri, att n ciclul de formare iniial (licent i masterat), ct
i n cadrul programelor de formare continu. La nivelul programelor de masterat, un
domeniu potenial de calificare ar fi Managementul serviciilor pentru afaceri.
Principalele competene dezvoltate de un astfel de program includ:
Dintre competenele profesionale amintim:
C1 - Operarea cu concepte i metode tiintifice n domenii interdisciplinare
C2 - Integrarea conceptelor avansate i metodelor specifice tiinelor economice n
dezvoltarea serviciilor pentru afaceri
C3 - Integrarea principiilor managementului schimbrii, managementului relaiei cu clienii
i responsabilitii sociale n dezvoltarea serviciilor pentru organizaii
C4 - Modelarea i implementarea proceselor de afaceri n domeniul serviciilor destinate
organizaiilor
C5 - Proiectarea, dezvoltarea i managementul serviciilor pentru afaceri
C6 - Inovarea serviciilor pentru afaceri utiliznd tehnologii moderne
Ca i competene transversale precizm:
CT1 - Aplicarea normelor i valorilor de etic profesional pentru luarea deciziilor i
realizarea independent sau n grup a unor sarcini/ obiective complexe la locul de munc
CT2 - Planificarea i organizarea resurselor umane n cadrul unui grup sau al unei
organizaii, n condiii de contientizare a responsabilitii pentru rezultatele profesionale
CT3 - Asumarea nevoii de formare continu pentru a crea premisele de progres n carier
i adaptare a propriilor competene profesionale i manageriale la dinamica mediului
economic
Profilul ocupaional al absolvenilor programului de masterat mai sus menionat vizeaz
(este precizat i codul COR):
241227 Specialist n dezvoltare organizaional
241919 Manager proiect
241922 Analist servicii client
241928 Specialist mbuntire procese
241931 Responsabil proces
241939 Administrator societate comercial
241946 Manager mbuntire procese
242307 Analist calitate
71
244101 Consilier/ Expert/ Inspector/ Referent/ Economist n Management
244107 Consultant n management
247007 Agent de dezvoltare
Un program de formare continu pentru pregtirea de personal calificat n domeniul

serviciilor pentru afaceri, program de tip modul compact ar trebui s aib un buget de ore
de cel putin 28 ore de curs i 28 ore de seminar. Un astfel de modul compact are la baz o
abordare interdisciplinar care permite acumularea de cunotine complexe de
management, marketing, finane, contabilitate, antreprenoriat, dar i formarea unor abiliti
de comunicare i prezentare, ntr-un mod care s permit cursanilor s neleag
sistemele de servicii pentru afaceri i s-i dezvolte abilitatea de a lucra n echipe, de a
lucra cu clienii i furnizorii i de a lucra eficient n sectorul serviciilor pentru a crea valoare
pentru clieni.
Cursul exploreaz tipurile de servicii pentru afaceri, evideniind nevoia pentru o abordare
interdisciplinar care s permit inovarea n servicii i studierea tehnologiilor i a
instrumentelor necesare pentru a genera inovaie n industria serviciilor.
Aplicaiile sunt concepute astfel nct s implice studenii n discuii i dezbateri, s
faciliteze analiza i dezbaterea de articole i lucrri tiinifice, analizarea i rezolvarea de
studii de caz, rezolvarea de teme n clas i acas, susinerea unei prezentri i realizarea
unui proiect final.
Formulm, astfel, dou recomandri de inovare n servicii necesare unei mai bune
nelegeri a sistemelor de servicii n procesele de afaceri:
implementarea unui program informatizat de managementul relaiilor cu clienii i
monitorizarea celor trei componente ale acestuia: orientarea clienilor, satisfacerea
clienilor i loializarea clienilor (dup modelul companiilor private);
asigurarea competenelor profesionale necesare i monitorizarea continu a
performanelor angajailor care contribuie n mod direct la crearea de valoare pentru
client, dar i indirect la adugarea de valoare proceselor operaionale ale
organizaiei,
4. Bibliografie
[1] - Yhang Shu, Study of e-Government The effective way of building service oriented government,
Journal of International Relations, 2010
[2] - Dave Mayo, Service Oriented Government: 7th SOA For E-Gov, 2009
[3] - Guvernul Romaniei, HG nr. 195/2010 privind aprobarea Strategiei nationale "e-Romania", 2010
[4] - European Commission, Smarter, Faster, Better eGovernment, 8th Benchmark Measurement, 2009
[5] - European Commission, eGovernment in Romania, 2010
[6] - Monica Palmirani, The role of legal knowledge from e-government to e-governance, Proceedings of
ICAIL2003, 2003
[7] - The Economist Intelligence Unit, E-government in Central Europe - Rethinking public administration,
2004
[8] - Panos Hahamis, Jennifer Iles and Mike Healy, e-Government in Greece: Bridging the gap Between
Need and Reality, Electronic Journal of e-Government, Volume 3, Issue 4, 2005
72
[9] - Demetrios Sarantis, Dimitris Askounis, Electronic government interoperability framework in Greece:
Project management approach and lessons learned in public administration, Journal of US-China
Public Administration, Volume 7, No.3, 2010
[10] - United Nations eGovernment Survey 2010, 2010
[11] - I. Foster, C. Kesselman, S. Tuecke, The Anatomy of the Grid: Enabling Scalable Virtual Organizations.
International Journal of High Performance Computing Applications, 15 (3) pp 200-222, 2001
[12] - I. Foster, C. Kesselman, J. Nick, S. Tuecke, The Physiology of the Grid - An Open Grid Services
Architecture for Distributed Systems Integration (extended version of Grid Services Architecture for
Distributed Systems Integration. IEEE Computer 35(6), pp 37-46). Open Grid Service Infrastructure
WG, Global Grid Forum, 2002
[13] - S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D.
Snelling, P. Vanderbilt, Open Grid services infrastructure (ogsi) version 1.0, 2003
[14] - Russell Kay, QuickStudy: Representational State Transfer (REST), ComputerWorld, 2007
[15] - Leonard Richardson, Sam Ruby - RESTful Web Services, OReilly Media, 2007
[16] - Ethan Cerami, Web Services Essentials. Distributed Applications with XML-RPC, SOAP, UDDI &
WSDL, OReilly Media, 2002
[17] - Antonescu, D., Rolul i importana activitii de consultan n atragerea i obinerea finanrilor pentru
mediul de afaceri din Romnia, Institutul de Prognoz Economic, Academia Romn, 2008.
[18] Ciumara, T.M., Piaa serviciilor de consultan n management din Romnia, Tez de doctorat,
INCE, 2010.
[19] Masi L, Fodell D., Murphy W., Wright K., 2009, Service Science, Management and Engineering
(SSME), IBM.
[20] Ministerul Economiei, Comerului i Mediului de Afaceri, Analiza serviciilor publice i private de
consultan destinate mediului de afaceri din Romnia Studiu calitativ i cantitativ, 2010.
[21] Ministerul Economiei, Comerului i Mediului de Afaceri, Strategia Guvernamental pentru
mbuntirea i Dezvoltarea Mediului de Afaceri, 2010.
[22] Ministerul Finanelor Publice, Cadrul Strategic Naional de Referin 2007-2013, www.mfinante.ro .
[23] Ministerul Finanelor Publice, Documentul Cadru de Implementare a Programului Operaional
Asisten Tehnic, , octombrie 2009, www.mfinante.ro .
[24] Piaa de consultan n management din Romnia n perioada 2009-2010, Asociaia Consultanilor
de Management din Romnia AMCOR., 2009.
[25] Pinhanez C., Kontogiorgis P., 2008, A Proposal for a Service Science Discipline Classification
System, IBM Research, T.J. Watson.
[26] Raport privind piaa de consultan din Romnia, 2008-2009, AMCOR.
[27] Raport privind piaa european de consultan n management, FEACO, 2007-2008.
[28] Serviciile pentru ntreprinderi un sector n expansiune, Comisia Naional de Prognoz, 2007.
[29] SR ISO 10002 : 2005 privind Managementul calitii; Satisfacia clientului precum i Liniile directoare
pentru tratarea reclamaiilor n cadrul organizaiilor.
[30] Survey of the European management consultancy market 2009, FEACO.
[31] www.feaco.org .
[32] www.ec.europa.eu .
[33] http://www.europeanprojects.ro/poscce322.html .
[34] www.fseromania.ro .
[35] www.fonduriadministratie.ro .
73
[36] www.inforegio.ro .
[37] www.oecd.ro .
74

WP1-2 RA - 2 - Anexa 3 PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

WP1-2 RA - 2 - Anexa 3 PDF

Încărcat de

Drepturi de autor:

Formate disponibile

Studiu de caz in domeniul

Servicii administratia publica

1 Tipuri de servicii in administratia publica date generale ..................................... 4

Etapa Descriere etapa

Figura 2. Masurarea maturitatii serviciilor publice online, model definit de C.E.

Figura 3. Nivelul mediu al sofisticarii serviciilor publice online in tarile EU27+

Figura 6. Rata de sofisticare de nivel 5 (targetizare sau serviciu proactiv)

1.3.1. Descrierea domeniului de servicii e-Guvernare

Dupa cum a fost mentionat si in introducere, termenul de e-Guvernare, provenind de la

Printre beneficiile aduse de e-Guvernare, cele mai importante se refera la:

Pentru ca serviciile de guvernare electronica sa fie folosite cu succes si adoptate de catre

Totusi, in special in contextul proiectului INSEED este important de remarcat ca e-

1.3.2. e-Participare si e-Incluziune

1.3.3. e-Guvernare in Romania

2. Cautarea unui loc de munca

3. Serviciu pentru urmarirea beneficiilor asistentei sociale

4. Eliberarea documentelor personale

5. Serviciu pentru inmatricularea autovehiculelor

6. Eliberarea autorizatiilor de constructie

7. Serviciu pentru monitorizarea declaratiilor la politie

8. Serviciu pentru librariile publice

9. Eliberarea certificatele personale

10. Inscrierea in universitati

11. Serviciu pentru anuntarea schimbarii de domiciliu

12. Servicii de sanatate pentru cetateni

14. Serviciu pentru plata impozitului pe profit

15. Serviciu pentru plata TVA

16. Inregistrarea operatorilor economici noi si modificarea datelor operatorilor

17. Date statistice ale operatorilor economici

18. Serviciu pentru gestiunea declaratiilor vamale

19. Eliberarea autorizatiilor de mediu

20. Serviciu pentru achizitiile publice.

Concluzia este ca in Romania exista un nivel mare de fragmentare al serviciilor de e-

Servicii referitoare la managementul de proiect:

Servicii referitoare la consultanta achizitii publice de servicii si bunuri:

2.1.2. Arhitectura de tip RPC

Figura 9. Functionarea unei serviciu web de tip RPC

Figura 11. Stiva serviciului web de tip RPC

Figura 12. Interactiunea serviciilor web folosind protocoalele de tip RPC

2.1.3. Arhitectura de tip REST

Figura 13. Resursa, URI, Reprezentare -> REST

- POST /weatherforecast.asmx HTTP/1.1

2.2. Arhitectura orientata spre servicii

2.2.9. Arhitectura orientata pe servicii in sistemele Grid

<owl:Class rdf:ID="OrganicThing" />

d. Definirea indivizilor (instantelor)

e. Definirea proprietatilor simple

2.3.2. Cazuri de utilizare

2.3.3. Concluzii Web semantic

2.4.1. Noi capabilitati ale serviciilor publice electronice

2.4.2. Dezvoltarea interactiunii cu utilizatorii

2.4.3. Managementul identitatii electronice

2.4.4. Interoperabilitatea serviciilor publice electronice

2.5.1. Procesul actual

2.5.2. Prezentarea potentialului de inovare a serviciului Servicii publice de

2.5.2.1. Inovari tehnologice

2.5.2.2. Inovari de management/organizationale

2.6.1 Procesul actual

- Furnizori existenti ai serviciului

- Indicatori ai calitii serviciului

- Gradul actual de informatizare

- Gradul actual de automatizare

2.6.2 Prezentarea potentialului de inovare a serviciului publice de consultan i