Ghidul managerului pentru noile tehnologii informatice si de comunicatie

Introducere1
În volumul intitulat „Ghidul managerului pentru noile tehnologii informatice şi
de comunicaţie”2, elaborat de aceiaşi autori, care a apărut în editura Lucman în
noiembrie 2002, am vizat în partea a cincea doar o prezentare frugală a
tehnologiei ASP. Am acordat mai multă atenţie XML.
Aici vom avea în vedere aplicaţii elaborate cu trei tehnologii: JSP, ASP şi PHP,
deci ne vom întâlni şi cu limbajele respective.
Ideea că un sit comercial poate fi realizat doar cu ajutorul pachetului Microsoft
FrontPage este greşită din start. Un sit comercial este mult mai complex decât un sit
obişnuit. Şi el se bazează pe unul dintre limbajele de tip script, deci pentru scenarii:
Java, JavaScript, VBScript, JScript, PHP sau PERL (Practical Extraction Report
Language), PerlScript.
PHP şi PERL merg pe filozofia Common Gateway Interface. Acest CGI se bazează pe
un formular completat de vizitator dar atenţie, pentru fiecare client Web care accede un
sit elaborat cu PHP sau PERL, se încarcă în memoria serverului atât programele cât şi
câte o copie a interpretorului. Este o risipă de memorie!
ASP şi JSP au schimbat puţin filozofia CGI. Avem tot timpul să vă lămurim cum!
Stimate manager, veţi fi nevoit să citiţi această carte sau să apelaţi la un cunoscător al
unuia din aceste limbaje. Oricum, vă mai trebuie ceva bani pentru achiziţionarea unui
mediu de dezvoltare serios (vezi mai jos, medii IDE) şi pentru un pachet software pentru
administrarea bazelor de date.
Java şi VBScript sunt limbajele de bază ale tehnologiilor JSP, Java Server Pages şi
respectiv ASP, Active Server Pages.
Medii IDE pentru proiectarea siturilor comerciale
Mai oportun este ca situl comercial să se realizeze cu ajutorul unui mediu de dezvoltare
aşa-zisul IDE, Integrated Development Environment. Un astfel de mediu are
1

Cursul « Aplicaţii de comerţ electronic şi tehnologii » predat de profesorul dr. Somnea Dan, la
facultatea R.E.I. an II, din anul 2002/2003 în locul cursului de Internet.

2
Puteţi comanda la editura Lucman (tel./fax: 021-223-7755, sau ) un exemplar.
Editura are depozitul la adresa: Bucureşti, str. Sevastopol nr.24. Mai sunt cca- 30 exemplare. Dacă
lucrarea s-a epuizat, sunteţi trecut în lista de aşteptare. Rotativa se porneşte dacă se adună cel puţin
300 comenzi ferme. Până acum s-au scos două tiraje, unul de 250 (sept. 2002) şi al doilea de 330
exemplare (nov. 2002). Urmează ca în luna sept. 2003 să se scoată un număr de cca. 350 exemplare,
plus câte comenzi ar apare între timp. Exemplarele au fost destinate în principal formelor de
învăţământ de zi şi distanţă, pentru facultatea R.E.I. Au fost şi cumpărători izolaţi care au ... apucat
cartea, pentru că ştiau de aceşti autori de la editura tehnică, când publicau acolo.


instrumente pentru crearea unui proiect, scrierea programelor, depanarea lor (punerea la
punct) . Programele sunt componentele sitului.
Există medii care sunt orientate spre suprafeţe grafice. Iată câteva denumiri: Allaire
JRun Studio, Apache Tomcat Servlet and JavaServer Pages Development with
VisualAge for Java, Borland /Inprise JBuilder, Microsoft Visual InterDev, seria de
servere .net Microsoft Entreprise (vezi mai jos), Macromedia Dreamweaver MX etc.
Containere pentru servleturi/pagini JSP alias servere de aplicaţii Web

Ca să dezvoltaţi şi să testaţi un sit comercial trebuie şi o reţea de PC-uri pentru încercare.
Ultima condiţie este extrem de greu de simulat. De aceea s-au scris diverse simulatoare
de încercare pentru a afla cum se comportă situl la diverse trafice de încărcare şi condiţii
de reţea.
Pentru producţia de situri comerciale dinspre platforma JSP sunt containerele pentru
servleturi şi pagini JSP: Allaire JRun, Apache Tomcat, BEA Weblogic Entreprise
Server, iPlanet Web Server Entreprise Edition, Sun NetObject, IBM WebSphere
Application Server, Oracle Application Server, Inprise Application Server.
Lumea serverelor Microsoft .Net Entreprise şi Visual Studio

Dinspre platforma ASP cităm strategia materializată de Microsoft Distributed Network

Architecture, adică arhitectura unui sistem distribuit de la corporaţia cu acelaşi nume, ce
a stat la baza unei serii de zece servere plus serverul Windows 2000.
Despre aceste servere nu putem emite pretenţii de a le avea în A.S.E.! Instrumentul de
dezvoltare al acestora a fost precis mediul IDE Microsoft Visual Studio InterDev!
Sunt în total vreo zece servere. Pentru alte detalii, vezi şi Epilog şi referinţa /8/, o
documentaţie plină de fraze ditirambice, aşa cum sunt majoritatea comunicărilor şi
broşurilor celor care caută să se facă înţeleşi posibililor lor consumatori de produse
software. Pentru conformitate redăm o mostră de frază: « Microsoft Commerce Server
2000 permite afacerilor ?! din diferite domenii construirea de soluţii e-commerce
scalabile (Sic !) personalizate, care optimizează experienţa clientului şi le oferă
managerilor un timp real (hopa !!!) de analiză şi control al afacerilor online. » Spuneţi şi
dumneavoastră domnule profesor Pruteanu ce ditrambi sunt aceşti … ! Aţi înţeles
ceva stimaţi actuali şi posibil viitori manageri? Să ştiţi că nu învinuim pe traducător ci,
pe creatorii unor atari fraze cu salarii sfidătoare. Dar mai bine să ne oprim ! Şi ce este
mai grav este că cei îndrituiţi a-şi face publică « marfa », îşi bat joc de munca celor care
concep aceste produse software din interiorul corporaţiei Microsoft !
Iată deci o veritabilă dilemă pentru un potenţial administrator de sit comercial ca …
lumea! Nu este cazul să fiţi dezorientaţi!
Să revenim pe pământ !

Ca să aflaţi ceva despre efortul de realizare al unui sit comercial mai nepretenţios,
încercaţi să parcurgeţi acest manual, jumătate scris în limba română şi jumătate în limba
franceză.


În capitolele scrise în limba română ne ocupăm de tehnologiile JSP şi ASP, plecând de
la instrumente freeware fără a avea acces la pachetul Macromedia Dreamweawer MX.
Capitolele scrise în limba franceză constituie o parte din cursul predat studenţilor
economişti de către profesorul dr. Mihai Calciu la Universitatea Lille I şi, care are în
vedere tocmai acest pachet alături de aplicaţiile EasyPHP, phpMyAdmin sub Windows

