Sunteți pe pagina 1din 292

Cuprins

Introducere

3

Introduction

8

1. Universul termenilor platformei JAVA

13

2. Primii paşi cu tehnologia JSP

28

3. Directive şi obiecte JSP

43

4. Generarea şirurilor de interogare, a formularelor şi a cadrelor

56

5. Accesul la bazele de date, clasele de tip JAVA Beans

70

6. Sesiuni şi jaloane

87

7. Primii paşi în tehnologia ASP

96

8. Să construim un catalog de produse pentru un site comercial

117

9. Înregistrarea vizitatorilor unui site comercial în ASP

144

10. Coşul de cumpărături şi partea legată de comenzi şi plăţi

157

11. Le commerce électronique et ses tehnologies

171

12. Comprendre les applications Web

184

13. Interaction des site de commerce electronique avec le visiteur

204

14. Mise en place d’un catalogue de produits

231

Anexa A – Iniţiere în HTML, DHTML şi XHTML

254

Anexa B – Sintaxa JSP

275

Întrebări şi răspunsuri

278

Epilog

288

Bibliografie

291

Adrese Web utile

291

Introducere 1

Î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,

tehnologiei ASP. Am acordat mai multă atenţie XML.

am vizat în partea a cincea doar o prezentare frugală a

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 comenzi@lucman.ro) 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

apucat

învăţământ de zi şi distanţă, pentru facultatea R.E.I. Au fost şi cumpărători izolaţi care au 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: http://java.sun.com/products/jdk. 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:

http://www.allaire.com 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ă

anun ţ ate prin pictograma al ă turat ă . Observa ţ iile importante sunt anun

Introduction 1

Le e-commerce

Le progrès technique dans le domaine des circuits intégrés à permis de décliner les dimensions de l’ordinateur. Les mainframes étaient prioritairement destinés aux centres de calcul territoriaux qui traitaient les données pour plusieurs unités économiques, les mini-ordinateurs étaient utilisés comme ordinateurs d’entreprise et les micro-ordinateurs traitaient les données d’un service ou bureau. Ont suivi les ordinateurs de bureau (desktop). L’adoption large des ordinateurs personnels grâce aux programmes de bureautique (traitement de texte, tableur,…) a mené à une certaine démocratisation de l’informatique. Les simplifications apportées aux ordinateurs personnels et à leurs systèmes d’opération, nécessaires pour assurer les moindres coûts, leur ont apporté un handicap par rapport à la protection des données, la capacité de travailler simultanément avec plusieurs utilisateurs (multi-user) ou d’exécuter plusieurs processus en même temps (multi-tasking).

La montée en puissance de l’informatique

La montée en puissance des ordinateurs personnels a permis l’adoption au début des années 1990 du système Unix par les ordinateurs PC, sous le nom déjà célèbre de Linux. Ceci a mené à la confrontation de deux cultures et philosophies informatiques différentes. L’une qui vient d’un monde de l’informatique professionnelle, attentive à la sécurité de l’information, aux capacités de communication et favorable aux systèmes ouverts, représentée par Linux ; l’autre qui vient du monde de l’informatique utilisateur, commerciale avec des tendances monopolisatrices représentée par Windows. Indifféremment de la manière dont va se solder la confrontation des systèmes Linux et Windows, ce qui est à retenir de cette évolution, c’est que la notion de terminal non-intelligent a disparu et avec elle aussi la notion d’informatique centralisée. Parallèlement se sont beaucoup développées les technologies de réseau d’ordinateurs et l’informatique distribuée.

Le modèle d’ordinateur central supposait la concentration des calculs et traitements de données dans l’ordinateur central qui devait servir de multiples terminaux passifs, qui ne faisaient rien d’autre que de faciliter l’affichage et la saisie de données. Avec le remplacement des terminaux par des ordinateurs de bureau qui disposent d’intelligence et de capacités de calcul de plus en plus importantes, on arrive naturellement à une démocratisation du traitement des données dans le réseau. Le rôle d’ordinateur central disparaît et apparaissent un

1 Introducerea la “Cours de commerce éléctronique” predat de domnul prof. Dr. Mihai Calciu, la Universitatea I Lille. Sunt prezentate doar o parte din capitole. Restul şi actualizări se pot vedea la http://mihai.calciu.free.fr.

