Programare in Internet

Internet.
Arhitecturi de sisteme
distribuite
Curs 1
Internet-ul poate fi descris ca un sistem deschis. Prin sistem

deschis se intelege un sistem a carei arhitectura nu este
secreta, adica producatorii sai i-au facut publica structura
suficient de detaliat astfel incat alti dezvoltatori sa-si poata
interfata la el propriile produse
Exemple de sisteme deschise: UNIX, protocoalele retelei
Internet. Putem considera ca sistemele deschise au inspirat
de asemenea tehnologiile bazate pe Java si/sau XML
Exemple de sisteme proprietare: Microsoft Windows, Mac
OS
Internet-ul are o arhitectura multinivel, inspirata de
modelul de referinta ISO/OSI
Scurt istoric al Internet-ului
Crearea Internet-ului a fost declansata de proiecte de cercetare din cadrul armatei US

de la sfarsitul anilor 50 si inceputul anilor 60
Armata US a sponsorizat dezvoltarea unei retele de cercetare, Arpanet, care
interconecta universitati si centre militare
Arpanet a fost stabilita in 1971
In 1974 au fost propuse primele protocoale independente de hardware: primele
versiuni ale TCP si IP inventate de Vincent Cerf and Robert Kahn
In anii 80 componenta militara a retelei Arpanet a fost transformata intr-o alta retea,
iar Arpanet a fost redenumita Internet
In 1990 Tim Berners Lee a creat World Wide Web (WWW, WEB sau W3). Aceasta a
propus:
O metoda de a atasa nume simbolice calculatoarelor din Internet
O metoda de reprezenta documentele cu legaturi simbolice intre ele (HTML)
Conceptele de server WEB pentru stocarea acestor documente si navigator
(engl.browser) pentru afisarea acestor documente
In 1992 a fost creat primul browser grafic de catre Marc Andriessen, si anume Mozaic.
Ulterior acesta a evoluat in Netscape
Structura Internet-ului
Aplicatii
utilizator
TFTP
SNMP
Aplicatii
utilizator
FTP
Nivelul presentare
Telnet
Nivelul aplicatie
Nivelul sesiune
Nivelul transport
TCP
Nivelul retea
IP
Nivelul legaturii de date

Nivelul fizic
UDP
ICMP
Internet-ul este o retea de sub-retele.

Sub-retelele comunica intre ele
printr-un nod special numit gateway.
Corespondena nivelurilor TCP-IP i

ISO OSI
Protocoale ale retelei Internet
Telnet protocol ce permite accesul la distanta la un calculator conectat la Internet, cu

conditia ca utilizatorul sa aiba drept de acces la calculatorul respectiv
FTP si TFTP protocoale de transfer de fisiere intre calculatoare
SMTP protocol pentru transferul postei electronice intre calculatoare
Kerberos protocol pentru transferul confidential de date intre calculatoare
SNMP protocol pentru monitorizarea si administrarea retelelor de calculatoare
DNS protocolul care permite denumirea simbolica a calculatoarelor conectate la Internet
NFS colectie de protocoale care permite accesul transparent la fisierele si directoarele dintro retea de calculatoare
TCP protocol orientat pe conexiune ce permite transferul sigur si fiabil al datelor intre
procesele aplicatiilor ce ruleaza pe calculatoare conectate la Internet
UDP protocol neorientat pe conexiune cu functie oarecum similara cu TCP, doar ca nu
garanteaza transferul sigur al datelor
IP protocol ce asigura transferul pachetelor intre calculatoarele conectate la Internet
ICMP protocolul de transfer a informatiilor de comanda si eroare intre componentele retelei
ARP si RARP protocoale ce asigura corespondenta directa si inversa intre adresele
hardware si adresele Internet ale calculatoarelor conectate la Internet
Adresarea in Internet
Principala functie a Internet-ului este schimbul de date intre calculatoare.
Pentru aceasta fiecare calculator din Internet are asignata o adresa IP
Versiunea cea mai raspinadita la ora actuala a protocolului IP este IPv4. In
IPv4 adresa unui calculator este un sir de 32 de biti. Acest sir se reprezinta
sub forma unui 4-uplu format din 4 octeti, separati prin cate un punct.
Exemplu: 151.23.40.3. Exista si versiunea IPv6 care foloseste 128 de biti
Multimea de adrese IP este impartita in 4 clase
Clasa A, 0 adresa retea (7) adresa calculator (24)
Clasa B, 10 adresa retea (14) adresa calculator (16)
Clasa C, 110 adresa retea (21) adresa calculator (8)
Clasa D, 1110 adresa multicast (28)
Clasa E
127.0.0.1 = adresa de loopback. Datele trimise aici se intorc inapoi la sursa.
Este utila pentru testarea aplicatiilor de retea folosind un singur calculator
Adresele IP sunt dificil de memorat in format numeric. De aceea s-a
introdus o metoda de a le atasa nume simbolice prin sistemul de numire a
domeniilor (engl.domain name system DNS)
Sistemul de numire a domeniilor in Internet

(engl.domain name system - DNS)
DNS = o modalitate de a denumi simbolic calculatoarele dintr-o retea bazata pe

TCP/IP (Internet) folosind o schema de denumire ierarhica
Exemplu: imap.dcs.kcl.ac.uk este numele calculatorului pentru gestiunea postei
electronice dintr-un anumit departament
Fiecare sufix dintr-un nume se numeste domeniu. Exemplu: dcs.kcl.ac.uk
kcl.ac.uk ac.uk uk. Relatia de exprima natura ierarhica a notatiei
com
edu
gov
mil
net
Determinarea adresei IP pornind de la nume

se face prin interogarea unui server de nume
(engl.name server). DNS = multimea tuturor
acestor servere
org
int
uk
ac
kcl
dcs
ro
Clienti si servere
Server = un calculator (program in executie) din cadrul unei retele care furnizeaza servicii
altor calculatoare (programe in executie) din cadrul retelei
Client = un calculator (program in executie) dintr-o retea care beneficiaza de serviciile unui
calculator (sau program) server
In Internet, comunicarea intre un client (program) si un server (program) se face folosind
suita de protocoale TCP/IP. Aceasta se bazeaza pe notiunile de port si soclu (engl.socket)
Port = un canal abstract prin care un calculator (program care ruleaza pe calculator) poate
comunica cu exteriorul. Un port este identificat printr-un numar. Porturile 01023 sunt
rezervate pentru servicii speciale. Cateva dintre acestea sunt:
Port 7:
ECHO
Port 21:
FTP
Port 23:
Telnet
Port 80:
HTTP
Port 25
SMTP
Port 110
POP3
Port 150
SQL-NET
Soclu = a pereche formata dintr-o adresa de IP si un port. Un soclu abstractizeaza notiunea
de canal de comunicatie intr-o retea bazata pe TCP/IP, usurand astfel programarea
Tipuri de servere
Servere de fisiere. Furnizeaza fisiere la cererea clientului; spre exemplu un depozit

de documente (engl.document repository).
Servere de baze de date. Stocheaza colectii mari de date structurate sub forma unor
baze de date; furnizeaza servicii de interogare a acestora folosind SQL.
Servere de groupware. Groupware = un sistem care permite unui grup de
participanti sa lucreze impreuna intr-un mediu partajat.
Servere WWW. Sunt servere de fisiere care contin componentele unui site din
WWW. Accesul la ele se face printr-un program client special numit navigator.
Servere de posta electronica. Permit receptia, stoarea si trimiterea de mesaje prin
posta electronica.
Servere de obiecte. Stocheaza obiecte si permit programelor client sa trimita mesaje
acestor obiecte.
Servere de imprimare. Furnizeaza clientilor servicii de imprimare.
Servere de aplicatii. Sunt servere dedicate uneia sau mai multor aplicatii
particulare si contin programele dedicate aplicatiei respective.
Middleware
Middleware este un term destul de vag ce se refera in general la toate nivelurile

software intermediare care sprijina comunicatia dintre un client si un server.
Un middleware furnizeaza un set standard de interfete pentru o colectie de
resurse distribuite disparate, eterogene si proprietare. Astfel dezvoltatorii isi vor
interfata aplicatiile cu partea de middleware in loc de interfetele de nivel coborat
ale resurselor proprietare.
Un exemplu de middleware este software-ul care interfateaza un program
navigator de sistemul WWW.
O tehnologie foarte raspandita este middleware-ul orientat pe mesaje MOM
(engl.message-oriented middleware). MOM gestioneaza tranzactiile dintre un
client si un server prin intermediul unor cozi care stocheaza mesajele transmise
intre clienti si serveri.
Un exemplu de MOM este WebSphere MQ dezvoltat de IBM (fost MQSeries).
WebSphere MQ gestioneaza transferul de mesaje intre clienti si serveri si stie sa
prelucreze patru tipuri de mesaje: datagrame mesaje unidirectionale, mesaje de
cerere, mesaje de raspuns si mesaje de raportare. WebSphere MQ este un lider in
domeniul platformelor middleware pentru integrarea aplicatiilor de e-business.
Arhitecturi multistrat (engl.tiered architectures)
O aplicatie distribuita este compusa dintr-o multime de programe care ruleaza pe

mai multe calculatoare conectate in retea. O schita a acestor programe impreuna
cu calculatoarele (engl.hosts) pe care ruleaza, responsabilitatile lor si protocoalele
prin care comunica se numeste arhitectura distribuita.
O clasificare a arhitecturilor distribuite se bazeaza pe conceptul de strat
(engl.tier). Un strat poate fi un calculator (insa putem avea aplicatii distribuite
virtual care ruleaza pe un acelasi calculator) sau o partitie logica de prelucrare
din cadrul aplicatiei. Deobicei un strat corespunde unui client sau server.
Avantaj: paradigmele de codificare sunt diferite de la strat la strat astfel ca
straturi diferite cer indemanari de programare diferite
Partitionarea logica a unei aplicatii distribuite trebuie sa aiba in vedere cel putin
urmatoarele trei elemente:
Logica de prezentare
Logica problemei (engl.business logic)
Logica datelor, responsabila cu persistenta datelor, controlul accesului concurent,
corectitudinea tranzactiilor, etc
Avantaj: straturile permit separarea elementelor enumerate mai sus
Clasificarea arhitecturilor multistrat
1 strat (engl.one tier)

Este simpla deoarece nu exista conectare in retea
Performante bune, deoarece nu exista comunicatii in retea
Sistemul este autocontinut
Nu exista posibilitatea accesului de servicii la distanta
Arhitectura monolitica, deci potential de cod spaghetti
2 straturi (engl.two tiers)
Straturi: client si server de WWW, arhitectura oarecum simpla
Separa logicii de prezentare de logica problemei
Potential mic pentru partajarea resurselor, o problema in comertul electronic
3 straturi (engl.three tiers)
Straturi: client, server de WWW, server de baze de date
Separa logica de prezentare, logica problemei si logica datelor
Necesita expertiza in plus, maparea obiectual-relational este destul de dificila
4 straturi (engl.four tiers)
Straturi: client, server WWW, server de aplicatii, server de baze de date
Flexibilitate ridicata, practic poate realiza orice
Nivel de expertiza foarte inalt, curba de invatare mare, cost foarte ridicat, poate fi
ineficienta datorita generalitatii
Arhitectura in 4 straturi
Client
Server
WEB
Server de
aplicatii
Baza de date
Partea dintre logica de prezentare (client) si logica datelor (baza de date) se mai
numeste si strat intermediar (engl.middle layer). El contine printre altele obiectele
problemei (engl.business objects), ce corespund entitatilor din domeniul problemei
Putem avea arhitecturi cu n 4 straturi (engl.n-tiers)
Cu cat numarul de straturi este mai mare, cu atat performantele pot sa scada,
implementarea este mai dificila si cere expertiza mai mare, complexitatea
sistemului este mai mare, costul total al sistemului creste. In consecinta, stabilirea
numarului de straturi trebuie facuta cu grija, in functie de cerintele reale ale
aplicatiei. Cel mai adesea o arhitectura in 3 straturi este suficienta.
Serverele de aplicatii sunt in general foarte scumpe si curba de invatare este foarte
lenta. Exemple de servere de aplicatii:
Proprietare: Weblogic (BEA), Websphere (IBM), ColdFusion (Macromedia),
etc
Disponibile liber: Zope, JBoss
Protocoale
Protocol = un set de reguli care guverneaza schimburile de mesaje intre

calculatoare/procese din cadrul unui sistem distribuit
Exemplu: un protocol simplu pentru o aplicatie de vanzare cu amanuntul de
produse electronice de uz personal.
Pentru a afla ce modele de calculatoare personale tip laptop sunt
disponibile pentru vanzare, un client trimite mesajul:
MODEL PC-LAPTOP
si primeste un raspuns de forma:
LISTA DE MODELE
P-0001 Dell Inspiron 8000
P-0002 Toshiba Protg 1800
Pentru a afla pretul unui anumit model, clientul trimite mesajul:

PRET p-0002
si primeste un raspuns de forma:
PRET 1399
Un exemplu de protocol: POP3

POP3 (Post Office Protocol versiunea 3) este un protocol simplu pentru posta
electronica. Un alt protocol mai complicat este IMAP. Clientii pot trimite si
citi posta de la un server de POP3. Cateva dintre mesajele la care stie sa
raspunda un server de POP3 sunt:
USER: un utilizator doreste sa-si citeasca posta electronica si transmite
numele contului
PASS: apoi transmite server-ului parola contului; daca numele contului si
paraola au fost corecte server-ul raspunde cu un mesaj ce incepe cu +,
altfel a aparut o eroare
STAT: care este numarul de mesaje primite ?
DELE: se doreste stergerea unui mesaj de pe server
RETR: se doreste aducerea unui mesaj de pe server
Programarea interactiunii dintre un client si un server de posta electronica la
acest nivel este perimata. Acum se folosesc biblioteci cu un grad inalt de
abstractizare, fapt ce usureaza programarea si nu necesita cunoasterea in
detaliu a unui protocol particular de posta electronica. Exemplu: JavaMail
Paradigme de programare distribuita

Se prezinta cateva modele de proiectare si implementare folosite in
dezvoltarea sistemelor distribuite. Se au in vedere doua obiective:
Gradul de apopiere de tehnologiile Internet, spre exemplu
TCP/IP
Examinarea a doua categorii de arhitecturi in functie de cine
initiaza transferul datelor: clientul sau serverul
Se discuta:
Modelul transferului de mesaje
Modelul obiectelor distribuite
Modelul evenimentelor
Modelul tuplelor
Modelul transferului de mesaje (I)
Se bazeaza pe ideea de protocol. Acesta poate fi gandit ca un limbaj ce

intruchipeaza functiile cerute de un client si pe care le furnizeaza un server.
Protocoalele se impart in:
Protocoale fixe, al caror vocabular este fixat si incapsulat in codul serverului si
clientului.
Protocoale adaptive, care se pot schimba la momentul executiei
Un exemplu de protocol fix este cel pentru comunicarea cu un server de nume:
Partea de client: CAUTA Nume, STERGE Nume, ADAUGA Nume, Resursa,
MODIFICA Nume, Resursa
Partea de server: RESURSA Detalii, STERGE OK, ADAUGA OK,
MODIFICA OK, EROARE Cod
O metoda de a implementa protocoalele adaptive este folosirea obiectelor
serializabile. Acestea sunt obiecte care pot fi transferate in retea sub forma de
date. Un astfel de obiect poate contine functionalitatea unei noi comenzi din cadrul
protocolului.
Modelul transferului de mesaje (II)
In cadrul acestui model clientii si serverii comunica prin transfer de mesaje de-a
lungul unor canale de comunicatie. Corespunde oarecum cu structura retelei in
care ruleaza clientii si serverii. Scopul acestui model este de a abstractiza detaliile
de nivel coborat si de a face astfel programarea aplicatiilor mai usoara.
Se preteaza in urmatoarele situatii:
Cerintele de comunicare sunt foarte simple
Sunt necesare performante foarte bune; acest model este cel mai eficient dintre
modele discutate; plata pentru aceasta eficienta este cresterea complexitatii
programarii
Exemplu: HTTP, protocolul de comunicare cu un server de WWW
Exista doua clase:
Transfer sincron de mesaje: entiatea A trimite un mesaj catre entitatea B, in
timp ce entitatea B prelucreaza mesajul, entitatea A se opreste si asteapta un
raspuns, dupa ce entitatea B raspunde entitatea A isi continua activitatea
Transfer asincron de mesaje: entiatea A trimite un mesaj catre entitatea B, in
timp ce entitatea B prelucreaza mesajul, entitatea A isi continua activitatea,
cand entiatea B raspunde, entitatea A poate prelua mesajul
Modelul obiectelor distribuite
Se numeste obiect distribuit un obiect rezident pe un calculator care poate fi invocat

de obiecte rezidente pe alte calculatoare astfel incat, dpdv al programatorului,
obiectele sa para a fi situate pe un acelasi calculator (adica toate detaliile de
comunicare sa fie ascunse programatorului).
Tehnologia obiectelor distribuite presupune urmatoarele:
Interceptarea apelurilor catre obiecte
Localizarea obiectelor
Comunicarea mesajelor si parametrilor catre aceste obiecte
Optional, returnarea eventualelor rezultate si transmiterea lor obiectului
apelant
Avantaj: obiectele distribuite corespund 100% modelului orientat pe obiect si din
acest motiv trecerea de la proiectare la implementare este usoara
Dezavantaj: performantele tehnologiilor de obiecte distribuite sunt inferioare
tehnologiilor de transfer de mesaje
Exemple
CORBA, propus de OMG
Apelul metodelor la distanta (engl.Remote Method Invocation) Java RMI
DCOM, propus de Microsoft
Acest model presupune asocierea unor portiuni de cod cu anumite
evenimente. Codul va fi executat automat la declansarea evenimentelor
respective.
Acest model de programare este foarte raspandit in programarea
interfetelor grafice. Dezvoltarea unei astfel de interfete presupune
urmatoarele:
Controale grafice, spre exemplu butoane, sunt plasate intr-un
container de tip fereastra principala, numita si cadru (engl.frame)
Fereastra cadru implementeaza o interfata prin intermediul careia va
fi invocata la declansarea unor evenimente. Codul de tratare a
evenimentelor va fi amplasat in metodele ce implementeaza aceasta
interfata.
Fereastra cadru se inregistreaza la controalele grafice ca obiect
ascultator (engl.listener), ceea ce semnifica faptul ca este interesata de a
fi informata la declansarea anumitor evenimente.
La declansarea unui eveniment, controlul grafic informeaza toate
obiectele ascultator inregistrate la el.
Magistrala de obiecte (I)
Modelul evenimentelor este folosit si in arhitecturile de tip magistrala de obiecte

(engl.object bus)
Obiecte ascultator
Obiect transmitator
Magistrala de obiecte
Magistrala de obiecte (II)
Intr-o magistrala de obiecte, serverele imping datele catre clienti, din acest motiv
folosindu-se si terminologia push tehnology. Spre deosebire, in obiectele distribuite
clientii extrag datele de la serveri, folosindu-se terminologia pull technology.
In magistrala de obiecte, transmitatorul este server si ascultatorii sunt clienti.
Arhitectura magistrala de obiecte este utila in aplicatiile in care evenimentele se
declanseaza in timp real iar multimea de ascultatori se poate schimba dinamic.
Exemple:
Furnizarea de date despre piata de capital institutiilor financiare interesate
Teleconferinte sau aplicatii conversationale (engl.chat room), unde mesajele intre
participanti se transmit in timp real
Aplicatii multimedia distribuite de tip video la cerere (engl.video on demand), unde un
mare volum de date trebuie transmis in timp real abonatilor
Exista doua mari clase de arhitecturi de tip magistrala de obiecte:

Arhitectura butuc si spite (engl.hub and spoke)
Magistrala cu multitransmisie (engl.multicast bus architecture)
Arhitectura butuc si spite

Transmitator
Dispecer
Ascultatori
Transmitatorul trimite date catre dispecer (butuc), iar acesta le distribuie ascultatorilor
inregistrati. Poate exista cate un dispecer pe canal, sau un singur dispecer pentru toate
canalele.
Avantaje: usor de implementat folosind socket-ui sau RMI, contabilizarea poate fi

centralizata la dispecer
Dezavantaje: se genereaza un volum mare de trafic comparativ cu magistralele cu

multitransimise, fiabilitate scazuta deoarece totul depinde de dispecer
Magistrala cu multitransmisie
Tehnica multitransmisiei permite transferul unui singur mesaj de
la transmitator catre mai multi receptori.
Mesajul este transmis pe o magistrala, de unde este preluat de toti
ascultatorii interesati; ascultatorii sunt activati printr-un
eveniment care ii informeaza ca mesajul este disponibil pe
magistrala.
Un exemplu este iBus de la SoftWired Ltd care poate fi gandita ca
un fel de implementare software a protocolului Ethernet. Astfel
mesajele vor fi preluate numai de destinatarii interesati; daca
mesajul nu este necesar este pur si simplu ignorat si lasat sa treaca
urmatorului destinatar conectat la magistrala.
Modelul tuplelor
A fost folosit in limbajul de programare de nivel inalt Linda, dezvoltat de

cercetatorii americani Nicolas Carriero and David Gelerntner in 1980. Acesta a
fost raspandit doar in mediul academic. Firma Sun s-a inspirat din el in 1990
pentru a dezvolta tehnologia JavaSpaces ca parte a proiectului JINI. JINI este o
arhitectura deschisa pentru interconectarea in retea a unei multimi de servicii
implementate soft sau hard si care poate fi reconfigurabila dinamic, iar
JavaSpaces este modelul de programare distribuita folosit in JINI.
In JavaSpaces procesele comunica prin intermediul unor zone partajate numite
spatii (engl.spaces). Clientii pot accesa aceste spatii prin 3 operatii:
write, pentru adaugarea unui nou obiect la un spatiu
take, pentru citirea unui obiect si eliminarea sa dintr-un spatiu
read, pentru crearea unei copii a unui obiect dintr-un spatiu
Spatiile sunt containere de obiecte cu urmatoarele proprietati:

Sunt partajate si pot fi accesate concurent
Sunt persistente
Sunt asociative adica obiectele sunt localizate prin regasire asociativa (engl.associative
lookup)
Tranzactiile pe aceste spatii sunt sigure
Spatiile permit schimbul de continut executabil
World Wide Web
Curs 2
WWW
SIT WEB
SITE WEB
Viziunea viitoare asupra WEB
Omniprezent
Nu exista autoritate centrala
Colectie de omponente eterogene si autonome
Web semantic
Calcul P2P
Procese
Web pragmatic
Web pragmatic
Modele si tehnologii bazate pe servicii Web, semantica, agenti
care pot fi utilizati pentru a crea sisteme informatice mari,
deschise
Web pragmatic
Negociere: modelare semantica, interactiuni P2P, interactiuni
multiple in procese de business
Directii de dezvoltare:
Automatizare: oameni, programe

Marcare mai bogata
Activitati mai bogate: Pasiv Activ, Servicii Procese
Considerare context: semantica intelegere mutuala pragmatica
Evolutie sisteme: centralizat

Terminal
3270
Terminal
Terminal
Terminal
Terminal
Mainframe
Terminal
Terminal
Terminal
Terminal
Terminal
Terminal
Evolutie sisteme: Client-Server
PC
Client
E-Mail
Server
Master-Slave
Workstation
Client
Web
Server
PC
Client
PC
Client
Database
Server
Evolutie sisteme: Peer-to-Peer
Application
Application
Application
Application
E-Mail
System
Web
System
Database
System
Evolutie sisteme: Cooperative
Agent
Application
Application
Application
Agent
Agent
Agent
Application
Agent
E-Mail
System
Agent
Agent
Web
System
(Mediators, Proxies, Aides, Wrappers)
Agent
Database
System
Evolutie similara la nivelul retelelor
Internet
Intranet: retea privata la nivelul unei intreprinderi
Extranet: retea privata limitata la anumite
intreprinderi selectate
Virtual Private Network (VPN): un mod de a
realiza intranet sau extranet in Internet
Internet computing sau servicii Web toate aceste
posibilitati
Sisteme deschise: caracteristici
Componente autonome
Componente eterogene
Configuratia se modifica dinamic:
comportare, arhitectura, implementare,
interactiuni
intra si ies
Sisteme deschise si Web pragmatic
Servicii
Semantica
Agenti
Ce este World Wide Web ?
WWW este un sistem hipermedia distribuit. Se bazeaza pe un model de structurare a

documentelor care foloseste trei concepte:
Multimedia se refera la integrarea mai multor tipuri de media in cadrul
aceluiasi model de document: text, grafica, imagine, video, etc.
Hiperdocument se refera la crearea de legaturi intre documente, folosind un
mecanism propriu modelului de document.
Documente distribuite se refera la documente care contin legaturi la
documente stocate pe alte calculatoare din cadrul unei retele.
Se spune ca WWW foloseste un model de documente hipermedia distribuite.
Termenul de hipermedia inglobeaza conceptele de multimedia si hiperdocument.
Fiecare autor care creaza o resursa informationala (engl.information resource) in
WWW o considera ca fiind un document separat. Insa, putem considera ca, la nivel
global, multimea tuturor resurselor informationale din WWW formeaza un unic
document hipermedia distribuit. Din acest punct de vedere, termenul de resursa
informationala este mai potrivit decat cel de document.
Exista trei nivele de distribuire a resurselor informationale in WWW: acelasi fisier,
fisiere separate pe acelasi calculator, calculatoare diferite.
Scurt istoric al WWW
WWW s-a nascut in lumea academica, la Laboratorul european de fizica