şi mai ales Linux.
Afirmam mai sus ceva legat de acel soft pentru bazele de date. Fiecare din siturile
comerciale trebuie să apeleze la baze de date. Deci trebuie să aveţi în vedere ca
programatorul pe care îl angajaţi să mai ştie şi unele comenzi ale limbajului de
interogare structurat, SQL, Structured Query Language.
Dacă vreţi să recurgeţi la tehnologia PHP, deci şi la limbajul mySQL (tot SQL),
examinaţi şi referinţa /5/, dar mai ales să aruncaţi un ochi în capitolele scrise în franceză
din această carte.
Pentru partea dedicată tehnologiei ASP parcurgeţi capitolele 7-10, unde am explicat un
exemplu de sit comercial testat în stadiul preliminar şi care poate fi îmbunătăţit.
Pentru o privire asupra fiecăreia dintre tehnologiile JSP, ASP şi PHP, bazate pe
Macromedia Dreamweaver MX, citiţi şi capitolele din partea a doua. În ce ne priveşte,
în A.S.E. nu avem acces la Dreamweaver şi ne mulţumim şi cu ce avem. Şi avem unele
instrumente din platforma Windows!
Am fi avut mai multe şi pe partea de dezvoltare a aplicaţiilor de e-commerce, dacă am fi
acceptat instalarea pe staţiile din laboratoarele studenţeşti a unuia dintre dialectele Linux
în varianta WorkStation, de pildă Suse, cu o suprafaţă grafică KDE!
În partea dedicată prezentării tehnologiei JSP veţi afla că, cu modestul cadru de
dezvoltare (se foloseşte termenul kit în engleză) J2SE, Java 2.0 Standard Edition al
corporaţiei Sun MicroSystems, cu un container pentru servleturi şi pagini JSP Resin
1.1.4 sau JRun Standard 3.0, ambele cu regim de freeware, fără drept de folosire pentru
producţia de situri comerciale aducătoare de profit şi, cu un programator cunoscător al
limbajului Java, înzestrat cu multă răbdare, puteţi încropi un sit comercial. Pentru acesta
citiţi capitolele 1-6.
Între pachetele cu funcţia de container pentru servleturi şi pagini JSP cităm în primul
rând pe Jakarta Tomcat. Un serios concurent este însă JRun, al firmei Allaire în două
variante: Standard şi Studio. Ultimul este pe bani! Primul este shareware! Vezi şi mai
jos.
Tehnologia JSP a fost şi este dezvoltată cu asiduitate de corporaţia Sun Microsystems,
în timp ce tehnologia ASP este opera celor de la Microsoft.

Cadrul de lucru J2SE se poate descărca de la adresa: />Mai indicat este însă să procuraţi ediţia Entreprise a aceluiaşi cadru şi anume J2EE.
Aceasta este însă distribuită sub licenţă cu prealabila perioadă de testare (shareware).
Atât J2SE cât şi J2EE nu folosesc suprafaţa grafică. Tot atunci se instalează automat şi o
bibliotecă de pachete cu clase Java, denumită JRE, Java Runtime Environment, adică


maşina virtuală Java, Java Virtual Machine (vezi capitolul 1). Există câte un JRE pentru
fiecare cadru de lucru.
Cadrele de lucru J2SE şi J2EE mai sunt denumite şi SDK 2 Standard Edition, respectiv
pentru SDK 2 Entreprise Edition.
Versiuni de motoare servlet

Recomandăm în ordine pe: Tomcat. Acesta a ajuns la versiunea 5. Merg foarte bine şi
versiunile mai vechi 3.1 sau 3.2, care au regimul de licenţă deschisă.
Există apoi aplicaţia firmei Caucho Technologies denumită Resin. Prin anul 2000 a fost
o versiune distribuită sub licenţă deschisă cu numărul 1.1.4. Pe aceasta o vom
implementa pe staţiile studenţeşti din corpul 1000, etajul 4. Pachetul este creaţia lui
Ferguson Scott. Dacă aţi vizita portalul www.Caucho.com aţi constata că versiunile mai
noi sunt pe bani cu trecere prin perioada de evaluare.
În sfârşit, compania Allaire posedă pachetul JRun (versiunile Standard şi Studio).
Regimul de open source nu are decât versiunea 3.0 standard. Intraţi şi la:
ca să vă convingeţi că totul este acum shareware deci pe bani!
Pentru a crea cu trudă un sit în ASP, recurgem la Microsoft FrontPage, MS Access,
editorul wordpad şi cam atât!
Ar fi fost mai bun Microsoft Visual InterDev. Nu emitem pretenţii la Microsoft SQL
Server în loc de MS Access.
Acasă aveţi de regulă Windows 98. Sub acesta există Microsoft Personal Web Server,
versiunea a patra. Sub Windows 2000 Workstation Professional, dacă îl aveţi, se recurge
la Microsoft Information Internet Server 5.0. IIS a apărut pe vremea sistemului
Windows NT/4 varianta Server. IIS nu este acceptat şi de Windows NT/4 Workstation!

Din păcate toate acestea nu suportă servleturi Java, decât dacă cumpăraţi de la firmă
adausurile de rigoare! Folosesc însă cu dezinvoltură limbajul VBScript şi obiectele
ActiveX Data, ADO. ActiveX este dezvoltat după modelul obiectelor din componente,
COM, Component Object Model. Acest ActiveX căruia în „romgleză” i se spune
„controale ActiveX” este accesibil atât pe partea client (deci MSIE, nu şi Netscape) cât
şi pe partea de server.
Insistăm! Sub browserul Netscape obiectele ActiveX sunt ignorate!
Înainte de a trece mai departe, Windows 98 etc. permit instalarea motorului Caucho
Resin 1.1.4.
Dar ce oferă alţii în materie de motoare servlet?

Începem cu AOL / Netscape. Până de curând a tronat Netscape Java Web Server ca
server Web. El a fost înlocuit însă de către mai noul iPlanet Web Server Entreprise
Edition. Acesta a înlocuit şi un alt server Web de la Netscape, denumit Netscape
Entreprise Server.


Există piese software şi pentru platforme Unix, AIX/Linux. Despre aceste platforme
vezi referinţa /2/. Sub Linux tronează Tomcat.
Pro XML!

Toate browserele se „feresc să rămână în urmă” şi încearcă să se alinieze la standardul şi
limbajul XML şi la standardele XSL, XLST, Xpath etc. în mod tot mai hotârît. Conduc
detaşat doar editorul/browserul Mozilla de la NCSA şi total necunoscutul editor/browser
InDelv de la www.indelv.com. Sunt singurele care se descurcă în XSLT, adică XLS
Transformations.
Nici nu îndrăznim a vă indica să procuraţi şi răsfoi o altă referinţă de peste 800 pagini,
cu fraze întortocheate, chiar din limba în care a fost concepută, engleză. Este totuşi o
muncă meritorie şi enormă depusă de către doamna sau domnişoara Lee Anne Phillips,
un exeget în materie de documentare asupra standardelor XML / XHTML. Este vorba

de: XML, XPath, XLink, Xpointer, de limbajele de stil, precum: CSS1, CSS2, DSSSL,
XSL, XSLT. Cartea s-a numit în original „Special Edition Using XML” şi a fost tradusă
la editura Teora sub denumirea de XML. A apărut la editura americană QUE, în anul
2000 iar la noi, un an mai târziu. Bravii noştri traducători nu au descâlcit şi unele fraze
prea lungi din lucrarea originală! What a pitty!
Am presupus poate greşit că aţi răsfoit referinţa /1/, pag. 208-233. Aţi fi aflat destule
despre folosirea intensă a limbajului XML în schimburile electronice de documente
finanicar-contabile dintre verigile implicate în tranzacţii din siturile: B2B, B2C, C2C.
Vezi totuşi şi partea a doua din limba franceză.
Pentru ai fi independenţi întrucâtva de referinţa /1/ am alcătuit anexa A. Aici tratăm
HTML, DHTML şi o scurtă iniţiere în XHTML, ca să depăşim această referinţă. În
IT&C intervalul de timp ideal pentru actualizarea documentaţiilor este semestrul! Anul
este … prea lung!
Să pornim la drum într-o manieră cât de cât metodică.

Convenţiile de scriere
Textul obişnuit este cules cu acest set de caractere (font). Listele de programe sunt
culese cu acest corp de literă:
<html>
<head><title>Razboiul din Irak!</title>

când nu sunt numerotate sau aşa:
01. <html>
02. <head><title>Razboiul din Irak!</title>

când sunt numerotate.
Procedeele de operare sunt anunţate prin pictograma alăturată.
Observaţiile importante sunt anunţate prin pictograma alăturată

1

Capitolul

Universul termenilor platformei
Java
Vom explica pe înţelesul dumneavoastră o serie de termeni din universul Java.
Au trecut destul de mulţi ani de când acest limbaj concurează cu deosebit succes
familia de limbaje C/C++. Java este adulat şi de către IBM et. Co, în ciuda
efortului venerabilei corporaţii Microsof. Din cauza proliferării unui număr
imens de pachete de clase şi componente, se poate spune că Java îşi trăieşte a
doua tinereţe, acum în perioada programării orientate spre componente.