ou plusieurs ordinateurs qui jouent le rôle de serveurs. En parallèle, le rôle du terminal disparaît et apparaît celui de l’ordinateur client.

Aujourd’hui, le multimédia utilise l’ordinateur pour intégrer et assurer un accès interactif pour du contenu statique (textes, images et graphiques) et dynamique (audio, vidéo et animations). L’hypermédia combine l’accès nœud et liens de l’hypertexte avec du contenu multimédia. Le World Wide Web est un cadre de communication hypermédia basé sur l’ordinateur et le réseau Internet, qui permet aux consommateurs et aux firmes de fournir du contenu hypermédia et d’y accéder de manière interactive.

Le e-commerce

Le commerce électronique ou e-commerce est défini comme étant la vente et l’achat à travers les médias digitaux. Les possibilités visuelles et multimédia et le caractère intuitif de la navigation de type nœud et lien ont d’abord révélé l’Internet comme un nouveau canal de distribution pour la vente en détail. Les premières applications étaient de type boutique électronique ou magasin on-line. Elles utilisaient les pages web écrites en langage html pour la présentation de l’information et des langages de programmation disponibles sur les serveurs.

Le site web où l’on peut acheter des biens et des services, n’est qu’une forme de commerce électronique. Elle représente une faible partie du chiffre d’affaires du secteur. Plus récemment, le commerce électronique est passé à une vitesse supérieure. A coté des boutiques électroniques on-line apparaissent de nouvelles formes d’intermédiation commerciale appelées places de marché, qui réunissent de l’information en provenance de multiples offreurs sur Internet. Se développent aussi les formes dynamiques de commerce comme les enchères, le regroupement ad-hoc des acheteurs, le troc électronique et les marchés boursiers.

Pour pouvoir supporter ces nouvelles formes de commerce et le commerce entre entreprises, il est nécessaire d’automatiser de nombreux échanges d’information. Cela suppose le transfert d’information structurée d’un ordinateur à un autre pour des traitements automatiques. Historiquement, la première forme de commerce électronique a été le magasin on-line ou le shopping cart. Les vendeurs communiquaient directement avec les consommateurs par l’intermédiaire de leurs sites web en utilisant les méthodes de marketing traditionnelles. C’est la forme la plus adaptée à la communication homme-machine. Cette démarche s’est avérée coûteuse, spécialement pour les détaillants. Le nombre grandissant des sites de vente en ligne et de leurs messages publicitaires inondait les acheteurs et rendait difficile le choix des fournisseurs.

Avec la difficulté grandissante des vendeurs et acheteurs de se retrouver de manière intuitive et efficace, est apparu le besoin de créer des places de marché on-line. Les places de marché sont des intermédiaires dignes de confiance qui ont comme première mission d’agir en qualité de lieu central de collecte aidant les

acheteurs et les vendeurs à se retrouver et à faire du commerce de manière efficace.

La place de marché se substitue au besoin de l’acheteur d’effectuer une seule transaction avec une seule entité et prend en charge la facturation du client, l’intermédiation des services post-achat, la gestion de retours et d’autres situations. En d’autres termes, la place de marché devient un marchand de références qui remplace les différents vendeurs. Dans ces conditions, pour assurer la fluidité dans la collecte et la présentation de l’offre et dans le déroulement des transactions, une forte automatisation des transferts d’information structurée (documents, formulaires) est nécessaire par la communication de machine à machine, pour faciliter le « commerce silencieux ». Conçus pour servir aussi bien le commerce de détail (b-to-c, business to consumer) que celui de gros (b-to-b, business to business), les lieux de marché connaissent une meilleure diffusion et atteignent des degrés d’efficience et de réduction des coûts, supérieurs dans le b-to-b.

La typologie des lieux de marché qu’on observe actuellement permet de distinguer au moins trois catégories : les méga, micro et méta lieux de marché. Les méga places de marché ont un caractère horizontal. Elles couvrent un très large spectre de catégories de produits et proposent des gammes de produits plutôt larges que profondes. Elles cherchent à satisfaire un large spectre de besoins pour un grand nombre de consommateurs. Les catégories de produits sont multiples. Dans chaque catégorie, l’offre de produits est multiple et provient d’une multitude de producteurs. Les micro places de marché sont verticales par défaut. Elles apportent l’offre la plus grande de produits dans la même catégorie. Elles se distinguent par la profondeur de la gamme de produits. Les méta lieux de marché n’ont pas de correspondant off-line. Ils cherchent à offrir des solutions à des problèmes à la place de catalogues de produits.