particulelor (CERN) din nevoia de acces rapid si comod la publicatiile stiintifice. In
1989 Tim Berners Lee a conceput prima lucrare ce a descris un prototip de sistem.
In 1990 proiectul s-a aprobat oficial, fiind denumit World Wide Web si s-a produs si
prima implementare. In 1991 sursele prototipului au fost facute publice si totodata
sistemul a fost instalat oficial in cadrul CERN.
In 1992 numarul de servere WWW fiabile a ajuns la 26, incluzand locatii din toata
lumea. In 1993 numarul de servere a crescut la 200.
In 1993 a aparut primul navigator grafic, Mosaic, autor Marc Andresseen din cadrul
National Center of Supercomputing Applications (NCSA). Ulterior el a pus bazele
unei firme, iar Mosaic a devenit popularul navigator Netscape.
In 1994 a aparut consortiul WWW (W3C). CERN a cedat responsabilitatea WWW
Institutului francez de cercetare in stiinta calculatoarelor si control (INRIA). Acum
W3C este parte a Massachusets Institute of Technology (MIT) si INRIA.
In 1995 Microsoft a produs Internet Explorer declansandu-se astfel razboiul
navigatoarelor WWW. Acest razboi continua si astazi.
Desi WWW a aparut in 1990, conceptele de baza au ramas aceleasi pana astazi: URL
(denumirea unui document), HTTP (regasirea unui document) si HTML (descrierea
continutului unui document).
Arhitectura WWW
Este o arhitectura client/server tipica.
Un server WWW are sarcina de a gestiona o multime de documente din
cadrul WWW. Aceste documente se numesc si pagini WWW.
Un client generic de WWW este un program care emite cereri catre un
server WWW pentru accesarea paginilor WWW gestionate de acel
server. Exemple de clienti sunt:
Un navigator WWW care permite regasirea si afisarea paginilor
WWW in scopul vizualizarii continutului lor de catre un agent uman.
Un program de tip softbot care localizeaza diverse pagini WWW in
scopul crearii unui index. Indexul poate fi utilizat ulterior de un
motor de cautare.
Conceptele pe care se bazeaza tehnologia WWW sunt:
Schema de denumire a resurselor (engl.uniform resource locator) URL
Protocolul de transfer al documentelor (engl.hypertext transfer protocol)
HTTP
Limbajul de specificare a continutului paginilor WWW (engl.hypertext
markup language) HTML
Identificarea resurselor in WWW
Pentru identificarea resurselor in WWW se foloseste un URL (engl.Uniform

Resource Locator). Un URL este un identificator simbolic al resursei si este compus
din doua parti:
Schema, care indica modalitatea folosita pentru denumirea resurselor. Spre
exemplu, schema poate fi numele unui proocol: ftp, http, etc
Partea specifica schemei, care indica cum se adreseaza resursa in cadrul schemei
respective
Sintaxa URL este schema : parte-specifica-schemei. Partea specifica schemei are
sintaxa // [utilizator [: parola] @ ] gazda [ : port] / cale
utilizator si parola sunt optionale si se aplica doar cu schemele care au sens (de
exemplu ftp).
gazda indica numele calculatorului pe care se afla resursa, sau adresa de IP a
acestuia.
port reprezinta numarul portului pe care se face conexiunea. Este optional,
deoarece acest numar este predefinit pentru serviciile standard. Pentru HTTP
portul predefinit este 80.
cale reprezinta calea de acces la resursa in cadrul calculatorului specificat. In
general este o cale fizica existenta in sistemul de fisiere de pe calculatorul gazda.
Introducere in HTTP
Este protocolul de comunicare intre clientii si serverele WWW. El specifica

cererile care pot fi adresate de clienti si raspunsurile care pot fi generate de
servere. Specificatia contine structura si formatul (sintaxa) acestora.
Scurt istoric:
HTTP/0.9 versiunea initiala, inainte de raspandirea WWW, foarte limitata. Singura
cerere admisa este GET, la care serverul raspunde cu documentul cerut.
HTTP/1.0 dezvoltata din 1992, este un document informativ, nu un standard.
Foloseste conceptul de tip media (MIME). S-au introdus noi cereri, dintre care foarte
importanta este cererea POST pentru trimiterea de date de la client catre server.
HTTP/1.1 propusa in 1997. Inlatura principalele probleme ale versiunii anterioare:
modelul interactiunii unice cerere/raspuns pe conexiune TCP/IP, model care are
performante slabe, lipsa de suport pentru gazdele virtuale non-IP. Conceptul de gazda
virtuala (engl.virtual host) permite unui server WWW sa deserveasca cereri catre mai
multe calculatoare gazda. In HTTP/1.1 este posibil sa se specifice explicit in cererea
HTTP calculatorul gazda careia ea ii este adresata rezultand astfel conceptul de gazda
virtuala non-IP.
Cererile si raspunsurile HTTP se mai numesc si mesaje. Un mesaj este un sir de

caractere ce contine: linia de start (engl.start line), zero sau mai multe campuri
antet (engl.message header field) si optional un camp corp (engl.message body field).
Cereri si raspunsuri HTTP
Antetele unui mesaj pot fi: antete generale (engl.general header) se refera la mesaj, nu la
entitatea transmisa; antete de entitate (engl.entity header) se refera la entitatea transmisa
sau referita; antete raspuns (engl.response header) serverul comunica clientului informatii
care nu au fost incluse in linia de start.
Cereri Linia de start se numeste linie de cerere (engl.request line) si are structura:
metoda spatiu url_resursa spatiu versiune_http sfarsit_linie
GET /staff/badica/index.html HTTP/1.1
Connection: Keep-Alive
Host: www.dcs.kcl.ac.uk
Accept: text/html
Raspunsuri Linia de start se numeste linie de stare (engl.status line).

HTTP/1.1 200 OK
Date: Thu, 01 Aug 2002 16:03:06 GMT
Server: Apache/1.3.20 (Unix) PHP/4.0.3pl1 mod_perl/1.26
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
2d8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
....
</html>
Sintaxa formala a unei cereri HTTP
HTTP 1.0 este descris la nivel informativ in documentul RFC 1945.

HTTP 1.1 este descris in propunerea de standard RFC 2068.
O cerere HTTP are structura urmatoare ([...] specifica un element optional si *
specifica 0 sau mai multe repetitii ale unui element):
cerere =
linie-de-cerere
(antet-general | antet-cerere | antet-entitate)*
sfarsit-de-linie
[corp-mesaj]
linie-de-cerere = metoda spatiu uri spatiu versiune-http sfarsit-de-linie

metoda =
OPTIONS | GET | HEAD | POST | PUT | DELETE |
TRACE | CONNECT | metoda-extensie
uri = * | uri-absolut | cale-absoluta
Sintaxa formala a unui raspuns HTTP

Un raspuns HTTP are structura
urmatoare:
raspuns =
linie-de-stare
(antet-general | antet-raspuns | antet-entitate)*
sfarsit-de-linie
[corp-mesaj]
linie-de-stare = versiune-http spatiu cod-stare

spatiu fraza-motiv sfarsit-de-linie
cod-stare = cod-succes | redirectare |
eroare-client | eroare-server | ...
cod-succes = ok | creat | acceptat | ...

ok = 200
creat = 201
acceptat = 202
redirectare = mutat-permanent | mutattemporar | ...
mutat-permanent = 301
mutat-temporar = 302
eroare-client = cerere-gresita | neautorizat |

plata-necesara | interzis |
resursa-inexistenta | metoda-nepermisa | ...
cerere-gresita = 400
neautorizat = 401
plata-necesara = 402
interzis = 403
resursa-inexistenta = 404
metoda-nepermisa = 405
eroare-server = eroare-interna | nu-esteimplementata | ...
eroare-interna = 500
nu-este-implementata = 501
Cookies
HTTP este un protocol fara stare (engl.stateless). Acest lucru inseamna ca HTTP nu
dispune de un mecanism propriu care sa permita unui server WWW sa poata
pastra informatii despre starea utilizatorului..
Termenul de cookie se refera la mecansimul prin care o aplicatie WWW pe partea
de server poate stoca si regasi informatii pe partea de client. El permite adaugarea
adaugarea unei stari a conexiunii stocata la client.
Serverul specifica clientului ca vrea sa stocheze un cookie prin antetul Set-Cookie,
in maniera urmatoare:
Set-Cookie: Nume=Valoare
Ulterior, clientul va include cookie-ul intr-un antet al unei cereri sub forma:
Cookie: Nume=Valoare
Suplimentar, antetul Set-Cookie mai poate contine urmatoarele informatii:
domain: specifica domeniul in care se aplica cookie-ul
expires: specifica data de expirare a cookie-ului
path: specifica URL-urile la care clientul va returna cookie-ul in cererea HTTP
secure: specifica faptul ca cookie-ul va fi returnat de client numai daca conexiunea
este sigura.
Ex: Set-Cookie: Credit=111; secure; expires=Thursday, 07-Dec-2000,
10:00:00 GMT; domains=.comp-craiova.ro; path=/
Trimiterea de date catre un server WWW
Paginile de WWW pot fi statice si dinamice. Paginile statice sunt stocate explicit pe
server si returnate clientilor ca raspuns la cereri GET. Paginile dinamice sunt
generate dinamic de server, nefiind stocate explicit. Este posibil ca aceste pagini sa
fie configurate pe baza unor date trimise de la client catre server. Astfel de date pot
fi de exemplu criterii de cautare intr-o baza de date, paginile generate dinamic fiind
in acest caz rapoartele rezultate in urma cautarii.
Exista doua metode de a transmite date de la client la server:
Folosind metoda GET, datele sunt atasate URL-ului sub forma unor perechi variabilavaloare. In acest caz URL-ul reprezinta un program aflat pe server si datele sunt
transmise acestui program in mediul sau de executie (engl.environment). La URL se
adauga un sir de forma:
?nume1=valoare1&nume2=valoare2& &numen=valoaren
Un este codificat prin + si un caracter special printr-un cod hexa precedat de
%. Ex. ?cale=%2Fweb%2 semnifica valoarea /web/ pentru variabila cale.
Folosind metoda POST, datele sunt atasate in corpul cererii, spre deosebire de cazul
anterior, unde sunt atasate URL-ului, in antet. Ele sunt transmise programului prin
intrarea standard.
Serverul preia datele de la programul invocat prin iesirea standard si le trimite

apoi clientului. Aceasta tehnica de a extinde functionalitatea unui server WWW
pentru generarea dinamica de pagini se numeste Common Gateway Interface
(CGI).
Interactiunea dintre CGI si formularele HTML
Formularele (engl.form) furnizeaza paginilor WWW suport pentru interactivitate.

Ele se specifica cu elementul form. Acesta accepta atribute ca: action pentru a
indica programul de prelucrare a datelor formularului, method pentru
specificarea metodei HTTP folosita pentru transferul datelor catre server (GET sau
POST), target pentru a specifica fereastra care contine formularul, etc.
In interiorul elementului form se introduc elemente pentru descrierea controalelor
de interactivitate. Acestea pot fi:
input, un element general cu tipul descris prin atributul type. Acesta poate
fi: text pentru o caseta de editare, password pentru o caseta de editare a
unei parole, checkbox pentru o caseta de validare, radio pentru un buton de
selectie exclusiva (engl.radio button), submit pentru un buton de trimitere a
datelor catre server, etc.
select, pentru definirea unui meniu. Optiunile meniului se descriu cu
elementele option si optgroup. Meniul poate fi cu selectie simpla sau
multipla (multiple)
textarea, pentru definirea unei camp de editare multilinie.
Pentru vizualizarea datelor trimise catre server se va implementa formularul
folosind metoda GET si se va vizualiza URL-ul generat in campul de adresa al
navigatorului WWW.
Programare pe partea de client
Curs 3
Clasificare
Programare pe partea de client (engl.client side
programming) = executarea de programe la client in
scopul cresterii gradului de interactivitate al paginilor
WWW. Programele destinate a fi executate la client se pot
transmite de la server catre client fie in format sursa, fie in
format obiect.
Programare pe partea de server (engl.server-side
programming) = executarea de programe la server in
scopul de a genera date si/sau rapoarte care sunt trimise
clientului sau mai general, pentru extinderea
functionalitatii unui server de WWW. Datele si rapoartele
sunt trimise clientului de obicei in format HTML.
Tehnologii Dynamic HTML

Termenul Dynamic HTML DHTML nu se refera la o anumita
versiune sau facilitate a HTML - desemneaza acele facilitati din
diversele variante sau extensii ale HTML care ajuta la crearea de
continut dinamic.
Cele mai populare elemente ale DHTML:
Foile de stil (engl.Cascading Style Sheets - CSS).
Scripting-ul la client (elementul SCRIPT). Un exemplu este JavaScript.
Se refera la incorporarea in cadrul unei pagini a unor programe in
format sursa. Ele vor fi executate la client.
Obiectele (elementul OBJECT). Se refera la incorporarea in cadrul unei
pagini a unor programe in format obiect. Ele vor fi executate la client.
Modelul obiectelor document (engl.Document Object Model DOM).
Acesta este liantul dintre elementele anterioare si limbajul de marcare
HTML sau XML.
Eventuale mecanisme particulare specifice programului navigator.
Separarea prezentarii de continut
Se recomanda separarea prezentarii (margini, culori, fonturi) de continutul si

structura documentului (antet, pagini, paragrafe, titluri, sectiuni). Pentru aceasta se
pot folosi foi de stil (engl.Cascading Style Sheets CSS).
Prezentarea unui document este in general determinata de mai multi factori:
Intentiile proiectantului paginii
Reguli genrale pe care trebuie sa le urmeze proiectantul
Preferintele utilizatorului
Limitarile cauzate de terminalul pe care se vizualizeaza prezentarea
Din acest motiv apare necesitatea utilizarii mai multor foi de stil cacscadarea
foilor de stil.
Foaie de stil
CSS
Prezentare
Document
HTML
Applet-uri
Miniaplicatii Java
O miniaplicatie (engl.applet) Java = un program Java care ruleaza sub controlul unui program
client de navigare WWW. Miniaplicatia este transferata de la server catre client sub forma de
cod obiect (class sau jar).
Conditia ca o miniaplicatie sa poata fi executata pe calculatorul clientului este ca programul de
navigare sa dispuna de un subprogram de interpretare a codului binar al masinii virtuale Java.
Un astfel de program navigator se numeste Java-enabled.
Restrictii: i) o miniaplicatie nu se poate atinge (in citire sau scriere) de discul calculatorului
client pe care ruleaza; din acest motiv se spune metaforic ca ruleaza inside the sandbox; ii)
lansarea in executie a unei miniaplicatii poate dura deoarece descarcarea fisierelor class si apoi
incarcarea lor sub controlul programului client de navigare poate consuma un timp semnificativ
de mare.
O miniaplicatie se include intr-o pagina WWW cu elementele APPLET sau OBJECT.
Initial s-a folosit elementul APPLET, deoarece singurele programe executabile care se
puteau include in paginile WWW sub forma de cod obiect erau miniaplicatiile Java.
Exemplu: <APPLET CODE="Miniaplicatie" CODEBASE="." WIDTH="300"
HEIGHT="200"></APPLET>
Ulterior s-a introdus elementul OBJECT pentru a se permite includerea si a altor aplicatii
sub forma de cod obiect in paginile WWW. Exemplu:
<OBJECT WIDTH="500" HEIGHT="300">
<PARAM NAME="code" VALUE="Miniaplicatie"/>
<PARAM NAME="codebase" VALUE ="."/>
</OBJECT>
Construirea unei miniaplicatii Java
O miniaplicatie Java este o aplicatie grafica ce foloseste bibliotecile Java pentru

construirea de interfete grafice AWT sau Swing.
O miniaplicatie nu are constructor deoarece este creata de programul de navigare
sub controlul caruia ruleaza. Ea se construieste prin extinderea clasei Applet din
AWT sau JApplet din Swing si redefinirea urmatoarelor metode (cel putin
init() trebuie redefinita):
init(), se executa o singura data la incarcarea miniplicatiei.
start(), se executa dupa init() si ori de cate ori este reafisata pagina care
contine miniaplicatia
stop(), se executa cand pagina ce contine miniaplicatia nu mai este afisata si
imediat inainte de destroy()
destroy(), se executa cand miniaplicatia se inchide si trebuie descarcata din
memorie
Operatiile din cadrul redefinirii metodei init() sunt asemenatoare cu cele din
cadrul unui constructor al unei aplicatii grafice obisnuite. Spre exemplu, aici se
initializeaza controalele grafice membre ale interfetei miniaplicatiei si se adauga la
miniaplicatie. Din acest motiv oice miniaplicatie poate fi rulata si ca o aplicatie
obisnuita daca se defineste o metoda main() in care se creaza un obiect
miniaplicatie si apoi se executa operatiile din init().
Interfete grafice in Java
Se spune ca AWT (java.awt) este de categorie grea (engl.heavyweight) si Swing

(javax.swing) este de categorie usoara (engl.lightweight). AWT se bazeaza pe
obiectele grafice ale platformei gazda. Swing redeseneaza toate controalele grafice.
AWT este mai rapida, dar e dependenta de platforma (la aspect); Swing este mai
lenta, dar independenta de platforma.
O interfata grafica este formata din componente. Componentele pot fi amplasate in
containere, care sunt la randul lor componente. Astfel se pot construi interfete grafice
complexe.
Modelul de programare folosit la programarea interfetelor grafice se numeste
programare orientata pe evenimente (engl.event-driven programming). Componentele
genereaza evenimente la actiunile utilizatorului. La componente se inregistreaza niste
obiecte speciale numite obiecte ascultator (engl.listener) interesate sa primeasca aceste
evenimente.
Obiectele ascultator primesc evenimentele sub forma unor apeluri de metode. Din
acest motiv ele trebuie sa implementeze anumite interfete astfel incat sa permita
aceste apeluri. Aceste interfete sunt subclase ale clasei de baza EventListener.
In momentul in care un obiect ascultator receptioneaza un eveniment, in apelul
corespunzator evenimentului se transmit si informatii referitoare la obiectul grafic
care a transmis evenimentul.
Crearea unui applet simplu
Ciclul de viata al unui applet
Interfata grafica cu utilizatorul
Definirea parametrilor
Tag-ul APPLET
Aflarea adreselor URL