Client Web şi server Web

A

şadar să intrăm în universul termenilor platformei Java!

Să adâncim faţă de referinţa /1/ două noţiuni şi anume, cea de client Web şi cea
de server Web. Două calculatoare comandate fiecare de câte un program,
comunică între ele. Unul dintre programe serveşte la răsfoirea spaţiului Web. I se mai
spune program de vizitare, de navigare. Cine nu a folosit Microsoft Internet Explorer
(MSIE)! Acestuia să îi spunem client Web sau browser.

Pe celălalt calculator, gazdă a sitului vizitat, se află un alt program denumit server Web.
El este specializat în executarea programelor scrise într-unul din limbajele pentru
scenarii.
Să complicăm puţin lucrurile! Există şi un server Web dar poate exista şi un aşa-zis
server de aplicaţii Web. I-am spus mai sus motor servlet.

Deşi tratăm tehnologia JSP, admiteţi o paranteză! În tehnologia ASP, serverul MS IIS
este şi gazda aplicaţiilor. Acest IIS „interpretează” pe loc instrucţiunile programelor cu
extensia .asp, componente ale unei aplicaţii şi generează dinamic un document tip html
care ajunge la PC-ul gazdă a browserului MSIE. Terminat paranteza!
Aici este vorba însă de tehnologia JavaServer Pages. Serverul de aplicaţie poate prelua
şi sarcina serverului Web clasic, pe lângă aceea de container pentru servleturi. Mai poate


să se întâmple însă şi aşa: să trimită serverului Web clasic servleturile ca să le
gestioneze, adică să le pună la dispoziţia cererilor clienţilor Web. Oricum, serverul de
aplicaţii are în această a doua ipostază doar funcţia producător de servleturi.
Protocolul http şi dialogul dintre client Web – server Web. Lanţul …
slăbiciunilor !

Spuneam mai sus că serverul Web dialoghează cu clientul Web pe baza unui protocol.
Cel mai adesea acesta este http. Acesta nu este legat de servleturi. Vizitatorul vede pe
ecranul PC-ului gazdă a browserului MSIE un formular. Cum credeţi că a apărut el aici?
A fost generat de către programul servlet. Vizitatorul completează datele în rubricile
formularului. Ele pleacă la server, când s-a recurs la butonul pentru trimitere. Datorită
unui alt program dinainte proiectat şi anunţat în servlet, ce este asociat acestui formular,
se analizează aceste date şi se construieşte răspunsul. El este expediat înapoi la clientul
Web tot sub forma unui document generat în HTML.
Acest schimb de replici client – server respectă oricum protocolul http deci formatul
HyperText Transport Protocol, care nu ne interesează pe noi nespecialiştii IT!
În lumea browserelor şi … din nou obsesia XML!

Apropo, pe lângă programul de navigare (sau vizitare) browser MSIE, se folosesc cu
aplomb şi altele cum sunt: Netscape Navigator sau Communicator. Poate aţi auzit şi de
NCSA Mozilla sau venerabilul NCSA Mosaic. Ultimul este opera celor de la Centrul
pentru Arhitecturi de Supercomputere al Universităţii Minnesota, Illinois. La NCSA,

(National Center for Supercomputing Architecture) cu un deceniu în urmă, Mark
Andersen a conceput şi elaborat Mosaic. Era primul browser grafic. Mai înainte Tim
Berners Lee a conceput Viola, un browser de tip text orinetat spre emultaor de terminal
VT-xxx. Studenţii din anii terminali, urmaşii lui Mark, dezvoltă cu dezinvoltură în
referatele lor, nucleul unei noi versiuni de browser denumit Mozilla. Este aliniat la
standardul XML 1.0! Cunoaşte şi interpretează corect structurile acestui limbaj extins
pentru marcaje, eXtensible Markup Language şi chiar şi şabloanele limbajului de stiluri,
XSL, eXtensible StyleSheet Language.

Ce este XSL?
Să zicem că am descris în XML (vezi şi: /1, 2, 9, 16/) un articol de revistă şi descrierea
arată astfel:
LISTA 1.1 Aspectul documentului de intrare (scris în XML)

01.
02.
03.
04.
05.
06.
07.
08.
09.

<?xml version=”1.0”>
<article fname=”19990101_xsl”>
<title>XML Style Sheets</title>
<date>January 1999</date>
<copyright>1999, Benoit Marchal</copyright>
<abstract>Style sheets add flexibility to document viewing.</abstract>

<keywords>XML, SXL … </keywords>
<section>
<title>Styling</title>


10. <section>
11.

Style sheets are inherited form SGML, an XML ancestor. Style sheets
originated in publishing and document management applications. XSL is XML’s
standard style sheet, see <url> />12. </section>
13. <section>
14. <title>How XSL Works</title>
15.

An XSL style sheet is a set of rules where each rule specifies how to format
certain elements in the document. It has rules for title, paragraphs and
keywords.

16.

With XSL, these are powerful enough not only to format the document but
also to reorganize it, e.g. by moving the title to the front of page or extracting
the list of keywords. This can lead to exciting applications of XSL outside the
realm of traditional publishing. ...

17. </section>
18. <section>
19. …
20. </section>
21. </article>

Am reprodus o parte din exemplul clasic al lui Benoit Marchal (referinţa /9/) care l-a
pasionat tocmai acest XSL şi XSLT mai mult decât XML în sine. Observaţi o serie de
balize inventate pentru descrierea componenţei unui articol. E vorba de titlul articolului
(liniile 02 şi 03), de data apariţiei sale (linia 04) etc. Mai jos vedem baliza abstract care
înfăşoară conţinutul (liniile 06 şi 21), de o serie de titluri de secţiuni şi de secţiunile în
sine. În fine intrăm şi pe teritoriul oarecum al HTML, unde apar balize pentru paragrafe,

deci pentru frazele textului.
Acum să presupunem că dispunem de un procesor XT, cum este cel al lui James Clark,
vezi /14/, care citeşte la intrare documentul de mai sus de tip XML. Procesorul are un
transformator XSL, deci un XSLT. Acesta foloseşte un limbaj cu instrucţiuni în toată
regula! Iată pentru cazul nostru acest transformator de aspect de document:
LISTA 1.2 Instrucţiunile de transformare (scrise în limbaj XSLT)

01. <?xml version=”1.0” encoding=”ISO-8859-1”?>
02. <xsl:stylesheet xmlns=” />xmlns=” />03. <xsl:output method=”html”/>
04. <xsl:template match=”/”>
05. <HTML>
06. <HEAD>
07. <TITLE>About Style Sheets</TITLE>
08. </HEAD>
09. <BODY>
10. <xsl:apply-templates/>
11. </BODY>
12. </HTML>
13. </xsl:template>
14. <xsl:template match=”section/title”>
15. <P><I><xsl:apply-templates/></I></P>
16. </xsl:template>
17. <xsl:template match=”article/title”>


18.
19.
20.
21.
22.

23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.

<P><B><xsl:apply-templates/></B></P>
</xsl:template>
<xsl:template match=”url”>
<A TARGET=”_blank”>
<xsl:attribute name=”HREF”>
<xsl:apply-templates/>
</xsl:attribute>
<xsl:apply-templates/>
</A>
</xsl:template>
<xsl:attribute name= ”HREF”>mailto :<xsl :apply-templates/>
</xsl:attribute>
<xsl:apply-templates/>
</A>

</xsl:template>
<xsl:template match=”p”>
<P><xsl:apply-templates/></P>
</xsl:template>
<xsl:template match=”abstract | date | keywords | copyright”/>
</xsl:stylesheet>