Même s’ils sont capables à long terme de réduire les chaînes traditionnelles de distribution en éliminant des intermédiaires, ils se développeront à court terme à l’intersection des canaux de distribution traditionnels.

Le e-business

Naturellement, les possibilités visuelles et multimédia ont d’abord révélé l’Internet comme un nouveau canal de distribution pour la vente en détail. On s’est vite aperçu que les implications étaient beaucoup plus larges et que le e- commerce affectait encore plus profondément les échanges entre entreprise (le b- to-b). En développant leurs interfaces d’échange, les entreprises doivent adapter leurs structures et processus internes, leur back-office, pour faire face aux exigences de flexibilité, synchronisation et réactivité induites par les nouveaux mécanismes d’échange. Ce qui les amène à une refonte de leurs systèmes d’information dans des systèmes de e-business.

Le e-business se définit comme l’intégration des applications de front et back- office dans un moteur qui permet de redéfinir les modèles d’affaires et de maximiser la valeur pour le client. Les systèmes d’information des entreprises ont subi à l’ombre de l’Internet une révolution silencieuse. On renonce maintenant aux applications traditionnelles, construites pour résoudre des problèmes spécifiques à l’entreprise, souvent avec des ressources maison. Les systèmes modernes sont actuellement constitués autour d’un nombre réduit de composantes nommées applications d’entreprise, le plus souvent commerciales.

Les entreprises ressentent de plus en plus la pression de la diffusion des possibilités de commande en libre-service, du coût excessif des conseils techniques avant la vente, un coût croissant des erreurs de commande, des problèmes de coordination engendrés par la prolifération des canaux de vente et la complexité croissante des produits. Elles cherchent à augmenter l’efficacité de la force de vente, coordonner les ventes en équipe, faciliter la tâche du client, lui permettre de configurer ou personnaliser l’offre.

Les applications de marketing direct permettent, à partir des adresses de mener des campagnes de diffusion de messages promotionnels envers des clients ou prospects. L’automatisation du management des campagnes et des processus de marketing direct facilite la gestion et le déploiement de tels programmes, en automatisant la gestion des réponses, la segmentation de la clientèle et assure des aspects logistiques des évènements.

La planification de ressources de l’entreprise ou ERP (enterprise resource planning) se trouve au cœur de l’entreprise, derrière la vente et la gestion de la relation client et devant l’achat et les relations avec les fournisseurs. L’ERP n’est pas un seul système mais un cadre qui contient des applications administratives (finance, comptabilité), de gestion des ressources humaines (salaires, primes), planification des ressources de fabrication (MRP ou manufacturing resource planning). L’ERP est le système d’opération interne de l’entreprise, c’est la colonne vertébrale du e-business. Les entreprises qui l’ont adopté ont vu leurs stocks et leurs coûts se réduire et ont constaté une amélioration générale de leur fonctionnement. Le e-commerce favorise la diffusion de l’ERP.

L’intégration des applications d’entreprise ou l’EAI (enterprise applications integration), permet de faire communiquer tout type d’applications, que ce soit des développements « maison » ou des progiciels intégrés. L’EAI n’occupe pas une position particulière dans le flux de transformation : achat, production, vente.

Dans l’industrie de l'automobile, de grands acteurs comme Ford, General Motors et plus récemment Renault, mettent en commun leurs fournisseurs sur une place de marché (e-marketplace). Ces industriels, qui il y a quelques années construisaient encore eux-mêmes la majeure partie de leurs véhicules, vont pouvoir se recentrer sur le marketing, la gestion du client ou la distribution, et proposer ainsi des véhicules mieux adaptés aux besoins des usagers.