Afisarea unor mesaje
Afisarea imaginilor
Aflarea contextului de executie (pagina n care ruleaza
appletul
Afisarea unor documenten browser
Comunicarea cu alte applet-uri
Arhivarea appleturilor (cea mai eficienta modalitate de
a distribui un applet jar)
Semnarea appleturilor arhivare, certificat, semnatura
Un exemplu de miniaplicatie Java

import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
BL al = new BL();
public void init() {

b1.addActionListener(al);
b2.addActionListener(al);
public class Miniap extends JApplet {
Container continut = getContentPane();
JLabel l1 =
new JLabel("Eticheta 1");
continut.setLayout(new FlowLayout());
JButton b1 = new JButton("Buton 1");
continut.add(l1); continut.add(b1);
JButton b2 = new JButton("Buton 2");
continut.add(b2); continut.add(txt1);
JTextField txt1 =
}
new JTextField(10);
class BL implements
public static void main(String args[]) {
ActionListener {
JApplet miniap = new Miniap();
public void actionPerformed (
JFrame frame = new JFrame(Miniap");
ActionEvent e) {
frame.setDefaultCloseOperation(
String name =
JFrame.EXIT_ON_CLOSE);
((JButton)e.getSource()).
frame.getContentPane().add(miniap);
getText();
frame.setSize(300,200);
txt1.setText(name);
miniap.init(); miniap.start();
}
frame.setVisible(true);
}
}
}
Tehnologii pe partea de client
Partea a II-a
Programare la client folosind scripting
Prin limbaj de scripting se intelege un limbaj de programare interpretat. Solutia de

interpretare permite transmiterea programelor in cod sursa, cu conditia existentei la
destinatie a unui interpretor pentru executia lor. Exemple de limbaje de scripting:
dBase, Visual Basic, Perl, Unix shell, Python, Tcl, Ruby, etc. Un program scris intr-un
limbaj de scripting se numeste script.
In WWW, scripting-ul se foloseste atat la client cat si la server. Executia unui script la
server poate produce continut ce este transmis prin HTTP clientului (de exemplu prin
CGI). Executia unui script la client produce continut dinamic. Scripting-ul la client
este parte a tehnologiei Dynamic HTML DHTML.
Deosebirea esentiala dintre un limbaj de programare compilat si un limbaj de
scripting (interpretat) este momentul legarii (engl.binding) - momentul in care devin
cunoscute atributele unei variabile. La limbajele compilate momentul legarii este cel
al traducerii, iar la cele interpretate este cel al executiei. Amanarea legarii atributelor
conduce la flexibilitate a executiei in dauna eficientei.
Cel mai raspandit limbaj de scripting pe partea de client este JavaScript, inventat de
Netscape si standardizat de Asociatia europena a producatorilor de calculatoare
(engl.European Computer Manufacturers Association ECMA) ECMAScript.
Microsoft a incercat sa popularizeze Visual Basic Scripting Edition VBScript.
Datorita standardizarii JavaScript, Microsoft a decis apoi sa suporte acest standard
prin versiunea proprie JScript, si astfel ca interesul pentru VBScript a scazut.
Ce este JavaScript ?
JavaScript este un limbaj de scripting orientat pe obiect inventat de Netscape. Spre

deosebire de limbajele orientate pe obiect bazate pe clase, cum sunt C++ si Java,
JavaScript este un limbaj orientat pe obiect bazat pe prototipuri.
JavaScript este un limbaj extensibil. Exista o componenta de baza, numita Core
JavaScript, care contine elementele de baza ale limbajului (cuvinte cheie, operatori,
enunturi, structuri de control, modelul obiectual) si o multime de obiecte de baza
(ex.Array, Date, Math). La ea se pot adauga extensii sub forma unor obiecte
suplimentare. Exemple sunt Client-side JavaScript care contine in plus obiecte pentru
controlul programului navigator si DOM si Server-side JavaScript care contine obiecte
suport pentru partea de server (de ex. pentru comunicarea cu o baza de date
relationala). In continuare prin JavaScript vom subintelege partea client a JavaScript.
Navigatoarele WWW interpreteaza scripturile JavaScript din paginile HTML. Ele
citesc pagina, interpreteaza marcajele si o afiseaza, executand in acelasi timp
scripturile JavaScript pe masura intalnirii lor in cadrul paginii. Rezultatul acestui
proces de interpretare/executie este vizualizat de utilizator in fereastra navigatorului.
Intre JavaScript si Java exista asemanari de suprafata si deosebiri fundamentale.
Asemanarile se refera la sintaxa enunturilor si a structurilor de control.
Deosebirile: Java are legare la compilare (engl.statically typed), este puternic tipizat
(engl.strongly-typed) si foloseste un model obiectual bazat pe clase. JavaScript are legare la
executie (engl.dynamically typed), este mult mai permisiv in ceea ce priveste declaratiile
(engl.loosely-typed) si foloseste un model obiectual bazat pe prototipuri.
Caracteristici ale limbajului JavaScript

In JavaScript se scriu secvente de program numite
scripturi.Majoritatea acestor secvente sunt alcatuite din functii,
care raspund anumitor evenimente.
In JavaScript NU se citesc si NU se scriu fisiere;
JavaScript este un limbaj interpretat. Asta inseamna ca
browserul preia o instructiune , o executa , apoi preia o alta
instructiune o executa, s.a.m.d.
JavaScript este un limbaj care utilizeaza obiecte;
In JavaScript se face distinctie intre literele mari si literele mici
Erorile de sintaxa se depisteaza greu, drept urmare se poate
folosi functia alert ( ).
Foloseste parti din sintaxa lui C++ si a limbajului Java
JavaScript lucreaza cu functii definite de programatori sau cu/si
functii predefinite
JavaScript in pagini HTML

Exista trei modalitati de a introduce intr-un document
HTML si anume:
Scriptul se scrie in antet; .<script
language=JavaScript > si</script>;
Scriptul se scrie in body; .<script
language=JavaScript > si</script>;
Scriptul apare ca si fisier extern cu extensia js, deci
nume.js;
<script src = nume.js > si </script>
JavaScript in pagini HTML (I)
Folosirea elementului SCRIPT:
<SCRIPT> Enunturi JavaScript... </SCRIPT>
Specificarea limbajului si versiunii de scripting cu atributul LANGUAGE:
<SCRIPT LANGUAGE="JavaScript1.3">
Specificarea codului JavaScript direct in elementul SCRIPT:
<HTML>
<HEAD>
<SCRIPT LANGUAGE ="JavaScript1.3">

</SCRIPT>
Fisierul js1.js:
</HEAD>
document.write("Salut!");
</HTML>
Specificarea codului JavaScript intr-un fisier/URL separat:
<HTML>
<HEAD>
<SCRIPT SRC="js1.js"></SCRIPT>
</HEAD>
</HTML>
JavaScript in pagini HTML (II)
Utilizarea entitatilor JavaScript permite specificarea de expresii JavaScript ca valori

ale atributelor elementelor HTML. O entitate JavaScript are sintaxa &{expresie
JavaScript}; Un exemplu de folosire:
<SCRIPT LANGUAGE="JavaScript">
var lungime = 25;
</SCRIPT>
<HR WIDTH="&{lungime*2};%" ALIGN="left"/>
Sirurile de caractere in cadrul unui literal JavaScript se pun intre apostroafe:

document.writeln("<HR ALIGN='left' WIDTH=" + lungime*2 + "%>")
Aplicatiile JavaScript sunt orientate pe evenimente (engl.event-driven). Un

eveniment este de obicei rezultatul unei actiuni a utilizatorului. Un script poate
reactiona la evenimente prin intermediul unui secvente de cod de tratare a
evenimentului (engl.event handler). Un event handler este o secventa de cod
JavaScript, de obicei un apel de functie JavaScript.
Daca un eveniment se aplica unui element HTML, atunci se poate specifica un
event handler in cadrul elementului. Evenimentul se aplica obiectului JavaScript
creat de element.
<element onEveniment="cod JavaScript">
JavaScript in pagini HTML (III)

<HEAD>
<SCRIPT>
function calcul(f) {
f.rez.value = eval(f.expr.value)
}
</SCRIPT>
</HEAD>
<BODY>
<FORM>
Introduceti o expresie:
<INPUT TYPE="text" NAME="expr" SIZE=15/>
<INPUT TYPE="button" VALUE="Calculeaza"
onClick="calcul(this.form)"/><BR/>
Rezultat:
<INPUT TYPE="text" NAME="rez" SIZE=15/>
</FORM>
</BODY>
Obiectul this desemneaza obiectul buton, iar this.form formularul care contine
butonul.
Functia calcul() primeste ca argument un formular, preia expresia de calculat din
campul expr, o evalueaza cu eval() si depune rezultatul in campul rez.
Evenimentul tratat este Click pe buton.
Core JavaScript
Variabilele se declara la initializare sau optional cu var. Pot fi globale sau locale
(definite in corpul unei functii). Cele locale se declara obligatoriu cu var.
Exista tipuri primitive si tipuri compuse. Tipurile primitive sunt: numerele (intregi
si reali), valorile logice, sirurile de caractere, valoarea null si valoarea
undefined. Tipurile compuse sunt vectorii si obiectele.
Pentru specificarea constantelor (numite si valori) se folosesc literali. Exista literali
pentru specificarea numerelor (2, 3.14), valorilor logice (true si false),
vectorilor ([1,2,3,aaa]) si obiectelor ({camp_1:a,camp_2:3}).
Structurile de control sunt cele din Java: secventierea, if-else, switch, for,
while, do-while, label, break si continue. Exista in plus structurile pentru
manipularea obiectelor: for-in si with. Comentariile sunt ca in Java.
Caramizile de baza ale JavaScript sunt functiile. Ele se declara astfel:
function nume(argumente) { corpul functiei }
Functiile pot intoarce optional o valoare cu return si pot fi recursive.
Argumentele functiilor sunt disponibile din vectorul arguments.
Exista o multime de functii predefinite
Functiile si variabilele globale pot fi referite si din alte ferestre daca se prefixeaza
cu numele ferestrei in care au fost definite.
Tipuri de date si variabile

In JavaScript exista urmatoarele tipuri de date : tip sir; tip numar intreg; numar intreg in
baza 10, 8 sau 16.
O variabila se poate declara cu particular var.
O variabila poate primi orice valoare, nu se declara tipul ei.
Operatori aritmetici : +, -, * /, %
++ ,-- , + (operator unar), - (operator unar)

Operatori relationali : <, <=, >, >=
Operatori de egalitate = = pentru test egalitate
!= pentru test inegalitate

Operatori logici
! (negarea logica)
|| operatorul logic sau (este operator binar): daca cel putin

unul din operanzi este true, rezulta true, altfel rezultatul este false
&& operatorul logic si

Operatori logici pe biti << ,>> operatori de deplasare
& - si pe biti
| - sau pe biti
- sau exclusiv pe biti
~ - negarea pe biti- are rolul de a inversa continutul

bitilor
Instructiunile urmatoare au aceeasi sintaxa si

semantica ca si in limbajul Java:
IF
Compusa ( {.} )
Switch;
While;
Do While
For
Functii predefinite
alert ( mesaj) afiseaza o caseta in care se afiseaza mesaj

confirm( mesaj caseta afiseaza date de tip sir. Utilizatorul poate apasa
butonul OK , caz in care se returneaza true , sau Cancel, caz in care se
returneaza false
prompt ( sir_afisat, sir_asteptat) caseta afiseaza sir_afisat si asteapta
introducerea valorii in sir_asteptat. Sir_asteptat poate fi initializat cu zero.
escapes(s)
eval(s) - s e un String, care conine operaii matematice (d. ex.:.2+4).
Funcia returneaz rezultatul acestei operaii, n acest caz 6. Dac nu este
vorba despre o expresie calculabil, atunci se returneaz un mesaj de eroare.
isFinite(n) - decide dac nr. n este finit
isNaN(x) - Verific dac valoarea x este un nr. valabil (not-a-number).
Funcia returneaz valoarea true, daca x e un nr.
Number(x) - Convertete coninutul obiectului x n nr. i l returneaz
parseInt (sir) converteste un sir catre un intreg. Conversia se face pina
cand este intilnit un character care nu este cifra;
parseFloat(sir) - converteste un sir catre o valoare reala. Conversia se face
pana cand este intilnit un character care nu este cifra. Punctul este virgula
zecimala.
Ex. Citire nume + afisare mesaj
Tipul Object
Un obiect JavaScript este privit ca o colecie neordonat
de proprieti, fiecare proprietate avnd zero sau mai
multe atribute. Proprietile pot conine fie alte obiecte,
fie valori primitive sau metode. O valoare primitiv are
unul dintre tipurile fundamentale: Undefined, Null,
Boolean, Number i String.
un obiect are tipul de baz Object.
o metod este o funcie asociat unui obiect prin
intermediul unei proprieti.
un obiect este compus din proprieti
fiecare proprietate are un nume, o valoare i o mulime
de atribute
Ex. utilizare obiecte
Obiecte ce pot fi folosite
Modelul obiectual din JavaScript
Construirea unui obiect:

Initializarea cu un literal:
nume = {prop1:val1, prop2:value2, ..., propn:valn};
Definirea unei functii constructor:
function TipObiect(argumente) {
this.prop1 = val1;
}
obiect = new TipObiect(argumente);
Proprietatile unui obiect se pot accesa cu obiect.prop sau cu obiect["prop"].
Obiecte JavaScript predefinite: Array, Boolean, Date, Function, Math,
Number, RegExp, String.
Ierarhii de obiecte in JavaScript: daca se doreste crearea unui obiect care mosteneste
de la un alt obiect se seteaza valoarea prototype a sa la obiectul de la care se
mosteneste. Notiunea de clasa de baza din limbajele bazate pe clase a fost inlocuita cu
notiunea de obiect prototip.
Exemple de programe JavaScript

var lungime = 25;
culori = ["rosu",,"galben"];
matr = [[4,2],[5,1]];
for (i=0;i<=1;i++) {
for (j=0;j<=1;j++)
document.write(matr [i][j]+" ");
document.write("<BR/>");
}
dreptunghi = {n:"d100",L:20,l:10};
function pers(n, p, v) {
this.n = n; this.p = p;
this.v = v;
}
function l_prop(ob,nume_ob) {
var rez = "";
for (var i in ob)
rez += nume_ob + "." + i + " = " +
ob[i] + "<BR/>";
return rez + "<BR/>";
}
c = new pers("Badica",Amelia",43);
document.writeln(l_prop(c,"c"));
function Angajat() {
this.nume = "";
this.dept = "general";
}
function Manager() {
this.raporteaza = [];
}
Manager.prototype = new Angajat;
function Muncitor() {
this.proiecte = [];
}
Muncitor.prototype = new Angajat;
function Vanzator() {
this.dept = "vanzari";
this.quota = 100;
}
Vanzator.prototype = new Muncitor;
ion = new Angajat;
adi = new Manager;
gelu = new Muncitor;
gabi = new Vanzator;
Validarea datelor introduse in formulare

<HTML>
<HEAD>
<SCRIPT LANGUAGE="JavaScript">
<!-function validare(formular) {
if (formular.nume.value == "") {
alert("Va rugam sa introduceti numele !"); return false;
}
return true;
}
//-->
</SCRIPT>
</HEAD>
<BODY>
<FORM METHOD="GET" ONSUBMIT="return validare(this)">
<P>Nume: <INPUT TYPE="text" NAME="nume" SIZE="32"/></P>
<INPUT TYPE="submit" NAME="trimite" VALUE="Trimite"/>
</FORM>
</BODY>
</HTML>
Instrumente pentru conceperea documentelor HTML

Editoare de texte cu suport pentru limbaje de programare
ce permit accesul la lista de elemente si atribute HTML:
UltraEdit si TextPad (disponibile shareware)
Editoare de cod HTML folosesc paradigma WYSIWYG

(engl.What You See Is What You Get) si sunt utile celor care
cunosc elementele si atributele HTML uzuale.
AceHTML Pro, HotDog, 1st Page
Netscape/Mozzila Composer si Microsoft Frontpage
Instrumente de editare (engl.authoring tools) ce ofera un

mediu de lucru vizual pentru crearea de pagini si site-uri
Web. Ele permit gestionarea relatiilor dintre documente si
vizualizarea structurii site-ului.
Macromedia Dreamweaver si Adobe GoLive.
Concluzii
Pe cat posibil incercati sa separati partea de continut de partea de
prezentare din paginile Web. Pentru aceasta identificati intai
unitatile de continut pe care trebuie sa le contina pagina si abia apoi
puneti-va problema modului de prezentare al acestora.
Aveti in vedere ca descarcarea unor programe in cod obiect si
rularea lor in programul navigator poate duce la incetinirea
incarcarii paginii.
Folositi scriptingul la client numai atunci cand este absolut necesar.
Scriptingul face sa creasca dependenta paginilor pe care le scrieti de
programul navigator.
Atunci cand doriti sa creati pagini complexe si folosirea scriptingului
la client este absolut necesara, incercati sa identificati cu clientul
dumneavoastra navigatoarele carora le sunt adresate paginile. Un
pas important va fi apoi testarea navigatorului inainte de afisarea
paginilor sau a anumitor parti specifice din pagini.
Programarea serverelor WWW
Servere WWW
Server WWW = un program cu rol de server care este capabil sa
raspunda la cereri HTTP.
Modul de functionare al unui server WWW este foarte important
pentru infrastructura si aplicatiile WWW, desi in acelasi timp este
ascuns utilizatorilor uzuali ai WWW.
Probleme importante referitoare la serverele WWW sunt:
Performanta
Configurarea si administrarea
Extensia si programarea
Un exemplu de server WWW foarte folosit si disponibil liber in

domeniul public este Apache. Un sondaj din 1998 a aratat ca
51.9% din toate serverele active de WWW erau servere Apache.
Performanta serverelor WWW

Cele mai fol. ->doua suite standard (engl.benchmark) pentru
testarea performantelor serverelor WWW:
WebStone, dezvoltata de Silicon Graphics, Inc. SGI
SPECweb96, dezvoltata de Standard Performance Evaluation Corporation
SPEC
WebStone este o suita configurabila de teste de performanta,

destinata a fi utilizata de administratorii WWW.
Configurabilitatea este utila pentru a proiecta teste specifice
pentru diverse sabloane de acces la servere.
SPECweb96 este o suita fixa de teste de performanta. Sabloanele
de test au fost obtinute analizand cele mai frecvente moduri de
utilizare ale serverelor WWW.
Configuratii de servere WWW

Optiunile de configurare ale unui server WWW se refera in
general la:
Modul in care se va executa serverul pe masina care il gazduieste.
Daca serverul deserveste mai multe masini gazda si in caz
afirmativ modul in care realizeaza acest lucru. Daca serverul
deserveste mai multe masini gazda atunci acestea se numesc gazde
virtuale (engl.virtual host).
Modul de lucru: server de origine sau proxy.
Executia serverelor WWW

Executie la cerere
Este o metoda invechita. Presupune existenta unui superserver care
asculta toate cererile si pentru fiecare in parte activeaza si executa
serverul corespunzator. In UNIX acest superserver se numeste
inetd. Aceasta metoda are marele dezavantaj ca necesita prea
multe resurse sistem de fiecare data cand se incarca serverul in
memorie si se creaza procesul aferent.
Executie permanenta
Serverul este pornit manual de utilizator sau automat la pornirea
sistemului si se executa in permanenta. Dupa pornire serverul
asculta cererile HTTP pe portul pe care a fost configurat. Pornirea
manuala este recomandata intr-un mediu de dezvoltare a unei
aplicatii WWW. Pornirea automata este recomandata dupa ce
aplicatia WWW a fost instalata (engl.deployed).
Serverul poate fi pornit de la linia de comanda sau instalat ca
serviciu al sistemului de operare.
Deservirea gazdelor virtuale (I)

Un server WWW poate deservi una sau mai multe masini gazda. In al
doilea caz masinile gazda deservite se numesc gazde virtuale.
Gazdele virtuale usureaza activitatea de administrare a serverului
deoarece: exista o singura instanta a serverului, exista o singura
configuratie a serverului, se monitorizeaza executia unui singur server.
Exista doua tipuri de gazde virtuale: gazde virtuale IP si gazde virtuale
non-IP.
Gazde virtuale IP:
Fiecare gazda virtuala este o gazda IP avand o adresa de IP distincta care apare
ca intrare in DNS.
Se asigneaza toate adresele de IP ale gazdelor virtuale deservite masinii pe care
ruleaza serverul WWW.
Metoda este simpla dar are doua dezavantaje: i) este nevoie de o adresa de IP
distincta pentru fiecare gazda virtuala; ii) asignarea mai multor adrese de IP unei
singure masini poate crea probleme retelei.
Deservirea gazdelor virtuale (II)

Gazde virtuale non-IP:
Se bazeaza pe un suport special oferit de protocolul HTTP. Acest
suport pentru deservirea gazdelor virtuale non-IP este disponibil
numai in HTTP/1.1.
HTTP/1.1 a introdus in cadrul unei cereri HTTP antetul special
HOST. Acest camp antet este obligatoriu. El contine numele gazdei
careia ii este adresata cererea.
Configurarea gazdelor virtuale deservite se face analog cu cazul
anterior. Singura diferenta este ca intrarile DNS ale gazdelor
virtuale vor contine acum aceeasi adresa de IP.
Metoda are doua avantaje: i) este nevoie de o singura adresa de IP
pentru deservirea tuturor gazdelor virtuale; ii) crearea unei noi
gazde virtuale non-IP se poate face mai usor decat in cazul gazdelor
virtuale IP. Metoda are un mare dezavantaj: se poate aplica numai
pentru versiunile HTTP ulterioare HTTP/1.1.
Servere de origine
Majoritatea serverelor de WWW sunt configurate ca servere de
origine. In acest caz cerrile HTTP sunt tratate local de server.
1: Cerere catre server
Client
2: Raspuns catre client
Server de origine
O problema importanta este localizarea resurselor, cu alte cuvinte

maparea URL-ului intr-o adresa a unei resurse din cadrul sistemului
local de fisiere. Resursele sunt de doua tipuri: statice (stocate fizic) si
dinamice (generate de programe externe).
Spatiul WWW al unui utilizator specific se refera in URL prin
caracterul ~ urmat de numele utilizatorului. Spatiul WWW al
utilizatorilor se poate organiza in doua moduri:
Crearea unui spatiu WWW central pentru toti utilizatorii. Unui utilizator ii va
revni un director in acest spatiu: webhome/name/.
Crearea unui director special pentru fiecare utilizator in cadrul directorului
personal: /home/name/WWW/.
Servere proxy
Un server proxy accepta cereri pentru resurse si fie le rezolva din
memoria cache locala, fie prin inaintarea cererii catre serverul de
origine.
1: Cerere catre proxy
Client
4: Raspuns catre client
Proxy
2: Cerere catre
server
3: Raspuns catre
proxy
Server de origine
Un server proxy actioneaza astfel ca un intermediar intre client si

serverul de origine. Scopul intermedierii pote fi filtrarea cererilor sau
trecerea de la un protocol nesigur la un protocol sigur, de exemplu
HTTPS.
SSI
SSI (engl.Server Side Include) este o tehnologie ce permite includerea de
informatii intr-o pagina WWW inainte de trimiterea paginii la client.
O pagina care foloseste SSI contine instructiuni speciale. Aceste instructiuni
sunt interpretate de server ori de cate ori pagina este ceruta de un client.
Instructiunile pot specifica: includerea unor documente in pagina curenta (de
exemplu un header sau un footer), a datei curente, a valorii unui contor de
acces, etc.
Avantajul SSI fata de CGI este ca este o tehnologie mult mai simpla si ca nu
implica apelul nici unui program extern.
Nu exista un standard de SSI si de aceea fiecare server are o sintaxa si
functionalitate proprie pentru SSI.. Pentru serverul Apache instructiunile SSI
sunt de forma unor comentarii HTML/XML cu structura urmatoare:

Un exemplu este urmatorul:

Apache permite folosirea si a unor facilitati SSI avansate desemnate prin
acronimul XSSI. Un exemplu este posibilitatea definirii unui flux de control ca
in programarea procedurala prin comenzile if, elif, else si endif.
Aplicatii WWW
Aplicatiile de comert electronic au o parte semnificativa pe partea de server.
Pentru a descrie aceasta parte se foloseste frecvent termenul de aplicatie WWW
= extensia dinamica a unui server WWW.
Aplicatiile WWW sunt in general de doua tipuri:
Aplcatii orientate pe prezentare. Contin pagini WWW interactive si sunt
capabile sa genereze continut dinamic ca raspuns la cererile clientilor.
Aplicatii orientate pe serviciu. Implementeaza un punct terminal pentru un
serviciu WWW. Serviciu WWW = un serviciu oferit de o aplicatie altor
aplicatii, prin intermediul platformei WWW.
Aplicatiile WWW contin componente WWW. Componentele WWW sunt
caramizile pe baza carora se poate extinde dinamic functionalitatea unui
server WWW. In tehnologia Java, componentele WWW sunt miniservere sau
pagini JSP.
Componentele WWW sunt suportate de serviciile unei platforme speciale de
executie numita container WWW. Containerul furnizeaza servicii ca:
dispecerizarea cererilor, securitate, concurenta, gestiunea ciclului de viata, etc.
O aplicatie WWW consta in general din: componente WWW, fisiere de
resurse statice si clase/biblioteci de ajutor (engl.helper).
Extensia functionalitatii serverelor WWW
Functionalitatea standard oferita de un server WWW este insuficienta pentru

programarea aplicatiilor de comert electronic.
O aplicatie de comert electronic are o arhitectura multistrat, numarul de straturi fiind
de obicei minim 3: client, server WWW, server de baze de date.
Pe langa serverul WWW mai exista obiectele din domeniul problemei (engl.business
objects). Impreuna ele formeaza stratul intermediar al unei arhitecturi tipice pentru o
aplicatie de comert electronic.
In consecinta se pune problema extinderii functionalitatii unui server de WWW. O
varianta este folosirea interfetei CGI, insa ea prezinta o serie de dezavantaje:
Pentru fiecare cerere HTTP trebuie startat un proces separat.
Interfata dintre serverul WWW si scriptul CGI este nesatisfacatoare.
O abordare eleganta o constituie o solutie Java pentru extinderea functionalitatii unui
server WWW, si anume miniserverele Java (engl.Java servlet). Aceasta solutie are
urmatoarele avantaje:
Portabilitate
Miniserverele sunt rezidente si starea este persistenta intre cereri succesive
Beneficierea de avantajele tehnologiei Java: orientare pe obiect, modelul de
securitate Java, integrarea relativ usoara cu tehnologii ca RMI si CORBA
CGI
CGI (engl.Common Gateway Interface) defineste o interfata pentru comunicarea dintre

un server de informatii (cum este cazul unui server WWW) si un program de aplicatie.
CGI este o interfata independenta de limbaj. Este posibil sa se implementeze o
aplicatie CGI (numita si script CGI) in orice limbaj care suporta comunicarea
standard intre procese prin intermediul intrarii si iesirii standard si a variabilelor de
mediu. Pentru scripturile CGI se foloseste deseori unul dintre limbajele: Perl, Python
sau Tcl. Se pot folosi insa si limbaje gen C/C++.
Procesul de comunicare decurge astfel:
Dupa primirea cererii HTTP si inaintea pornirii scriptului CGI, serverul
initializeaza o multime de variabile de mediu (engl.environment variables). Aceste
variabile vor fi mostenite de procesul corespunzator lansarii scriptului CGI. Existe
variabile independente de cerere si variabile dependente de cerere. Pe langa aceste
variabile de mediu, daca protocolul este HTTP, se creaza cate o variabila de mediu
ce incepe cu prefixul HTTP pentru fiecare linie din antetul cererii (de exemplu
HTTP_ACCEPT).
Daca cererea contine informatii aditionale dupa antetul cererii, atunci informatia
este trimisa scripului CGI la intrarea standard. Se trimite un numar de octeti egal
cu valoarea variabilei de mediu CONTENT_LENGTH.
Scriptul genereaza datele de iesire la iesirea standard. Pentru generearea
raspunsului catre client, serverul fie interpreteaza si prelucreaza aceste date, fie le
inainteaza nealterate. El indica acest acest lucru serverului prin antete speciale.
Arhitectura CGI
Server
Client
Server HTTP
Aplicatie
Date in cererea HTTP

Inainteaza datele aplicatiei
Rezultate pentru server

Returneaza rezultatele clientului
HTTP
CGI
Functionarea miniserverelor Java

Presupune urmatorii pasi:
Un program client emite o cerere HTTP catre un server WWW.
Serverul interpreteaza cererea si executa o secventa de program careia ii
transmite parametrii cererii.
Programul apelat interpreteaza parametrii cererii si executa o portiune de cod
care genereaza dinamic o pagina HTML.
Prelucrarile executate de miniserver pot duce la:

Generarea unei pagini WWW statice.
Generarea unei pagini WWW modificata prin inserarea unui continut dinamic.
Configurarea unei pagini WWW pe baza parametrilor cererii HTTP.
Parametrii sunt preluati de la utilizator printr-un formular HTML.
In general miniserverele sunt potrivite pentru aplicatiile orientate pe

serviciu sau pentru controlul aplicatiilor orientate pe prezentare.
Interfata implementata de un miniserver

La fel ca si o miniaplicatie, un miniserver nu contine o functie main(). El va
fi invocat de catre containerul de miniserveri la receptionarea unei cereri
HTTP de catre serverul WWW. Pentru aceasta un miniserver trebuie sa
implementeze o interfata javax.servlet.HttpServlet
Dezvoltarea unui minserver presupune extinderea clasei
javax.servlet.HttpServlet si redefinerea metodelor sale. Interfata
cuprinde metodele service(), init() si destroy().
La executarea unei cereri catre un miniserver au loc urmatoarele: i) daca
miniserverul nu exista atunci containerul de miniserveri incarca clasa
corespunzatoare miniserverului, creaza o instanta a acestei clase si apeleaza
metoda init(); ii) se apeleaza metoda service(). In functie de tipul
cererii, ea va apela o metoda doYYY() unde YYY identifica cererea HTTP, de
exemplu doGet() sau doPost().
Cand containerul trebuie sa descarce miniserverul din memorie el va apela
metoda destroy().
Metodele init() si destroy() se refera la ciclul de viata al miniserverului
(la fel ca la miniaplicatii). Aceste operatii se executa mult mai rar decat
service().
Prelucrarile din cadrul unui miniserver
In cadrul metodelor init() si destroy() se implementeaza acele prelucrari care

asigura persistenta informatiei stocate de miniserver.
In metodele service() sau doYYY() se implementeaza prelucrarile legate de
tratarea cererilor primite de la client. Acestea presupun de obicei urmatoarele:
Setarea tipului continutului in obiectul raspuns HTTP, de tip
javax.servlet.http.HttpServletResponse:
raspuns.setContentType("text/html");
Obtinerea unui flux de iesire la nivel de octet (OutputStream obtinut din
raspuns cu getOutputStream()) sau la nivel de caracter (PrintWriter
obtinut din raspuns cu getWriter()):
PrintWriter iesire = raspuns.getWriter();
Obtinerea valorilor parametrilor cererii setati de client in formularul HTML, din
obiectul cerere de tip javax.servlet.http.HttpServletResponse, cu
getParameter(). Daca numele parametrilor este necunoscut atunci se poate
obtine lista numelor parametrilor cu getParameterNames().
Construirea raspunsului prin scrierea in fluxul de iesire a unor enunturi HTML.
Pentru aflarea de informatii de configurare se foloseste metoda
getServletConfig() care intoarce un obiect SevletConfig. Din el se pot
extrage parametrii de initializare ai miniserverului cu getInitParameter() si
getInitParameterNames().
Obiecte partajate
Componentele WWW in general si miniserverele in particular folosesc
de obicei si alte obiecte pentru a-si indeplini sarcinile. Astfel: i) pot
folosi obiecte private; ii) pot folosi obiecte publice atribute ale unui
domeniu standard; iii) pot accesa baze de date; iv) pot accesa alte
resurse WWW.
Componentele WWW cooperante pot partaja informatii sub forma
unor obiecte definite ca atribute ale unui domeniu standard: context
WWW (aplicatie), sesiune, cerere HTTP si respectiv pagina JSP.
Pentru reprezentarea acestor patru domenii, in pachetul
javax.servlet sunt definite patru clase: ServletContext,
HttpSession, ServletRequest si JspContext.
Accesul la aceste obiecte se face prin metode de tip
[get|set]Attribute.
Fire multiple in miniservere

Containerul de miniservere utilizeaza fire de executie separate pentru
tratarea cererilor. Pentru aceasta containerul are o rezerva (engl.pool) de fire
de executie. Fiecarei cereri i se aloca un fir.
Deoarece este teoretic posibil sa se execute cereri simultane pentru un acelasi
miniserver, se pune problema gestionarii corecte a resurselor miniserverului
ce sunt partajate de aceste cereri multiple. Resursele partajate pot fi: atribute
ale domeniilor standard, variabile membre ale clasei miniserverului, fisiere,
baze de date, conexiuni de retea, etc.
Din acest motiv controlul accesului la resursele partajate se va realiza
folosind tehnici de sincronizare.
Variante:
Cea mai simpla solutie este ca metoda service() sa se implementeze cu
synchornized.
Daca insa sectiunea critica din cadrul acestei functii se executa conditionat, atunci
este mai eficient sa se foloseasca synchronized doar pentru portiunea de cod
corespunzatoare acelei sectiuni critice.
Se poate crea o clasa pentru accesul la resursa partajata, metodele de acces fiind
declarate synchronized.
Gestiunea sesiunii
O problema majora a HTTP este ca nu permite pastrarea starii comunicarii dintre