Pe scurt ce se realizează mai sus! A fost scris conform regulilor limbajului XSLT un
grupaj de instrucţiuni de comandare a procesorului XSLT. Priviţi documentul iniţial.
Acolo am întâlnit categoriile sintactice: article/title adică titlu de articol, date, copyright,
abstract, keywords, article/section, url şi href. Pentru fiecare în lista de mai sus stă scris
ce să se genereze în XHTML când se întâlneşte o atare categorie sintactică.
Pe baza acestor reguli de producţie, transformatorul a generat la ieşire un document cu
structura XHTML (vezi şi anexa A). Mai mult nu detaliem.
Iată acest document XHTML:
LISTA 1.3 Documentul rezultat la ieşirescris în limbaj XHTML)

01.
02.
03.
04.
05.
06.

07.
08.
09.

10.
11.

12.

<HTML><HEAD><TITLE>About Style Sheet</TITLE></HEAD>
<BODY>
<P><B>XML Style Sheets</B></P>
<P><I>Styling</I></P>
<P>Style sheets are inherited form SGML, an XML ancestor. Style sheets
originated in publishing and document management applications. XSL is XML’s
standard style sheet, see href=”> /><P><I>How XSL Works</I></P>
<P>An XSL style sheet is a set of rules where each rule specifies how to format
certain elements in the document. It has rules for tile, paragraphs and
keywords.</P>
<P>With XSL, these are powerful enough not only to format the document but
also to reorganize it, e.g. by moving the title to the front of page or extracting
the list of keywords. This can lead to exciting applications of XSL outside the
realm of traditional publishing. ...</P>
…
</BODY>
</HTML>


Dacă priviţi cu atenţie lista 1.2, toate balizele sunt scrise cu litere mari! Cum arăta la
intrare documentul XML (lista 1.1) şi cum arată acum, după transformare (lista 1.3).
Toate browserele MSIE 5.x, nu cunosc versiunea 1.0 XML ci, una din versiunile
anterioare: 0.91 şi 0.92 care impuneau şi respectarea unor alinieri canonice la marginea
stângă, faţă de versiunea 1.0!
Ca să nu rămânem datori la întrebarea „Ce este XML?” vă spunem pe scurt că este un
fel de limbaj pentru marcaje, în care însă inventăm propriile balize (tags). Stricteţea

sintactică vă va stresa. Orcie scrieţi, trebuie verificat sintactic cu un document ... pe post
de veritabil ... grămătici, acel DTD adică definiţia tipului de document, Document Type
Definition!
În fişierul XML spuneţi care document va fi verificatorul şi aici începe chinul, dacă
scrieţi dumneavoastră în XML. Noroc că sunt generatoare automate de documente
XML (vezi : /13/) ca şi convertoare de structuri XML – XHTML(vezi : /14/).
XML este limbajul în care comunică curent verigile implicate în lanţul unei tranzacţii de
comerţ electronic (vezi şi /3/).
Protagoniştii lanţului unei tranzacţii de comerţ electronic.

Primul este cumpărătorul secolului XXI, posesorul unei cartelele de credit. Îi spunem în
engleză consumer. Este vorba apoi de banca care a emis acest „card”, denumită în
engleză issuer, apoi de banca verificatoare, acquirer, de banca creditoare a reţelei de
depozite, merchant bank şi în sfârşit, de angrosistul sistemului de depozite denumit în
engleză, merchant. Toate documentele financiar-bancare circulă între aceste verigi graţie
mijloacelor de comunicaţie şi calculatoarelor cuplate la aceasta, înzestrate cu programe
adecvate. Programele instalate la diversele sedii ale acestor verigi „vorbesc“ în XML,
deci înfăşoară (balizează spun snobii XML) datele documentelor fianciar-contabile în
… haina pretenţiosului XML. « Etapa » XML a reprezentat transpunerea „birocraţiei
unificate” EDIFACT a ţărilor din defuncta Piaţă Comună. EDIFACT înseamnă
Exchange Data Interface for Administration, Commerce, and Transport. Evident, se
respectă într-un mod riguros rigida sa sintaxă.

Modelul master slave cu trei straturi
Să insistăm puţin asupra comunicării dintre programele client şi server. În jargon i se
spune model cu două, trei sau n starturi, 2-tier, 3-tier, respectiv n-tier master-slave. Să ne
oprim la modelul 3-tier: stratul client, client tier, stratul intermediar, middle tier şi în
sfârşit, stratul final, data tier, unde se află fişierele bazei de date.
La nivelul client, programul de vizitare trimite cererea (adică datele completate în
rubricile formularului) la serverul Web. Acesta are acum rol de strat intermediar. El nu

poate interoga direct baza de date. Poate aţi solicitat ca să vi se furnizeze sortimentele de
articole vândute de depozitele acelui sit comercial vizitat. Atunci se adresează unui
server specializat de baze de date.


Lumea bazelor de date

Bazele de date sunt deservite de alte sisteme specializate precum: Oracle, IBM DB2,
Ingres, Informix, mySQL, PostGRES, etc.
Serverul intermediar nu traduce el cererea într-un limbaj ştiut serverul specializat în
căutări de informaţie prin bazele de date. Este instruit prin program (servlet în jargon
JSP). Întrebarea ajunge la stratul data tier. Aici se alcătuieşte un răspuns. I se spune tabel
cu rezultatele găsite.
Revenim la servlet. Acesta primeşte tabelul rezultat şi construieşte un alt tabel cu balize
HTML după care, cu ajutorul serverului Web, îl trimite mai departe clientului Web. Pe
ecranul staţiei gazdă a browserului se redă acest document şi vizitatorul află ceea ce a
solicitat. În fine acum vă e clar!
Applet, servlet, container

În tehnologia JSP, limbajul folosit este Java vezi figura 1.1. Fluxul de caractere
(răspunsul) ajunge la client, unde este interpretat de către MSIE. Datorită unei piese
software de care nu am vorbit, browserul MSIE interpretează şi aşa-zisele miniaplicaţii
Java, applets.
În dreptunghiul startului intermediar observaţi două subnivele, unul pentru prezentare şi
altul pentru accesul la bazele de date. Este nivelul denumit EJB, Entreprise Java Bean.
Aici se află un servlet construit cu un veritabil arsenal de mijloace EJB!

FIGURA 1.1 Cele trei niveluri ale modelului 3-tier master-slave
(reproducere din manualul devapp.pdf al Allaire JRun, varianta standard)

Cum am spus mai sus termenul applet, un diminutiv de la application, este tradus lejer
prin miniaplicaţie. Aveţi unul mai bun? Până găsiţi dumneavoastră o traducere mai bună
să vă spunem ce este!


Este un program scris iniţial în limbajul Java, care a fost compilat, deci tradus, din forma
sursă într-o formă intermediară, cea de cod de octeţi (bytecode). Acest cod este
interpretat pe PC-ul care găzduieşte clientul Web. O condiţie însă! Pe acest PC trebuie
să fi fost instalat în prealabil un component software, alături de browserul MSIE. Este
aşa numita „maşină virtuală Java”.
Servlet este tot o miniaplicaţie rulată la server. I se mai spune şi miniaplicaţie server.
Termenul are două sensuri.
Primul se referă la o întreagă activitate desfăşurată în spatele serverului Web şi aţi aflat
mai sus care este aceasta.
Al doilea sens, este acesta: dacă aplicaţia este complexă (deci cuprinde clasele tip
Entreprise Java Bean), ea va include programe care conversează optim cu bazele de
date.
Noi nu ne-am permis în acest manual să ajungem până la nivelul cadrului de lucru
J2EE, oprindu-ne la J2SE. Motivul ? Un software cu regim shareware nu are ce căuta la
un laborator studenţesc.
Component, pachet, clasă, metodă, et. Co.

Un component este o parte a aplicaţiei. Pe de altă parte, în diversele locuri ale
componentului se apelează la metodele şi clasele unor pachete. Pachetul nu este o
subdiviziune a componentului! Un pachet are mai multe clase gata dezvoltate.
Dacă aplicaţia sitului comercial nu conţine clase simandicoase „tip EJB”, ne mulţumim
cu clasele cadrului de lucru J2SE. Containerul care o execută nu este container EJB ci
unul simplu ! Dacă am avut fericita ocazie de a dezvolta aplicaţii de e-commerce
pornind de la J2EE, avem ocazia de a ne întâlni şi cu containerul EJB!
În 1999, firma BEA Systems a oferit aplicaţia Weblogic pe CD-ul care a însoţit referinţa