Déroulé dans un nouveau cadre concurrentiel caractérisé par la dérégulation et la globalisation, le processus d’intégration inter et intra-entreprises, déterminé par l’adoption des NTIC, modifie de manière substantielle les systèmes d’organisation et d’échange des entreprises. On assiste progressivement au passage de systèmes d’organisation hiérarchiques, de commande vers des systèmes collaboratifs, de type réseau. Les échanges inter et intra entreprises sont de moins en moins transactionnels et de plus en plus relationnels. Même s’il s’agit d’évolutions technologiques normales, on peut considérer l’Internet comme un phénomène éclair qui a imprégné ces changements d’un esprit ouvert et humain.

Par le recours aux nouvelles technologies en général, et à Internet en particulier, l’entreprise grâce à une information mieux maîtrisée et plus rapidement transmise à ses employés pour leur permettre de prendre plus vite les décisions les plus efficaces, peut réussir à augmenter son chiffre d’affaires et en même temps à diminuer ses coûts.

Capitolul

1

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. <?xml version=”1.0”>

02. <article fname=”19990101_xsl”>

03. <title>XML Style Sheets</title>

04. <date>January 1999</date>

05. <copyright>1999, Benoit Marchal</copyright>

06. <abstract>Style sheets add flexibility to document viewing.</abstract>

07. <keywords>XML, SXL … </keywords>

08. <section>

09. <title>Styling</title>

10.

<section>

11. <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 <url>http://www.w3.org/Style</url>.</p>

12. </section>

13. <section>

14. <title>How XSL Works</title>

15. <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 title, paragraphs and keywords.</p>

16. <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 17. </section> 18. <section> 19. …

20. </section>

21. </article>

</p>

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=”http://www.w3.org/1999/XSL/Transform

xmlns=”http://www.w3.org/TR/REC-html4.0”>

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.

<P><B><xsl:apply-templates/></B></P>

19. </xsl:template>

20. <xsl:template match=”url”>

21. <A TARGET=”_blank”>

22. <xsl:attribute name=”HREF”>

23. <xsl:apply-templates/>

24. </xsl:attribute>

25. <xsl:apply-templates/>

26. </A>

27. </xsl:template>

28. <xsl:attribute name= ”HREF”>mailto :<xsl :apply-templates/>

29. </xsl:attribute>

30. <xsl:apply-templates/>

31. </A>

32. </xsl:template>

33. <xsl:template match=”p”>

34. <P><xsl:apply-templates/></P>

35. </xsl:template>

36. <xsl:template match=”abstract | date | keywords | copyright”/>

37. </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. <!DOCTYPE html PUBLIC –

02. <HTML><HEAD><TITLE>About Style Sheet</TITLE></HEAD>

03. <BODY>

04. <P><B>XML Style Sheets</B></P>

05. <P><I>Styling</I></P>

06. <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 <A TARGET=”_blank”

href=”>http://www.w3.org/Style”>http://www.w3.org/Style</A>.

07. <P><I>How XSL Works</I></P>

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

09. <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 10. …

11. </BODY>

12. </HTML>

</P>

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!

servlet construit cu un veritabil arsenal de mijloace EJB! FIGURA 1.1 Cele trei niveluri ale modelului

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 Ada- Kaleh-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).

care respect ă un tipic de programare (vezi capitolul 6). Program, subprogram Ca s ă explic

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

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

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 ă ă 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 ă 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 ă ţ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 ă 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, ă 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.

se ocup ă de aceast ă trecere de la un proces la altul. Procesul (task) este

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

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

Capitolul

2

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

/dir/pagina.jsp,

http://adresa-sit/dir/ fie

în mod direct, prin schema de adresare tot tip URL, dar în forma următoare:

http://adresa-sit/dir/

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.

Deci se vor ocoli pa ş ii de compilare ş i înc ă rcare. FIGURA 2.1

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:

ş i pa ş ii enumera ţ i mai sus: FIGURA 2.2 Pa ş ii de

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

Un prim exemplu de pagin ă JSP în câteva variante 1. Mai întâi de toate s

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 &lt;&lt;BEST&gt;&gt; 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 ă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 ă 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: ă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 ă 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

va fi înregistrat ş i fi ş ierul cu denumirea _welcome1 FIGURA 2.3 Aspectul documentului din

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

02. <head>

03. <title>Welcome!</title>

04. </head>

05. <body>

06. <%

07. out.println("<H3 ALIGN=\"CENTER\">" + "Welcome to our store !" + "</H3>");