un client si un server WWW. Pentru a inlatura aceasta problema s-au propus diverse
metode:
Folosirea campurilor ascunse. Aceasta metoda presupune transmiterea repetata
de la server catre client si apoi de la client catre server a istoricului interactiunii
sub forma unei multimi de campuri ascunse intr-un formular HTML.Un exemplu
de camp ascuns este <INPUT TYPE="hidden" name="ascuns1"
value="element1">. De fiecare data cand utilizatorul selecteaza un nou
element serverul primeste o pereche nume-valoare de forma
element_selectat="", dupa care serverul creaza un nou camp ascuns
pentru acest element si il paseaza in formularul raspuns, etc
Rescrierea URL-ului. Aceasta metoda consta in adaugarea de informatii
suplimentare la un URL pentru a identifica in mod unic o sesiune.
Folosirea autentificarii HTTP. Aceasta metoda presupune identificarea si
autentificarea utilizatorului la primul sau acces asupra serverului. Ulterior
serverul va identifica utilizatorul din antetele HTTP.
Folosirea cookie-urilor.Un cookie este o informatie pe care un server WWW o
poate stoca pe calculatorul unui client. Ulterior, aceasta informatie va fi trimisa
serverului la fiecare cerere a clientului. Serverul poate folosi aceasta informatie
pentru gestiunea sesiunii.
Gestiunea sesiunii folosind miniservere
Un cookie se creaza si se adauga la raspunsul HTTP inaintea setarii tipului

continutului.
Cookie c = new Cookie("element_selectat", "carte1");
raspuns.addCookie(c);
Serverul va determina ce cookie-uri exista in cererea HTTP cu getCookies().
O sesiune consta in una sau mai multe cereri HTTP catre un server WWW dealungul unei perioade de timp.
Implementarea unei sesiuni foloseste clasa HttpSession. Un obiect sesiune este
pastrat pe server si el stocheaza informatiiile despre un client de-alungul unei
sesiuni a clientului respectiv.
Clasa HttpSession foloseste clasa Cookie pentru stocarea identificatoului
sesiunii la client sub forma unui cookie. Sesiunea este pastrata un interval maxim de
timp intre doua cereri succesive ale clientului.
Informatia se pastreaza in obiectul sesiune sub forma unor perechi variabilavaloare. Pentru accesul la aceste perechi se folosesc metodele setAttribute(),
removeAttribute(), getAttribute(), getAttributeNames();
Dezvoltarea unei aplicatii care foloseste miniservere
Se compileaza sursele java pentru a obtine fisierele class.

Se creeaza un subdirector in directorul webpps. Acest subdirector contine pagina
radacina a aplicatiei si se numeste context.
Se creeaza un subdirector WEB-INF care va contine:
un fisier de configurare a aplicatiei web,xml
un subdirector classes unde se depun fisierele class, pe subdirectoare
corespunzatoare structurii de pachete a programului java
Apelul miniserverului se poate face direct, dintr-un formular sau dintr-o legatura.
In toate cazurile se va specifica un URL de forma:
URLGazda/context/servlet/fisier_class
Un exemplu este:
http://localhost/Miniserver1/servlet/Miniserver1
Un miniserver poate fi repornit fie prin repornirea containerului de miniservere, fie
doar prin repornirea lui individuala.
Informatii suplimentare despre miniservere in The Java Web Services Tutorial:
Capitolul 3: Getting Started with Tomcat
Capitolul 4: Getting started with Web Applications
Capitolul 15: Java Servlet Technology
JSP
JSP (engl.Java Server Pages) este o tehnologie pentru generarea de pagini dinamice
bazata pe ideea mixarii de cod Java cu cod HTML in paginile WWW. Este
recomandata pentru aplicatiile WWW orientate pe prezentare.
O alta tehnologie de pagini dinamice foarte folosita la ora actuala este PHP. PHP este
un limbaj de scripting pentru partea de server, inspirat din C. Codul PHP poate fi
incorporat in paginile WWW.
JSP functioneaza peste o arhitectura de miniservere.
La incarcarea unui JSP, se genereaza automat codul java pentru miniserverul
corespunzator si apoi acesta este compilat si incarcat in containerul de miniservere.
Acest proces se repeta ori de cate ori codul JSP este modificat.
<HTML>
<HEAD> <TITLE> Un exemplu cu JSP </TITLE> </HEAD>
<BODY>
<ul>
<% for (int i=0;i<20;i++) { %>
<li><strong><%= i %></strong>O linie</li></br>
<% } %>.
</ul>
</BODY>
</HTML>
Elemente de baza ale JSP
In JSP se pot referi niste obiecte predefinite: HttpServletRequest request,

HttpServletResponse response, jsp.PageContext pageContext,
http.HttpSession session, ServletContext application,
jsp.JspWriter out, ServerConfig config, java.lang.Object page.
Exista trei tipuri de elemente de scripting in JSP:
Expresii de forma <%= expresie %>
Miniscripturi (engl.scriptlet) de forma <% cod Java %>
Declaratii de forma <%! Cod %>
Expresiile se utilizeaza pentru a insera valori direct in pagina generata. De exemplu:
Current time: <%= new java.util.Date() %>
Miniscripturile reprezinta un cod Java mai complex decat niste expresii simple.
<% String queryData = request.getQueryString();
out.println(Date GET: + queryData); %>
Declaratiile permit inserarea de metode sau campuri in codul java al corpului clasei
miniserver, in afara metodei _jspService().
<%! private int jj =10; %>
Informatii suplimentare despre JSP in The Java Web Services Tutorial:
Capitolul 16: JavaServer Pages Technology
Capitolul 17: JavaServer Pages Standard Tag Library
Capitolul 18: Custom Tags in JSP Pages
Servere de baze de date
Baze de date relationale

Bazele de date relationale bazate pe SQL sunt cele mai raspandite sisteme
comerciale de baze de date. Prin baza de date relationala vom intelege o multime
de relatii (tabele) accesate prin limbajul de specializat SQL.
Un tabel sau relatie poate fi gandit ca o reprezentare bidimensionala a unei colectii
de date, structurata sub forma unei multimi de linii si coloane. O linie corespunde
unei inregistrari si o coloana corespunde unui camp. Fiecare camp are un nume si
un tip. Daca un camp contine o valoare unica atunci el se numeste cheie primara
(engl.primary key). Se pot crea legaturi intre relatii prin stocarea cheilor primare
ale unei relatii intr-o alta relatie sub forma de chei externe (engl.foreign key).
Pentru exemplificare sa consideram o baza de date pentru o aplicatie de comert
elctronic pentru vanzare de carti librarie virtuala, cu trei relatii:
Carte. Contine informatii referitoare la carti. Pentru o carte avem: ISBN-ul (cheie
primara), titlul, numele si prenumele primului autor, editura, anul aparitiei, pretul.
Client. Contine informatii referitoare la clientii librariei virtuale. Pentru fiecare client
avem: un identificator unic (cheie primara), numele, prenumele, numarul de telefon.
Tranzactie. Contine informatii referitoare la tranzactiile de cumparare. Pentru o
tranzactie se pastreaza: un identificator unic (cheie primara), identificatorul clientului
care a generat tranzactia (cheie externa in tabelul Client), data cumpararii, ISBN-ul
cartii cumparate, cantitatea, pretul total.
O baza de date
SQL
SQL (engl.Structured Query Language) este un limbaj pentru
definirea, interogarea si actualizarea bazelor de date relationale.
Exista numeroase dialecte de SQL. Cateva dintre cele mai
importante sunt:
ANSI/ISO SQL. Este versiunea standard de SQL definita de organizatiile de
standardizare ANSI si ISO. Exista doua standarde: SQL-89 numit si SQL1 si
SQL-92 numit si SQL2. Standardul de referinta la ora actuala este SQL2
IBM DB2. Este un standard de facto asociat cu sistemul DB2 al lui IBM.
Variante specifice diverselor servere existente pe piata: Ingres, Microsoft SQL
Server, Oracle, etc.
Cateva comenzi SQL foarte folosite sunt select, insert, delete,

update, commit, rollback, grant si revoke.
SELECT
Interogarea unei baze de date relationale se face cu comanda select
cu sintaxa:
select campuri from relatii where conditii;
Un exemplu de selectie simpla este:

select isbn, titlu from Carte;
Un exemplu de selectie multipla (din mai multe relatii) este:

select
Client.nume,Client.prenume,Carte.titlu,Tranzactie.cantitate
from
Client,Carte,Tranzactie
where
Client.id_client=Tranzactie.no_client and
Carte.isbn = Tranzactie.isbn;
INSERT, UPDATE si DELETE
Pentru adaugarea de noi linii la o relatie se foloseste comanda insert cu sintaxa:

insert into relatie (campuri) values linii;
Un exemplu este:
insert into Carte
(isbn,titlu,prim_autor,editura,an_aparitie,pret)
values
("9739751547", "Limbajul Java. O perspectiva pragmatica",
"Irina Athanasiu", "Computer Libris Agora",2000,1);
Pentru actualizarea/modificarea datelor dintr-o relatie se foloseste comanda update
cu sintaxa:
update relatie set actualizari where conditie;
Un exemplu este:
update Tranzactie set cantitate = 2
where id_tranzactie = 0001;
Pentru eliminarea unor linii dintr-o relatie se foloseste comanda delete cu sintaxa:
delete from rlatie where conditie;
Un exemplu este urmatorul:
delete from Client where nume="Ionescu";
ROLLBACK si COMMIT
Comenzile commit si rollback sunt utile pentru lucrul cu
tranzactii. O tranzactie este o secventa de operatii de acces la o
baza de date, secventa ce are proprietatea de atomicitate. Acest
lucru inseamna ca fie secventa nu se executa, fie trebuie
executata in totalitate pentru pastrarea consistentei datelor.
O baza de date care lucreaza in regim tranzactional se poate afla
in doua stari:
starea de autovalidare (engl.autocommit), caz in care orice cerere de
actualizare declanseaza automat modificarea continutului bazeio de date.
starea de validare manuala (engl.manual commit), caz in care modificarea
continutului bazei de date are loc atunci cand se executa comanda
commit. Pana la executarea acestei comenzi, starea bazei de date
dinaintea tranzactiei poate fi refacuta cu comanda rollback.
GRANT si REVOKE
Comenzile grant si revoke permit administratorilor
de sistem sa creeze utilizatori si sa le dea respectiv ia
drepturi pe urmatoarele patru nivele:
Nivel global: drepturile globale se aplica la toate bazele de
date de pe un anumit server
Nivelul baza de date: drepturile alocate la acest nivel se
aplica tuturor relatiilor unei baze de date.
Nivelul relatie: drepturile alocate la acest nivel se aplica
tuturor coloanelor unei relatii.
Nivelul coloana: dreptuile la acest nivel se aplica individual,
coloanelor unei relatii.
Functiile unui server de baze de date

Interpretarea cererilor SQL primite de la clienti, executia lor si
returnarea rezultatelor.
Optimizarea interogarilor. O interogare SQL se poate executa in mai
multe moduri, diferentele intre timpii de raspuns corespunzatori
fiecarui mod putand fi mari. Un server va analiza cererea SQL, va
examina modul de stocare a relatiilor si va produce intr-un timp
rezonabil un plan de executie cat mai eficient.
Prevenirea erorilor datorate unui acces concurent la date.
Detctarea si inlaturarea situatiilor de interblocaj.
Administrarea accesului controlat la date din motive de securitate.
Administrarea operatiilor de arhivare/restaurare a bazei de date.
Restaurarea bazei de date in cazul unor caderi ale sistemului se
realizeaza prin gestiunea unui jurnal (engl.log) al tuturor
tranzactiilor executate.
JDBC
JDBC este o interfata de programare si o infrastructura pentru
accesul la o baza de date relationala.
JDBC isi propune sa standardizeze mecanismul de conectare, de
trimitere a cererilor, de lucru cu tranzactii, cat si de reprezentare a
rezultatelor unei cereri.
Programatorul este liber sa foloseasca ce dialect SQL doreste, in
functie de serverul de baze de date cu care lucreaza.
JDBC propune o solutie multinivel:
La nivelul cel mai de sus, o aplicatie Java executa cereri SQL prin intermediul
unei interfete de programare definita in pachetul java.sql. Acest pchet nu
contine altceva decat definitiile unor interfete Java. Implementarile acestor
interfete sunt furnizate separat pentru diversele sisteme de baze de date.
Aplicatia acceseaza baza de date prin intermediul unui program special numit
JDBC driver manger.
Acest program gestioneaza programele specifice de control (engl.driver) pentru
fiecare sistem de baze de date in parte. Un program de control implementeaza
interfata java.sql.Driver.
Infrastructura JDBC
Aplicatie
Interfata de
programare JDBC
Managerul de drivere
JDBC
Punte intre JDBC si

ODBC
Driver JDBC pentru
MySQL
Baza de date
MySQL
Driver ODBC pentru

Microsoft Access
Baza de date
Microsoft Access
Clase si interfete in programarea JDBC

Principalele interfete definite in pachetul java.sql sunt:
Driver. Acesta este interfata asociata cu programul de control. Ficare program
de control va furniza o clasa care implementeaza aceasta interfata. O astfel de
clasa pentru MySQL este com.mysql.jdbc.Driver, iar pentru o punte
JDBC-ODBC este sun.jdbc.odbc.JdbcOdbcDriver.
DriverManager. Aceasta clasa gestioneaza programele de control disponibile
pentru conectarea la diverse baze de date.
Statement. Este o clasa utila pentru crearea si executarea de cereri SQL.
PreparedStatement. Este o subclasa a clasei Statement utila pentru
crearea de enunturi SQL parametrizate si care sa poata fi executate eficient.
CallableStatement. Este o subclasa a clasei Statement utila pentru
executarea de proceduri stocate.
ResultSet. Se utilizeaza pentru reprezentarea multimii de rezultate obtinute in
urma executiei unei interogari SQL.
ResultSetMetaData si DatabaseMetaData. Sunt clase pentru
reprezentarea metadatelor referitoare la o multime de rezultate respectiv la o
baza de date. Exemple de metadate sunt: numele atributelor unei relatii, tipurile
atributelor unei relatii, diverse caracteristici ale sistemului de baze de date
(standardul SQL, daca suporta sau nu proceduri stocate, etc.)
Conectivitatea la baze de date in Java (I)

Pasii de prelucrare la folosirea JDBC sunt urmatorii:
i) Incarcarea programului de control specific serverului de baze de date. Clasa incarcata
contine membrii statici ce creaza o instanta a programului de control si il inregistreaza la
gestionarul programelor de control.
Class.forName(com.mysql.jdbc.Driver);
ii) Definirea URL-ului conexiunii.

String dbUrl = "jdbc:mysql://127.0.0.1/magazin";
String utilizator = "";
String parola = "";
iii) Stabilirea conexiunii.

Connection c =
DriverManager.getConnection(dbUrl, utilizator,parola);
iv) Crearea unui obiect pentru reprezentarea unei cereri SQL.

Statement s = c.createStatement();
v) Executarea cererii SQL.
ResultSet r =
s.executeQuery("select isbn,prim_autor,titlu from Carte;");
Conectivitatea la baze de date in Java (II)