/4/, pentru o perioadă limitată de timp ancorată absolut la acea perioadă calendaristică.
Era o demonstraţie a unei aplicaţii de tip EJB. Acum ea este neoperaţională din motivul
arătat mai devreme!
Tot pe acelaşi CD sunt însă trei motoare servlet open source: Caucho 1.1.4, Allaire Jrun
3.0 Standard şi Tomcat 3.0. Ele pot fi folosite în compania fişierelor cadrului JDK2
varianta SE şi este totuşi ceva decât nimic!
JDK este un instrument pentru dezvoltarea de programe scrise în limbajul Java. Maniera
de lucru este primitivă! Instrumentele sale din care este alcătuit acest cadru nu sunt
pregătite pentru suprafeţe grafice de lucru. Programatorul care le foloseşte trebuie să
memoreze tot felul de comenzi lungi şi greoaie. Este un adevărat chin pentru cel căruia
i-aţi trasa sarcina construirii sitului comercial!
Veţi remarca la partea scrisă în limba franceză, recomandarea justă de folosire a
aplicaţiei Macromedia Dreamweaver MX, ca substitut al acestei primitive abordări.
Între altele acest Dreamweaver ştie Java, VBScript, VBasic şi PHP!


Diferenţa dintre servlet, scriptlet şi pagina JSP
Un program scris în limbajul Java este un fişier de tip text cu extensia .java.
Pagina JSP este tot un program scris conform regulilor sintactice ale limbajului JSP. Şi
ea este tot un fişier de tip text dar are extensia .jsp.
În lipsa unui mediu de dezvoltare (Dreamweaver nu este un mediu de dezvoltare în
adevăratul sens al cuvântului) recurgem la editorul Wordpad. În corpul paginii JSP se
pot întâlni şi instrucţiuni Java. Sunt aşa-zisele scenarii, scriptlets. Comenzile din
limbajul JSP împreună porţiuni de cod Java pur din aceşte scenarii sunt transformate de
către motorul servlet (Tomcat, Caucho, JRun etc.) în fişiere cu extensia .java. Deci
motorul este un … programator automat, care va genera cod sursă Java. Tot acesta
comandă compilarea în cod de octeţi, deci vă scuteşte de a memora complicatele
comenzi ale cadrului JDK2!

Maşina virtuală Java

Maşina virtuală Java (în engleză Java Virtual Machine JVM) reprezintă marea revoluţie
a platformei Java Sun Microsystems. A ajuns până în cuptoarele cu microunde, celulare,
PDA-uri. Este într-un cuvânt cheia portabilităţii platformei! Această „JVM” a fost scrisă
într-un limbaj tradiţional, de regulă C. JVM este în fond un program şi nu un dispozitiv
hardware. Este un fel de mediu de execuţie. Pentru fiecare platformă hard/soft există
câte o … maşină JVM. Este implantată într-o memorie flash a unui terminal portabil. La
PC-ul staţionar sau la laptop, notebook, nu este nevoie de memorie flash! Rostul său
este să … „ronţăie” codul de octeţi de care vorbeam mai sus.
Gazda maşinii JVM poate fi un:
•

PC al platformei IBM (bazată pe Pentium IV, III, II) ;

•

Laptop cu microprocesor Pentium IV, III Mobile sau Pentium II MMX ;

•

PDA Palm, Compaq sau HP, cu microprocesor de tipul Motorola sau ;

•

Apple model iBook, IMac, cu microprocesor PowerPC.

Pentru fiecare există câte o maşină virtuală Java!
Notaţi că sunt destule sisteme de operare. Amintim:
•

Familia Windows, 95, 98, Me, NT/4, 2000, 2002;

•

Linux cu cele vreo şapte dialecte ale sale: Caldera, Red Hat, Debian, SuSE,
Mandrake, Turbo, Slackware;

•

În lumea celularelor: GeOS, Palm OS, Windows CE, actualul Pocket PC;

•

Pentru platforma Macintosh: Apple OS şi MacOS;

•

Pentru staţii Sun, Solaris,


•

Pentru mainframes IBM ES 9000, multe sisteme de operare pe care nu le mai
enumerăm ;

•

Pentru megaminicalulatoare IBM AS/400 la fel ;

•

Pentru arhitecturi IBM RISC/6000, AIX-ul, Unix-ul corporaţiei IBM ;

•

Pentru defuncta corporaţie DEC cu ale sale miniuri PDP-11, megamini-uri
VAX 780, Ultrix, etc.

Citiţi părţile a doua şi a treia a referinţei /1/. Lumea nu stă pe loc.
Atât codul sursă cât şi codul de octeţi sunt coduri absolut independente de platformă.
Maşina virtuală este dependentă de idiosincraziile sistemului de operare ca şi de
arhitectura hardware! Cei mai mari realizatori de maşini virtuale Java sunt corporaţiile
Sun Microsystems şi IBM. Ei îşi oferă gratis maşinile JVM!
În platforma IBM PC, unul din fişierele cadrului JDK „instanţiază” maşina virtuală
Java. Nu ne interesează care este acea componentă a JDK. Cum o instanţiază? JVM „se
trezeşte” în clipa în care îi daţi să execute un applet sau un servlet.
Dar oare nu este mai lent să se interpeteze un cod de octeţi decât să se ruleze un cod
maşină nativ! Aşa este, dar nu uitaţi că dispunem azi de microprocesoare teribil de
puternice şi mai sunt şi atâţia bolnavi mintali amatori de creare de viruşi informatici!

Applet şi servlet
Atât appletul cât şi servletul sunt programme, adică aplicaţii. Sunt stocate în fişiere cu
extensia .class. Nu mai sunt de tip text ci binar! Appletul este interpretat la PC-ul gazdă
de către browser (MSIE etc.) graţie faptului că acest browser colaborează cu maşina
JVM. Servletul rezidă la calculatorul gazdă a serverului Web. Şi aici se află o maşină
JVM.

Clase Java beans
Clasa, instanţierea, constructorul, obiectul

Clasa este un tipar, aşa cum foloseşte croitorul ! Dar este mai mult de atâta! În ea s-au

înmagazinat datele, parametrii dar şi inteligenţă! Inteligenţa este găzduită de metodele,
algoritmele dacă vreţi, care operează cu aceste date şi parametri trimişi din exterior prin
interfaţa clasei.
Şablonul clasei „naşte“ obiectul clasei. A instanţia spun programatorii şi înţeleg ce am
afirmat adineaori.
La instanţiere, fiecare clasă recurge la un aşa-zis „constructor”. Este tot un program. El
produce obiectul. Asimilaţi rezultatul constructorului cu imaginea memorată, după
folosirea declanşatorului aparatului foto!
Ce vor să însemne aceste clase tip „Java Beans”. Mai întâi etimologia cuvântului: Bean
îl traducem prin păstaie (de fasole sau mazăre dar este prea grotesc). Băutării înrăiţi de


cafea ce lucrează la sediul general al corporaţiei Sun Microsystems au adoptat
denumirea Bean, fiindcă tot începuseră cu Java. Java este denumirea cafenelei unde se
prepară la nisip cafeaua. Probabil că nu e a unui român! Dacă era, i-ar fi spus AdaKaleh-ul iar corporaţia poate l-ar fi … adoptat în loc de Java!
Clasele Beans sunt tot clase Java care respectă un tipic de programare (vezi
capitolul 6).
Program, subprogram