08. out.println("<CENTER><FONT FACE=\"Verdana\" COLOR=\"DARKGREEN\" SIZE=\"4\">" + "We sell the &lt;&lt;BEST&gt;&gt; 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 &lt;&lt;BEST&gt;&gt; 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,

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: &lt; , &gt; ).

). Deci virgulele urmau fiecărui parametru, excepţie făcând ultimul.

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

import java.io.*; import javax.servlet.*; import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.*; import javax.servlet.http.*;

test;

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 &lt;&lt;BEST&gt;&gt; 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.

Fereastra tip document a browserului

Programul de vizitare, navigatorul sau browserul, cum vreţi să îi spuneţi, este o aplicaţie.

O aplicaţie poate exista la un moment dat sub forma a unuia sau mai multe procese.

Fiecărui proces îi este asociată o fereastră de tip document. La urma urmei, browserul poate gestiona una sau mai multe fişiere cu extensia .htm/.html. Fiecărui fişier îi corespunde o fereastră document, un anume context. Fereastra document este în cadrul ferestrei de aplicaţie.

Expresii

Iată următorul caz :

LISTA 2.4 Fişierul welcome3.jsp

01. <html>

02. <head>

03. <title>Welcome!</title>

04. </head>

05. <body>

06. <%="<H3 ALIGN=\"CENTER\">" + "Welcome to our store!" + "</H3>" %>

07. <%="<CENTER><FONT FACE=\"Verdana\" COLOR=\"DARKGREEN\" SIZE=\"4\">" + "We sell the &lt;&lt;BEST&gt;&gt; products!" + "</FONT></CENTER>" %>

08. </body>

09. </html>

Explicaţii şi parafraze

Ce observăm acum? Faptul că în pagina welcome3.jsp apar două scenarii în loc de unul. Pot fi oricâte! Mai remarcăm apoi că se foloseşte câte un semn egal.

Să ne fixăm atenţia asupra textelor ce urmează semnelor egal (liniile 06 şi 07). Textele

sunt aproape identice cu ce am scris mai sus la welcome2.jsp. Este totuşi o diferenţă! Priviţi acele bare inverse ce apar din loc în loc în faţa ghilimelelor.

Am fost obligaţi să folosim aceşti dubleţi de caractere \" din motivul următor: HTML foloseşte ghilimelele pentru atributele balizelor sale. Deoarece limbajul Java foloseşte

tot ghilimele pentru literali (nu numai apostrofii), trebuie adaugat sistematic această bară

inversă (backslash) înaintea ghilimelei care delimitează o valoare de atribut HTML.

Forma echivalentă a textului de mai sus se exprimă din punct de vedere sintactic în felul acesta:

<%=expresie_Java %>

Semantica, adică înţelesul acestei transcrieri este: „evaluează pe loc expresia aflată în dreapta semnului egal şi execută ce se cere în cadrul ei”. Expresia de mai sus este o alipire (concatenation, concatenare cum spun informaticienii) de literali.

Să apară data şi ora!

LISTA 2.5 Pagina welcomets0.jsp în care apar data şi ora

01. <%@ page import='java.text.*, java.util.Date' %>

02. <html><head><title>Welcome!</title></head>

03. <body><font color="ultramarine">

04. <center>

05. <%

06. String data_ora = DateFormat.getInstance().format(new Date());

07. %>

08. <p>Today is: <%=data_ora %>

09. </center></font></body>

10. </html>

10. </html> FIGURA 2.4 Aspectul documentului Explica ţ ii ş i

FIGURA 2.4 Aspectul documentului

Explicaţii şi parafraze

Constatăm pe prima linie a listei directiva page. Limbajul JSP este alcătuit din: etichete, directive şi comenzi din cadrul scenariului JSP.

Scenariul JSP l-am întâlnit până acum sub forma expresiei şi instrucţiunii din limbajul Java. Unii le spun declaraţii. Dar să nu ne pierdem în terminologie!

Directivele stabilesc proprietăţile unei pagini JSP. Una dintre directive este şi page (pagină). Ea are multe funcţii. Nu ne propunem a le înfăţişa ca într-un manual de referinţă.

În cazul de faţă, directiva page asumă că limbajul va fi Java (lipseşte atributul language = ”nume-limbaj”), dar anunţă motorul să preia informaţiile deja definite dintr-o serie de pachete externe aplica