vi) Prelucrarea rezultatelor.
while(r.next()) {
System.out.println(
r.getString(isbn") + ", "
+ r.getString("prim_autor")
+ ": " + r.getString(titlu") );
}
vii) Inchiderea conexiunii.

c.close();
Pentru tratarea erorilor in operatii SQL, JDBC furnizeaza clasa SQLException.

Se recomanda ca parametrii unei conexiuni sa fie indicati cu ajutorul unui fisier
de proprietati:
driver=sun.jdbc.odbc.JdbcOdbcDriver
url=jdbc:odbc:carte
utilizator=admin
parola=admin
Enunturi pregatite
Daca o anumita interogare SQL se executa de un numar repetat de
ori, atunci este mai eficient sa se foloseasca un enunt pregatit
(engl.prepared statement). In esenta un enunt pregatit este o
interogare compilata si optimizata pentru fi executata mai eficient.
Un enunt pregatit este in acelasi timp si un sablon de interogare. Un
astfel de sablon contine niste parametrii specificati prin semnul
intrebarii. Valoarea acestor parametrii se completeaza inaintea
executiei interogarii.
String sablon= "update Angajat set salariu=? where id=?";
PreparedStatement cerere =
conexiune.preparedStatement(sablon);
float[] salarii_noi = getSalariiNoi();
int[] id_angajati = getIdAngajati();
for (int i=0;i< id_angajati.length;i++) {
cerere.setFloat(1,salarii_noi[i]);
cerere.setInt(2,id_angajati[i]);
cerere.execute();
}
Metadate
Metadatele sunt date pentru descrierea altor date. JDBC contine un numar de clase
utile pentru extragerea de metadate referitoare la baze de date, multimi de
raspunsuri, tabele, programe de control, etc.
Metadatele sunt utile in urmatoarele situatii:
Pentru a testa daca sistemul de baza de date are anumite facilitati, a caror lipsa ar putea
produce erori. O astfel de facilitate este spre exemplu disponibilitatea procedurilor
stocate.
Daca nu se cunoaste structura bazei de date.
Tipuri de metadate:
Metadate referitoare la baza de date. Se obtin cu ajutorul clasei DatabaseMetaData.
Aceste metadate includ: numele programului de control, versiunea programului de
control, verificarea disponibilitatii standardului SQL2, verificarea disponibilitatii unor
facilitati specifice ale SQL, etc.
Metadate referitoare la multimea de rezultate. Se obtin cu ajutorul clasei ResultSet.
Aceste metadate includ: numarul de atribute din multimea de rezultate, numele
atributelor, numl relatiei din care s-au obtinut atributele, tipurile acestor atribute, etc.
Metadatele pot fi folosite pentru implementarea unor programe utilitare. Un

exemplu ar putea fi un program utilitar pentru executarea unei interogari generale
si salvarea rezultatelor impreuna cu diverse informatii referitoare la baza de date.
Maparea obiectual relational

Intr-o aplicatie de comert electronic se inglobeaza obligatoriu o baza
de date.
De asemenea, o astfel de aplicatie va contine si un nivel de obiecte din
omeniul problemei (engl.business objects). Se pune problema maparii
acestor obiecte in relatii ale modelului relational.
Pentru aceasta se creaza cate o clasa corespunzatoare ficarei relatii a
bazei de date, cate o variabila membru pentru ficare atribut al acestei
relatii si metode corespunzatoare de acces la aceste variabile membru.
Codul metodelor de acces va folosi cereri SQL pentru acces la
atributele corespunzatore din baza de date.
Rezerve de conexiuni
Deschiderea unei conexiuni la o baza de date este un proces consumator de timp. El poate
dura mult mai mult decat executarea unei cereri.
Din acest motiv se pune problema refolosirii conexiunilor in aplicatiile care se conecteaza de
un numar repetat de ori la o baza de date.
Se foloseste o clasa speciala numita rezerva de conexiuni (engl.connection pool). Aceasta clasa
ruleaza pe un fir separat si are urmatoarele responsabilitati:
Prealocarea conexiunilor pe constructorul clasei. Constructorul mai primeste un numar maxim de
conexiuni, un numar initial de conexiuni si un indicator daca rezerva sa astepte sau nu cand se cere
o conexiune si nu exista nici una libera.
Gestiunea conexiunilor disponibile. Daca se cere o conexiune si exista o conexiune libera, atunci ea
este alocata si trecuta in lista conexiunilor ocupate.
Alocarea de noi conexiuni. Daca se cere o conexiune, nu exista nici una libera si nu s-a atins numarul
maxim de conexiuni, atunci se creaza o noua conexiune pe un fir separat. Daca insa s-a atins limita
maxima, se asteapta sau nu in functie de indicatorul setat in constructor.
Asteptarea pentru eliberarea unei conexiuni.
Inchiderea conexiunilor.
Intr-o aplicatie cu miniservere, rezerva de conexiuni poate fi alocata unui singur miniserver
sau se poate partaja intre mai multe miniservere.
Notiuni generale de comert

electronic
Definirea comertului electronic
Comert = o multime de tranzactii intre doi sau mai multi participanti cu scopul ca
fiecare participant sa castige ceva din acest schimb. Schimbul presupune bani,
produse (tangibile sau intangibile, servicii) si/sau informatii
Tipuri de comert:
Comertul traditional
Comertul electronic, care include comertul bazat pe tehnologii Internet/Web
E-Commerce (Comert electronic) = procesul de vanzare si/sau cumparare de bunuri
si/sau servicii folosind tehnologia informatiei
Afaceri (engl.business) = modul in care o companie isi organizeaza activitatea astfel
incat sa se autosustina si sa genereze profit (valoare)
E-Business = procesul de realizare a afacerilor folosind tehnologia informatiei
Puncte de vedere:
Unii autori considera ca E-Business E-Commerce, sugerand ca E-Commerce
se refera exclusiv la activitatile de vanzare/cumparare, in timp ce E-Business
include si alte activitati: aprovizionare, marketing, etc
Drept suport tehnologic vom avea in vedere sistemele distribuite, tehnologiile
Internet si WWW si tehnologiile bazate pe limbajul Java
Factorii care au contribuit la aparitia si contribuie la

raspandirea comertului electronic
Aparitia si raspandirea retelelor de date Intranet/Internet, cresterea
gradului de interconectivitate intre retele
Competitia intensa face ca majoritatea companiilor sa caute noi
metode de imbunatatire a calitatii serviciilor
Globalizarea determina companiile sa se orienteze spre piata
internationala in scopul cresterii profitului. Comertul electronic
permite depasirea usoara a barierelor geografice in cadrul acestui
proces
Epoca informationala face ca la ora actuala informatia sa fie din ce in
ce mai valoroasa. Din acest motiv majoritatea companiilor cauta noi
mijloace de colectare si folosire a informatiei despre clienti in scopuri
de marketing
Tehnologia informatiei, incluzand sistemele distribuite si tehnologiile
WWW, face posibila punererea in practica a comertului electronic
Nevoia de automatizare a activitatilor de rutina in vederea reducerii
costurilor si cresterii calitatii serviciilor
Tipuri de comert electronic

Business-to-Customer (B2C) vanzator = companie, cumparator = client
Amazon: www.amazon.com
stabilita in 1994, initial ca vanzator de carti, s-a extins ulterior si in
alte domenii (electronice, jucarii, muzica, etc)
Foloseste tehnologia cosului de cumparaturi (engl.shopping cart)
Business-to-Business (B2B) vanzator, cumparator = companii
TradeAccess: http://www.tradeaccess.com
sprijina formarea de relatii in cadrul afacerilor si faciliteaza
negocierea pe baza unor premise de beneficii reciproce
Consumer-to-Consumer (C2C) vanzator, cumparator = client
eBay: www.ebay.com
stabilita in 1995, permite vanzarea/cumpararea de produse (carti,
muzica, electronice, bijuterii, etc) intre clienti prin sistem de licitatie
(engl.auction)
este o piata electronica in care vanzatorii isi afiseaza produsele,
cumparatorii liciteaza (engl.bid) si in final poate cumpara produsul
acel cumparator care a licitat cel mai mult
Avantaje si limitari ale comertului electronic (I)
Avantaje pentru firme

Extinderea la pietele intrenationale
Scaderea costului de creare, procesare, distribuire, pastrare si gasire a
informatiei bazata pe hartie
Creeaza posibilitatea modelarii produselor si serviciilor pe nevoile
cumparatorilor
Costuri de comunicatie mai mici
Avantaje pentru cumparatori
Da posibilitatea cumparatorilor sa faca tranzactii 24 h/zi, in tot timpul anului din
aproape orice locatie
Acorda cumparatorilor mai multe posibilitati de alegere
Cumparatorii pot alege usor un pret cat mai mic pentru un produs sau serviciu
Permite o livrare rapida a produselor si/sau serviciilor (in anumite cazuri)
Cumparatorii pot primi informatii relevante in secunde, nu in zile sau saptamani
Face posibila participarea in licitatii virtuale
Permite cumparatorilor sa interactioneze cu alti cumparatori in comunitati
electronice si sa compare experientele
Faciliteaza competitia, ceea ce rezulta in scaderea preturilor
Avantaje si limitari ale comertului electronic (II)

Avantaje pentru societate
Da posibilitatea mai multor persoane sa lucreze de acasa si sa
cumpere de acasa ceea ce rezulta in trafic mai mic pe strazi si
poluare scazuta a aerului
Permite ca anumite marfuri sa fie vindute la preturi mai scazute, cu
avanateke pentru cei cu venituri mai mici
Creste eficienta si/sau se imbunatateste calitatea
Limitari
Exista o lipsa de standarde universal acceptate pentru calitate,
securitate si incredere.
Uneltele de dezvoltare software sunt inca in plina evolutie
Existe unele dificultati in integrarea intre aplicatiile soft de comert
electronic si Internet cu unele aplicatii existente si baze de date
vechi (engl.legacy)
Accesul Internet este inca scump si/sau inoportun (cel putin in
Romania)
Tipuri de tranzactii comerciale

Scopul principal al comertului este tranzactia comerciala
sau tranzactia de cumparare.
In comertul traditional intalnim doua categorii de
tranzactii de cumparare:
Cumparaturi majore: sunt practicate de marile firme atunci
cand urmaresc achizitii majore. Se bazeaza pe o succesiune
de faze care se intalnesc in majoritatea situatiilor reale.
Cumparaturi spontane sau directe: sunt practicate de firme
sau persoane atunci cand urmaresc achizitii ce implica sume
relativ mici de bani astfel incat nu exista pericolul platii unui
pret prea mare sau al cmprrii unui produs necorespunzator
dpdv calitativ. Aceste cumparaturi sunt practicate intutiv sau
spontan cu un minim de decizii rationale.
Fazele unei tranzactii comerciale majore (I)

Faza precontractuala:
Cumparatorul cauta informatii despre vanzatori, despre
produsele pe care doreste sa le cumpere, despre facilitati,
termene si conditii de cumparare. Vanzatorul prospecteaza
potentialii cumparatori ai produselor sale folosind tehnici de
marketing: oferte, reclame, etc.
Faza contractuala:
Stabileste o relatie formala intre cumparator si vanzator,
incluzand termenii si conditiile ce vor fi aplicate in tranzactie
prin incheierea unui contract.
Faza realizarii comenzii:
Include plasarea si prelucrarea ordinelor de cumparare si a
raspunsurilor la acestea din partea vanzatorului. Unele
tranzactii pot implica amendamente la ordinele de
cumparare, renegocieri si anulari.
Fazele unei tranzactii comerciale majore (II)

Faza logistica:
In aceasta faza a tranzactiei se livreaza produsele sau se realizeaza
serviciile. In plus pot fi implicate unele servicii post-livrare, cum ar fi
inspectii sau returnari.
Faza de achitare:
Consta in plata produsului sau serviciului. Exista situatii in care avem
plati partiale, ce se succed la perioade precise de timp. In aceasta faza se
implica institutia financiara a cumparatorului. Ea confirma tranzactia
ce afecteaza contul cumparatorului si ii actualizeaza balanta.
Faza de post-procesare:
Reprezinta acele activitati aditionale executate dupa terminarea
tranzactiei propriuzise. Exemple sunt: colectarea si raportarea
informatiilor manageriale, memorarea si raportarea de statistici la o
autoritate statistica nationala, etc.In plus vanzarea unui podus sau
serviciu poate crea o relatie intre vanzator si cumparator de tipul:
service, intretinere, aducere la zi (engl.upgrade), etc.
Articole tranzactionate
Articol tranzactionat = o entitate vanduta sau cumparata.
Produse sau servicii. Produsul este o entitate ce poate fi identificata
fizic si poate fi livrata. Serviciul este o actiune ce poate fi intreprinsa.
Articole tranzactionate digital si fizic. Un aricol digital poate fi livrat
printr-o retea de telecomunicatii. Un articol fizic poate fi livrat numai
prin activitati logistice, cum ar fi trasnportul produsului sau diverse
facilitati in cazul unor servicii.
Categorii de produse tranzactionate:
Produse standard = au un identificator de produs si pot fi comandate din
cataloagele vanzatorilor
Marfuri = produse care exista intr-o forma identificabila, in cantitati
considerabile si in forme identice, disponibile la surse variate. Exemple:
produsele primare (cafea, ulei brut).
Produse specializate = sunt proiectate sa satisfaca cerinte particulare ale
anumitor clienti. Exemple: programele.
Produse configurabile = produse standard care trebuie modificate conform
cerintelor unui anumit cumparator particular prin optiuni, extensii,
parametrizari, specializari, etc.
Modele de afaceri folosind WWW
Nu exista un consens privind conceptul de model al afacerilor (engl.business model).

Cu toate acestea termenul este vehiculat foarte mult la ora actuala.
In principiu, prin business model se intelege metoda prin care o companie isi
organizeaza activitatea de afaceri in scopul obtinerii de profit. El include:
activitatile desfasurate, fluxul informational/material intre ele, actorii implicati si
rolurile acestora, beneficiile actorilor si sursele lor de venituri.
Nu exista o taxonomie unanim acceptata a modelelelor de afaceri pe WWW. O
clasificare in functie de modul de obtinere a profitului este:
Modelul agentului de bursa (engl.brokerage)
Modelul reclamei (engl.advertising)
Modelul mediatorului de informatie (engl.infomediary)
Modelul comerciantului sau negustorului (engl.merchant)
Modelul producatorului (engl.manufacturer)
Modelul afilierii sau parteneriatului (engl.affiliate)
Modelul comunitatii (engl.community)
Modelul inscrierii sau abonamentului (engl.subscription)
Modelul volumului de utilizare (engl.utility, pay as you go)
Observatie: aceste modele nu sunt disjuncte.
Modelul agentului de bursa (engl.brokerage)

Un agent de bursa (engl.broker) faciliteaza comunicarea dintre un grup de
cumparatori (engl.buyer) si un grup de vanzatori (engl.seller) prin intermediul
unei piete (engl.market)
De obicei se percepe o taxa pentru tranzactiile mijlocite.
Apare in diverse forme:
complex virtual de magazine (engl.virtual mall), gazduieste un numar mare
de comercianti
licitatie (engl.auction), de exemplu eBay
cumparare in grup (engl.buyer aggregator), cumparatorii sunt grupati
pentru ca tranzactiile sa aiba loc in grup
licitatie inversa (engl.reverse auction sau name-your-price), cumparatorul
fixeaza pretul si agentul incearca sa-l satisfaca cu un produs corespunzator
lista clasificata (engl.classified), de exemplu Loot, contine o lista de
produse/servicii disponibile pentru vanzare sau dorite pentru cumparare
distribuire (engl.distributor), conecteaza producatorii cu cumparatori engross sau cu amanuntul
Modelul reclamei (engl.advertising)

Este o extensie a modelului de transmisii media. Transmitatorul,
in acest caz un site WWW, furnizeaza informatii si si/sau
servicii, de obicei (dar nu neaparat) liber, amestecate cu
reclame. Prezenta acestor reclame este sursa majora (eventual
singura) de venituri a transmitatorului.
Variante:
Portal generalizat: se caracterizeaza printr-un volum foarte
mare de trafic. Exemple: Yahoo, HotMail, AOL, etc.
Natura generica a portalului generalizat pericliteaza
increderea utilizatorilor. Astfel s-a ajuns la conceptul de
portal personalizat. Exemple: My Yahoo, My Netscape, etc.
Portalul specializat, numit si vortal sau portal vertical se
bazeaza pe difuzarea unui continut specializat.
Modelul mediatorului de informatie (engl.infomediary)

Prespune colectarea de informatii despre consumatori si
obisnuintele lor la cumparare in scopul realizarii de campanii de
marketing si publicitate. Un mediator de informatie colecteaza
astfel de informatii si le vinde apoi altor companii interesate.
Un mediator de informatie poate functiona si in directie inversa:
furnizarea de informatii consumatorilor despre site-urile din cadrul
unui segment de piata de interes
Exemple:
Sisteme de recomandare, permit schimbul de informatii intre
clienti privind calitatea produselor si serviciilor
Sisteme care ofera liber diverse facilitati (de exemplu posta
electronica) in schimbul dreptului de a monitoriza activitatea
clientului in scopuri de marketing
Modelul comerciantului sau negustorului

(engl.merchant)
Presupune vanzarea de marfuri sau servicii folosind WWW
vanzatori en-gross (engl.wholesaler) sau cu amanuntul
(engl.retailer) traditionali, care folosesc WWW-ul pentru
tranzactii. Sunt numiti si click & mortar prin comparatie cu
comertul traditional, unde se numesc si brick & mortar
Vanzatorii grupati intr-un complex de magazine (engl.mall)
Vanzatori virtuali, cum este Amazon
Folosesc tehnologia cosului de cumparaturi (engl.shopping cart)
care presupune: cautarea produsului, adaugarea la cos, plata si
livrarea produselor
Sau tehnologia portofelului electronic (E-Wallet)
Modelul afilierii sau parteneriatului (engl.affiliate)

Spre deosebire de portalurile generalizate, care se bazeaza pe un
volum mare de trafic, se bazeaza pe oferirea de stimulente
financiare (engl.financial incentives) partenerilor sub forma unui
procent din vanzari pentru acele vanzari generate de site-urile
acestora.
Variante
Pay per click comisionul este in functie de numarul de clickuri din site-ul partener-ului
Pay per sell comisionul este in functie de numarul de vanzari
generate din site-ul partenerului
Afisarea unor indicii (engl.banner) afisarea de
reclame/referinte in site-ul partenerului
De regula partenerii sunt mediatori de informatie
Modelul comunitatii (engl.community)

Se bazeaza pe increderea utilizatorilor, spre deosebire de un
volum mare de trafic
Uneori utilizatorii pot contribui cu continut
Poate fi combinat cu modelul inscrierii pentru servicii speciale
Variante:
Modelul contribuitorului voluntar: se bazeaza pe crearea unei
comunitati de utilizatori care suporta site-ul prin donatii
voluntare.
Retele de cunostinte: sunt o sursa de informatie bazata pe
expertiza profesionala si experienta altor utilizatori. Sunt
asemanatoare cu un forum unde utilizatorii pot pune intrebari
si primi raspunsuri de la (presupusi) experti in domeniu
Modelul inscrierii sau abonamentului (engl.subscription)

Uitlizatorii platesc pentru accesul unui site. Continutul site-ului
trebuie sa aiba valoare pentru ei
Din pacate s-a constatat ca utilizatorii nu sunt in general dispusi sa
plateasca pentru accesul la informatie prin intermediul WWW-ului
Din acest motiv s-a procedat la combinarea informatiei disponibile
liber (engl.free content) cu cea disponibila contra unei taxe
(engl.premium content)
O alta varianta este cea a micro-inscrierilor (engl. microsubscription):
spre exemplu, in loc de a plati pentru accesul la o intreaga carte de
bucate, se plateste doar accesul la o reteta
Modelul volumului de utilizare

Se bazeaza pe masurarea utilizarii unui site. Metoda este cunoscuta
si sub numele de pay as you go si se foloseste in mod curent pentru
plata energiei electrice si a serviciilor telefonice. Se mai numeste si
pay per byte.
Lanturi de furnizori (I)

Lant de furnizori (engl.supply chain) LF = o multime de relatii
simbiotice intre doua sau mai multe companii astfel incat fiecare
companie furnizeaza marfuri si/sau servicii altor companii din cadrul
lantului, care la randul lor furnizeaza marfuri si/sau servcii altor
companii din cadrul lantului, etc.
Conform MIT, LF = o abordare integrata si orientata-proces a
procurarii, producerii si livrarii produselor si servicilor catre clienti.
Actorii unui LF sunt: furnizorii (engl.suppliers), producatorii
(engl.manufacturers), vanzatorii cu amanuntul (engl.retailers), clientii
(engl.customers).
Un LF gestioneaza fluxuri materiale, informationale si financiare.
Fluxuri materiale = miscarea bunurilor de la furnizor la client
Fluxuri informationale = transmiterea ordinelor si actualizarea
rapoartelor de livrare
Fluxuri financiare = termenele de creditare si planificarea platilor
Lanturi de furnizori (II)

Deziderate pentru un lant de furnizori:
evitarea suprastocurilor
prelucrarea rapida a ordinelor de aprovizionare
eliminarea birocratiei
Exemplu:
un fermier isi vinde recolta de orz unei companii care
produce bere
berea este vanduta unui restaurant
clientii viziteaza restaurantul si beau bere
o fabrica produce instalatiile de fabricat bere din orz si liniile
de imbuteliere si le vinde companiei care produce bere
o fabrica produce containerele (butoaie) in care este
imbuteliata berea si le vinde companiei care produce bere
Lanturi de furnizori (III)

Producator de
instalatii
Fermier
Instalatii de produs
bere si imbuteliat
Orz
Producator de
containere
Butoaie
Producator de bere
Bere in butoaie
Restaurant
Bere la halba
Consumator de bere
Probleme in dezvoltarea sistemelor de E-Commerce
Sunt sisteme distribuite

Necesita aplicarea de tehnologii si tehnici specifice sistemelor distribuite:
arhitecturi client/server, protocoale, etc.
Tehnologiile Internet si WWW nu au fost initial concepute pentru astfel de sisteme.
Ele se numesc si tehnologii mostenite (engl.legacy). Probleme: se epuizeaza adresele
de retea, serverele WWW nu pastreaza istoria conexiunilor, sunt necesare pagini
WWW generate dinamic, etc
Deseori trebuie integrate cu sistemele deja existente in cadrul companiei
(engl.legacy systems), care nu au fost destinate WWW-ului (engl.WWW-enabled)
Siguranta si confidentialitate (eng.security and privacy)
Cauze: publicarea informatiei pe WWW, Internet si WWW sunt sisteme deschise
Siguranta site-urilor; Siguranta tranzactiilor; Asigurarea confidentialitatii
Dezvoltarea sistemelor de E-Commerce
Programare si abstractizare (reteaua trebuie abstractizata; pentru aceasta se pot
folosi obiecte distribuite, exemple: RMI si CORBA sau spatii de tuple, de exemplu
JavaSpaces); Viteza de dezvoltare (tehnici RAD); Separarea prezentarii de
continut (XML); Proiectarea sistemelor distribuite (tranzactii, baze de date
replicate)
Un sistem pentru vanzarea electronica de carti

Functionalitatea unui site de vanzare cu amanuntul, inspirat de Amazon
Permite rasfoirea unui catalog de carti
Permite rasfoirea listei celor mai populare carti. Aceasta lista este
actualizata din ora in ora
Permite selectarea de carti, adaugarea lor la un cos de cumparaturi
virtual si in final cumpararea lor
Informeaza clientul cand cartile au fost expediate
Permite clientilor sa contribuie cu recenzii/recomandari/impresii
despre cartile cumparate
Trimite regulat utilizatorilor abonati la o lista de email-uri
(engl.mailing list) mesaje despre cartile recent aparute si/sau ofertele
speciale
Pentru implementare se pot folosi urmatoarele tehnologii si tehnici care
sunt discutate in curs: servere WWW, browsere, obiecte distribuite,
servere de mail, servere de baze de date, tehnologii pentru persistenta
starii in serverele WWW, etc
Arhitectura sistemului
Catalogul
cartilor
Server pentru
mailing list
Navigator
client
Server de
WWW
Baza de date cu
stocul
Obiecte
distribuite
Baza de date
cu clientii
Server de e-mail
Reteaua companiei unde este

inregistrata cartea de credit
XML
Curs 8
Ce este XML ?
XML este un acronim pentru eXtensible Markup Language limbaj extensibil de

marcare.
XML este un limbaj de meta-marcare. Limbaj de meta-marcare (engl.meta-markup
language) = un limbaj pentru definirea limbajelor de marcare.
Limbaj de marcare (engl.markup language) = un limbaj pentru descrirea formei
unui document (cum trebuie interpretat continutul documentului). Un limbaj de
marcare defineste un tip de document. Aceasta idee a fost introdusa pentru prima
oara in SGML si apoi preluata de acolo si in XML.
Un document scris intr-un limbaj de marcare este compus din date si marcaje.
Marcajele sunt acele informatii care indica utilizatorului cum trebuie interpretat
continutul documentului (datele propriuzise).
Exista diverse tipuri de marcaje:
Stilistice: indica stilul de prezentare a documentului: I, U, B, FONT, etc.
Structurale: indica cum este structurat documentul: HEAD, BODY, P, H, etc
Semantice: indica semnificatia continutului documentului: TITLE, META, etc.
Un limbaj de marcare creat cu XML se numeste si aplicatie XML (ex. XHTML).

XML s-a inspirat din SGML. Dezvoltarea XML s-a decis in 1996 datorita: i)
inflexibilitatii HTML si ii) complexitatii SGML. Recomandarea finala a XML 1.0 a
fost adoptata de W3C in 1998.
Utilitatea XML
Avantaje:
Faciliteaza interoperabilitatea datelor intre aplicatii.
Ofera o alternativa la raspandirea formatelor proprietare.
Atat datele cat si marcajele sunt stocate sub forma de text, fapt ce permite manevrarea si
editarea usoara, practic cu orice editor de texte.
Fiind un limbaj de meta-marcare, este configurabil.
Poate fi citit si interpretat relativ usor de un agent uman.
Este standardizat, ceea ce inseamna ca este relativ unanim cunoscut si acceptat.
Este liber in sensul ca specifcatia este disponibila liber, este independent de platforma si
este bine sustinut de unelte software disponbile liber.
Tipuri de aplicatii care folosesc XML:

Interactiunea cu doua sau mai multe surse de date, reprezentate in formate diferite =
integrarea datelor (engl.data integration) disponibile de la aplicatii diferite putand rula pe
platforme diferite
Transferarea unei parti a prelucrarilor asupra datelor pe calculatoarele client in
arhitecturile client-server
Furnizarea de vederi diferite asupra acelorasi date
Agenti pentru colectarea de informatii
Documente XML bine-formate
Cerinta de a fi bine-format (engl.well-formed) este o constrangere de baza impusa

documentelor XML.
Un document XML bine-format trebuie sa respecte regulile de sintaxa incluse in
specificatia XML 1.0, adica:
Documentul contine unul sau mai multe elemente. Putem considera ca un element este un
nod al unui arbore.
Exista un singur element numit radacina care contine in interiorul sau toate celelalte
elemente;
Fiecare element, exceptand radacina, trebuie incuibat corect in cadrul unui element
cuprinzator numit parintele sau.
Un document XML contine date si marcaje. Datele sunt reprezentate sub forma unor
secvente de caractere (engl.character data). Marcajele indica structura documentului
(sunt metadate). Ele includ:
Marcajele de inceput si sfarsit ale elementelor; Marcajele elmentelor vide; Comentariile;
Referintele la entitati; Delimitatorii sectiunilor CDATA; Definitiile de tip de document
(engl.Document Type Definition DTD); Instructiunile de prelucrare.
Un document XML se compune din trei parti:

Declaratie; indica faptul ca avem un document XML.
Prolog sau antet, ce poate fi vid. Contine o definitie de tip sau o referinta la definitia de tip.
Elementul radacina, care contine in interiorul sau toate celelalte elemente.
Un exemplu: arbori binari in XML

<?xml version="1.0" standalone="yes"
encoding="UTF-8" ?>
<! Un arbore binar reprezentat
in XML -->
<ARBBIN>
<INFO>a</INFO>
<ARBBIN>
<INFO>b</INFO>
<ARBBIN/>
<ARBBIN>
<INFO>d</INFO>
Prima linie este declaratia de document XML.
<ARBBIN/>
Textul inclus intre <!- si --> este un comentariu.
<ARBBIN/>
Elementul de baza pentru structurarea unui
</ARBBIN>
document este elementul. Un element este inclus intre
</ARBBIN>
<ARBBIN>
un marcaj de inceput si un marcaj de sfarsit.
<INFO>c</INFO>
<ARBBIN> este un marcaj de inceput si </ARBBIN> este
<ARBBIN>
un marcaj de sfarsit.
<INFO>e</INFO>
Primul marcaj <ARBBIN> incepe elementul radacina
<ARBBIN/>
al documentului.
<ARBBIN/>
<ARBBIN/> este un marcaj vid si este echivalent cu
</ARBBIN>
<ARBBIN/>
<ARBBIN></ARBBIN>. Indica un element vid.
</ARBBIN>
Elementul <ARBBIN>a</ARBBIN> contine textul a
</ARBBIN>
in interiorul sau.
Elemente XML cu atribute

Informatia din cadrul unui nod al arborelui se poate reprezenta ca
valoare a unui atribut.
...
<ARBBIN>
<INFO info="b" />
<ARBBIN/>
<ARBBIN>
<INFO info="d" />
<ARBBIN/>
<ARBBIN/>
</ARBBIN>
</ARBBIN>
...
Un element poate avea mai mult decat un atribut.
<INFO cheie="10" info="b" />
Documente XML valide (i)
Validitatea este o constrangere aditionala care poate fi impusa documentelor XML.