Ca să explicăm afirmaţia de mai sus, să folosim jargonul generaţiei a treia de limbaje de
programare. Fie două programe P1 şi P2. P1 cheamă P2 de multe ori. Spunem că P2
este o subrutină, o funcţie, un subprogram. La generaţia a patra, deci aceea a limbajelor
orientate spre obiecte, i se spune metodă. P1 trimite date lui P2. Nu intrăm în detalii
cum! În jargon spunem acestor date, parametri reali, argumente reale. P2 aplică
algoritmul, adică „îşi face numărul său” şi prelucrează aceste valori, şi întoarce
rezultatele. Că le transmite sau nu lui P1 şi cum le transmite, aceasta este mai puţin
important. Algoritmul este conceput şi scris dinainte. El trebuie să se refere la aceste
date prin adrese de memorie. Adresele nu sunt cele din spaţiul programului P1 ci sunt
zone de memorie interne lui P2. Sunt deci locuri din memorie, cărora li s-au asociat în
mod convenţional denumiri simbolice dacă vreţi. Aceste locuri le numim argumente

fictive, parametri fictivi. Aici se aduc valorile parametrilor reali.

Ce conţine o aplicaţie complexă de sit
comercial
În figura de mai jos, reproducere din manualul de firmă al pachetului Allaire JRun
varianta Standard, se disting două categorii de componente.
Primele sunt aplicaţiile care conţin obişnuitele pagini JSP şi servlet-uri. Motorul servlet
JRun mai are destule alte fişiere şablon (template). Evident, există şi alte componente
dar din motive didactice nu mai le enumerăm. Şi aşa nu ne ocupăm aici de biblioteci
taglib şi de şabloane.
A doua categorie este constituită din aşa-zisele clase tip Entreprise Java beans, EJB.
Sunt tot fişiere. Li se spun şi biblioteci de clase EJB. Accesul se efectuează prin
intermediul unei interfeţe adecvate EJB. Aceasta, la rându-i, este alcătuită dintr-o suită
de fişiere parametru, care conţin valorile unei proprietăţi (consideraţi-le un fel de
parametri fictivi).
Faptul că sunt mai multe aplicaţii Web, nu trebuie să constituie o nelămurire! Un motor
servlet JRun (dar şi alte tipuri de motoare servlet) este în stare să se ocupe simultan de
mai multe situri comerciale.


FIGURA 1.2 Osatura unor aplicaţii complexe de tipul sitului comercial
(reproducere din manualul devapp.pdf al Allaire JRun, varianta standard)

Relaţia dintre serverul Web şi motorul servlet
Până acum nu a apărut poate prea clar această nuanţă. Caucho Resin este un motor
servlet ca de altfel şi Allaire JRun.
JRun poate să funcţioneze ca server propriu Web clasic şi, în acelaşi timp pe post de
container pentru servleturi şi pagini JSP, deci de server de aplicaţie.
De asemeni, admite ca treaba serverului Web clasic să nu o mai facă el ci un server Web
extern. Deci comunică cu unul dintre serverele Web clasice.

Tomcat este mai comod decât Jrun ! Nu se oboseşte ci, recurge la serviciile serverului
clasic extern Apache Web Server.
În figura de mai jos se văd care servere Web clasice pot fi folosite de către motorul
servlet JRun. Este vorba de: Personal Web Server (PWS, Windows 95/98), Information
Internet Server (IIS, Windows 2000, 2002), Netscape Entreprise Server (NES) sau, în
sfârşit de Apache. Mai observaţi acele dreptunghiuri mici denumite conector, connector.
Ei bine conectorul este un program specializat (i se mai spune în engleză şi driver). Nu
divagăm!
Serverul propriu Web al aplicaţiei JRun apare pe figură sub numele de JRun Web
Server. Aceasta pe de o parte. Pe de altă parte, remarcaţi că pe acelaşi PC pot funcţiona
mai multe motoare servlet JRun.
Ele sunt procese (tasks, vezi mai jos). Unul „dialoghează” datorită rulării aplicaţiilor de
comerţ electronic cu Apache, NES şi cu IIS, iar celălalt, cu serverele Web Apache şi
JRun.


FIGURA 1.3 Relaţia dintre diversele categorii de servere implicate
(reproducere din manualul devapp.pdf al Allaire JRun, varianta standard)

Deci :
Există pe de o parte un container pentru servleturi şi pagini JSP, căruia îi spun unii
pe scurt server JRun şi prodcu confuzie. Mai bine spuneţi-i server de aplicaţii
Web.
Există un alt server denumit server Web care se ocupă de prelucrarea cererilor de la
PC-uri ce găzduiesc clienţi Web şi administrează uneori şi servleturile.
Conţinutul unui răspuns al serverului este fie o pagină statică, fie una dinamică.
Pagina statică este un fişier cu extensia .html, adicp un docmuent anost de tip
HTML. Poate avea una sau mai multe appleturi sau nici un applet.
Pagina dinamică este ceva generat. Este un fişier cu una dintre extensiile .jsp, .asp,
.php etc. Când se solicită această pagină, are loc mai întâi o prelucrare la server.

Rezultă mai întâi un flux de caractere HTML care, odată ajuns la PC, este redat pe
ecran.

Arhive de fişiere ale unui sit comercial
Fişierele care au extensia .jar sunt de fapt arhive. Ştiţi poate de zip, arj sau rar. Sunt
arhive construite cu winzip, arj sau winrar!
Şi în cadrul de lucru JDK există un program pentru crearea şi administrarea arhivei de
fişiere, cum poate folosiţi cu dezinvoltură pe WinZip sau WinRAR.


Apropo, WinZip ştie structura tip JAR. Nu am informaţii dacă şi aplicaţia WinRAR a
aflat de această structură! Un sit comercial are fişiere care au diverse extensii.
Ce tipuri de documente pot intra într-o arhivă:
•

Fişierele cu pagini statice de casă.

•

Fişiere cu extensia .java (servlet-uri java).

•

Fişiere executabile .class.

•

Documente care descriu structura aplicaţiei sitului comercial, după rigoarea
limbajului XML. Acestea au extensia .xml.

•

Şi alte tipuri dar preferăm pentru motive didactice a le ignora.

Toată această colecţie de fişiere alcătuiesc o anume ierarhie de directoare. Fiecare firmă
realizatoare de motor servlet a căutat să îşi impună propria structură de desfăşurare. Va
fi acceptat până la urmă tipicul structurii grupului Jakarta. Veţi observa uneori în acest
manual două tipuri de ierarhii, pe de o parte aceea proprie firmei Allaire şi pe de alta,
aceea a firmei Caucho.
Ei bine, aceste fişiere sunt comprimate şi arhivate cu un utilitar denumit jar, ce se află în
J2EE şi J2SE. JAR înseamnă Java ARchive.
Development phase, Deployment phase

Desigur de la maşina pe care s-a conceput situl până la maşina ţintă, deci gazdă a sitului,
aplicaţia este transportată în mod comprimat. Faza de punere la punct se numeşte în
engleză development. Componentele aplicaţiei sunt înglobate într-o arhivă. Aici se
conservă întreaga ierarhie. Aceasta trebuie în prealabil desfăşurată (în engleză,
deployment). Rezultă ierarhia de directoare cu fişierele sitului.
Desfăşurarea trebuie efectuată mai înainte de momentul lansării în exploatare a sitului.
Cei de la Allaire au voit ca extensia să se cheme WAR şi nu JAR, adică Web Archive.
De fapt un fişier cu extensia .war este o structură de date .jar. (J de la Java).
Fake-root directory

Nu este cazul să intrăm în amănunte tehnice de genul unde este directorul de implantare
tip rădăcină deplasabilă, fake-root, ce se poate planta în undeva în ierarhia generală a
sistemului de operare. Fiecare motor servlet are propriul său … fake-root.
Nu pe dumneavoastră stimate manager trebuie să vă intereseze unde se află exact acest
director ci, pe cel care se ocupă de implementarea şi întreţinerea programelor sitului
comercial. Poate sunteţi chiar dumenavoastră şi, vă felicităm atunci, fiindcă sunteţi un
manager modern!

Proces, multitasking, multithreading, soclu şi
port
Deşi am explicat primele două noţiuni în referinţa /1/, le reluăm şi aici.
Proces