Ea se bazeaza pe ideea de tip de document mostenita din SGML.
Un document XML se numeste valid daca este bine format si daca exista o definitie
de tip de document DTD cu care documentul este consistent. Se spune ca
documentul este o instanta a acestei definitii de tip.
Adaugand o DTD documentului XML care contine un arbore binar se obtine:
<?xml version="1.0" standalone="yes" ?>
<! Un arbore binar reprezentat in XML -->
<!DOCTYPE ARBBIN [
<!ELEMENT ARBBIN (INFO,ARBBIN,ARBBIN)? >
<!ELEMENT INFO (#PCDATA) >
]>
<ARBBIN> ...
Aici DTD-ul este continut in cadrul aceluiasi fisier cu documentul XML.

DTD-ul este inclus intre marcajle <!DOCTYPE ARBBIN [ and ]>. Marcajul de start
al DTD-ului indica elementul radacina al documentului.
DTD-ul contine o declaratie pentru fiecare element al documentului.
Fiecare declaratie de element specifica numele elementului si un model al
continutului sau.
Documente XML valide (ii)
DTD-ul poate fi plasat intr-un fisier separat. Daca presupunem ca DTD-ul este plasat
in fisierul arbbin.dtd, atunci va trebui sa schimbam doar specificatia DTD-ului din
documentul XML:
<!DOCTYPE ARBBIN SYSTEM "arbbin.dtd">
Fisierul arbbin.dtd va contine doar declaratiile elementelor:

<!ELEMENT INFO (#PCDATA)>
Daca informatia dintr-un nod se reprezinta ca valoare a atributului info al

elementului INFO atunci DTD-ul este:

<!ELEMENT INFO EMPTY>
<!ATTLIST INFO
info CDATA #REQUIRED>
Definitii de tip de document
O definitie de tip de document specifica:

Elementul radacina al documentului
Numele, atributele si modelul de continut al fiecarui element din document:
<!ELEMENT nume_element model_de_continut >
Modelul de continut al unui element se specifica cu !ELEMENT si poate fi:
Vid, specificat prin EMPTY
Text, specificat prin #PCDATA
Alte elemente structurate in secventa (,), optionale (?), alternative (|) sau
repetitive (* si +)
Atributele se specifica pentru fiecare element in parte cu !ATTLIST incluzand
numele atributului, tipul valorii sale si setarea valorii implicite:
<!ATTLIST nume_element
nume_atribut tip_atribut setare_valoare_implicita
...
nume_atribut tip_atribut setare_valoare_implicita >
Tipuri de atribute: enumerare, CDATA, etc.
Setari de valoare implicita: #IMPLIED, #REQUIRED, #FIXED, etc.
Exemplu de DTD pentru o fisa de contacte

<!ELEMENT client (nume, telefon*,
companie?, (contact|atitudine|
personal)*)>
<!ELEMENT nume (prenume,
initiala_tata?, familie, porecla*)>
<!ELEMENT telefon (#PCDATA)>
<!ELEMENT companie (#PCDATA)>
<!ELEMENT contact (#PCDATA|data)*>
<!ELEMENT prenume (#PCDATA)>
<!ELEMENT initiala_tata (#PCDATA)>
<!ELEMENT familie (#PCDATA)>
<!ELEMENT porecla (#PCDATA)>
<!ELEMENT data (#PCDATA)>
<!ELEMENT personal (#PCDATA|data)*>
<!ELEMENT atitudine EMPTY>
<!ATTLIST atitudine interes (mare|
potrivit|mic|necunoscut)
"necunoscut">
<!ATTLIST companie limba (engleza|
franceza|romana) "engleza">
<!ATTLIST contact tip (prim|ultim|
altceva) "altceva">
<client>
<nume><prenume>Amelia</prenume>
<initiala_tata>P.</initiala_tata>
<familie>Badica</familie>
<porecla>Costu</porecla>
</nume>
<telefon>0251-145190</telefon>
<companie limba="romana">
Universitatea din Craiova
</companie>
<contact type="prim">
<data>20 Ian 1995</data>
</contact>
<contact type="ultim">
<data>19 Dec 2002</data>
</contact>
<atitudine interes="potrivit"/>
<personal> Ii place fotbalul
<data>23 Nov 1995</data> Ii
place mancarea italiana
</personal>
</client>
Entitati, siruri de caractere neanalizate, spatii de nume,
Orice procesor de XML trebuie sa distinga intre date si marcaje. Pentru a putea
desemna caracterele < > ' si " ca date trebuie sa folosim entitatile predefinite <
> ' si ". Pentru & se foloseste entitatea predefinita &.
Caracterele speciale UNICODE pot fi referite &#codZecimal; sau
&#xcodHexazecimal;. Astfel se specifica prin © sau ©.
Pentru a indica faptul ca un sir de caractere trebuie sa nu fie analizat de procesorul
documentului XML se foloseste o sectiune CDATA:
<INFO><![CDATA[Text intr-un element <INFO>]]></INFO>
Entitatile parametrice sunt asemanatoare cu macroinstructiunile si sunt utile pentru

organizarea unui DTD.
<!ENTITY % nume "lista_nume">
De exemplu putem defini <!ENTITY % antete " H1|H2|H3|H4|H5|H6 "> si utiliza
apoi %antete in cadrul DTD-ului.
Numele de elemente si atribute dintr-un document XML pot defini un vocabular

partajat destinat reutilizarii in cadrul unor aplicatii multiple. Pentru evitarea
coliziunilor de nume intre astfel de vocabulare partajate se folosesc spatiile de nume
(engl.namespaces).
Limbaje formale si analizoare sintactice
XML este un metalimbaj formal pentru definirea de limbaje formale specifice.

Limbaj formal = o multime de secvente de simboluri (enunturi, fraze) construite pe
baza unei multimi de reguli de formare numita sintaxa limbajului si interpretate
potrivit unui anumit inteles numit semantica limbajului.
Pentru analiza si prelucrarea enunturilor unui limbaj formal (a documentelor
XML in particular) este necesar un program special numit procesor de limbaj. O
componenta de baza a unui procesor de limbaj este analizorul sintactic
(engl.parser). Un analizor sintactic pentru un limbaj formal L primeste la intrare o
multime de enunturi si indeplineste urmatoarele functii:
Decide daca enunturile verifica sintaxa limbajului L.
Daca nu, indica cat mai precis posibil ce reguli sunt incalcate si unde anume.
Daca da, produce o reprezentare structurata intermediara a enunturilor astfel
incat ele sa poata fi ulterior interpretate si prelucrate conform semanticii lui L.
Un programator de aplicatii va fi interesat in primul rand cum poate integra un
procesor de limbaj in cadrul unei aplicatii. In cazul XML el se va confrunta cu
problema integrarii analizoarelor sintactice de XML. In general exista doua
modalitati prin care un analizor sintactic poate comunica rezultatele analizei
celorlalte componente ale aplicatiei: i) prin evenimente analizor sintactic bazat pe
evenimente (engl.event-driven parser); ii) prin construirea explicita a unei structuri
intermediare care sa descrie complet enunturile analizate translator.
Analiza si prelucrarea documentelor XML folosind Java
Un analizor sintactic de XML poate fi i) cu validare (engl.validating parser), caz in care el

verifica consistenta documentului XML cu un DTD sau ii) fara validare (engl.nonvalidating parser), caz in care el verifica doar daca documentul XML este bine-format.
Exista o standardizare a interfetelor de programare (engl.Application Programming
Interface API) pe care trebuie sa le implementeze un analizor sintactic de XML astfel
incat el sa poata fi integrat cat mai usor si portabil in cadrul unei aplicatii. In prezent
exista doua API standard:
Simple API for XML SAX, un standard de-facto existent in doua versiuni SAX1 si
SAX2. Defineste o multime de interfete pentru un analizor sintactic bazat pe
evenimente (engl.event-driven parser). SAX a fost definita intai pentru Java, dar s-au
definit ulterior versiuni similare si pentru alte limbaje (C++);
Document Object Model DOM, un standard W3C pentru un analizor sintactic care
traduce un document XML intr-o structura de date abstracta de tip arbore numita
DOM. Exista 3 nivele de DOM: nivelul 1 (recomandare W3C), nivelul 2
(recomandare candidat W3C) si nivelul 3 (document W3C in lucru). DOM se doreste
a fi o specificatie independenta de limbaj, fiind valabila si pentru limbajele de
scripting (JavaScript)
SAX
SAX este un standard de facto pentru o interfata de programare a unui
mecanism de analiza sintactica bazat pe evenimente a documentelor
XML. Un programator de aplicatii va putea folosi orice biblioteca de
programe de analiza sintactica conforma cu standardul SAX, fiind
suficient sa cunoasca doar aceasta interfata standard.
Termenul bazat pe evenimente se refera la folosirea unor functii callback. Aceste functii trebuie furnizate de programatorul de aplicatii si
ele trateaza o serie de evenimente de interes primite de la analizorul
sintactic. Un analizor sintactic conform cu SAX va trebui sa
implementeze interfata SAX. Functiile call-back sunt implementate de
obiecte speciale de tratare a evenimentelor (engl.handler). Un astfel de
obiect trebuie sa implementeze niste interfete standard.
O biblioteca conforma cu SAX va trebui sa contina partea de interfete
standard SAX si o implementare particulara a acestor interfete. O astfel
de bibliotca este Xerces.
Interfete SAX
SAX contine trei parti:
Partea de baza org.xml.sax. Aici se definesc interfetele standard ale
obiectelor de tratare a evenimentelor SAX.
ContentHandler evenimente referitoare la continut
DTDHandler evenimente referitoare la DTD
ErrorHandler evenimente de eroare
EntityResolver evenimente de tratare a entitatilor
XMLReader interfata unui analizor sintactic XML orientat pe
evenimente
Attributes interfata pentru o lista de atribute XML
Partea de clase de ajutor org.xml.sax.helpers. Aici se definesc niste
implementari implicite pentru interfetele SAX.
DefaultHandler implementare implicita a tuturor celor 4 interfete
pentru tratarea evenimentelor SAX.
AttributesImpl implementare implicita pt o lista de atribute
XML
...
Partea de extensii org.xml.sax.ext.
Folosirea SAX
Folosirea SAX presupune parcurgerea urmatorilor pasi:
Furnizarea de implementari pentru obiectele de tratare a evenimentelor SAX. O
metoda comoda este extinderea implementarii implicite din clasa
DefaultHandler. Aceasta clasa furnizeaza implementari implicite pentru toate
cele 4 interfete standard SAX. In cadrul acestei implmentari se vor redefini doar
metodele care sunt necesare.
Se creaza o clasa pentru reprezentarea unui analizor sintactic. Pentru aceasta este
util sa se utilizeze o biblioteca care sa dispuna deja de o astfel de implementare.
Spre exemplu, pachetul Xerces dispune de clasa SAXParser.
In programul principal se realizeaza urmatoarele prelucrari:
Se creaza un obiect de tratare a evenimentelor SAX..
Se creaza un obiect pentru reprezentarea unui analizor sintactic.
Se inregistreaza obiectul de tratare a evenimentelor la analizorul sintactic.
Se executa functia de analiza sintactica a obiectului analizor.
In functiile de tratare a evenimentelor de analiza sintactica se realizeaza toate
prelucrarile necesare din cadrul aplicatiei respective. Spre exemplu, se pot folosi
aceste evenimente pentru extragerea informatiilor relevante pentru aplicatie din
cadrul documentului XML si reprezentarea lor sub forma unei structuri
intermediare. Aceasta structura se poate prelucra ulterior.
Exemplu de folosire SAX
Pentru citirea unui arbore binar dintr-un document XML si construirea unei reprezentari
interne adecvate vom folosi un analizor sintactic cu validare:
class ValidatingSAXParser extends SAXParser {
public ValidatingSAXParser() throws SAXException {
this.setFeature("http://xml.org/sax/features/validation", true);
}
Tratarea evenimentelor de analiza sintactica si construirea arborelui binar:

public class BTreeHandler extends DefaultHandler {
public void startElement(String uri, String localName, String rawName,
Attributes atts) { ... }
public void endElement(String uri,String localName, String rawName) {}
public void warning(SAXParseException e) { ... }
public void error(SAXParseException e) { ... }
public void fatalError(SAXParseException e) { ... }
}
In main() se construieste un obiect de tratare a evenimentelor si un analizor sintactic:

BTreeHandler handler = new BTreeHandler();
XMLReader parser = new ValidatingSAXParser();
parser.setContentHandler(handler);
parser.setErrorHandler(handler);
parser.setDTDHandler(handler);
parser.setEntityResolver(handler);
parser.parse( ... );
Construirea unui arbore binar folosind SAX (I)

private Stack treeStack = new Stack();
private Stack tagStack = new Stack();
final int INFO = 0;
final int ARBBIN = 1;
public void startElement(String uri,
String localName, String rawName,
Attributes atts) {
if (localName.equals("ARBBIN")) {
tagStack.push(new Integer(ARBBIN));
}
else if (localName.equals("INFO")) {
tagStack.push(new Integer(INFO));
treeStack.push(new BTree(new BTreeNode(atts.getValue("info"),
new BTree(),new BTree())));
}
}
Construirea unui arbore binar folosind SAX (II)

public void endElement(String uri,
String localName, String rawName) {
if (localName.equals("ARBBIN")) {
if (((Integer)tagStack.peek()).intValue() == ARBBIN) {
tagStack.pop();
treeStack.push(new BTree());
}
else {
tagStack.pop();tagStack.pop();
BTree right = (BTree)treeStack.pop();
BTree left = (BTree)treeStack.pop();
((BTree)treeStack.peek()).getRoot().setLeft(left);
((BTree)treeStack.peek()).getRoot().setRight(right);
}
}
}
DOM
DOM (nivelul 2) este o platforma si o interfata independenta de limbaj ce permite

programelor si scripturilor sa acceseze si sa actualizeze dinamic continutul si
structura documentelor XML.
Pachetul de baza org.w3c.dom poate fi gandit ca o specificatie a unui tip
abstract de date pentru reprezentarea unui document XML sub forma unui
arbore. Principalele interfete definite in acest pachet sunt urmatoarele:
Node este tipul primar al unui nod dintr-un arbore DOM
NodeList reprezinta o colectie ordonata de noduri
Element reprezinta un element al unui document XML Extinde tipul Node.
NamedNodeMap reprezinta o colectie de noduri ce pot fi accesate prin nume
(de exemplu nodurile atribut unui element XML).
Document reprezinta nodul document al unui arbore DOM. Extinde tipul
Node.
Attr reprezinta un nod atribut al unui element XML. Extinde tipul Node.
Text
Comment
Entity
ProcessingInstruction
...
Folosirea DOM
La fel ca si pentru SAX, folosirea DOM presupune existenta unei
biblioteci care sa implementeze interfetele DOM. O astfel de biblioteca
este pachetul Xerces.
Folosirea DOM presupune parcurgerea urmatorilor pasi:
Implementarea unui modul de prelucrare a informatiei dintr-un
document XML reprezentat sub forma unui arbore DOM.
In programul principal se realizeaza urmatoarele prelucrari:
Construirea unui obiect pentru reprezentarea unui analizor
sintactic conform cu DOM. Pachetul Xerces furnizeaza pentru
aceasta clasa DOMParser.
Se executa functia de analiza sintactica a obiectului analizor.
Se extrage obiectul document si se prelucreaza.
DOMParser parser = new DOMParser();
parser.parse( ... );
Document doc = parser.getDocument();
Element root = doc.getDocumentElement();
...
Construirea unui arbore binar folosind DOM (I)

public static BTree doc2BTree(Element doc) {
NodeList children = doc.getChildNodes();
int noOfChildren = children.getLength();
if (noOfChildren==0) {
return new BTree();
}
else {
Element info = null; Element left = null;
Element right = null; int left_already = 0;
for (int i=0;i<noOfChildren;i++) {
Node node = children.item(i);
if ((node.getNodeType()) == (Node.ELEMENT_NODE)) {
if (((Element)node).getTagName().equals("INFO")) {
info = (Element)node;
}
else if (((Element)node).getTagName().equals("ARBBIN")) {
if (left_already == 0) {
left_already = 1; left = (Element)node;
}
Construirea unui arbore binar folosind DOM (II)

else {
right = (Element)node;
}
}
}
}
NamedNodeMap atts = info.getAttributes();
Attr att = (Attr)atts.getNamedItem("info");
return new BTree(new BTreeNode(att.getValue(),
doc2BTree(left),doc2BTree(right)));
}
}
Ce este XSL ?
XSL (Extensible Stylesheet Language) este un limbaj de prelucrare a documentelor

XML. XSL este o aplicatie XML.
XSL are doua componente relativ distincte:
Limbajul de transformare XSLT. XSLT permite trasformarea unui document
XML intr-un alt document XML sau document text. XSLT 1.0 este o
recomandare W3C din 16 Noiembrie 1999. XSLT foloseste limbajul XPath
pentru adresarea diverselor parti din arborele unui document XML.
Limbajul de formatare XML-FO. XML-FO permite descrierea formatului de
prezentare a unui document XML prin furnizarea unui vocabular de formatare.
Pentru prezentarea unui document XML sunt necesari in general doi pasi:
Transformarea documentului XML initial intr-un document XML care foloseste
vocabularul XML-FO. Acest pas poate optional sa realizeze si o filtrare a
continutului documentului initial.
Formatarea documentului XML-FO rezultat, cu ajutorul unui program special
de formatare, adica transformarea sa intr-un format specific de prezentare/
afisare/ vizualizare. Exemple de astfel de formate sunt PDF, Postscript si RTF.
In WWW se poate folosi XSLT pentru a transforma un document XML intr-un
document XHTML sau WML. Transformarea poate avea loc fie la server, fie la
client.
Scurt istoric
Una dintre sursele de inspiratie pentru XSL a fost DSSSL
Document Style Semantics and Specification Language. DSSSL este
un standard ISO referitor la prelucrarea documentelor SGML.
Asemanator cu XSL, DSSSL are doua componente: limbajul de
transformare si limbajul de formatare.
Desi este un standard ISO, numarul de implementari ale DSSSL este
foarte scazut. In plus, expertiza in folosirea DSSSL este foarte saraca.
Totusi, DSSSL are un avantaj cheie fata de XSL: faptul ca ofera un
limbaj de programare, bazat insa pe mai putin popularul Scheme
(derivat din Lisp). Acest lucru poate fi considerat a fi si un
dezavantaj.
O alta sursa de inspiratie pentru componenta de formatare a XSL a
constituit-o CSS. Desi sintaxa XSL-FO se bazeaza pe XML si este
astfel foarte diferita de sintaxa CSS, terminologiile folosite in XSLFO si CSS sunt foarte asemanatoare.
Transformari XSL
XSLT este un limbaj de transformare a unui document XML intr-un alt format.
Formatul de iesire poate fi tot XML (de exemplu XHTML sau WML) sau alt format
text.
Pentru producerea unei transformari este nevoie de trei elemente:
Sursa transformarii, documentul XML de intrare
Specificatia transformarii, un document XSLT
Motorul transformarii, un program numit procesor XSLT. Acest program aplica
specificatia XSLT a transformarii, sursei transformarii.
XSLT
XML
Motor de transformare
(Procesor XSLT)
XHTML (or text or XML)
Concepte de baza XSLT

XSLT modeleaza un document sub forma de arbore. XSLT se bazeaza pe
XPath. XPath este un limbaj de expresii pentru adresarea unei parti dintr-un
document XML. Poate fi gandit si ca un limbaj de interogare a arborilor
XML.
XPath si XSLT recunosc 7 tipuri de noduri ale arborelui XML de intrare: i)
Radacina documentului: este nodul de start al oricarui document; ii)
Element: reprezinta un element al sursei XML. iii) Text: reprezinta un
continut text dintr-un element al sursei XML. iv) Atribut: reprezinta un
atribut al unui element din sursa XML; v) Spatiu de nume: vi) Comentariu:
vii) Instructiune de prelucrare: reprezinta textul unei instructiuni de
prelucrare din sursa XML.
Pe multimea nodurilor unui document este definita o relatie de ordonare
liniara numita ordinea documentului. In esenta aceasta ordine exprima
urmatoarele: i) nodul radacina este primul; ii) nodurile element apar
inaintea copiilor lor; iii) atributele si spatiile de nume asociate unui element
apar inaintea copiilor elementului respectiv; iv) spatiile de nume asociate
unui element apar inaintea atributelor elementului respectiv.v) ordinea
relativa a spatiilor de nume si a atributelor unui element este dependenta de
implementare.
XPath
XPath = limbaj pentru adresarea unei parti dintr-un
document XML. Un enunt XPath se numeste expresie.
Expresiile XPath se evalueaza la unul din tipurile:
Multime de noduri (engl.node-set). Un exemplu de astfel de xpresie
este o cale de localizare a unor noduri (engl.location path)
Boolean (true sau false)
Numar (numar real reprezentat in virgula mobila)
Sir de caractere (engl.string)
Evaluarea unei expresii XPath se face in raport cu un

context ce contine:
Un nod context
O pereche de intregi strict pozitivi: pozitie context dimensiune
context
O multime de legaturi de variabile (engl.variable bindings)
O biblioteca de functii
Multimea de declaratii de spatii de nume din domeniul expresiei
Un document XML folosit pentru interogari (I)

Se considera o organizatie formata dintr-o lista de grupuri,
impreuna cu o multime de top manageri. Un grup este fie o
lista de grupuri cu un manager, fie o multime de angajati.
Fiecare grup si fiecare angajat are un identificator unic
(atributul id). Pentru simplificare se presupune ca id-ul unui
angajat este chiar numele sau.
DTD-ul corespunzator acestei descrieri este urmatorul:
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ELEMENT
<!ATTLIST
<!ATTLIST
organization (group+, topmgr) >

topmgr (employee+) >
group ((mgr, group+) | (employee+)) >
mgr (employee) >
employee EMPTY >
employee id CDATA #REQUIRED >
group id CDATA #REQUIRED >
Un document XML folosit pentru interogari (II)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE organization SYSTEM "org.dtd" >
<organization>
<group id="HR">
<mgr>
<employee id="Bill"/>
</mgr>
<group id="HR-prod">
<mgr>
<employee id="Edna"/>
</mgr>
<group id="HR-prod-empl">
<employee id="Kate"/>
<employee id="Ronald"/>
</group>
</group>
<group id="HR-QA">
<mgr>
<employee id="John"/>
</mgr>
<group id="HR-QA-empl">
<mgr>
<employee id="Amelia"/>
</mgr>
<group id="HR-Amelia">
<employee id="Jane"/>
<employee id="Jake"/>
</group>
</group>
</group>
</group>
<topmgr>
<employee id="Bill"/>
<employee id="John"/>
<employee id="Amelia"/>
</topmgr>
</organization>
Exemple de expresii XPath (I)
/organization/group
Rezultat (toate grupurile de nivel ierarhic 1):
/organization[1]/group[1] (grupul HR).
/organization//group
Rezultat (toate grupurile, indiferent de nivelul ierarhic):
/organization[1]/group[1] (grupul HR)

/organization[1]/group[1]/group[1] (grupul HR-prod)
/organization[1]/group[1]/group[1]/group[1]
/organization[1]/group[1]/group[2]
/organization[1]/group[1]/group[2]/group[1
/organization[1]/group[1]/group[2]/group[1]/group[1]
//employee/attribute::id
Rezultat (numele tuturor angajatilor):
/organization[1]/group[1]/mgr[1]/employee[1]/@id (angajatul Bill)

/organization[1]/group[1]/group[1]/mgr[1]/employee[1]/@id
/organization[1]/group[1]/group[1]/group[1]/employee[1]/@id
/organization[1]/group[1]/group[1]/group[1]/employee[2]/@id
/organization[1]/group[1]/group[2]/mgr[1]/employee[1]/@id
/organization[1]/group[1]/group[2]/group[1]/mgr[1]/employee[1]/@id
/organization[1]/group[1]/group[2]/group[1]/group[1]/employee[1]/@id
/organization[1]/group[1]/group[2]/group[1]/group[1]/employee[2]/@id
/organization[1]/topmgr[1]/employee[1]/@id
Exemple de expresii XPath (II)
/organization/node()
Rezultat (toate nodurile descendente din elementul radacina (element, text, atribut):
/organization[1]/#text[1]
/organization[1]/group[1]
/organization[1]/topmgr[1]
//*/attribute::id sau //*/@id

Rezultat (nodurile atribut id ale tuturor elementelor)
17 rezultate
count(//employee)
Rezultat (numarul angajatilor):
11
string(//employee/attribute::id)
Rezultat (numele primului angajat in ordinea standard):
Bill
//group/employee[last()]
Rezultat (ultimul angajat din lista fiecarui grup):
/organization[1]/group[1]/group[1]/group[1]/employee[2]
/organization[1]/topmgr[1]/employee[3]
(/organization) | (/organization/group)
Rezultat (organiztaia si grupurile de nivel ierarhic 1):
/organization[1]
/organization[1]/group[1]
Modelul de prelucrare folosit de XSLT
O transformare XSLT descrie o multime de reguli pentru transformarea unui

arbore de intrare intr-un arbore de iesire. O regula contine o parte de conditii,
numita sablon (engl.pattern) si un tipar (engl.template). Sablonul este identificat cu
nodurile arborelui sursa. In cazul unei identificari (engl.matching), tiparul este
instantiat si astfel el genereaza o parte din arborele documentului de iesire.
Prelucrarea unui arbore sursa se bazeaza pe parcurgerea recursiva a arborilor:
Prelucrarea de baza este aplicarea regulilor unei multimi de noduri din arborele
sursa. Procesul incepe prin aplicarea regulilor listei de noduri formata doar din
nodul radacina.
Prin aplicarea regulilor unui nod din arborele sursa se obtine un arbore de
iesire. La aplicarea regulilor unei liste de noduri, se aplica regulile pentru fiecare
nod din lista si se concateneaza rezultatele.
Prelucrarea unui nod presupune determinarea tuturor regulilor aplicabile
nodului. Daca se pot aplica mai multe reguli, pentru a determina regula
aplicabila se foloseste o strategie de rezolvare a conflictelor bazata pe
specificitate. Se va selecta regula cu partea de conditii cea mai specifica. Nodul
caruia i se aplica regulile devine nodul curent, iar lista de noduri din care a facut
parte cand fost selectat este lista nodurilor curente.
Un tipar poate contine instructiuni pentru selectarea altor noduri carora li se
vor aplica regulile de transformare. Daca lista acestor noduri este nevida, atunci
procesul de aplicare a regulilor continua recursiv pentru aceasta lista pana cand
nu se mai selecteaza noduri noi pentru prelucrare.
Sabloane
O regula este aplicabila unui nod daca nodul se identifica cu
sablonul regulii.
Un sablon specifica o multime de conditii asupra unui nod.
Un nod se identifica (engl.matches) cu sablonul daca
satisface aceste conditii.
Un sablon este un caz particular de expresie XPath care se
evalueaza la o multime de noduri.
Un nod se identifica cu un sablon daca nodul este membru
al rezultatului evaluarii sablonului intr-un context posibil ce
poate fi chiar nodul respectiv sau un stramos al sau.
Spre exemplu un sablon employee se va identifica cu orice
element employee deoarece evaluand expresia employee
avand drept context parintele unui nod employee, nodul va
fi un element al rezultatului.
Reguli
Un document XSLT contine reguli de transformare. O regula de
transformare are sintaxa urmatoare:
<xsl:template match="sablon" mode="valoare">
tipar
</xsl:template>
Specificarea sablonului se face cu atributul match. Valoarea acestui atribut

este o expresie XPath care se evalueaza la o multime de noduri.
Atributul mode se foloseste pentru a identifica starea in care este aplicabila
regula.
Corpul regulii poate fi folosit in principiu in doua scopuri:
Pentru aplicarea recursiva a altor reguli, nodurilor selectate
Pentru generarea (construirea) unei parti a documentului rezultat
Aplicarea regulilor se face cu sintaxa:

<xsl:apply-templates select=expresie
mode="valoare">
</xsl:apply-templates>
Atributul mode specifica starea in care sunt aplicabile regulile si atributul

select specifica nodurile selectate pentru aplicare. Valoarea atributului
select este o expresie XPath care se evalueaza la o multime de noduri.
Variabile si parametri
O variabila poate deveni legata (engl.bound) la o valoare, in
cadrul unei reguli.
Un parametru specifica o valoare implicita care poate fi
suprascrisa in momentul in care primeste o valoare prin
aplicarea unor reguli cu parametrii.
La aplicarea unei reguli cu parametrii, se pot specifica
valorile parametrilor, suprascriind astfel valorile implicite.
Legarea variabilelor se face cu elementul xsl:variable.
Definirea valorilor parametrilor in corpul unei reguli se
face cu elementul xsl:param. Valorile parametrilor la
apelul unei reguli se specifica cu elementul xsl:withparam.
Numele variabilelor si parametrilor se specifica cu atributul
name.
Exemplu de transformare (I)

Sa presupunem ca dorim sa determinam toate perechile
(e1,e2) de angajati cu proprietatea ca e1 este un top manager
diferit de Bill si este in acelasi timp un sef direct sau
indirect al lui e2.
Acest exemplu ilustreaza intr-o maniera intuitiva trei
concepte importante ale XSLT:
Utilizarea modurilor
Legarea de valori la variabile
Transferul parametrilor la aplicarea regulilor
Exemplu de transformare (II)

<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="organization">
<result>
<xsl:apply-templates
select="/organization/topmgr/employee" mode="selecttopmgr"/>
</result>
</xsl:template>
<xsl:template match="employee" mode="selecttopmgr">
<xsl:variable name="varID">
<xsl:value-of select="@id"/>
</xsl:variable>
<xsl:if test="$varID != 'Bill'">
<xsl:apply-templates mode="display"
select="//group[mgr/employee[@id=$varID]]/group//employee">
<xsl:with-param name="varID" select="$varID"/>
</xsl:apply-templates>
</xsl:if>
</xsl:template>
<xsl:template match="employee" mode="display">
<xsl:param name="varID"/>
<pair>
<xsl:attribute name="topmgrID">
<xsl:value-of select="$varID"/>
</xsl:attribute>
<xsl:attribute name="employeeID">
<xsl:value-of select="@id"/>
</xsl:attribute>
</pair>
</xsl:template>
</xsl:stylesheet>
Sisteme distribuite obiectuale si

invocare la distanta
Tematica
Aceasta prelegere trateaza comunicarea intre OD folosind
invocarea metodelor la distanta (engl.remote method
invocation RMI). RMI are o semantica diferita fata de
invocarile locale.
Invocarea procedurilor la distanta (engl.remote procedure
call RPC) este varianta procedurala a RMI.
SD bazate pe evenimente (engl.distributed event-based
systems) permit obiectelor sa se inregistreze la OD de interes
astfel incat sa poata fi instiintate de aparitia unor
evenimente la acele OD. Evenimentele permit comunicarea
asincrona intre OD.
Ca studiu de caz se prezinta o aplicatie Java RMI.
Privire de ansamblu
Applications
Aceasta
prelegere
RMI, RPC and events

Request reply protocol
Middleware
layers
External data representation

Operating System
Modelele clasice de programare au fost extinse la programarea distribuita: i) apelul de

proceduri la distanta; ii) invocarea metodelor la distanta; iii) programarea bazata pe
evenimente.
Partea de middleware urmareste realizarea urmatoarelor deziderate:
Transparenta locatiei. Clientul nu cunoaste locatia serverului si daca apelul va rula in cadrul aceluiasi
proces, intr-un proces separat sau pe un calculator separat. Similar, obiectele generatoare si
receptoare de evenimente nu-si cunosc unul altuia locatiile.
Protocoalele de comunicatie. Protocoalele care suporta nivelul de abstractizare oferit de middleware
sunt independente de nivelul de transport. De exemplu protocolul RR poate lucra peste UDP sau TCP.
Platforma (hardware + sistem de operare). Se urmareste independenta de platforma.
Utilizarea unor limbaje de programare diferite. Uneori nivelul middleware permite programarea
aplicatiilor distribuite in mai multe limbaje de programare (de exemplu CORBA).
Interfete
Limbajele moderne de programare permit organizarea programelor sub forma unei multimi
de module care comunica intre ele. Comunicarea se face prin definirea unei interfete pentru
fiecare modul in parte.
Interfata unui modul specifica procedurile si variabilele sale ce pot fi accesate din alte
module.
Modulele unui SD pot rula in procese separate. Astfel ca un modul nu va putea accesa
variabilele din alt modul. Chiar daca de exemplu CORBA permite specificarea accesului la
anumite atribute, accesul propriuzis se va face prin medode getter si setter.
Tehnicile clasice de transfer a parametrilor (apel prin valoare si apel prin referinta) nu sunt
potrivite cand apelantul si apelatul sunt in procese diferite. Specificarea unei proceduri sau
metode intr-o interfata a unui modul intr-un SD se face prin parametrii de intrare si/sau de
iesire. Parametrii de intrare sunt transmisi modulului la distanta prin trimiterea valorilor lor
intr-un mesaj de cerere si apoi folosirea lor drept argumente pentru executarea operatiei la
server. Parametrii de iesire sunt returnati in mesajul de raspuns si sunt utilizati drept rezultat
al apelului sau vor inlocui valorile variabilelor corespunzatoare din mediul apelului. Cand un
parametru este atat de intrare cat si de iesire, valoarea corespunzatoare va fi transmisa atat
in mesajul de cerere cat si in cel de raspuns.
Deoarece pointerii dintr-un proces nu sunt valizi intr-un alt proces, ei nu se transmit ca
argumente si nu se returneaza ca rezultate in apeluri la distanta.
In modelul client-server, serverul furnizeaza o interfata pentru servicii IS (engl.service
interface). In SD obiectuale, un OD furnizeaza o interfata la distanta ID (engl.remote
interface). Intre ele exista diferenta ca metodele dintr-o ID pot transmite obiecte si/sau ROD
ca argumente si pot returna obiecte si/sau ROD ca rezultate.
Limbaje de definire a interfetelor

RMI poate fi integrata in cadrul unui limbaj de programare care suporta
definirea interfetelor. In acest fel parametrii de intrare si iesire pot fi mapati
pe utilizarea normala a parametrilor in limbajul respectiv. Un exemplu este
Java RMI. Aceasta abordare este utila in cazul in care aplicatia distribuita
este scrisa intr-un singur limbaj si ea are avantajul uniformitatii.
Cu toate acestea, exista diverse servicii deja scrise in C++ sau in alte limbaje
de programare. Este benefic sa se asigure accesul la distanta la acestea din
programe scrise in limbaje de programare diferite, incluzand Java. Pentru
aceasta s-au proiectat limbaje de definire a interfetelor (engl.interface
definition language IDL) care sa permita OD scrise in limbaje diferite sa se
invoce unele pe altele.
Un IDL este o notatie pentru definirea interfetelor. Pentru fiecare parametru
al unei interfete se specifica: i) daca este de intrare si/sau de iesire; ii) tipul
sau.
Exemple de IDL:
CORBA IDL (vezi exemplul de pe pagina urmatoare).
IDL pentru RPC in DCE (Distributed Computing Environment, al OSF) DCE
IDL, foloseste sintaxa C.
DCOM IDL (bazat pe DCE IDL), folosit de DCOM (Distributed Common Object
Model, al firmei Microsoft).
Exemplu CORBA IDL

// In file Person.idl
struct Person {
string name;
string place;
long year;
};
interface PersonList {
readonly attribute string listname;
void addPerson(in Person p) ;
void getPerson(in string name, out Person p);
long number();
};
Comunicatia intre obiecte in SD obiectuale

Modelul obiectual al unui SD extinde modelul obiectual traditional
datorita OD.
In continuare vom trata urmatoarele probleme:
Modelul obiectual: este o recapitulare a elementelor modelului obiectual,
relevante pentru discutia referitoare la SD obiectuale.
SD obiectuale: o prezentare a SD obiectuale ce arata ca modelul
obiectual este foarte potrivit in SD
Modelul obiectual distribuit: o extensie a modelului obiectual in vederea
aplicarii sale SD
Consideratii de proiectare: i) in timp ce invocarile locale se executa o
singura data, ce semantica trebuie adoptata pentru invocarile la distanta
? ii) cum se poate realiza o semantica a RMI cat mai apropiata de cea a
invocarilor locale si ce diferente nu pot fi eliminate ?
Implementare: se arata cum se poate proiecta un nivel middleware aflat
deasupra protocolului cerere-raspuns pentru a asigura suportul necesar
RMI intre OD ale unei aplicatii distribuite
Colectarea distribuita a gunoaielor (engl.distributed garbage collection): o
prezentare a unui algoritm de colectare distribuita a gunoaielor ce poate
fi folosit intr-o implementare a RMI
Modelul obiectual
O aplicatie obiectuala consta dintr-o multime de obiecte ce interactioneaza. Un obiect

incapsuleaza date si cod. Vom presupune ca accesul la datele private ale unui obiect se
poate face numai prin intermediul metodelor sale.
Referinte la obiecte. Obiectele sunt accesate prin referinte. Invocarea metodelor unui
obiect se face prin intermediul referintei la obiect. Obiectul a carui metoda a fost
invocata se numeste obiect tinta (engl.target) sau receptor (engl.receiver). Referintele
pot fi atribuite variabilelor, transmise ca argumente metodelor sau returnate ca
rezultate ale metodelor.
Interfete. O interfata defineste semnaturile unei multimi de metode. Un obiect
furnizeaza o anumita interfata daca clasa sa contine cod ce implementeaza metodele
interfetei. O clasa poate implementa mai multe interfete. O interfata defineste un tip
ce se poate folosi in declaratii de variabile sau parametrii.
Actiuni. O actiune se initiaza cand un obiect invoca o metoda a altui obiect. Obiectul
receptor executa metoda corespunzatoare si eventual intoarce controlul obiectului
apelant. O invocare poate avea doua efecte: i) schimbarea starii obiectului receptor;
ii) invocari ulterioare de metode ale altor obiecte.
Exceptii. Exceptiile furnizeaza o metoda eleganta de a trata conditiile de eroare, fara
complicarea codului. Are loc o separare clara a codului pentru tratarea erorilor de
codul pentru o executie normala.
Colectarea gunoaielor. Este mecanismul prin care se asigura eliberarea automata a
spatiului de memorie ocupat de obiectele care nu mai sunt necesare.
SD obiectuale
Starea unui obiect este multimea valorilor variabilelor membre. In
acest fel starea unui program obiectual este partitionata logic intr-o
multime de obiecte. Distribuirea fizica a acestor obiecte in procese
si/sau calculatoare diferite este o extensie naturala.
SD obiectuale pot adera la o arhitectura client-server. Obiectele sunt
gestionate de servere iar clientii pot invoca metodele acestora folosind
RMI. Obiectele din servere pot fi la randul lor clienti ale unor obiecte
din alte servere.
Obiectele dintr-un SD pot fi replicate pentru cresterea tolerantei la
defecte si imbunatatirea performantelor sau pot migra pentru
cresterea performantei si a disponibilitatii.
Faptul ca obiectele sunt gestionate de procese diferite forteaza
incapsularea. Obiectele pot folosi primitive de sincronizare pentru a-si
asigura accesul concurent corect la propriile variabile membre.
Accesul la obiecte doar prin metode permite independenta fata de
formatul de reprezentare si de platforma gazda.
Modelul obiectual distribuit (I)

Are la baza doua concepte fundamentale: i) referinta unui obiect la distanta
(engl.remote object reference) ROD; ii) interfata la distanta (engl.remote
interface) ID.
ROD este o extensie a conceptului de referinta a unui obiect, la cazul SD. O
ROD este un identificator care se poate folosi intr-un SD pentru referirea la
un obiect unic. ROD se folosesc pentru invocarea unei metode a unui OD si
pot fi transmise ca argumente si intoarse ca rezultate in RMI.
O ID specifica metodele unui OD care pot fi invocate prin RMI de catre alte
obiecte. In CORBA, definirea ID se face folosind limbajul CORBA IDL. In
Java RMI, o ID se defineste prin extinderea interfetei Remote.
local
remote
invocation
A
C
local E
invocation
invocation
local
invocation
D
remote
invocation
Modelul obiectual distribuit (II)

Actiunile intr-un SD obiectual pot presupune lanturi de RMI.
In cazul in care un limbaj suporta colectarea gunoaielor, sistemul RMI asociat
va trebui sa asigure colectarea gunoaielor corespunzatoare OD. Acest lucru se
realizeaza de obicei printr-o cooperare intre colectorul local de gunoaie si un
modul care realizeaza colectarea distribuita a gunoaielor.
Orice invocare la distanta poate esua: i) datorita faptului ca procesul ce
contine OD fie s-a oprit sau fie este prea solicitat si nu poate raspunde la
timp; ii) datorita faptului ca mesajul de cerere sau de raspuns s-a pierdut.
Din acest motiv o invocare la distanta trebuie sa poata genera o exceptie care
sa indice fie depasirea unei cuante de timeout, fie o eroare in executia metodei.
remoteobject
remote
interface
Data
m1
m2
m3
implementation
of methods
m4
m5
m6
Semantica RMI
Am aratat ca implementarea functiei doOperation in protocolul RR se poate face in

diverse moduri, asigurandu-se diverse nivele ale garantarii livrarii parametrilor:
Reincercarea de a transmite mesajul de cerere: mesajul de cerere este retransmis pana
cand se receptioneaza un raspuns sau se presupune ca serverul s-a oprit.
Filtrarea duplicatelor: cand se utilizeaza retransmiterea, cererile duplicate sunt filtrate si
eliminate de catre server.
Retransmisia rezultatelor: se pastreaza o istorie a mesajelor cu rezultatele, pentru a
permite retransmiterea fara reexecutarea operatiilor la server.
Diverse combinatii ale acestor variante conduc la o varietate de semantici posbile

pentru fiabilitatea RMI din punctul de vedere al apelantului.
Fault tolerance measures
Retransmit request
message
Duplicate
filtering
Invocation
semantics
Re-execute procedure
or retransmit reply
No
Not applicable
Not applicable
Yes
No
Re-execute procedure
At-least-once
Yes
Yes
Retransmit reply
At-most-once
Maybe
Semantica invocarii maybe

Semantica invocarii maybe:
In acest caz apelantul nu va putea sti cu siguranta daca
invocarea s-a executat sau nu. Aceasta situatie apare cand nu sa luat nici una dintre masurile de toleranta la defecte. Putem
avea urmatoarele tipuri de erori: i) erori de omisiune in cazul
in care mesajul de invocare sau de rezultat s-a pierdut; ii) erori
de oprire in cazul in care serverul ce contine OD se defecteaza.
Daca mesajul de rezultat nu a fost receptionat dupa scurgerea
cuantei de timeout si nu exista reincercari, nu exista
certitudinea daca metoda s-a executat sau nu.Se poate insa ca
metoda sa se fi executat, dar mesajul cu rezultatul sa se fi
pierdut. Mai mult, in cazul unui sistem asincron este posibil ca
mesajul de raspuns sa soseasca dupa timeout.
Aceasta semantica este utila in aplicatiile in care eventualele
invocari esuate sunt acceptabile.
Semantica invocarii at-least-once

Semantica invocarii at-least-once:
In acest caz apelantul fie primeste un rezultat, in cazul in care
apelul s-a executat cel putin o data, fie o exceptie ce il
informeaza ca nu s-a receptionat nici un rezultat.
Aceasta semantica se poate realiza prin retransmisia mesajelor
de cerere, fapt ce mascheaza eventualele erori de omisiune in
mesajle de cerere sau raspuns.
Sufera de urmatoarele tipuri de erori: i) erori de oprire ale
serverului ce contine OD; ii) erori arbitrare, in cazul in care
retransmiterea mesajului de invocare poate conduce la
receptionarea multipla si executia multipla a metodei invocate,
fapt ce poate determina stocarea si returnarea unor valori
eronate (se intampla in cazul operatiile neidempotente).
Aceasta semantica este acceptabila atunci cand metodele ID
sunt toate idempotente.
Semantica invocarii at-most-once

Semantica invocarii at-most-once:
In acest caz apelantul fie primeste un raspuns, in cazul in
care apelul s-a executat exact o data, fie o exceptie ce il
informeaza ca nu s-a receptionat nici un rezultat.
Aceasta semantica se poate realiza prin utilizarea tuturor
masurilor de toleranta la defecte. Ca si in cazul anterior,
utilizarea reincercarilor va duce la mascarea erorilor de
omisiune a mesajelor de invocare sau de rezultat. Masurile
aditionale previn erorile arbitrare asigurandu-se ca
pentru fiecare invocare o metoda se va executa cel mult o
singura data.
Semantica Java RMI si CORBA este at-most-once. CORBA
permite folosirea semanticii maybe pentru apelurile care nu
intorc nici un rezultat.
Sun RPC foloseste o semantica at-least-once.
Transparenta RMI
In general, invocarile la distanta sunt similare cu invocarile locale din
punct de vedere sintactic.
Cu toate acestea, invocarile la distanta sunt mai vulnerabile la erori
decat invocarile locale. Indiferent de semantica adoptata, exista
intotdeauna posibilitatea sa nu se obtina nici un rezultat si in cazul unei
erori sa nu se distinga intre o eroare de retea si o eroare in procesul
server. Din acest motiv trebuie ca obiectele care efectueaza invocari la
distanta sa poata recupera din eventualele erori.
Astfel se apreciaza ca diferentele dintre invocarile locale si invocarile la
distanta trebuie sa existe la nivelul interfetelor. Spre exemplu, in Java
RMI, OD se disting prin faptul ca implementeaza interfata Remote.
Ele pot genera exceptii RemoteException.
Implementatorii OD cu interfetele specificate printr-un IDL vor avea in
vedere faptul ca aceste obiecte pot fi accesate concurent de clienti
multiplii, trebuind sa ia masurile de proiectare corespunzatoare.
O alta varianta o reprezinta RMI tranzactional.
Implementarea RMI
Consta dintr-o multime de obiecte si module ce includ:
Modulul de comunicatie
Modulul de gestiune a ROD
Software-ul de RMI, ce contine obiectele proxy, skeleton si dispatcher.
Pe langa aceasta mai trebuie rezolvate urmatoarele probleme: generarea

claselor pentru obiectele proxy, skeleton si dispatcher, partitionarea claselor
intre programul client si programul server, obtinerea de catre client a unei
ROD, folosirea firelor de executie in server, activarea OD, asigurarea
persistentei obiectelor, localizarea obiectelor.
client
object A proxy for B
Request
server
remote
skeleton
object B
& dispatcher
for Bs class
Reply
Communication
Remote
module
reference module
Communication Remote reference

module
module
Modulul de comunicatie si modulul de gestiune a ROD
Modulul de comunicatie:
Existe doua module de comunicatie care interactioneaza cu un protocol RR. Aceste module
vor folosi doar primele trei campuri din cadrul mesajelor de cerere-raspuns: messageType,
requestId si objectReference.
Modulele de comunicatie sunt responsabile sa asigura o anumita semantica, de exemplu atmost-once.
Modulul de comunicatie din server selecteaza obiectul dispatcher corespunzator clasei
obiectului invocat. Pentru aceasta el obtine referinta locala a obiectului de la modulul
pentru referinte la distanta, dupa ce i-a transmis ROD din cadrul mesajului de cerere.
Modulul de gestiune a ROD:

Este responsabil cu traducerea intre referintele locale si ROD si pentru crearea ROD.
Pentru aceasta el gestioneaza o tabela de obiecte la distanta (engl.remote object table)
TOD. Aceasta tabela memoreaza corespondenta intre referintele locale in cadrul procesului
si ROD. Tabela include: i) cate o intrare pentru fiecare OD continut de procesul server; ii)
cate o intrare pentru fiecare obiect proxy local.
Modulul este apelat de software-ul de RMI, cand se impacheteaza sau despacheteaza ROD.
Actiunile acestui modul sunt: i) cand un OD este transmis ca argument sau intors ca
rezultat pentru prima oara, acest modul este interogat pentru a crea o ROD pentru acest
obiect, acest ROD fiind adaugat la tabla; ii) cand se primeste un mesaj de cerere sau
raspuns cu un ROD, modulul este interogat pentru a determina referinta locala
corespunzatoare. Ea poate fi un obiect proxy sau o referinta la OD propriuzis. Daca ROD
nu este in taabela, atunci se creaza un nou obiect proxy si se adauga la tabela.
Software-ul de RMI
Consta dintr-un nivel intermediar intre obiectele aplicatiei si modulele de comunicatie

si gestiune ROD.
Obiectul proxy. Rolul unui obiect proxy este de a face invocarea metodelor la distanta
transparenta pentru client; ele vor delega invocarea catre OD, ascunzand: referirea
OD, impachetarea argumentelor, despachetarea rezultatului si expedierea/receptia
mesajelor. Exista cate un obiect proxy pentru fiecare obiect la distanta referit dintr-un
proces client ce detine o ROD. Clasa obiectului proxy implementeaza metodele ID ale
OD pe care il reprezinta, dar diferit de OD. Fiecare metoda a obiectului proxy
impacheteaza o ROD la obiectul tinta, propriul methodId si argumentele sale intr-un
mesaj de cerere trimis catre server. Apoi asteapta un mesaj de raspuns, despacheteaza
rezultatul si il intoarce obiectului apelant.
Obiectul dispatcher. Un server are un obiect dispatcher (dispecer) si un obiect skeleton
(schelet) pentru fiecare clasa reprezentand un OD. Obiectul dispecer primeste
mesajul de cerere de la modulul de comunicatie si utilizeaza campul methodId pentru
a selecta metoda corespunzatoare din obiectul schelet. Obiectele dispecer si schelet
utilizeaza acelasi methodId pentru metodele ID.
Obiectul skeleton. Obiectul schelet implementeaza metodele din ID. Implementarea
este destul de diferita de cea din OD. O metoda a scheletului despacheteaza
argumentele metodei din mesajul de cerere si invoca metoda corespunzatoare din OD.
Apoi asteapta terminarea invocarii, impacheteaza rezultatul, impreuna cu exceptiile,
intr-un mesaj de raspuns catre mesajul de cerere expediat de obiectul proxy.
Probleme la implementarea RMI (I)
Generarea claselor pentru obiectele proxy, dispecer si schelet. Acest lucru se

realizeaza in mod automat de catre un compilator de interfete. Spre exemplu, in
CORBA interfetele sunt specificate in CORBA IDL si din ele se genereaza cod C++
pentru clasele proxy, dispecer si schelet. In Java RMI, multimea metodelor unui OD
se defineste intr-o interfata Java. Ea trebuie apoi implementata in cadrul clasei OD.
Compilatorul de Java RMI genereaza automat clasele proxy, dispecer si schelet din
clasa corespunzatoare OD.
Programele client si server.
Programul server contine clasele dispecer si schelet, impreuna cu clasele corespunzatoare
tuturor OD gazduite de server (numite si clase servant). In plus, serverul contine si o
sectiune de initializare, de exemplu intr-o metoda main in Java sau C++. Ea este
responsabila cu cu crearea si initializarea cel putin a unuia dintre OD gazduite de server.
OD aditionale pot fi create ca raspuns la cererile clientilor. Sectionea de initializare poate
de asemenea sa inregistreze unele OD cu servicu de nume (engl.binder). In general se
inregistreaza un singur obiect, care va fi folosit sa le acceseze pe celelalte.
Programul client contine clasele obiectelor proxy corespunzatoare OD. Poate folosi servicul
de nume pentru a regasi ROD.
Metode factory. Am aratat ca ID nu pot contine constructori. Acest lucru inseamna ca

OD nu pot fi create prin invocarea la distanta a constructorilor. OD se creaza fie in
sectiunea de initializare a serverului, fie printr-o ID proiectata special pentru aceasta.
Termenul de metoda factory este folosit pentru a indica o metoda de creare a OD. Un
obiect factory este un obiect creat cu o metoda factory. Orice OD care trebuie sa poata
crea noi OD la cerere trebuie sa furnizeze metode in propria ID pentru acest scop.
Probleme la implementarea RMI (II)
Serviciul de nume (engl.binder). In general, programele client necesita o modalitate de

a putea obtine o ROD pentru cel putin un OD gazduit de server. Un serviciu de nume
intr-un SD este un serviciu separat care gestioneaza o tabela cu maparile numelor
textuale ale OD la ROD. Acest serviciu este utilizat de programele server pentru
inregistrarea OD pe care le gazduiesc si de programele client pentru regasirea lor.
Serviciul de nume Java RMI este RMIRegistry, iar servicul de nume CORBA este
CORBA Naming Service.
Fire pe server. Ori de cate ori un obiect executa o invocare la distanta, executia poate
conduce la alte invocari de metode, eventual la distanta, inainte de intoarcerea unui
rezultat. Pentru a se evita ca o invocare la distanta sa provoace intarzieri ale unor
invocari ulterioare din acelasi obiect, in general serverele aloca cate un fir separat
pentru executia fiecarei invocari la distanta in parte.
Activarea OD.
Unele aplicatii cer ca informatiile sa supravietuiaca perioade lungi de timp. Nu este insa
practic ca obiectele ce gestioneaza aceste informatii sa fie mentinute in cadrul proceselor in
executie pentru un timp nelimitat, deoarece ele nu sunt efectiv folosite in tot acest timp.
Pentru a se evita pierderea de resurse datorata executiei continue a serverelor ce gazduiesc
OD, se poate recurge la pornirea acestor servere ori de cate ori acest lucru este cerut de
catre clienti. Procesele care pornesc procese server se numes activatori (engl.activator), de
exemplu serviciul Inetd din Linux.
Un OD este activ cand este disponibil pentru RMI intr-un proces in executie. Altfel el este
pasiv, dar poate fi activat. Un OD pasiv consta din 2 parti: i) implementarea metodelor; ii)
starea sa in forma impachetata.
Probleme la implementarea RMI (III)

Activarea OD. (continuare)
Activarea unui OD consta din crearea unui obiect activ din obiectul pasiv
corespunzator prin crearea unei noi instante a clasei sale si initializarea
variabilelor membre ale sale din starea salvata. Activarea poate avea loc la cerere,
de exemplu cand obiectul este invocat de alt obiect.
Un proces activator are urmatoarele responsabilitati: i) inregistrarea obiectelor
pasive care sunt disponibile pentru activare. Acest lucru presupune inregistrarea
numelor serverelor la URL-urile sau numele fisierelor corespunzatoare obiectelor
pasive; ii) pornirea proceselor server si activarea OD din cadrul lor; iii)
Monitorizarea locatiilor serverelor pentru OD ce au fost deja activate.
In CORBA activatorul se cheama implementation repository. In Java RMI exista
cate un activator pentru fiecare calculator server.
Persistenta obiectelor.
Un obiect care transcede peste activarile/dezactivarile proceselor server se
numeste obiect persistent OP. Un astfel de obiect este in general gestionat de o
memorie de OP MOP care stocheaza starea sa in forma impachetata pe disc.
O MOP gestioneaza un numar foarte mare de OP. Ele sunt activate in momentul
invocarii lor de catre alte obiecte. Activarea este transparenta din punctul de
vedere al obiectului apelant. Cand nu mai sunt necesare in memorie, OP sunt
pasivizate si salvate in MOP. MOP are nevoie de o strategie pentru pasivizarea OP
(de exemplu la sfarsitul unei tranzactii, cand OP au o stare consuistenta, sau la
terminarea programului). MOP realizeaza si o optimizare, salvand doar acele
obiecte care au fost modificate de la ultima salvare.
Probleme la implementarea RMI (IV)
Persistenta obiectelor. (continuare)

MOP permit in general organizarea OP sub forma de colectii cu nume
interpretabile de un agent uman URL sau cale in sistemul de fisiere.
Exista doua abordari pentru a decide daca un obiect este OP sau nu: i) MOP
gestioneaza multimea radacinilor colectiilor de obiecte persistente si orice obiect
care este accesibil dintr-o astfel de radacina este OP. Aceasta abordare este
folosita de Persistent Java. MOP ce folosesc aceasta abordare se bazeaza pe un
colector de gunoaie pentru a elimina obiectele care nu mai sunt accesibile dintr-o
radacina persistenta; ii) MOP utilizeaza clase speciale pe care se bazeaza
persistenta. Un OP apartine unei astfel de subclase. Obiectele care nu mai sunt
necesare trebuie sterse in mod explicit (abordare specifica C++).
Localizarea obiectelor.
In momentul in care un OD ramane in acelasi proces unde a fost creat, pe durata intregului
sau ciclu de viata, ROD bazate pe adresa de IP si numarul portului pot fi folosite pe post de
adresa a obiectului. Dar exista posibilitatea ca un OD sa calatoreasca in diverse procese,
posibil pe calculatoare diferite, in ciclul sau de viata. In acest caz ROD nu mai poate fi
folosita pe post de adresa a obiectului. Clientii acestui OD vor avea nevoie atat de ROD cat
si de adresa OD.
Se poate folosi un serviciu de localizare (engl.location service) pentru localizarea unui obiect
pe baza ROD. El foloseste o tabela care mapeaza ROD intr-o locatie probabila a OD
(probabila deoarece este posibil ca OD poate sa fi migrat intre timp de acolo). Gasirea
locatiei se poate baza pe o schema care combina un mecanism de cache cu un mecanism de
difuzare (engl.broadcast) si poate fi imbunatatita prin folosirea unor pointeri la locatiile
urmatoare (engl.forward location pointer).
Colectarea distribuita a gunoaielor (I)

Scopul unui colector distribuit de gunoaie (engl.distributed garbage collector)
este sa se asigure ca daca o referinta locala la un obiect sau o ROD sunt
pastrate intr-o multime distribuita de obiecte, atunci obiectul respectiv va
continua sa existe, insa imediat ce nu mai exista obiecte care il refera, obiectul
poate fi eliminat si memoria ocupata poate fi eliberata.
Java foloseste un algoritm de colectare distribuita a gunoaielor bazat pe
contorizarea referintelor. Fiecare OD de pe server va trebui informat ori de
cate ori o ROD apare, respectiv nu mai este folosita, intr-un proces client,
prin intermediul unui obiect proxy.
Colectorul distribuit coopereaza cu colectorul local in maniera urmatoare:
Fiecare proces server gestioneaza multimea proceselor client (masini virtuale in
cazul Java) care folosesc o ROD a unui OD al sau (multimea holders a acelui OD).
Ea se poate pastra ca o coloana suplimentara a tabelei de OD din cadrul sau.
Cand un client C primeste pentru prima oara o ROD pentru un obiect particular
B, va face o invocare addRef(B) catre serverul ce contine B si apoi creaza obiectul
proxy. Serverul va adauga apoi pe C la multimea holders a lui B.
Cand colectorul de gunoaie al clientului C observa ca obiectul proxy al lui B nu
mai este accesibil, va executa o invocare removeRef(B). Acest lucru va elimina pe
C din multimea holders a lui B.
Cand multimea holders a lui B devine vida, colectorul local al serverului va
elibera spatiul ocupat de B daca nu exista nici o referinta locala la el.
Colectarea distribuita a gunoaielor (II)