Să considerăm că folosiţi editorul Winword ca să puneţi la punct un document. La un
moment dat, fiindcă sunteţi cuplat prin modem la linia telefonică, vine un caracter (literă
sau cifră) prin linie. Acesta nu trebuie pierdut, altfel s-ar altera înţelesul mesajului. Este
grija sistemului de operare existent pe maşina dumneavoastră de calcul să „întrerupă”
executarea programului WinWord fără să simţiţi şi „să transfere controlul spre”
programul care se ocupă de recepţia caracterelor. Să zicem că acest program este
clasicul dialer.exe. Winword trebuie să nu îşi piardă contextul până unde aţi ajuns cu
punerea la punct a documentului, ca să fiţi în stare să vă continuaţi treaba. Există un
planificator de aşa-zise procese, task scheduler, care se ocupă de această trecere de la un
proces la altul.
Procesul (task) este un program ajuns într-un anume context.
Multitasking

Sistemul de operare a alocat zona de memorie pentru păstrarea acestui context. Aici „a
fost salvat”, adică s-a memorat conţinutul registrelor microprocesorului, după care
acelaşi task scheduler s-a ocupat de aplicaţia dialer.exe. Şi ea ajunsese într-un anume
context. El este păstrat altundeva, nu peste contextul lui WinWord ! În consecinţă,
planificatorul va reîncarca registrele microprocesorului cu valorile specifice de la
contextul anterior unde rămăsese dialer.exe. Apoi se va ocupa de preluarea caracterului.
După preluare, va „dezactiva” aplicaţia dialer.exe, păstrându-i noul context, după care
va reface contextul aplicaţiei WinWord, ş.a.m.d. Şi aceasta poate de sute de ori într-o
secundă, fără ca dumneavoastră să sesizaţi!
Acesta este mediul tipic de lucru denumit multitasking, multiproces.

Multithreading

Java permite şi multithreading-ul. Este un fel de multitasking care face risipă de spaţiu
de memorie. De data aceasta, microprocesorul apelază la o instrucţiune specială de
schimbare a „spaţiului de adresare”. Are loc o comutare ultrarapidă de conţinut de
registre ale microprocesorului spre spaţiile de adresă. Deci descarcă-încarcă aceste
registre speciale. Se zice că se trece de la un fir de execuţie la altul. Un program ocupă
un anume spaţiu din memoria operativă. Contextul acum nu se mai limitează la doar cei
câţiva zeci sau sute de octeţi, cum era în cazul multitasking-ului. Pur şi simplu aplicaţia
X are mai multe astfel de spaţii mari rezervate în memorie
Portul, soclul

Portul şi soclul sunt cu totul altceva O aplicaţie tip server dialoghează cu o aplicaţie tip
client prin mesaje. Mesajele aparţin protocolului întrebuinţat: http, ftp, smtp etc. Trebuie


neapărat o zonă de memorie, un bôite de lettre. Să-i zicem şi pe româneşte, cutie poştală.
Acesta este soclul. Soclul are un număr, o adresă. Este portul. Nu intrăm în alte
amănunte tehnice, dar soclul respectă cerinţele protocolului respectiv. De pildă ftp
foloseşte porturile 20 (pentru handshaking) şi 21, http recurge la portul 80. Sau Allaire
Jrun „ascultă” la portul 8100, în timp ce serverul Web Apache, portul 80, Tomcat şi
Resin folosesc portul 8080 etc.
După ce lansăm browserul vom anunţa în fereastra de adresare a sa (în cazul Netscape
se operează cu noţiunea de Location, nu Address) că vrem să lansăm un sit, de pildă aşa:
http://localhost:8080/test/mysit.jsp
Aici situl comercial se afla pe aceiaşi maşină de calcul, dar bine mersi putea ca să se afle
undeva pe alt fus orar şi atunci, în loc de localhost trebuia să menţionăm adresa
serverului gazdă a sitului comercial.

Jalonul alias cookie

Protocolul http este unul care nu are posibilitatea să înregistreze faptul că un vizitator a
efectuat mai multe intrări tip cerere/răspuns la acelaşi sit. Specialiştii numesc acest
protocol HTTP drept unul „fără stări”.
Când s-a născut acest sistem Web (vezi detalii în referinţa /1/), cam tot atunci a apărut şi
HTML. Era pe la începutul anilor ’90. HTTP a avut un succes formidabil, deşi nu s-a
preocupat să memoreze la serverul Web starea unei sesiuni. Atât clientul cât şi serverul
folosesc protocolul http. Internatutul cere. Serverul caută şi găseşte documentul. Apoi
trimite răspunsul.
S-a urmărit ca HTTP să fie cât mai rapid, mai simplu, deci cât mai compact. De aici
succesul!
Fiecare cerere a clientului Web este tratată separat de către server. Este un eveniment
izolat. HTTP nu ştie că internautul a mai vizitat acel sit şi nu îşi propune să memoreze
acest istoric al vizitelor sale.
Atunci, undeva trebuie păstrate aceste jaloane, identificatoare de sesiune, cookies! Mai
departe, vezi în capitolul 6 şi în cazul aplicaţiei complexe a sitului comercial din partea
dedicată tehnologiei ASP (capitolele 7-10).


2

Capitolul

Primii paşi cu tehnologia JSP
JSP, Java Server Pages este o tehnologie de vârf. Stă la baza celor mai mari
situri comerciale. Este concurată de tehnologia ASP. Prima a fost dezvoltată de
către corporaţia Sun Microsystems, a doua, de către corporaţia Microsoft.

Paşii procesului de generare ai unui servlet
Modurile de solicitare a servletului de la serverul Web de către clientul Web

P

entru început să contemplăm figura 2.1. Ce observăm din ea? Faptul că clientul
Web solicită servletul fie:
•

în modul indirect, prin adresarea clasică în stilul URL, aşa cum am arătat
http://adresa-sit/dir/.../dir/pagina.jsp, fie

•

în mod direct, prin schema de adresare tot tip URL, dar în forma următoare:
http://adresa-sit/dir/.../dir/servlet.

Nu descriem aplicaţii lansate prin schema a doua în cartea de faţă. Faptul că se
întrebuinţează una sau alta din cele două scheme de mai sus, îi este total indiferent
serverului Web, aflat la mijloc în figura 2.1.
Pagina JSP poate conţine linii cu text tip HTML şi scenarii (scriptlet în englezeşte),
scrise în limbaj Java, mai rar în JavaScript. La prima apelare a unei pagini JSP are loc
generarea unui fişier sursă .java şi traducerea în foma .class. Toate accesele ulterioare
efectuate de către clientul Web sunt rezolvate imediat, deoarece imaginea servletului
(.class) rămâne în memoria cache a serverului Web (vezi referinţa /1/ pentru termenul
cache). Deci se vor ocoli paşii de compilare şi încărcare.

FIGURA 2.1 Cei trei protagonişti implicaţi într-o sesiune la un sit comercial
(reproducere din manualul devapp.pdf al Allaire JRun, varianta standard)


şi paşii enumeraţi mai sus:

FIGURA 2.2 Paşii de transformare ai unei pagini jsp (reproducere din manualul
devapp.pdf al Allaire JRun, varianta standard)

Un prim exemplu de pagină JSP în câteva
variante
1. Mai întâi de toate să reţinem că trebuie pornit unul din motoarele
servlet. La staţii am implementat doar motorul Caucho 1.1.4, acesta
fiind cel mai rapid în comparaţie cu JRun şi cel mai mic consumator de
spaţiu. Totuşi paşii următori vor releva şi cazul motorului JRun 3.0.
2. Creăm apoi cu editorul Notepad (Windows) următorul document în care apar
banalele balize ale limbajului pentru hipertexte. Este bine să vă reamintiţi acest
limbaj. Vă recomandăm să citiţi anexa A.
LISTA 2.1 Un prim exemplu banal, welcome1.jsp

<html>
<head>
<title>Welcome!</title>
</head>
<body>
<H3 ALIGN="CENTER">Welcome to our store!</H3>
<CENTER><FONT FACE="Verdana" COLOR="darkgreen" SIZE="4">We sell the
<<BEST>> products!</FONT>
</CENTER>
</body>
</html>