Algoritmul prezentat foloseste o comunicatie cerere-raspuns cu o semantica
at-most-once intre invocarile modulelor de gestiune ROD ale celor doua
procese. Facem observatia ca apelurile suplimentare datorate algoritmului de
colectare nu afecteaza operarea normala a RMI; ele apr doar la crearea,
respectiv eliminarea obiectelor proxy.
Colectorul distribuit Java tolereaza defectele de comunicatie in felul urmator.
Operatiile addRef si removeRef sunt idempotente. Daca addRef genereaza o
exceptie, fapt ce inseamna ca fie a fost exeutata o singura data, fie nu a fost
executata, atunci clientul nu va crea obiectul proxy, dar va executa removeRef.
Daca si removeRef esueaza problema se rezolva prin mecanismul de
inchiriere.
Colectorul distribuit Java tolereaza defectele la client prin mecanismul de
inchiriere (engl.lease). Serverele inchiriaza OD pe care le gazduiesc clientilor
lor pentru o perioada limitata de timp. Este responsabilitatea clientilor sa
ceara reinnoirea inchiriererii in mod explicit. Perioada de inchiriere incepe
atunci cand un client executa o invocare addRef catre server. Inchirierea se
termina fie la o invocare removeRef, fie la expirarea cuantei de timp. Pentru
fiecare inchiriere serverul pastreaza identificatorul masinii virtuale a
clientului si perioada inchirierii.
Ideea acestui model este ca anumite obiecte pot fi instiintate astfel incat sa
reactioneze in cazul unor evenimente receptionate de alte obiecte.
De exemplu, in aplicatiile interactive, anumite actiuni ale utilizatorului
asupra obiectelor interfetei grafice sunt privite drept evenimente care
determina schimbari in obiectele ce mentin starea aplicatiei.
Similar, obiectele care sunt responsabile pentru afisarea unei vederi a starii
curente a aplicatiei sunt instiintate (engl.notified) atunci cand aceasta stare se
schimba.
SD bazate pe evenimente extind acest model astfel incat evenimentele sa poata
avea loc la OD. Ele utilizeaza tehnica de publicare-inscriere (engl.publishsubscribe) sau publicare-abonare.
Obiectele care genereaza evenimente isi publica tipurile de evenimente care pot fi
puse sub observatie de catre alte obiecte.
Obiectele care doresc sa primeasca instiintari de la obiectele generatoare de
evenimente trebuie sa se inscrie la ele pentru tipurile de evenimente de interes.
De obicei tipurile diferite de evenimente se refera la metodele care vor fi apelate la
obiectele receptoare.
Obiectele care reprezinta evenimente se numesc instiintari (engl.notifications).
Atunci cand un obiect generator semnaleaza un eveniment, toate obiectele
inregistrate sa primeasca acest eveniment vor fi instiintate.
Caracteristicile SD bazate pe evenimente

SD bazate pe evenimente au 2 caracteristici:
Eterogenitate. Modelul evenimentelor permite componentelor unui
SD sa lucreze impreuna. Singura cerinta asupra OD este publicarea
tipurilor de evenimente pe care acestea le ofera. Spre exemplu,
modelul evenimentelor se poate folosi pentru conectarea unor
componente eterogene in Internet.
Asincronism. Instiintarile sunt trimise asincron de catre OD
generatoare de evenimente catre toate obiectele interesate. Acest
lucru evita necesitatea ca obiectele generatoare si receptoare de
evenimente sa se sincronizeze intre ele. Un exemplu este un SD
pentru colaborare si lucru in grup. Se pot folosi evenimente pentru a
indica faptul ca un utilizator a intrat sau a parasit un post lucru sau
a modificat un obiect de informatie (de exemplu un document
partajat). Ceilalti utilizatori interesati vor fi instiintati automat.
Arhitectura SD bazate pe evenimente

Event service
subscriber
object of interest
1.
notification
object of interest
2.
object of interest
3.
subscriber
observer
notification
notification
observer
subscriber
notification
Arhitectura urmareste decuplarea obiectelor editor (engl.publisher) de

obiectele abonat (engl.subscriber) astfel incat ele sa poate fi dezvoltate
independent si pe cat posbil sa nu fie foarte incarcate.
Componenta principala este un serviciu de evenimente (engl.event service) care
gestioneaza o baza de date cu evenimentele publicate si interesele abonatilor.
Evenimentele obiectelor editor sunt publicate in cadrul serviciului. Abonatii
informeaza serviciul de tipurile evenimentelor de interes.
La aparitia unui eveniment la unul dintre obiectele de interes, se va trimite o
instiintare abonatilor la acel eveniment.
Rolurile participantilor in arhitectura SD bazate pe evenimente
Obiect de interes (engl.object of interest). Schimbarile de stare ale acestui obiect,

rezultate prin invocarea operatiilor sale, pot fi de interes pentru alte obiecte. Aceasta
arhitectura permite si incorporarea de obiecte de interes externe, cum ar fi o camera
in care intra o persoana prin intermediul unei cartele. Daca un obiect de interes poate
trimite instiintari in mod direct atunci el se considera a fi parte a serviciului de
evenimente.
Eveniment (engl.event). Un eveniment apare la un obiect de interes drept rezultat a
terminarii executiei unei metode.
Instiintare (engl.notification). Este un obiect care contine informatii despre un anumit
eveniment. Contine in general tipul si atributele eveenimentului incluzand identitatea
obiectului de interes, metoda invocata, momentul aparitiei evenimentului sau un
numar de ordine.
Abonat (engl.subscriber). Este un obiect care s-a abonat la un anumit tip de
evenimente ale unui alt obiect si va primi instiintari despre aceste evenimente.
Observator (engl.observer). Scopul principal al unui obiect observator este de a
decupla obiectele de interes de abonati. Ele contin o logica pentru a filtra
evenimentele conform cerintelor exprimate ale abonatilor. Intre un obiect de interes si
abonatii sai se pot interpune mai multi observatori.
Editor (engl.publisher). Este un obiect care declara ca va genera instiintari privind
anumite tipuri de evenimente.
Rolurile obiectelor observator

In principiu, instiintarile pot fi trimise direct receptorilor interesati de catre
obiectele de interes. Aceasta sarcina poate fi insa impartita intre obiectele
observator, ce pot avea urmatoarele roluri:
Inaintarea instiintarilor (engl.forwarding). Un observator cu acest rol va efectua
toate sarcinile de trimitere de instiintari obiectelor abonate in contul unuia sau
mai multor obiecte de interes. Singura sarcina a obiectelor de interes este de a
trimite aceste instiintari catre obiectul observator atasat. El va pasa acestuia si
informatiile referitoare la interesele abonatilor.
Filtrarea instiintarilor (engl.filtering). Un observator poate aplica diverse filtre in
scopul reducerii numarului de instiintari. Un filtru este un predicat care se
evalueaza in functie de continutul unui eveniment.
Sabloane de evenimente. Atunci cand un obiect se aboneaza la evenimentele unui
obiect de interes, el poate specifica sabloanele de evenimente in care este interesat.
Un sablon specifica o relatie intre anumite evenimente. O cerinta similara este
corelarea evenimentelor declansate la mai multe obiecte de interes.
Cutii postale pentru instiintari. Uneori instiintarile trebuie intarziate pana cand
un abonat este gata sa le receptioneze. In astfel de situatii un obiect observator
poate avea rol de cutie postala. Acest rol presupune ca observatorul sa colecteze
instiintarile si sa le trimita abonatului sub forma unui singur lot atunci cand
acesta este pregatit sa le primeasca. Abonatul va trebui sa poata comanda livrarea
instiintarilor de la observator. In momentul inscrierii la obiectul de interes,
abonatul va specifica si cutia postala corespunzatoare.
Java RMI. Concepte
Java RMI extinde modelul obiectual Java pentru a furniza suport pentru SD
obiectuale direct in cadrul limbajului Java.
Java RMI permite invocarea OD folosind aceeasi sintaxa ca si invocarile locale.
Un OD este constient de faptul ca va fi apelat de la distanta, el fiind fortat sa
implementeze interfata Remote.
Un obiect ce realizaeaza o invocare la distanta este constient ca apelul este unul la
distanta, fiind obligat sa trateze exceptiile RemoteException.
Spre deosebire de CORBA, nu este nevoie ca programatorul sa invete un IDL.
Probleme specifice ale Java RMI:
Transferul parametrilor si returnarea rezultatelor

Descaracarea claselor si serviciul de nume (engl.registry)
Construirea programelor client si server
Implementarea Java RMI
Studiu de caz:
Se considera exemplul unei table partajate (engl.shared whiteboard). Este o aplicatie
distribuita care deserveste un grup de utilizatori, furnizandu-le o suprafata comuna de
desenare. Utilizatorii au acces la o vedere comuna a suprafetei, ce prezinta obiectele grafice
desenate (linii, dreptunghiuri, cercuri).
Serverul mentine starea curenta a desenului. El ofera clientilor operatii de informare
asupra ultimelor figuri desenate, gestionand multimea tuturor acestor figuri. Fiecarei
figuri ii este atasat un numar de versiune care se incrementeaza automat de server.
Interfete in Java RMI

import java.rmi.*;
import java.util.Vector;
public interface Shape extends Remote {
int getVersion()
throws RemoteException;
GraphicalObject getAllState()
}
import java.rmi.*;
public interface ShapeList extends Remote {
Shape newShape(GraphicalObject g)
Vector allShapes()
int getVersion()
}
Exemplul prezinta doua ID: Shape si ShapeList. Ambele extind interfata

java.rmi.Remote si metodele lor pot genera exceptii
java.rmi.RemoteException.
Clasa GraphicalObject reprezinta starea unui obiect grafic incluzand:
tipul, pozitia, dreptunghiul inconjurator, culoarea conturului, culoarea de
umplere, daca este sau nu umplut.
Se observa ca se pot transfera si/sau returna ca rezultate obiecte obisnuite,
OD si tipuri primitive.
OD sunt desemnate prin numele ID corespunzatoare.
Metoda newShape() a clasei ShapeList este o metoda factory.
Clasa GraphicalObject
import java.awt.Rectangle;
import java.awt.Color;
import java.io.Serializable;
public class GraphicalObject implements Serializable {
public String type;
public Rectangle enclosing;
public Color line;
public Color fill;
public boolean isFilled;
public GraphicalObject() { }
public GraphicalObject(String aType, Rectangle anEnclosing,
Color aLine,Color aFill, boolean anIsFilled) {
type = aType;
enclosing = anEnclosing;
line = aLine;
fill = aFill;
isFilled = anIsFilled;
}
public void print(){
System.out.print(type);
System.out.print(enclosing.x + " , " + enclosing.y + " , "
+ enclosing.width + " , " + enclosing.height);
if (isFilled) System.out.println("- filled");
else System.out.println("not filled");
}
}
Transferul parametrilor in Java RMI

Orice obiect ordinar care implementeaza interfata Serializable poate fi
transmis ca parametru sau returnat ca rezultat in Java RMI (vezi clasa
GraphicalObject). Toate tipurile primitive si OD sunt serializabile.
Parametrii unei metode se considera implicit parametrii de intrare, iar
rezultatul unei metode este unicul parametru de iesire.
Clasele pentru argumente si/sau rezultate care nu sunt disponibile local se
descarca automat de catre sistemul RMI.
Transferul OD ca paremetrii. Atunci cand argumentele sau rezultatul sunt
OD, atunci ele se transmit ca ROD. Dupa receptionarea unui ROD ca rezultat
al unei invocari, clientul il poate folosi pentru invocari la distanta.
Transferul obiectelor obisnuite. Toate obiectele serializabile se copiaza si se
transmit prin valoare. Efectul acestui proces este crearea unui nou obiect la
destinatar. Invocarea de metode asupra sa poate determina ca starea sa sa
devina diferita de starea obictului initial de la expeditor.
Serializarea argumentelor si rezultatelor are doua particularitati:
Daca obiectul implementeaza interfata Remote el va fi inlocuit cu un ROD.
La serializare se adauga la informatia despre clasa si locatia clasei sub forma
URL-ului corespunzator. Artfel ea va putea fi ulterior descarcata de receptor.
Descarcarea claselor in Java RMI

Java permite descarcarea dinamica a claselor de pe o masina virtuala pe alta.
Acest lucru este util in Java RMI.
In momentul receptionarii unui obiect obisnuit, daca receptorul nu detine
clasa obiectului, o va descarca automat. Similar, daca receptorul unui OD nu
detine o clasa a obiectului proxy corespunzator, o va descarca automat.
Avantajele sunt:
Nu este nevoie ca fiecare utilizator sa gestioneze explicit toate clasele necesare in
propriul mediu de lucru.
Atat clientul cat si serverul pot folosi transparent instante ale unor clase noi, ori
de cate ori sunt adaugate astfel de clase.
Exemplu. Sa prespunem ca implementarea initiala a clasei

GraphicalObject nu permite obiecte grafice de tip text. Atunci un client
care foloseste obiecte text va putea implementa o subclasa a clasei
GraphicalObject si apoi va pasa catre server instante ale acestei clase.
Ceilalti utilizatori vor putea extrage obiecte ale acestei clase cu metoda
getAllState. Codul noii clase se va descarca automat de la primul client
catre server, si apoi de la server catre ceilalti clienti, acolo unde este cazul.
Serviciul de nume Java RMI
RMIRegistry este serviciul de nume (engl.binder) pentru Java RMI. El trebuie sa

ruleze pe fiecare calculator server care gazduieste OD. Acest serviciu gestioneaza o
tabela ce mapeaza numele OD (in stilul URL) la ROD. Accesul la RMIRegistry se face
prin metodele statice ale clasei Naming.
Numele unui OD are forma urmatoare: //numeCalculator:port/numeObiect
Facem observatia ca acest serviciu nu este valabil la nivel de sistem. Clientii trebuie sa
efectueze regasirea explicita a obiectelor pe calculatoarele gazda corespunzatoare
acestora.
void rebind (String name, Remote obj)
Aceasta metoda este utilizata de server pentru a inregistra un OD dupa nume. Rescrie orice legatura
existenta.
void bind (String name, Remote obj)
Aceasta metoda se utilizeaza de server pentru a inregistra un OD dupa nume, cu
exceptia ca daca numele este deja legat la o ROD, se genereaza o exceptie.
void unbind (String name, Remote obj)
Aceasta metoda elimina o legatura..
Remote lookup(String name)
Aceasta metoda este utilizata de clienti pentru a regasi un OD dupa nume. Metoda
intoarce ROD corespunzatpoare acelui OD.
String [] list()
Aceasta metoda intoarce un tablou de siruri de caractere ce reprezinta numele legate la
OD inregistrate in serviciul de nume.
Construirea programului server Java RMI

Serverul va gestiona urmatoarele OD:
Cate un OD pentru fiecare figura, prin implementarea interfetei Shape.
Un OD pentru reprezentarea colectiei de figuri, prin implementarea interfetei
ShapeList.
Serverul contine clasa ShapeListServer ce implementeaza metoda main

si clasele de deservire (engl.servant) corespunzatoare celor doua ID.
Clasa ShapeListServer cu metoda main(). Aceasta metoda creaza un obiect
servant pentru colectia de figuri si il inregistreaza la serviciul de nume.
Cele doua clase de deservire pentru Shape si ShapeList sunt ShapeServant
si ShapeListServant. Aceste clase extind clasa
java.rmi.server.UnicastRemoteObject, ce furnizeaza o implementare
predefinita pentru OD ce au durata de viata identica cu cea a procesului care le-a
creat.
Metoda main() a serverului creaza un manager de securitate a codului Java.

El este necesar pentru a permite aplicarea protectiilor de securitate specifice
unui server RMI. Acestea presupun: clasele descarcate nu pot afecta resursele
locale ale sistemului (de exemplu fisiere), dar permit programului sa-si
instaleze propriul incarcator de clase ca rezultat al invocarilor la distanta.
Clasa ShapeServer
import java.rmi.*;
public class ShapeListServer {
System.setSecurityManager(new RMISecurityManager());
System.out.println("Main OK");
try {
ShapeList aShapelist = new ShapeListServant();
System.out.println("After create");
Naming.rebind("ShapeList", aShapelist);
System.out.println("ShapeList server ready");
} catch(Exception e) {
System.out.println("ShapeList server main " +
e.getMessage());
}
}
}
Clasa ShapeServant
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
public class ShapeServant
extends UnicastRemoteObject implements Shape {
int myVersion;
GraphicalObject theG;
public ShapeServant(GraphicalObject g, int version)
throws RemoteException{
theG = g;
myVersion = version;
}
public int getVersion() throws RemoteException {
return myVersion;
}
public GraphicalObject getAllState() throws RemoteException {
return theG;
}
}
Clasa ShapeListServant
import java.rmi.*;
import java.rmi.server.UnicastRemoteObject;
public class ShapeListServant
extends UnicastRemoteObject implements ShapeList {
private Vector theList;
private int version;
public ShapeListServant() throws RemoteException {
theList = new Vector();
version = 0;
}
public Shape newShape(GraphicalObject g) throws RemoteException {
version++;
Shape s = new ShapeServant(g,version);
theList.addElement(s);
return s;
}
public Vector allShapes() throws RemoteException {
return theList;
}
public int getVersion() throws RemoteException {
return version;
}
}
Construirea programului client Java RMI

Dupa ce instaleaza un manager de securitate, un program client va utiliza un
serviciu de nume pentru a localiza un OD.
Dupa ce a obtinut o referinta initiala la un OD, el va putea efectua invocari la
distanta asupra acestui OD.
Invocarile pot continua pe masura ce clientul descopera noi OD. Metodele
invocate anterior pot intoarce noi astfel de referinte.
In exemplul nostru, invocad metoda allShapes asupra unui ShapeList,
se va returna un vector de obiecte Shape ale caror metode pot fi invocate
ulterior.
Daca clientul nostru ar implementa o interfata grafica a tablei partajate, el va
putea utiliza metoda getAllState a unui obiect Shape pentru a determina
aspectul grafic al figurii respective, astfel incat sa o poata afisa pe ecran. Apoi,
cand clientul va crea o noua figura, el va apela metoda newShape in server,
transmitand informatia despre figura creata.
Clientul va gestiona ultimul numar de versiune de la server. Interogand din
cand in cand serverul cu getVersion, el va putea determina cand s-au facut
adaugari ale unor noi figuri, astfel incat sa se actualizeze in mod
corespunzator desenul din interfata grafica.
Clasa ShapeClient
import java.rmi.*;
import java.rmi.server.*;
public class ShapeListSmallClient {
System.out.println("option = " + option + "shape = " + shapeType);
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
else
System.out.println(
"Already has a security manager,so cant set RMI SM");
ShapeList aShapeList = null;
try {
aShapeList = (ShapeList) Naming.lookup("//localhost/ShapeList");
Vector sList = aShapeList.allShapes();
} catch(RemoteException e) {
System.out.println("allShapes: " + e.getMessage());
} catch(Exception e) {
System.out.println("Lookup: " + e.getMessage());
}
}
}
Apeluri inverse in Java RMI
In loc de a proiecta clientii astfel incat ei sa interogheaze periodic serverul

(engl.polling), se poate concepe un mecanism prin care serverul sa instiinteze automat
clientii ori de cate ori apare un eveniment de interes. Pentru aceasta se pot folosi
apeluri inverse (engl.callbacks).
Apelurile inverse se pot implementa in Java RMI astfel:
Clientul creaza un OD cu o interfata ce contine o metoda ce va fi apelata de catre
server. Un astfel de obiect se numeste obiect de apel invers (engl.callback object).
Serverul furnizeaza o metoda prin care clientii interesati il pot informa asupra
ROD ale obiectelor de apel invers corespunzatoare lor. El va inregistra aceste
obiecte intr-o lista. Observatie: un obiect de apel invers este similar cu un obiect
ascultator (engl.listener) din Swing.
La aparitia unui eveniment de interes, serverul va instiinta in mod direct clientii
interesati, pe baza acestei liste.
Aceasta metoda inlatura cele doua dezavantaje ale tehnicii de polling:
i) supraincarcarea serverului prin interogarea lui repetata
ii) neinstiintarea la timp a clientilor de schimbarile aparute
Problemele apelurilor inverse sunt:
i) uneori clientii nu instiinteaza serverul ca parasesc sistemul. Pentru aceasta se
poate folosi tehnica inchirierii (engl.leasing).
ii) Serverul trebuie sa efectueze apeluri RMI catre obiectele de apel invers.
Datorita faptului ca aceste apeluri sunt sincrone, pot apare probleme.
Exemplu cu apeluri inverse in Java RMI

Se poate defini o interfata pentru apeluri inverse pentru aplicatia cu
tabla partajata:
public interface WhiteboardCallback implements Remote {
void callback(int version) throws remoteException;
}
Interfata se implementeaza ca OD de catre client. Serverul va trimite

clientului un numar de versiune, ori de cate ori se adauga o noua figura
pe tabla. Pentru aceasta, interfata ShapeList necesita doua noi
metode: register() si deregister(), definite astfel:
int register(WhiteboardCallback callback)
void deregister(int callbackId)
Clientul va obtine o ROD la OD ce reprezinta lista de figuri, va crea un

OD de apel invers ce implementeaza interfata WhiteboardCallback
si apoi va apela metoda register() a OD de pe server, transmitand
ca parametru obiectul de apel invers creat.
La sfarsitul executiei, clientul trebuie sa informeze serverul ca
paraseste sistemul executand metoda deregister().
Pasii de realizare a unei aplicatii Java RMI

1.
2.
3.
Scrierea si compilarea codului pentru interfetele Java. Am considerat o

aplicatie foarte simpla pentru implementarea unor operatii matematice.
Aceste operatii sunt descrise in interfata Calculator.
Scrierea si compilarea codului pentru clasele Java ce implementeaza
interfetele de la punctul anterior (asa numitele clase de deservire). Pentru
exemplul considerat clasa de deservire este CalculatorImpl.
Generarea claselor proxy (se cheama si stub in Java RMI) si schelet. Se
foloseste compilatorul RMI integrat in JDK:
>rmic CalculatorImpl
4.
5.
6.
Scrierea si compilarea codului pentru serviciul Java care va gazdui OD. In

exemplul nostru, aceasta este clasa CalculatorServer.
Scrierea si compilarea codului pentru aplicatia client. In exemplul nostru,
aceasta este clasa CalculatorClient.
Instalarea si rularea sistemului RMI. Presupune:
Pornirea serviciului de nume RMIRegistry:
>rmiregistry& sau start rmiregistry
Pornirea serverului:
>java CalculatorServer sau start java CalculatorServer
Pornirea clientului:
>java CalculatorClient

Limbă

Programare in Internet

Încărcat de

Informații document

Descriere:

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?

Descriere:

Drepturi de autor:

Formate disponibile

Programare in Internet

Încărcat de

Descriere:

Drepturi de autor:

Formate disponibile

Internet.

Internet-ul poate fi descris ca un sistem deschis. Prin sistem

Scurt istoric al Internet-ului

Crearea Internet-ului a fost declansata de proiecte de cercetare din cadrul armatei US

Nivelul legaturii de date

Internet-ul este o retea de sub-retele.

Corespondena nivelurilor TCP-IP i

Protocoale ale retelei Internet

Telnet protocol ce permite accesul la distanta la un calculator conectat la Internet, cu

Sistemul de numire a domeniilor in Internet

DNS = o modalitate de a denumi simbolic calculatoarele dintr-o retea bazata pe

Determinarea adresei IP pornind de la nume

Servere de fisiere. Furnizeaza fisiere la cererea clientului; spre exemplu un depozit

Middleware este un term destul de vag ce se refera in general la toate nivelurile

Arhitecturi multistrat (engl.tiered architectures)

O aplicatie distribuita este compusa dintr-o multime de programe care ruleaza pe

Avantaj: straturile permit separarea elementelor enumerate mai sus

Clasificarea arhitecturilor multistrat

1 strat (engl.one tier)

Protocol = un set de reguli care guverneaza schimburile de mesaje intre

Pentru a afla pretul unui anumit model, clientul trimite mesajul:

Un exemplu de protocol: POP3

Paradigme de programare distribuita

Modelul transferului de mesaje (I)

Se bazeaza pe ideea de protocol. Acesta poate fi gandit ca un limbaj ce

Modelul transferului de mesaje (II)

Modelul obiectelor distribuite

Se numeste obiect distribuit un obiect rezident pe un calculator care poate fi invocat

Magistrala de obiecte (I)

Modelul evenimentelor este folosit si in arhitecturile de tip magistrala de obiecte

Magistrala de obiecte (II)

Exista doua mari clase de arhitecturi de tip magistrala de obiecte:

Arhitectura butuc si spite

Avantaje: usor de implementat folosind socket-ui sau RMI, contabilizarea poate fi

Dezavantaje: se genereaza un volum mare de trafic comparativ cu magistralele cu

A fost folosit in limbajul de programare de nivel inalt Linda, dezvoltat de

Spatiile sunt containere de obiecte cu urmatoarele proprietati:

World Wide Web

Viziunea viitoare asupra WEB

Automatizare: oameni, programe

Evolutie sisteme: centralizat

Evolutie sisteme: Client-Server

Evolutie sisteme: Peer-to-Peer

Evolutie sisteme: Cooperative

Evolutie similara la nivelul retelelor

Sisteme deschise: caracteristici

Sisteme deschise si Web pragmatic

Ce este World Wide Web ?

WWW este un sistem hipermedia distribuit. Se bazeaza pe un model de structurare a

Scurt istoric al WWW

WWW s-a nascut in lumea academica, la Laboratorul european de fizica

Identificarea resurselor in WWW

Pentru identificarea resurselor in WWW se foloseste un URL (engl.Uniform

Este protocolul de comunicare intre clientii si serverele WWW. El specifica

Cererile si raspunsurile HTTP se mai numesc si mesaje. Un mesaj este un sir de

Cereri si raspunsuri HTTP

Raspunsuri Linia de start se numeste linie de stare (engl.status line).

Sintaxa formala a unei cereri HTTP

HTTP 1.0 este descris la nivel informativ in documentul RFC 1945.

linie-de-cerere = metoda spatiu uri spatiu versiune-http sfarsit-de-linie