3. Stocăm (salvăm) pagina în directorul dedicat aplicaţiilor curent testate.
În cazul motorului JRun, directorul de casă (fake-root) va fi notat cu
<HOME_JRun>. Concret acesta va fi c:\Program Files\Allaire\JRun.
În cazul motorului Caucho Resin îl vom nota <HOME_Resin> şi, concret se află

în directorul c:\Resin1.1.4\doc. Să nu confundăm însă aceste directoare de
casă cu directoarele aplicaţiilor curent testate. Directorul aplicaţiei curente este
la:
¾

(JRun ) <HOME_JRun>/servers/default/default-app

¾ (Resin) <HOME_Resin>/test


Ultimele observaţii:
Nu vom intra în amănunte de implementare a motoarelor. Semnalăm doar că JRun
şi Resin, la pornirea lor la cald, rulează automat un aşa numit scenariu de
configurare. În cazul JRun el se cheamă local.properties, iar în contextul
motorului Resin, httpd.conf. El conţine tot felul de comenzi şi valori necesare
iniţializării motorului respectiv.
Vă rugăm să nu ştergeţi din greşeală aceste fişiere cu scenarii sau, să salvaţi
exemplele în alte directoare. În caz contrar, ar trebui să învăţaţi cum să modificaţi
aceste scenarii pentru configurare!
Lansăm browserul MSIE. Schemele URL vor fi următoarele:
http://localhost:8080/test/welcome2.jsp (pentru Resin1.1.4), respectiv
http://localhost:8100/welcome2.jsp (pentru JRun)

Fiecare motor va genera în mod automat servletul sub forma unui cod sursă Java,
dacă pagina conţine una sau mai multe porţiuni cu scenarii (scriptlets în engleză).
Motorul va realiza de asemeni traducerea (compilarea) codului sursă în cod de
octeţi (.class). Va avea aceiaşi denumire.
Pentru aplicaţia de mai sus nu a existat nici un scenariu. Deocamdată!
Fiindcă fişierul a avut extensia .jsp, motorul a generat în mod automat un program scris
în limbajul Java în directorul:

<HOME_Resin>/work/_test/_jsp

În urma compilării, alături de fişierul sursă va fi înregistrat şi fişierul cu denumirea
_welcome1__jsp.class.

FIGURA 2.3 Aspectul documentului din lista 1.1

Rostul său a fost să creeze şi să trimită la clientul Web acel text din lista de mai sus.
Deci pagina a fost generată dinamic!

Primul scriptlet
Fişierul welcome1.jsp putea foarte bine să aibă una dintre extensiile .html sau .htm,
deoarece este un document tip html, fără nici un scriptlet. În acel caz ar fi fost o pagină
statică, moartă! Fişierul welcome2.jsp în schimb are un scenariu, scriptlet.
Scriptletul e delimitat de „separatorii”: <% şi %>. Priviţi aplicaţia welcome2.jsp.


LISTA 2.2 Fişierul welcome2.jsp

01.
02.
03.
04.
05.
06.
07.
08.

<html>
<head>

<title>Welcome!</title>
</head>
<body>
<%
out.println("<H3 ALIGN=\"CENTER\">" + "Welcome to our store !" + "</H3>");
out.println("<CENTER>SIZE=\"4\">" + "We sell the <<BEST>> products!" +
"</FONT></CENTER>");
09. %>
10. </body>
11. </html>

Explicaţii
În cazul de faţă, scriptletul este alcătuit din două instrucţiuni 07 şi 08. Denumirea out se
referă la obiectul implicit out al JSP. El are misiunea de a reda un flux de caractere la
fişierul logic de ieşire al aplicaţiei (de regulă ecranul). Denumirea println se referă la
metoda pentru realizarea dezideratului amintit. În lista aplicaţiei welcome1.jsp erau
aceste linii:
<H3 ALIGN="CENTER">Welcome to our store!</H3>
<CENTER><FONT FACE="Verdana" COLOR="darkgreen" SIZE="4">We sell the
<<BEST>> products!</FONT>

Cu ce diferă? Prin mai multe lucruri. Primul lucru care sare în ochi este faptul că apare o
paranteză rondă deschisă, apoi un grup de aşa-zis literali, delimitaţi de semne plus şi la
final de o paranteza rondă închisă. În sfârşit, totul se termină prin caracterul punct şi
virgulă. Orice instrucţiune Java se termină cu acest caracter « ; ».
Literalul este un şir de litere şi cifre (caractere) flancate de ghilimele. Semnul plus
serveşte la alipirea acestor literali.
Argumente reale şi fictive (parametri reali şi fictivi)

Metoda println() este un fel de subprogram, aşa cum afirmam mai sus. În consecinţă,
acest subprogram va avea o listă de parametri reali (argumente reale). O astfel de listă
este înconjurată de parantezele ronde. În cazul exemplului nostru s-a folosit un singur
parametru. Dacă lista ar fi avut mai multe argumente, atunci ar fi avut forma: (arg1,
arg2, ... ). Deci virgulele urmau fiecărui parametru, excepţie făcând ultimul.
Să descifrăm acum acest lung şir de caractere al unicului argument. Observaţi existenţa
balizelor din HTML dar şi a textului obişnuit. Vă recomandăm totuşi să recitiţi sau să
citiţi anexa A, pentru a vă explica mai departe la ce se referă aceste balize şi secvenţe
escape (adică notaţiile: < , > ).


Iată o parte din textul generat de către Caucho pentru pagina welcome2.jsp:
LISTA 2.3 Codul generat de către motorul servlet Resin la prima executare
a fişierului welcome2.jsp
/*
* JSP generated by Resin 1.1.4 -- Thu Sep 7 09:00:17 PDT 2000
*/
package _jsp._test;
import java.io.*;
import javax.servlet.*;
import javax.servlet.jsp.*;
import javax.servlet.jsp.tagext.*;
import javax.servlet.http.*;
public class _welcome2__jsp extends com.Caucho.jsp.JavaPage{
public void
_jspService(javax.servlet.http.HttpServletRequest request,
javax.servlet.http.HttpServletResponse response)
throws IOException, javax.servlet.ServletException
{
javax.servlet.jsp.PageContext pageContext =

com.Caucho.jsp.QJspFactory.create().getPageContext(this, request, response, null, true, 8192,
true);
javax.servlet.jsp.JspWriter out = (javax.servlet.jsp.JspWriter) pageContext.getOut();
com.Caucho.jsp.ByteWriteStream _jsp_raw_out;
_jsp_raw_out = (com.Caucho.jsp.ByteWriteStream) out;
javax.servlet.ServletConfig config = getServletConfig();
javax.servlet.Servlet page = this;
javax.servlet.http.HttpSession session = pageContext.getSession();
javax.servlet.ServletContext application = pageContext.getServletContext();
com.Caucho.jsp.QBodyContent _jsp_endTagHack = null;
try {
_jsp_raw_out.write(_jsp_string0, 0, _jsp_string0.length);
out.println("<H3 ALIGN=\"CENTER\">" + "Welcome to our store!" + "</H3>");
out.println("<CENTER><FONT FACE=\"Verdana\" COLOR=\"DARKGREEN\" SIZE=\"4\">" +
"We sell the <<BEST>> products!" + "</FONT></CENTER>");
_jsp_raw_out.write(_jsp_string1, 0, _jsp_string1.length);
} catch (Exception e) {
pageContext.handlePageException(e);
} finally {
JspFactory.getDefaultFactory().releasePageContext(pageContext);
}
}
...
<html>\r\n<head>\r\n<title>Welcome!</title>\r\n</head>\r\n<body>\r\n".getBytes();
_jsp_string1 = "\r\n</body>\r\n</html>\r\n".getBytes();
}
}

Nu vă vom cere să scrieţi aşa ceva niciodată! Citiţi însă cu luare aminte observaţiile
extrem de importante de la sfârşitul acestui prim capitol.

Aspectul ferestrelor document ale ambelor aplicaţii welcome1.jsp şi welcome2.jsp sunt
identice din punct de verdere al browserului. El este redat în figura 2.3.