Modul de Implementare Web a Tranzactiilor Electronice

CAPITOLUL 1.

Bazele comertului electronic si a tranzactiilor cu carti de credit

1.1. Introducere

Comertul electronic mondial are o dinamica ascendenta pe masura ce tot mai multi consumatori si tot mai multe afaceri se conecteaza la web. Cataloagele electronice bazate pe tehnologia paginilor web reprezinta un mod eficient de a vinde o gama intreaga de bunuri si servicii printr-o interfata grafica. Dezvoltarea tehnologica face posibil un proces de imbunatatire a imaginii ofertantului prin intermediul elementelor grafice, adaugand un plus de valoare prin intermediul informatiilor din fundal, asistand procesele de cautare ale cumparatorilor, elaborand platforme orientate catre clienti, facilitand procesarea ofertei si obtinand un feedback de la clienti.

World Wide Web (www) si Internetul au modificat sistemul de aprovizionare. Site-urile web au crescut viteza de acces la informatii a cumparatorilor, printr-un cost mediu scazut si acces rapid la informatii despre distribuitori si ofertele lor. Site-urile pentru cumparaturile online si cataloagele electronice pot fi accesate in orice moment. Motoarele de cautare asista potentialul cumparator in cautarea informatiilor despre diversi vanzatori.

PricewaterhouseCoopers defineste piata electronica ca fiind o comunitate de companii ce folosesc Internetul pentru a realiza tranzactii cu celelalte companii ("E-Markets – Its Not Just …, 2000). Facand asta ele sunt capabile sa evidentieze comunicarea, imbunatatind eficienta cumpararii si colaborarea ("E-Markets – Its Not Just …, 2000). De fapt pietele electronice schimba dinamica interactiunilor dintre vanzatori si cumparatori, de la „one-to-one” la „many-to-many” (Fisher, 2000). Piata electronica permite partenerilor de tranzactii sa conduca afaceri pe internet (EDI – electronic data interchange) eliminand supra-costurile hartiei (caracteristica schimbului clasic) (Elizabeth, 2000).

Conform strategiilor de comert electronic ale corporatiei Microsoft ("E-Commerce", 2002), comertul electronic consta in orice tranzactie incheiata pe cale digitala printr-o retea. In realitate, comertul electronic inseamna mai mult decat schimbul bunurilor pe Internet. Comertul electronic este o tehnologie capabila sa ofere unei afaceri o crestere a activitatii si eficientei procesarii tranzactiilor. De asemenea, comertul electronic mai poate fi o metoda de preschimbare a informatiilor organizatiei cu clientii si vanzatorii – proces in urma caruia ambele parti au de castigat. In cele din urma, comertul electronic va inlocui treptat contractele scrise intre companii, precum si intre companii si clienti (Trepper 2000).

Cunoasterea pietelor in general este esentiala pentru intelegerea pietelor electronice. In plus, cand ai de-a face cu asemenea subiecte de actualitate cum sunt pietele electronice multi inteleg un nou spatiu in care isi pot desfasura activitatea la fel ca intr-o piata obisnuita. In mod normal, piata este locul unde se intalneste cererea cu oferta (conform definitiei data de Kotler si Armstrong 1987, p.10): „o piata este setul complet al cererii actuale si potentiale de bunuri”. Exista trei modalitati de a conduce o piata:

Pe primul loc se afla acoperirea nevoilor de baza in care fiecare entitate economica din societate isi asigura bunurile strict necesare.

In plan secund se afla schimburile descentralizate in care indivizii ii vad pe ceilalti ca pe potentiali cumparatori ce creeaza piata.

In ultimul rand sunt schimburile centralizate, reprezentate de comerciantii localizati la anumite niveluri ale pietei.

„Distribuitorii aprovizioneaza vanzatorii si se intereseaza de bunurile cerute" (Bartels, 1976). Astfel, in loc sa realizeze tranzactii cu mai multi distribuitori, indivizii actioneaza la nivelul unei singure piete. Mai mult, in timp ce numarul tranzactiilor creste in economie, creste implicit si numarul comerciantilor si cel al pietelor. Oricum, in societatile dezvoltate nu mai este necesar ca pietele sa fie locatii fizice in care vanzatorii si cumparatorii sa interactioneze (de exemplu: pietele virtuale). Prin intermediul mijloacelor moderne de transport si comunicare un comerciant isi poate deschide foarte usor un site web si poate prelua non-stop comenzi de la sute de clienti din lumea intreaga si sa expedieze bunurile cumparate intr-un timp relativ scurt fara sa existe un contact fizic.

1.2. Modele de comert electronic

Analizand aplicatiile curente dezvoltate pe Internet, identificam urmatoarele modele de afaceri in comertul electronic: magazin electronic (e-shop), aprovizionarea electronica (e-procurement), magazin electronic universal (e-mall), piata unui tert (3rd party marketplace), comunitati virtuale (virtual communities), furnizor de servicii cu valoare adaugata pentru canalele de comert electronic (value chain service provider), platforme de colaborare, brokeraj de informatii si alte servicii.

Magazinul electronic (e-shop): un magazin electronic se implementeaza prin intermediul unui site Web; acesta este administrat de companie, pentru marketingul si vanzarile propriilor produse si servicii. Minimal, contine catalogul de produse sau servicii cu descrieri tehnice si comerciale pentru fiecare pozitie din catalog. Sistemul de gestiune al bazelor de date se va ocupa cu stocarea si manipularea datelor si cu oferirea posibilitatilor de acces la date. Varianta medie a unui magazin electronic contine facilitati pentru preluarea comenzilor (prin e-mail sau formulare interactive pe care le vor completa clientii), iar varianta extinsa cuprinde si posibilitatea efectuarii on-line a platii (prin carti de credit sau alte variante electronice).

Magazinul electronic universal (e-mall): ca si in lumea reala, magazinul electronic universal este o colectie de magazine electronice, reunite sub o umbrela comuna si care, in general, accepta metode de plata comune.

Aprovizionarea electronica (e-procurement): pentru procurarea bunurilor si serviciilor, marile companii si autoritati publice organizeaza licitatii. Prin publicarea pe Web a specificatiilor ofertei, scad atat timpul cat si costul de transmisie, marindu-se si numarul de firme care iau parte la licitatie. Astfel, creste concurenta si scade pretul.

Piata unui tert (3rd party marketplace): se apeleaza la o interfata utilizator pentru catalogul de produse al companiei, interfata ce apartine unui tert (ex.: furnizor de servicii Internet sau o banca). Aceasta metoda are avantajul ca interfata este unica pentru mai multi producatori, utilizatorii fiind familiarizati cu folosirea ei. Acest model de afaceri este mai putin folosit in comparatie cu cele precedente, dar am considerat ca merita mentionat.

Comunitati virtuale (virtual communities): valoarea cea mai importanta a unei comunitati virtuale este data de catre membrii sai (clienti sau parteneri), care adauga informatii proprii peste un mediu de baza furnizat de companie. Fiecare membru poate oferi spre vanzare produse sau servicii sau poate adresa cereri de cumparare a unor produse sau servicii. Calitatea de membru al unei comunitati virtuale presupune plata unei taxe.

Furnizor de servicii cu valoare adaugata (value chain service provider): furnizorii de servicii sunt specializati pe functii specifice, cum ar fi asigurarea logisticii, plata electronica sau expertiza in managementul productiei si a stocurilor. Plata acestor servicii se face pe baza unor tarife sau a unei cote procentuale.

Platforme de colaborare: platformele de colaborare cuprind un set de instrumente si un mediu informational pentru colaborarea intre companii. Acestea pot adresa functii specifice, cum ar fi conceptia sau proiectarea in colaborare. Castigurile provin din managementul platformei (taxa de membru sau taxa de utilizare), si din vanzari de instrumente specializate (pentru proiectare, workflow si gestiunea de documente). Prin workflow se intelege fluxul de documente, care implica doua entitati: o parte pasiva (documentele) si o parte activa (deplasarea acestor documente). Brokeraj de informatii si alte servicii: exemplele cuprind cataloage de clienti clasificati pe profil, vanzarea de oportunitati de afaceri, consultanta in domenii specializate. O categorie speciala o constituie serviciile de incredere furnizate de autoritatile de certificare sau de notariatele electronice.

Pentru vanzarea de continut se disting trei modele: vanzarea pe baza de subscriere (inregistrare), vanzarea la nivel de obiect (pay-per-view), sprijinirea vanzarilor prin publicitate si acordarea de produse gratuite pentru incurajarea vanzarilor viitoare sau pentru vanzarile de produse inrudite cu produsele gratuite:

Vanzarea pe baza de subscriere: acest model, folosit in special pentru vanzarea revistelor si a programelor televiziunilor prin cablu este principalul model folosit si de serviciile comerciale on-line. Se poate subscrie la servicii on-line precum MSN (Microsoft Network) sau AOL (America On-Line), la publicatii on-line, precum USA Today sau Wall Street Journal, sau chiar la jocuri on-line, cum ar fi celebrul Meridian 59, produs de 3DO. Jupiter Communications prevede ca pana in anul 2005 peste 40% dintre utilizatorii Web vor adera la cel putin una dintre formele de subscriere prezentate mai sus.

Vanzarea la nivel de obiect (pay-per-view): reprezinta o alternativa viabila la vanzarea pe baza de subscriere, si se refera la vanzarea anumitor informatii la bucata. In functie de necesitatile clientului, acesta poate decide sa cumpere un anumit articol dintr-un ziar, un anumit capitol dintr-o carte sau chiar un joc in sistem pay-per-view. Se poate cumpara chiar si o simpla interogare intr-o baza de date! Modelul pay-per-view este in continua testare. Deocamdata, el se confrunta cu probleme precum lipsa unei certitudini pentru client ca informatia pe care doreste sa o cumpere merita banii. De asemenea, pentru vanzatori, plata prin carte de credit pentru tranzactii de valoare foarte mica nu poate fi acceptata. Acest obstacol poate fi trecut o data cu aparitia micro-platilor.

Vanzarea de continut prin publicitate: modelul cu cel mai mare succes in ceea ce priveste vanzarea de continut il reprezinta publicitatea. In topul site-urilor cu cele mai mari venituri din publicitate se afla motoarele de cautare (search engines), precum Yahoo! sau Infoseek, si mai putin site-urile de continut. Intrucat serviciile de cautare sunt esentiale pentru gasirea informatiilor relevante pe Web, companiile sunt dispuse sa plateasca pentru bannere, care nu sunt altceva decat reclame pe care clientii pot apasa pentru a ajunge pe site-ul companiei respective.

e-Business este o integrare a mai multor domenii de aplicatii intr-un sistem care conecteaza o anumita afacere cu partenerii, clientii si furnizorii. Aceste sisteme nu sunt gandite neaparat numai in termeni de tehnologie Web, cu toate ca toate – sau aproape toate – sistemele care folosesc tehnologia Web pentru interfetele cu utilizatorii.

Scopul modelelor de e-business este de a reprezenta intr-un mod cat mai accesibil tipul de afacere si arhitectura sistemului (topologia aplicatiei si topologia de rulare) pentru diferite clase de aplicatii. Aceste modele descriu interactiunea dintre participantii la o solutie de e-business. In momentul de fata sunt definite sase modele de e-business: User-to-Business, User-to-Online Buying, Business-to-Business, User-to-Data, User-to-User si Aplication Integration.

Modelul User-to-Business (U2B) – este cazul general in care un utilizator (intern sau extern) interactioneaza asupra datelor si tranzactiilor unei intreprinderi. In caz particular se poate aplica la o intreprindere care ofera servicii sau bunuri care nu pot fi prezentate si vandute prin catalog. Poate fi vazut ca acoperind toate interactiunile de tip User-to-Business care nu sunt acoperite de modelul User-to-Online Buying.

Modelul User-to-Online Buying (U2OB) – este folosit pentru a descrie un caz special (un subset al modelului User-to-Business) in care bunure continut prin publicitate: modelul cu cel mai mare succes in ceea ce priveste vanzarea de continut il reprezinta publicitatea. In topul site-urilor cu cele mai mari venituri din publicitate se afla motoarele de cautare (search engines), precum Yahoo! sau Infoseek, si mai putin site-urile de continut. Intrucat serviciile de cautare sunt esentiale pentru gasirea informatiilor relevante pe Web, companiile sunt dispuse sa plateasca pentru bannere, care nu sunt altceva decat reclame pe care clientii pot apasa pentru a ajunge pe site-ul companiei respective.

e-Business este o integrare a mai multor domenii de aplicatii intr-un sistem care conecteaza o anumita afacere cu partenerii, clientii si furnizorii. Aceste sisteme nu sunt gandite neaparat numai in termeni de tehnologie Web, cu toate ca toate – sau aproape toate – sistemele care folosesc tehnologia Web pentru interfetele cu utilizatorii.

Scopul modelelor de e-business este de a reprezenta intr-un mod cat mai accesibil tipul de afacere si arhitectura sistemului (topologia aplicatiei si topologia de rulare) pentru diferite clase de aplicatii. Aceste modele descriu interactiunea dintre participantii la o solutie de e-business. In momentul de fata sunt definite sase modele de e-business: User-to-Business, User-to-Online Buying, Business-to-Business, User-to-Data, User-to-User si Aplication Integration.

Modelul User-to-Business (U2B) – este cazul general in care un utilizator (intern sau extern) interactioneaza asupra datelor si tranzactiilor unei intreprinderi. In caz particular se poate aplica la o intreprindere care ofera servicii sau bunuri care nu pot fi prezentate si vandute prin catalog. Poate fi vazut ca acoperind toate interactiunile de tip User-to-Business care nu sunt acoperite de modelul User-to-Online Buying.

Modelul User-to-Online Buying (U2OB) – este folosit pentru a descrie un caz special (un subset al modelului User-to-Business) in care bunuri sunt vandute printr-un catalog folosind un card de cumparari, un portofel, etc. Acest model include ambele cazuri de consumatori: care cumpara bunuri si care se aprovizioneaza de la un singur furnizor. Poate cuprinde legaturi cu sisteme de gestiune, de verificare de carti de credit, de livrare etc.

Modelul Business-to-Business (B2B) – este folosit pentru a descrie doua tipuri de interactiune intre doua intreprinderi:

Tipul (B2Bi) este cazul in care exista un contract de parteneriat intre intreprinderi, un exemplu in acest sens fiind o aplicatie pentru un lant de desfacere.

Tipul (B2M2B) este cazul unui e-MarketPlace, deci existenta unei piete electronice in care interactioneaza mai multi cumparatori si mai multi furnizori.

Modelul User-to-User (U2U) – descrie cazul colaborarii diferitilor utilizatori prin intermediul documentelor partajate, prin intermediul e-mail, etc.

Modelul User-to-Data (U2D) – descrie cazul in care utilizatorii au nevoie de cantitati insemnate de date, text, imagini, etc. si folosesc diverse instrumente pentru a extrage informatii.

Modelul Application Integration – folosit pentru integrarea diverselor aplicatii intr-o solutie de afacere, si poate fi utilizat atat in cadrul unui singur tip de afacere sau intre mai multe tipuri de afacere.

1.3. Sisteme electronice de plati

In domeniul mijloacelor electronice de plata, cercetarile sun in plina desfasurare. Exisa numeroase sisteme in curs de experimentare, altele abia au fost cercetate si supuse analizei. Este normal ca prudenta si securitatea sa fie cuvintele cheie ale acestor demersuri. Vom prezenta in continuare cateva sisteme de plati electronice mai cunoscute, grupate in patru categorii:

Sisteme cu carduri bancare.

Sisteme on-line.

Microplati.

Cecuri electronice.

Aceste noi mijloace de plata permit transferarea comoda, sigura si foarte rapida a banilor intre partenerii de afaceri. De asemenea, inlocuirea monedelor si bancnotelor (actualele forme traditionale de numerar) prin ceea ce denumim bani electronici conduce, pe langa reducerea costurilor de emitere si mentinere in circulatie a numerarului, si la o sporire a flexibilitatii si securitatii sistemelor de plati.

In ciuda unor campanii promotionale de anvergura derulate in occident, cu exceptia cartilor de credit nici una din noile metode de plata promovate nu a atins masa critica. Tranzactiile on-line care folosesc plata cu carduri sunt protejate criptografic, iar modalitatea concreta de criptare asigura faptul ca numai banca sau furnizorul de servicii pentru carduri de credit va putea vedea numarul cartii de credit, nu si comerciantul. Cu doar cativa ani in urma scepticii sustineau ca foarte putini clienti vor fi dispusi sa ofere on-line informatii referitoare la propriul card de credit (numarul acestuia). Realitatea de astazi, cand multe din cele mai populare situri de comert electronic accepta doar plata cu card de credit, vine sa ne arate ca acestia s-au inselat.

O parte din proces implica incheierea unor aliante/contracte cu institutii financiare, in timp ce din punct de vedere tehnic presupune utilizarea unor tehnologii avansate de criptare si autentificare pentru securizarea mesajelor trimise via Internet. Unul din primii pasi pe care trebuie sa-l faca comerciantul este sa-si deschida un cont la o banca care ofera servicii de tranzactionare on-line bazate pe carduri. Costurile pe care va trebui sa le suporte comerciantul includ o parte fixa, reprezentata de costul achizitionarii sau inchirierii echipamentelor si softului aferent necesare realizarii comunicarii securizate cu banca (de exemplu, implementarea unui firewall este obligatorie), precum si costuri variabile rezultate in urma comisioanelor precepute de banca/tranzactie.

De regula institutia financiara impune un volum minim de tranzactii/luna (cost variabil minim acceptat), percepand o suma minima pe care comerciantul o plateste indiferent de numarul de tranzactii pe care le deruleaza on-line. In schimb, poate fi avantajos pentru comerciant sa apeleze la o agentie de carduri care ofera servicii de tranzactionare on-line. Datorita volumului mare de tranzactii pe care aceste agentii le deruleaza, pot obtine discounturi semnificative de la banci si in consecinta au oferte mai tentante pentru clienti – societati comerciale care doresc sa-si puna o parte din business on-line.

Multe cumparari de bunuri si servicii prin Internet se fac platindu-se cu carduri bancare obisnuite (Visa, MasterCard etc.). Insa tranzactiile cu carduri contin informatii confidentiale privind cardul si informatiile personale ale clientilor, informatii ce pot fi interceptate in timpul transmisiei prin Internet. Fara un soft special, orice persoana care monitorizeaza traficul pe retea poate citi continutul acestor date confidentiale si le poate folosi ulterior Este necesara elaborarea unor standarde specifice sistemelor de plati, care sa permita coordonarea partilor legitime implicate in transfer si folosirea corecta a metodelor de securitate.

In 1996, MasterCard si Visa au convenit sa consolideze standardele lor de plati electronice intr-unul singur, numit SET (Secure Electronic Transaction). Protocolul SET isi propune sapte obiective de securitate in e-commerce:

Sa asigure confidentialitatea instructiunilor de plata si a informatiilor de cerere care sunt transmise odata cu informatiile de plata.

Sa garanteze integritatea tuturor datelor transmise.

Sa asigure autentificarea cumparatorului precum si faptul ca acesta este utilizatorul legitim al unei marci de card.

Sa asigure autentificarea vanzatorului precum si faptul ca acesta accepta tranzactii cu carduri prin relatia sa cu o institutie financiara achizitoare.

Sa foloseasca cele mai bune metode de securitate pentru a proteja partile antrenate in comert

Sa fie un protocol care sa nu depinda de mecanismele de securitate ale transportului si care sa nu impiedice folosirea acestora.

Sa faciliteze si sa incurajeze interoperabilitatea dintre furnizorii de soft si cei de retea.

Aceste cerinte sunt satisfacute de urmatoarele caracteristici ale acestei specificatii:

Confidentialitatea informatiei – Pentru a facilita si incuraja comertul electronic folosind cartile de credit, este necesara asigurarea detinatorilor de cartele ca informatiile de plata sunt in siguranta. De aceea, contul cumparatorului si informatiile de plata trebuie sa fie securizate atunci cand traverseaza reteaua, impiedicand interceptarea numerelor de cont si datele de expirare de catre persoane neautorizate. Criptarea mesajelor SET asigura confidentialitatea informatiei.

Integritatea datelor – Aceasta specificatie garanteaza ca nu se altereaza continutul mesajelor in timpul transmisiei acestora prin retea. Informatiile de plata trimise de cumparator la vanzator contin informatii de cerere, date personale si instructiuni de plata. Daca una din aceste informatii este modificata, tranzactia nu se va face corect. Protocolul SET foloseste semnatura digitala pentru integritatea datelor.

Autentificarea cumparatorului – Vanzatorul are nevoie de un mijloc de verificare a clientului sau, a faptului ca acesta este utilizatorul legitim al unui numar de cont valid. Un mecanism care face legatura dintre posesorul cartii de credit si un numar de cont specific va reduce incidenta fraudei si, prin urmare, costul total al procesului de plata. SET utilizeaza semnatura digitala si certificatele cumparatorului pentru autentificarea acestuia.

Autentificarea vanzatorului – Aceasta specificatie furnizeaza un mijloc de asigurare a clientului ca furnizorul are o relatie cu o institutie financiara, permitandu-i acestuia sa accepte cartile de credit. SET utilizeaza semnatura digitala si certificatele vanzatorului pentru autentificarea acestuia.

Interoperabilitate – Protocolul SET trebuie sa fie aplicabil pe o varietate de platforme hardware si soft. Orice cumparator trebuie sa poata sa comunice, cu softul sau, cu orice vanzator. Pentru interoperabilitate, SET foloseste formate de mesaje si protocoale specifice.

Cumpararea electronica – Intr-un scenariu tipic de e-commerce, etapele procesului de cumparare sunt urmatoarele:

Cumparatorul poate cauta bunuri si servicii avand mai multe posibilitati:

Foloseste un browser pentru a consulta cataloage online din pagina de Web a vanzatorului.

Consulta un catalog suplimentar aflat pe un CDROM.

Consulta un catalog pe hartie.

Cumparatorul alege bunurile pe care doreste sa le cumpere.

Cumparatorului ii este prezentata o lista a bunurilor, incluzand pretul acestora si pretul total, cu tot cu taxe.Aceasta lista trebuie furnizata electronic de serverul vanzatorului sau de softul de cumparare electronica din calculatorul clientului. Uneori se accepta negocierea pretului.

Cumparatorul alege mijloacele de plata. Sa consideram ca este ales ca mijloc de plata cartela de credit (cardul).

Cumparatorul trimite vanzatorului o cerere impreuna cu instructiunile de plata. In aceasta specificatie, cererea si instructiunile de plata sunt semnate digital de catre cumparatorii care poseda certificate.

Vanzatorul solicita autorizatia de plata a clientului sau de la institutia financiara a acestuia.

Vanzatorul trimite confirmarea cererii.

Vanzatorul trimite bunurile sau indeplineste serviciile solicitate in cerere.

Vanzatorul solicita plata bunurilor si serviciilor de la institutia financiara a cumparatorului.

Criptografia in SET – pentru a asigura securitatea platilor, SET foloseste perechi de chei RSA pentru a crea semnaturi digitale si pentru secretizare. Prin urmare, fiecare participant in procesul de tranzactionare poseda doua perechi de chei asimetrice: o pereche de chei "de schimb" – folosita in criptare si decriptare – si o pereche "de semnatura", pentru crearea si verificarea semnaturii digitale. De mentionat faptul ca rolul cheilor "de semnatura" este inversat in procesul de semnare digitala unde cheia privata este folosita pentru criptare (semnare), iar cea publica este folosita pentru decriptare (verificare a semnaturii).

Autentificarea este intarita de utilizarea certificatelor. Inainte ca un destinatar B sa primeasca un mesaj semnat digital de catre un emitator A, el vrea sa fie sigur ca detine cheia publica a lui A si nu a altuia care s-a recomandat drept A prin retea. O alternativa ar fi ca receptorul B sa primeasca cheia publica direct de la A printr-un canal de comunicatie securizat. De cele mai multe ori, insa, aceasta solutie nu poate fi practicata. Transmisia securizata a cheilor este realizata de un "tert de incredere" numit Autoritate de Certificate (AC), care-l asigura pe B ca A este proprietarul cheii publice pe care o detine. Autoritatea de Certificate furnizeaza certificate care fac legatura dintre un nume de persoana si o cheie publica. Utilizatorul A prezinta AC-ului informatii de identitate. AC-ul creaza un mesaj cu numele lui A si cheia publica a acestuia. Acest mesaj, numit certificat, este semnat digital de catre Autoritatea de Certificate. El contine informatii de identificare a proprietarului, precum si o copie a cheii publice (de schimb sau de semnatura). Participantii SET vor avea, de asemenea, doua certificate pentru cele doua perechi de chei: certificate "de semnatura" si certificate "de schimb". Certificatele sunt create si semnate in acelasi timp de catre AC.

Protocolul SET introduce o noua aplicatie a semnaturilor digitale, si anume conceptul de semnatura duala. Sa consideram urmatorul scenariu: vanzatorul B trimite o oferta cumparatorului A si o autorizatie bancii sale pentru a transfera banii, daca A accepta oferta. Insa B doreste ca banca sa nu vada termenii ofertei, si nici cumparatorul informatiile sale de cont. In plus, B vrea sa faca o legatura dintre oferta si transfer, astfel incat banii vor fi transferati doar daca A accepta oferta sa. El realizeaza toate acestea semnand digital ambele mesaje intr-o singura operatie care creeaza semnatura duala.

O semnatura duala este generata prin calcularea rezumatelor ambelor mesaje si concatenarea celor doua rezumate. Rezultatului obtinut i se calculeaza, la randul sau, un rezumat si, in cele din urma, acest ultim rezumat este cifrat cu cheia privata de semnatura a emitatorului. Trebuie inclus si rezumatul celuilalt mesaj pentru ca oricare din cei doi primitori sa valideze semnatura duala. Un primitor al oricarui mesaj ii poate verifica autenticitatea prin generarea rezumatului acestuia, concatenarea cu rezumatul celuilalt mesaj, si calcularea rezumatului rezultatului concatenarii. Daca noul rezumat se potriveste cu semnatura duala decriptata, primitorul poate fi sigur de autenticitatea mesajului.

Daca A accepta oferta lui B, trimite un mesaj bancii indicand acceptul sau si incluzand rezumatul ofertei. Banca poate verifica autenticitatea autorizatiei de transfer a lui B si se asigura ca acceptul este pentru aceeasi oferta prin utilizarea rezumatului autorizatiei pe care l-a primit de la B si a rezumatului ofertei prezentat de A pentru a valida semnatura duala. Astfel, banca poate controla autenticitatea ofertei, dar nu poate vedea termenii ofertei.

In cadrul protocolului SET, semnatura duala este folosita pentru a face legatura dintre un mesaj de comanda trimis vanzatorului si instructiunile de plata continand informatii de cont trimise achizitorului. Cand vanzatorul trimite o cerere de autorizatie achizitorului, include instructiunile de plata primite de la cumparator si rezumatul informatiilor de comanda. Achizitorul foloseste rezumatul primit de la vanzator si calculeaza rezumatul instructiunilor de plata pentru a verifica semnatura duala.

In prezent, tot mai multe produse de e-commerce implementeaza protocolul SET, ceea ce confera securitate platilor Internet cu card, prin mijloace criptografice.

1.4. Securitatea comunicatiilor

Unul din subiectele fierbinti care a tinut de nenumarate ori capul de afis in presa scrisa, TV si in special pe Internet reprezinta securitatea tranzactiilor. Stim cu totii ca, odata ce informatiile pe care le-am transmis in site, parasesc calculatorul personal si isi incep calatoria pe Internet, ele apartinand domeniului public. Un hacker priceput ar putea sa le intercepteze si sa le foloseasca asa cum crede de cuviinta. Nu este deloc usor, este putin probabil, dar este posibil.

In ce-l priveste pe consumator, el va fi foarte interesat de garantiile de securitate pe care le ofera magazinul virtual. Solutia utilizata pe scara larga la aceasta ora este SSL (Secure Socket Layer) – server securizat de date – in combinatie cu Certificatul Digital (Digital Certificate). Certificatul Digital este cel care recunoaste standardul si confirma ca serverul pe care se afla web site-ul utilizeaza intr-adevar criptarea SSL atunci cind primeste si transmite datele. In momentul in care sunt accesate pagini in care se cer informatii de plata de la consumator, acestea trebuie sa se afle pe un astfel de server securizat. Paginile de acest fel au in URL "https:" (Hyper Text Transfer Protocol Secure). Fara SSL si un Certificat Digital, nici un consumator avizat nu-si va transmite datele cartii de credit prin Internet.

Certificatele digitale sunt obtinute de la autoritati de certificare precum Verisign GeoTrust, Thawte etc. care asigura vizitatorul ca detinatorul certificatului este individul sau organizatia care pretinde ca este. Cu toate ca necesita destul de multi pasi pentru realizarea unei conexiuni, si ca nu este in totalitate sigur, protocolul de comunicatie SSL este probabil una din cele mai bune optiuni existente la ora actuala, si popularitatea lui va creste odata cu schimbarea politicii de export a cifrurilor sau algoritmilor de codificare.

Securitatea reprezinta un proces – un mod de a gandi legat de sisteme, retele, utilizatori si aplicatii care imbratiseaza un set de tehnologii. Setul minim de cerinte pe care trebuie sa le respecte o aplicatie ce utilizeaza sistemele bazate pe securitate sunt:

Confidentialitatea: mentinerea caracterului privat al informatiei.

Integritatea: dovada ca respectiva informatie nu a fost modificata.

Autenticitatea: dovada identitatii celui ce transmite mesajul.

Non-repudierea: siguranta ca cel ce genereaza mesajul nu poate sa-l denigreze mai tarziu.

Toate aceste proprietati pot fi indeplinite prin utilizarea de chei publice criptografice. Criptografia este considerata a fi o arta sau stiinta de mentinere a mesajelor secrete, asigurand confidentialitatea prin criptarea unui mesaj utilizand chei asociate cu un algoritm. Cheia utilizata trebuie sa fie secreta ambelor parti, problema reprezentand-o managementulcheilor si mentinerea lor secreta.

Criptografia are la baza codificarea mesajelor, un bloc fiind substituit prin altul, respectand anumite reguli. Codificarea se poate realiza in mai multe moduri acestea avand urmatoarele proprietati comune:

Atat intrarile cat si iesirile sunt reprezentate ca stream-uri de octeti.

Criptarea unei date se realizeaza cu ajutorul unei chei.

Decriptarea datei se realizeaza tot cu o cheie.

Criptarea se poate realiza cu chei simetrice sau asimetrice. Prima se realizeaza cu aceeasi cheie la criptare si la decriptare, iar cealalta cu chei diferite.

Criptarea asimetrica – are avantajul ca una din chei (cea de criptare) poate fi facuta publica. Aceasta cheie de criptare poate fi transmisa oricui, in timp ce cheia de decriptare este detinuta de cel ce a criptat, fiind denumita cheie privata.Un alt avantaj al cheilor asimetrice este ca asigura identitatea. Daca o persoana X cripteaza un mesaj cu I cheie privata si transmitandu-l unei persoane Y, aceasta il poate decripta cu o cheia publica putem spune ca Y are certitudinea ca mesajul vine de la X. Aceasta idee are la baza semnaturile digitale.

Criptarea simetrica – are avantajul vitezei, fiind foarte utila la criptarea fisierelor locale. Combinand avantajele celor doua tipuri de algoritmi au aparut protocoalele hibride care functioneaza astfel:

Criptarea mesajului:

Generarea cheii simetrice K.

Criptarea mesajului M cu cheia simetrica si obtinand mesajul M*.

Preluarea cheii publice.

Criptarea cheii simetrice cu cheia publica si obtinerea lui K*.

Transmiterea perechii {K*,M*}.

Decriptarea mesajului:

Receptionarea mesajului {K*,M*} si separarea celor doua campuri.

Decriptarea lui K* cu ajutorul cheii private proprii pentru obtinerea lui K.

Decriptarea lui M* cu K pentru obtinerea lui M.

In acest caz se genereaza cate o cheie separata pentru fiecare sesiune de mesaje cunoscuta sub numele de cheie sesiune. Criptarea mesajelor ofera confidentialitate, dar acest lucru nu este suficient. In cazul unei transmisii sau receptii trebuie sa existe certitudinea ca cel ce a generat mesajul este o persoana autorizata, motiv care a dus la adaugarea de noi proprietati cum ar fi integritatea si autentificarea, acestea fiind asigurate cu ajutorul semnaturii digitale.

Pentru a intelege modul de functionare este nevoie de cunoasterea unui al treilea algoritm si anume functiile de hashing. Acestea, spre deosebire de algoritmii de criptare si decriptare realizeaza doar functia de criptare iar mesajul original nu va fi recuperat niciodata. In principiu, un mesaj are intotdeauna aceeasi valoare dupa aplicarea functiei si este imposibil ca doua mesaje oarecare sa genereze aceeasi valoare.

Prin utilizarea unei astfel de functii se poate obtine o autentificare fara a cripta intreg mesajul cu acea cheie privata astfel:

Semnarea unui mesaj:

Efectuarea de hashing asupra mesajului M si obtinerea valorii H.

Criptarea lui H cu cheia privata (a celui ce transmite) si obtinerea semnaturii S.

Transmiterea perechii {M,S}.

Verificarea unui mesaj semnat:

Receptia {M,S} si separarea lor.

Efectuarea de hashing asupra lui M si obtinerea valorii H'.

Preluarea cheii publice apartinand celui ce a transmis.

Decriptarea lui S cu cheia publica si obtinerea lui H''.

Compararea lui H' cu H''. Daca H' si H'' sunt identice, mesajul a fost verificat corect, iar daca nu, exista o eroare.

Pentru a putea construi cheia ce se utilizeaza in timpul transmisiei se apeleaza la „o treia parte” de incredere denumita Autoritate Certificatoare (CA – Certification Authority). Ea genereaza un Certificat Digital ce genereaza o cheie publica. Cheia nu trebuie sa contina ambiguitati, ingloband datele personale care apoi sunt impachetate si semnate.

Un Certificat Digital este un document ce contine patru componente mari:

Cheie publica.

Informatia ce leaga cheia publica de detinatorul ei.

Informatia de validitate a certificatului.

Semnatura digitala.

Certificatele sunt clasificate ca: certificate self-signed si certificate CA-signed. Primul este semnat de detinatorul cheii iar al doilea de o alta persoana cu autoritate. Ele functioneaza ca si containere de chei publice iar informatia tipica include:

Numele detinatorului.

E-mail-ul acestuia.

Numele companiei.

Telefonul.

Informatii legate de certificat.

Un numar serial.

Un indicator de nivel de incredere.

Data generarii.

Data expirarii.

Informatia colectata si detinuta de proprietar este referita de nume distincte (sau Dname). Un certificat contine doua Dname: al detinatorului si al celui ce l-a generat. Non-repudierea este o alta proprietate a securitatii oferind certitudinea ca cel ce transmite mesajul nu poate sa nege mai tarziu ce a transmis.

Din cele prezentate putem sa observam ca: integritatea, confidentialitatea si non-repudierea sunt asigurate prin criptografia cheilor publice. Pentru aceasta trebuie insa sa se stie: cine genereaza certificatul, unde este stocata cheia si unde se gasesc certificatele? Un certificat digital bazat pe infrastructura cheilor publice(PKI – Public Key Infrastructure) asigura rezolvarea tuturor problemelor.

Componentele PKI sunt

Autoritatea Certificatoare(CA): responsabila cu generarea si revocarea certificatelor.

Autoritatea Registratoare(RA): responsabila cu verificarea constructiei generate de cheile publice si identitatea detinatorilor.

Detinatorii de Certificate(subiectii): Oameni, masini sau agenti software care detin certificate si le pot utiliza la semnarea documentelor.

Clientii: ei valideaza semnatura digitala si certificarea de la un CA.

Depozitele: stocheaza si fac accesibile certificatele si Listele de Revocare a Certificatelor (CRLs -Certificate Revocation Lists).

Politicile de securitate: definesc procesele si principiile de utilizare a criptografiei.

Dintre functiile realizate cu ajutorul PKI putem mentiona:

Inregistrarea: este un proces in care cel ce doreste sa obtina un certificat de la CA isi prezinta atributele sale. Acestea sunt verificate iar apoi se elibereaza certificatul.

Certificarea: este procesul in care CA elibereaza certificatul ce contine cheia publica subiectului apoi il depune intr-un depozit public.

Generarea Cheilor: in multe cazuri subiectul genereaza o pereche de chei in mediul sau, inainte de a transmite cheia publica la CA pentru certificare.Daca CA raspunde pentru generarea cheilor, acestea sunt oferite subiectului ca un fisier criptat sau token fizic asemeni unui smartcard.

Recuperarea Cheilor: in unele implementari PKI necesita ca toate cheile schimbate si/sau criptate sa fie depuse intr-un depozit securizat. Ele sunt recuperabile daca subiectul pierde cheia, acest lucru revenind lui CA sau sistemului de recuperare.

Actualizarea Cheilor: toate cheile perechi si certificatele lor asociate trebuie actualizate la un interval regulat. In acest sens exista doua situatii care necesita acest lucru:

Data care este specificata in certificat ca data de expirare este depasita si se actualizeaza.

Cheia privata a uneia din entitati din PKI este compromisa. In acest caz PKI trebuie sa anunte ca vechiul certificat nu mai este valid si urmeaza sa-l inlocuiasca. Una din cai este de pre-generare si stocare securizata a perechilor de chei pentru astfel de situatii. Actiune ce duce la informarea fiecarui utilizator de acest lucru. Alta cale este metoda "out-of-band" unde cu ajutorul telefonului, faxului, scrisorii se transmite acea cheie.

Certificarea incrucisata: permite utilizatorilor dintr-un domeniu administrativ sa utilizeze certificate generate de un CA operational in alt domeniu. Procesul implica un CA (CA_1) ce ofera o certificare pentru alt CA(CA_2). Acest certificat contine cheia publica CA asociata cu cea privata pe care CA_1 o utilizeaza, lucru ce permite subiectilor certificati prin CA_2 sa accepte certificatele generate de CA_1 sau orice CA subordonat.

Revocarea: apare in momentul expirarii perioadei de validitate care poate aparea cand: subiectul isi schimba numele, angajatul paraseste compania, cheia privata este compromisa. In cadrul standardului X.509, pentru a revoca un certificat se utilizeaza Lista Revocarilor Certificatelor (CRL – Certificate Revocation List). Aceasta lista identifica certificate si sunt semnate de CA.

Criptarea prin chei publice si implementarea lor in certificate digitale bazate pe sisteme de securitate se face pe baza unor retele standardizate si protocoale cum ar fi SSL.

SSL (Secure Sockets Layer) este un protocol non-proprietar deschis, dezvoltat de Netscape si care asigura securitate in comunicatii. Este acceptat de standardul WEB pentru autentificare si criptare client-server utilizand ca protocol de transport TCP/IP si poate rula pe protocoale ca HTTP, Telnet. El utilizeaza chei publice criptografiate. Principiul de functionare este urmatorul:

Clientul se conecteaza la un server SSL.

Clientul cere sa initieze o sesiune securizata.

Serverul intoarce: pot/nu pot suporta SSL.

Clientul si serverul comunica informatia securizata pas cunoscut sub denumirea de „handshaking”.

Clientul specifica ID-ul sesiunii, algoritmii de criptare si metodele de compresie.

Serverul poate face selectia utilizand aceasta informatie si schimba daca este nevoie certificatele.

Serverul specifica o cheie a sesiunii apropiata de algoritmii de criptare alesi la „handshaking”.

Clientul si serverul comunica in securitate.

O sesiune SSL implica doua protocoale separate: SSL Record Protocol si SSL Handshake Protocol. Primul controleaza transmisia datelor in cadrul sesiunii iar celalalt schimbul de mesaje intre client si server cand stabilesc prima data conexiunea.Tehnica criptarii genereaza multe pachete, incetinind transmisia. SSL 3.0 este cel mai utilizat si suportat de majoritatea WEB si serverelor Internet. TLS (Transport Layer Security) – este ultima versiune SSL.

S/MIME (Secure Multi-Purpose Internet Mail Extensions) – este un standard utilizat in transmiterea de e-mail in securitate. Permite criptarea informatiei si include certificatul digital ca o componenta in mesaj. El asigura functiile:confidentialitate, doar cel ce receptioneaza poate citi, posta transmisia nu poate fi alterata, clientul poate semna si include semnatura care garanteaza receptia, utilizeaza etichete pentru controlul accesului la mesajele securizate. Permite mesajelor criptate sa fie transmise prin agenti intermediari care le pot cripta si transmite la recipientele dorite. S/MIME ofera integritate si autentificare oricarui pachet e-mail si in prezent a este implementat la nivel industrial.

WTLC – este o versiune wireless al standardului TLS transformarea fiind bazata pe necesitatea suportarii datagramelor in mediile de banda larga. Pentru aceasta el utilizeaza un handshake optimizat prin refresh al cheilor dinamice. Acesta permite cheilor criptate sa fie actualizate regulat intr-o sesiune.

OCSP (On line Certificate Status Protocol) – specifica o sintaxa mesaj cerere-raspuns intre aplicatia client care solicita revocarea certificatului si aplicatia server care cunoaste starea certificatului revocat. OCSP server poate asigura informatii aditionale accesibile prin CRL Principiul functionarii este urmatorul:

Aplicatia transmite cererea de a cunoaste starea certificatului la serverul OCSP, acesta transmite o semnatura digitala care reprezinta „bun”, „revocat” sau „necunoscut”.

Cel identificat ca „bun” indica la minim ca certificatul nu a fost revocat la momentul cererii, ulterior el putand aparea ca revocat.

„revocat” indica ca respectivul certificat a fost revocat.

„unknown” indica ca nu cunoaste respectivul certificat.

Din cele prezentate se observa ca in cazul dezvoltarii de aplicatii ce utilizeaza Internetul sau Intranetul, cerintele unei bune securitati sunt confidentialitatea, integritatea, autentificarea si non-repudierea. Toate acestea se realizeaza prin utilizarea cheilor publice criptografiate in Certificate Digitale si care utilizeaza protocoale ca SSL sau S/MIME.

1.5. Arhitectura n-tier

Aplicatiile de tip three-tier si n-tier sunt dezvoltate, in general, pe baza paradigmei componentelor. Fiecare din nivelele aplicatiei contin propriile componente, implementate astfel incat sa rezolve sarcinile specifice nivelului respectiv.

Termenul componenta reprezinta inca o notiune controversata in comunitatea programarii orientate pe obiecte, fiind de multe ori folosit ca sinonim pentru obiectele economice complexe. Exista totusi o serie de diferente importante intre cele doua concepte:

Obiectele sunt create ca instante ale claselor. Clasa este cod sursa care defineste datele obiectului precum si metodele de manipulare a acestora.

Componentele sunt cod binar precompilat. Fiind precompilate, componentele sunt independente de limbajul in care au fost implementate.

La un nivel elementar, putem defini componenta ca fiind un grup pre-compilat de obiecte. O parte din aceste obiecte vor fi utilizate de catre programe client (obiecte publice), in timp ce altele sunt destinate exclusiv operatiilor din interiorul componentei (obiecte private). Componenta este deci similara unei aplicatii de dimensiuni mici, avand in plus capacitatea e a-si pune functionalitatea la dispozitia altor aplicatii.

Aplicatiile distribuite contin, in general, trei tipuri de componente:

Componente standard – ofera o functionalitate foarte larga, fiind utilizabile si necesare intr-o gama variata de aplicatii. (ADO, RDO, etc). Marile companii de software pun la dispozitia programatorilor un numar mare de componente generale, fiind preferabila si recomandabila utilizarea acestora in locul unor implementari personale.

Componente specifice aplicatiei – sunt construite si implementate pentru satisfacerea cerintelor specifice ale unei aplicatii, fara a fi destinate unui uz general.

Componente specifice unei arii de activitati (verticale) – sunt componente a caror tinta este o industrie specifica sau domeniu economic specific. Acest tip de componente este inca destul de rar intalnit, totusi eforturile de dezvoltare a pietei in aceasta directie sunt abia la inceput. Produse de tipul sistemelor contabile sau de gestiune pot fi utilizate ca si componente intr-un sistem mai larg, daca au fost proiectate sa asigure o interfata publica.

Daca dezvoltarea independenta a componentelor nu ridica probleme deosebite, rezolvarea problemelor de interactiune intre componente, a comunicarii dintre diferitele module ale aplicatiei, devine obiectivul central al proiectarii.

Modalitatile de interconectare a componentelor sunt variate, cuprinzând atât tehnologii care nu contin mecanisme de definire a interfetelor, cât si produse complexe care asigura mecanisme atât pentru construirea interfetelor cât si pentru realizarea conexiunilor. Din prima categorie fac parte:

Semnale si evenimente inter-procese: suportate de sistemele de operare Apple, Windows, Unix

Pipe: tehnica de comunicare între procese bazata pe stream-uri, specifica sistemului de operare Unix.

TCP/IP: protocol de retea

Transfer de fisiere, e-mail: construite, de exemplu pe baza protocolului TCP/IP.

Acces comun la baze de date: componentele interactioneaza prin intermediul înregistrarilor din baza de date.

Tehnicile mai avansate contin în RMI (Remote Method Invocation): este un mecanism pentru transmiterea de mesaje între obiecte care se executa pe calculatoare conectate la Internet. În prezent este un termen specific implementarilor Java.

RPC (Remote Procedure Call): reprezinta o interfata orientata spre proceduri pentru comunicare la nivel de socket, fiind un instrument destul de puternic ^n dezvoltarea aplicatiilor client/server.

COM (si DCOM, COM+, …): este standardul Microsoft pentru comunicatii între aplicatii Windows™. Programul poate fi scris în diferite limbaje si poate fi amplasat pe diferite calculatoare.

CORBA: Standardul OMG pentru comunicatiii între componente orientate-obiect. Este similar COM-ului, dar nu este restrictionat la Windows.

Proiectarea unei aplicatii construita prin componente se realizeaza în trei etape fundamentale, asa cum este prezentat în figura.

Figura Etapele de proiectare ale unei aplicatii plus si mecanisme de dezvoltare a interfatelor.

Proiectarea conceptuala transforma cerintele utilizatorului într-un format accesibil nivelului de proiectare logica, definind problema economica si functiile necesare pentru rezolvarea ei. Etapa presupune def inirea unui numar mare de scenarii economice sau scenarii de utilizare, destinate identificarii cât mai complete a viziunii clientului asupra aplicatiei precum si a functionalitatii cerute.

Aceasta faza reprezinta punctul central al modelarii economice si nu trateaza tehnologiile necesare implementarii sistemului.

În timpul stabilirii cerintelor pe care o aplicatie trebuie sa le satisfaca, este indicata analiza problemelor referitoare la performanta, mediu, eventuala integrare si interactiune cu sistemele existente, protocoale de comunicatie, restrictii hard sau soft, roluri ale utilizatorilor si drepturi de acces, localizarea datelor si relatia lor cu clientul, cerinte de criptare, integritate si protectie a datelor.

Proiectarea logica defineste entitatile, atributele, actiunile si interactiunile dintre entitati, fiind de obicei cea mai complexa etapa a dezvoltarii aplicatiei. Dupa identificarea utilizatorilor, a serviciilor de date precum si a componentelor economice ale sistemului, se poate trece la etapa de construire a componentelor. Este indicat ca primele componente care se implementeaza sa corespunda nivelului cel mai de jos al sistemului (accesul la date, servicii de mesagerie, etc.). Urmatoarele candidate la implementare sunt serviciile care sunt cele mai avantajate de plasarea într-un spatiu de proces, sau calculator separat de aplicatia client (generare de rapoarte, proceduri complexe de calcul, servicii de fax, etc).

Procesul de proiectare a componentelor este la rândul lui separat în trei nivele: construirea arhitecturii componentelor, proiectarea interfetelor, construirea produsului. În prima etapa se definesc elementele de baza ale functionarii componentei precum si modul în care acestea vor fi cuplate împreuna si vor interactiona. Pentru asigurarea unei flexibilitati maxime a sistemului, comportamentele variate ale produselor finale trebuie mapate corespunzator peste componente software. De asemenea, se impune definirea unui limbaj comun de comunicare între componente bazat pe un model din domeniul aplicatie, precum si evaluarea problemelor fizice care pot conduce la distorsiuni în comunicare dupa distribuirea fizica. Proiectarea interfetelor consta în definirea proprietatilor de stare si comportament ale fiecarei entitati în parte, astfel încât acestea sa fie capabile sa functioneze într-o varietate de configuratii si contexte. În ultima faza componentele sunt asamblate împreuna pentru a forma sistemul.

Exista situatii în care se pot utiliza diverse instrumente de construire a produselor. De exemplu, obiectele interfetei grafice (GUI) se pot asambla fie prin cod program, fie prin utilizarea unor medii de programare vizuala (VisualAge, C++Builder, etc).

În faza de proiectare fizica se iau deciziile referitoare localizarea aplicatiilor si a serviciilor peste nodurile sistemului, si corespunzator acestei plasari modul în care componentele vor fi implementate fizic. O regula de baza consta în plasarea fiecarei entitati la locul în care este utilizata (componentele care lucreaza cu bazele de date vor fi plasate pe serverul de baze de date, cele care valideaza informatiile utilizatorului vor fi alocate masinii clientului, etc). Exista, desigur consideratii suplimentare (constrângeri de securitate si performanta) care pot conduce la exceptii de la aceasta regula (MSDN99-00(.

Deoarece componentele sunt independente din punct de vedre al localizarii, modelul de distributie al serviciilor poate fi separat complet de proiectarea logica si fizica a interfetelor aferente. Mai mult, în decursul timpului acest model se poate modifica, fara ca aceasta operatie sa afecteze sursele client sau server. Dupa ce componenta a fost construita exista patru variante de distribuire a acesteia – în interiorul proiectului client, într-un automation server de tip in-process (DLL), într-un automation server de tip out-process (EXE) sau într-un automation server de tip remote (EXE pe un calculator aflat la distanta).

Model de proiectare incrementala: Modelul descris în continuare reprezinta solutia Microsoft pentru proiectarea aplicatiilor distribuite de dimensiuni mari (MSDN99-00(, fiind construit astfel încât sa permita dezvoltarea într-o maniera iterativa si incrementala.

Etapele de proiectare au fost rafinate astfel încât se identifica sase sub-modele.

Modelul de dezvoltare – cerinte: Echipa de dezvoltare. Procesul de dezvoltare. Controlul sursei. Managementul proiectului. Testare

Modelul economic – cerinte: Obiective economice. Costuri de dezvoltare. Beneficii din investitii. Resurse necesare. Constrângeri de timp. Securitatea si întretinere. Investitii în infrastructura existenta. Modele si politici economice

Modelul utilizator – cerinte: Interfata utilizator. Usurinta în utilizare. Configurari de retea si de calculator. Documentarea aplicatiei. Instruirea utilizatorilor.

Modelul logic – cerinte: Structura logica a aplicatiei. Modelarea obiectelor si a datelor.

Modelul tehnologic – cerinte: Dezvoltarea componentelor sau instrumente de reutilizare. Platforma de dezvoltare a sistemului si tehnologii de baze de date. Tehnologii de transmitere a mesajelor.

Modelul fizic – cerinte: Arhitectura fizica a aplicatiei. Distribuirea si interconectarea componentelor.

Figura 3.5.3 ilustreaza relatiile existente între sub-modele, respectiv între cerintele si obiectivele pe care fiecare model le implementeaza. Cerintele economice reprezinta punctul de intrare pentru dezvoltarea aplicatiei, în timp ce arhitectura fizica este punctul final. Între aceste doua seturi de cerinte, cerintele utilizatorului, cele logice si tehnologice sunt completate în mod iterativ, fiecare categorie fiind conditionata atât de sub-modelul economic cât si de modelele vecine. Modelul de dezvoltare coordoneaza întregul set de cerinte.

Figura 3.5.3 Modelul iterativ de proiectare

În mod ideal, proiectarea unei aplicatii distribuite de dimensiuni mari porneste prin definirea cerintelor economice. În cadrul acestei etape de proiectare se urmareste crearea unei viziuni de ansamblu asupra proiectului. Obiectivul final al modelului economic consta în crearea unui document de informare care prezinta asteptarile si presupunerile esentiale pe care se bazeaza proiectul. De asemenea, în cadrul acestei etape se determina costurile de dezvoltare a sistemului, se identifica setul de prioritati, se negociaza contracte si se stabilesc previziunile economice al proiectului. Instrumentele utilizate sunt în general instrumente economice (previziuni financiare, contabilitate, analiza economica si financiara, etc.) si nu instrumente de dezvoltare software.

Proiectarea modelului utilizator reprezinta procesul de întelegere, documentare si validare a viziunii utilizatorului asupra sistemului, ajungându-se în final la definirea solutiei economice din perspectiva clientului. Etapa este independenta de implementarile fizice, atentia focalizându-se asupra a ceea ce doreste utilizatorul, explicat în contextul a cum anume sa se realizeze, dar fara a se intra în detalii legate de modul de implementare.

Modelul poate fi subdivizat în cinci etape de baza: identificarea utilizatorilor si a rolurilor, colectarea intrarilor de la utilizatori, documentarea scenariilor de utilizare, validarea cu ajutorul clientului, respectiv validarea comparativa cu alte modele.

Instrumentele necesare în aceasta faza sunt în general conceptuale. De exemplu, tehnicile folosite pentru stabilirea profilului utilizatorului variaza de la interviuri, urmarirea activitatii sau colectarea de informatii statistice.

Modelul logic identifica modul în care politicile si regulile economice sunt separate în obiecte economice. Aceste obiecte abstracte sunt apoi combinate astfel încât sa defineasca nivelul logic al arhitecturii distribuite. Proiectarea modelului consta în executarea iterativa a cinci activitati specifice: identificarea obiectelor economice si a serviciilor, definirea interfetelor, identificarea dependentelor dintre obiecte, respectiv validarea. Exista o serie de instrumente software (ex. Visual Modeler) destinate acestei etape, în general bazate pe standardul UML (Unified Modeling Language).

Modelul tehnologic reprezinta etape în care se evalueaza si selecteaza instrumentele, infrastructura si platforma pentru dezvoltarea aplicatiei. Obiectele abstracte definite în modelul logic sunt transpuse în componente fizice, care sunt acum proiectate si implementate. De asemenea, în cadrul acestei faze se reevalueaza cerintele avansate în modelele anterioare, în scopul alegerii unei platforme tehnologice adecvate. Instrumentele software necesare dezvoltarii acestui model sunt diverse, de la sisteme de operare si medii de programare pâna la servere de baze de date (ex. COM/CORBA. Java/Visual Studio, MS Windows/Unix, MTS, IIS/Apache, SQL Server/Oracle, etc) .

Obiectivul modelului fizic consta în producerea unei arhitecturi care sa îndeplineasca într-o cât mai mare masura cerintele prezentate în sub-modelele anteriore. Aceasta etapa analizeaza/implementeaza problemele referitoare la performanta, latimea de banda, întretinere, stabilitate, eficienta, etc. Exista o serie de produse software care asista proiectarea si testarea arhitecturilor fizice – de la produse de analiza a performantelor pâna la instrumente de asamblare a componentelor, de depanare a aplicatiei distribuite sau de administrare si întretinere a bazelor de date distribuite.

Model de proiectare orientat spre arhitectura: Tehnica de proiectare orientata spre arhitectura se numeste "abordarea T" si a fost introdusa de David Taylor (Taylor95( ca reactie la problemele de integrare si compatibilitate aparute în proiectarea prin metode incrementale. Metoda propusa de "abordarea T" se bazeaza pe trei stiluri de modelare a arhitecturii (organizationala, de domeniu si tehnica), combinate cu instrumente si scenarii pentru proiectarea de detaliu

Figura Proiectarea prin abordarea T (Amber97)

Primul obiectiv al acestui model (Taylor95(, (Ambler97) consta în identificarea caracteristicilor prezente si previzionarea caracteristicilor viitoare ale oranizatiei. În al doilea rând, se urmareste definirea unui cadru de lucru robust pe baza caruia se vor dezvolta sî integra în aplicatie componentele sistemului. Se asigura contextul de definire a modului în care interactioneaza subsistemele în scopul satisfacerii cerintelor organizatiei.

Intrarile primare ale modelului includ constrângeri tehnice si organizationale, cerinte fundamentale identificate de client, experiente si idei ale echipei de dezvoltare, principiile de proiectare pe care le vor urma. Cerintele identificate în etapele urmatoare ale proiectarii sistemului vor fi utilizate ca intrari ale activitatii de actualizare a modelului.

Modelul organizatiei descrie structura si comportamentul origanizatiei precum si mediul sau extern. Scopul acestei modelari consta în obtinerea unei viziuni cât mai complete asupra modului în care functioneaza si se integreaza în mediu organizatia, astfel încât se se reduca la maxim implicatiile negative provocate de actiuni (economice, sociale, umane) întâmplatoare interne sau externe.

Modelul domeniului arhitectural extinde modelul organizatie prin identificarea si organizarea cerintelor comportamentale în componente consistente, descrise la un nivel superior, nedetaliat. Obiectivul acestei etape consta în construirea unei diagrame de nivel înalt a componentelor, care sa prezinte aplicatiile si subsistemele care vor asista organizatia, interfetele publice, interactiunile si relatiile dintre ele.

Modelul tehnic arhitectural se concentreaza asupra tehnologiilor care vor fi utilizate pentru implementarea sistemului precum si asupra modului în care acestea vor colabora. Sunt luate în considerare cerintele tehnice si constrângerile tehnologice impuse de mediu. Rezultatul acestui model consta în dezvoltarea unei diagrame a configurarilor de hardware, middleware si software. De asemenea se urmareste producerea unui prototip tehnic al sistemului, numit si prototip-de-demonstrare-a-conceptelor (Ambler97). Acesta este utilizat pentru testarea tehnologiilor alternative si adptarea în final a celei care raspunde cel mai bine cerintelor specifice.

Modelele detaliate se focalizeaza asupra descrierii fiecarei componete, aplicatii si subsistem component al modelului domeniului arhitectural sau al modelului tehnic arhitectural. Modelarea de detaliu utilizeaza tehnici de modelare/proiectare obiectuala (diagrame de clase, modele de date, etc.) astfel încât sa asigure toate informatiile necesare unei implementari coerente si complete a aplicatiei.

1.6. Caracteristicile MS SQL Server 2000 si a platformei .NET

SQL Server 2000 este un sistem de gestiune al bazelor de date performant, prezentând un nivel ridicat de scalabilitate și posibilități de adaptare la cerințele diverselor categorii de utilizatori. Având în vedere tehnologiile și instrumentele integrate, SQL Server 2000 determină reducerea timpului necesar pentru dezvoltarea aplicațiilor care necesită integrarea suportului pentru bazele de date. În acest sens, realizarea unor arhitecturi bazate pe SQL Server simplifică dezvoltarea soluțiilor Web complexe, a aplicațiilor tradiționale, oferind totodată posibilități avansate de organizare a informațiilor în depozitele de date. Implementarea acestei soluții simplifică substanțial procesele de administrare și oferă un nivel ridicat de securitate.

Bazele de date constituie unul din elementele fundamentale ale infrastructurii IT a companiilor. Având în vedere importanța informațiilor stocate în bazele de date pentru desfășurarea proceselor de afaceri, soluțiile de acest tip trebuie să asigure un nivel ridicat de scalabilitate, performanță și siguranță în exploatare. SQL Server 2000 răspunde în totalitate acestor nevoi, fiind o soluție flexibilă și adaptabilă la nevoile diverselor categorii de clienți. Nivelul ridicat de adaptare la cerințele utilizatorilor este demonstrat de existența celor șapte ediții ale acestei soluții, acestea permițând integrarea SQL Server pe o gamă variată de echipamente (începând cu servere bazate pe procesoare pe 64 de biți și încheind cu dispozitivele mobile).

Ultima versiune SQL Server integrează instrumente eficiente din categoria business intelligence, permițând în acest mod un control optim al proceselor de afaceri din cadrul companiei dumnevoastră. De asemenea, integrarea cu aplicațiile din familia Microsoft Office contribuie la simplificarea modalităților de analiză a datelor și la obținerea unor rapoarte de sinteză.

Implementarea SQL Server 2000 determină reducerea substanțială a resurselor care vor fi alocate pentru administrarea bazelor de date. În acest sens, nivelul ridicat de autoconfigurare, instrumentele grafice de administrare și numărul mare de experți tip wizard simplifică substanțial modul în care se realizează configurarea și administrarea acestui server. De asemenea, SQL Server 2000 oferă suport complet pentru XML (eXtensible Markup Language). Astfel, este oferită o posibilitate eficientă de transfer a datelor, fiind asigurat un nivel ridicat de integrare în medii eterogene.

Reducerea timpului necesar pentru dezvoltarea aplicațiilor având la baza SQL Server 2000 constituie un avantaj fundamental al acestei soluții. Prin tehnologiile integrate pot fi realizate mai simplu aplicații Web sau tradiționale care să exploateze bazele de date. Având în vedere nivelul ridicat de performanță, SQL Server 2000 poate constitui fundamentul aplicațiilor mission critical din categoria e-commerce sau a sistemelor complexe dedicate automatizării fluxurilor de business din cadrul companiei (soluții de tipul ERP, CRM, SCM etc).

Integrarea SQL Server 2000 în cadrul companiei dumnevoastră va determină reducerea substanțială a costurilor de implementare a sistemelor informatice care necesită suportul bazelor de date. Suplimentar, simplificarea proceselor de administrare și configurare a acestei soluții va conduce la diminuarea costurilor operaționale.

Scalabilitate și performanță: SQL Server 2000 oferă un nivel deosebit de scalabilitate, răspunzând în acest mod la cerințele diverselor categorii de utilizatori. Cele șapte ediții ale SQL Server oferă suportul bazelor de date pentru o gamă variată de aplicații, începând cu soluțiile dedicate dispozitivelor mobile și încheind cu sistemele informatice mission critical. În acest sens, se distinge ediția SQL Server Enterprise (64 bit) Edition care poate fi integrată în arhitecturi de până la 64 de procesoare și poate adresa un maxim de 512 GB RAM.

În tabelul următor sunt sintetizate informațiile privind cele șapte ediții ale SQL Server 2000:

Un nivel ridicat de disponibilitate: SQL Server 2000 prezintă un nivel ridicat de disponibilitate a bazei de date. Versiunea 2000 oferă posibilitatea de realizare online a backup-ului bazei de date, fără a fi afectate procesele de business derulate prin intermediul acestui server.

În SQL Server 2000 este posibilă realizarea backup-ului diferențial, această modalitate determinând reducerea spațiului alocat pentru fișierele salvate. Backup-ul diferențial are un impact redus asupra serverului, oferind posibilitatea de realizare mai frecventă a acestei operațiuni și conducând în acest mod la reducerea riscurilor de pierdere a datelor.

Noua facilitate log shipping permite sicronizarea eficientă a două baze de date separate fizic pe două mașini. Astfel, este posibil transferul log-urilor cu trazacții între două servere și este asigurată propagarea actualizărilor realizate.

Suplimentar, SQL Server 2000 oferă avantaje importante în arhitecturite bazate pe clustere de servere, asigurând un nivel deosebit de disponibilitate și siguranță în exploatarea datelor. Tehnologia Virtual Interface System Area Network (VI SAN) permite integrarea directă a SQL 2000 în cadrul arhitecturilor SAN, fiind asigurat un nivel ridicat de performanță.

Instrumente avansate de business intelligence: Analiza informației este o cerință tot mai acută a zilelor noastre. Informația sintetizată și centralizată care oferă un bun suport decizional, constituie o condiție sine qua non pentru realizarea unui management eficient.

SQL Server 2000 integrează soluții performante din categoria business intelligence, acestea simplificând analiza datelor și derularea proceselor decizionale din cadrul organizației.

SQL Server 2000 Analysis Services oferă instrumente pentru realizarea unor analize complexe asupra informațiilor stocate în baze de date de mari dimensiuni. Componenta Online Analytical Processing (OLAP) integrată în cadrul acestei soluții, oferă posibilități avansate de realizarea a analizelor multidimensionale asupra datelor. Suplimentar, OLAP permite realizarea analizei pe baza unor surse eterogene de informație, componenta OLE DB oferind posibilitatea de conectare la diverse alte sisteme de gestiune a bazelor de date.

OLAP Actions, o nouă facilitate din cadrul Analysis Services, permite declanșarea diverselor acțiuni pe baza rezultatelor analizelor. Analizele realizate prin intermediul instrumentelor OLAP pot deveni accesibile prin intermediul Web-ului, fiind asigurat în acest mod un nivel deosebit de mobilitate în accesarea acestor informații.

În plus, SQL Server 2000 integrează instrumente de data mining care permit realizarea unor analize avansate asupra surselor de date relaționale și a celor multidimensionale. Prin instrumentele de data mining vor putea fi identificate facil modele și tendințe privind informațiile stocate în bazele date.

SQL Server dispune de doi algoritmi (Microsoft Decision Trees și Microsoft Clustering) care permit realizarea unor analize complexe prin data mining.

Pentru realizarea analizelor și exploatarea avantajelor oferite de Analysis Services este posibilă integrarea cu diverse aplicații. Instrumentele Pivot Table și Pivot Chart, accesibile în cadrul suitei Microsoft Office, pot fi utilizate pentru sintetizarea datelor rezultate în urma analizelor OLAP sau data mining. Microsoft Data Analyzer este un instrument specializat dedicat managerilor, care permite realizarea simplă a unor rapoarte și grafice pe baza datelor furnizate de Analysis Services.

SQL Server 2000 Reporting Services este un instrument destinat realizării de rapoarte clasice și automate, disponibile la cerere sau generate periodic într-o multitudine de formate de raportare (HTML, PDF, Excel).

Suport extins pentru XML: XML constituie modalitatea cea mai simplă și, totodată, cea mai eficientă prin intermediul căreia datele pot fi transferate folosind rețelele locale și Internet-ul.

SQL Server 2000 integrează suport complet pentru XML. Astfel, este asigurată o modalitate eficientă de transfer a datelor și posibilități de integrare în mediile care presupun existența unor sisteme informatice eterogene.

Versiunea 2000 integrează tehnologiile XPath și URL Query, simplificând procesele de transfer a datelor în format XML. De asemenea, limbajul procedural Transact SQL (T-SQL) a fost întregit cu noi funcții care facilitează aceste operațiuni. Prin noua clauză OpenXML, specifică instrucțiunii SELECT, este automatizat transferul datelor din modelul relațional (caracteristic bazei de date) în cel ierarhic (specific limbajului XML), fiind asigurate mijloace pentru sincronizarea permanentă a celor două modalități de organizare a informației.

Simplificarea procedurilor de administrare și reducerea timpului pentru dezvoltarea aplicațiilor: SQL Server 2000 reduce eforturile solicitate pentru administrarea și configurarea bazei de date. În acest sens, sunt disponibile instrumente grafice de configurare și experți tip wizard pentru realizarea diverselor operațiuni de administrare.

Pentru dezvoltatori, noile funcționalități integrate în limbajul Transact-SQL contribuie la reducerea substanțială a eforturilor necesare pentru realizarea aplicațiilor tradiționale sau a celor orientate spre Web.

De asemenea, integrarea cu mediul de dezvoltare Visual Studio .NET contribuie la reducerea dramatică a timpului alocat pentru dezvoltarea și testarea aplicațiilor care solicită suport pentru bazele de date.

Securitate ridicată a datelor: Având în vedere posibilitățile de accesare a aplicațiilor cu suport pentru bazele de date prin intermediul Web-ului, SQL Server 2000 introduce importante îmbunătățiri la capitolul securitate.

În acest sens, au fost integrate instrumente pentru monitorizarea și auditul de securitate al serverelor, o gestiune eficientă a rolurilor și profilelor, precum și posibilități de tratare a principalelor evenimente de securitate care pot apărea în exploatarea acestei soluții.

De asemenea, versiunea 2000 extinde conceptul „out of the box” în ceea ce privește securitatea. SQL Server 2000 este preconfigurat pentru a oferi nivelul maxim de securitate după instalare, permițând astfel implementarea simplă și rapidă a serverului.

Integrarea cu alte soluții și servere: SQL Server 2000 prezintă un nivel deosebit de integrare cu alte soluții și servere. Sunt de menționat posibilitățile de integrare cu BizTalk Server și Commerce Server.

De asemenea, este de remarcat nivelul ridicat de integrabilitate cu soluțiile disponibile în noul Microsoft Office System. Astfel, Access 2003 poate fi utilizat pentru dezvoltarea aplicațiilor care să exploateze bazele de date SQL Server, precum și pentru realizarea de rapoarte și grafice pe baza informațiilor furnizate Analysis Services.

O data cu dezvoltarea calculatoarelor, cantitatea de informatie vehiculata in cadrul diverselor firme, institutii, organizatii sau intre persoane fizice a crescut exponential. Orice aplicatie software prelucreaza un volum mai mic sau mai mare de informatie si necesita stocarea acestuia pe disc. Algoritmii dezvoltati de-a lungul timpului au oferit solutii din ce in ce mai bune pentru problemele legate de stocarea si readucerea datelor – dar si pentru prelucrarea lor – mergand pana la a oferi modele standardizate de lucru.
Acest articol isi propune trecerea in revista a tehnologiilor actuale de lucru cu datele si propunerea altora noi.
Teoria structurilor de date si aparitia SQL: Punctul culminant al teoriei structurilor de date a fost atins in momentul definirii conceptului de baze de date relationale. Acesta descrie metode de modelare a problemelor reale in scopul definirii unor structuri care sa elimine redundantele in stocarea datelor si sa permita cu usurinta modificari cerute de evolutia problemei reale. Cu aceasta ocazie sunt identificate operatiile comune efectuate de marea majoritate a aplicatiilor, fapt care ii indreptateste pe teoreticieni sa puna bazele unui limbaj accesibil oricui si care sa permita implementarea cu usurinta a tuturor metodelor de lucru intalnite in aplicatiile ce necesita baze de date.

Definirea lui s-a facut doar la nivel teoretic, implementarea fiind lasata in sarcina companiilor ce dezvolta motoare de baze de date. Acest limbaj a fost denumit SQL (Structured Query Language) si este implementat de toate motoarele existente in prezent.
Avantajul principal al acestui limbaj s-a dorit sa fie simplitatea. Spre deosebire de un adevarat limbaj de programare ce necesita invatarea unor sintaxe stricte si usor de confundat, SQL are o sintaxa foarte apropiata de limbajul uman natural, usor de inteles si de utilizat. O fraza in acest limbaj trebuie sa fie lizibila pentru oricine cunoaste cele cateva cuvinte din limba engleza care compun vocabularul SQL: SELECT, FROM, WHERE, ORDER BY etc. Complexitatea sistemului care implementeaza algoritmii necesari lucrului efectiv cu datele, metodele de stocare, cautare etc, precum si optimizarile sunt perfect transparente pentru utilizator. Acest limbaj nu este considerat un limbaj de programare deoarece a fost conceput pentru a spune calculatorului CE date sunt necesare si nu CUM trebuie obtinute. Sunt necesare cunostinte minime de calculator pentru utilizarea SQL; acesta este de fapt si idealul urmarit de marile firme producatoare de motoare de baze de date: comercializarea unui sistem complex care sa permita implementarea oricarei baze de date; datele se pot apoi manipula doar cu ajutorul utilitarelor anexate sistemului, fara a mai fi nevoie de scrierea de aplicatii specifice.

Independenta aplicatiei fata de baza de date.

Al doilea mare avantaj il constituie portabilitatea. O aplicatie utlizeaza o baza de date prin intermediul acestor fraze SQL care nu sunt altceva decat simplu text. Orice motor de baze de date accepta astfel de fraze, facand posibila migrarea unei aplicatii de pe un motor pe altul mai performant fara nici o modificare.

Faptul ca SQL este un standard unanim recunoscut confera un mare avantaj aplicatiilor are isi pot alege oricand pe ce sistem sa ruleze.

In ciuda tuturor acestor avantaje prezentate mai sus, bazele de date raman in continuare o zona deosebit de complexa si pretentioasa a dezvoltarii de software. Cu toate avantajele sistemelor integrate oferite de marile firme, utilizatorii au deseori nevoie de aplicatii specifice domeniului lor de activitate. Ce pare mai ciudat, de multe ori firmele producatoare de software prefera sa implementeze propriul motor de baze de date, in ciuda volumului de munca implicat. Aceasta ar fi de asteptat in cazul aplicatiilor ce nu necesita stocarea unui volum mare de informatii, dar este in special cazul firmelor producatoare de jocuri, care manipuleaza un volum de informatii adeseori mai mare decat multe dintre aplicatiile de gestiune si contabilitate, avand in acelasi timp standarde mult mai ridicate in privinta necesarului de memorie si a vitezei de raspuns. De ce aceste firme evita standardele acceptate de producatorii bazelor de date si de ce reusesc intotdeauna sa atinga performante mai ridicate? Sa privim inca o data, mai cu atentie, la avantajele oferite de “clasicii” bazelor de date, si in special de SQL.

Sa observam in primul rand ca exista o diferenta mare intre teoria gandita acum mai bine de 30 de ani si implementarea actuala. Astfel, avantajele descrise pana acum au ramas mai degraba idealuri decat realitati.

Sa luam spre exemplu usurinta in utilizare. Limbajul foarte apropiat de cel natural necesita minime cunostinte de calculator pentru a folosi o baza de date prin intermediul SQL. in realitate nu exista nici o aplicatie care sa prezinte o interfata SQL utilizatorului neprofesionist. Exista foarte multe programe care folosesc baze de date ce suporta SQL, dar nici unul dintre ele nu prezinta o consola pentru comenzi directe. O interfata vizuala, oricat de limitata ar fi, este cu mult mai usor de folosit decat limbajul SQL. Nici o firma ce dezvolta software nu isi permite sa-si oblige clientii (dintre care marea majoritate sunt slab familiarizati cu calculatorul) sa invete un limbaj a carui insusire ar necesita cel putin un an de pregatire. Trebuie sa remarcam faptul ca oricat de intuitiva ar fi sintaxa unui limbaj, tehnicile de utilizare a acestuia sunt cu mult mai importante, iar acestea se deprind prin exercitii indelungate. invatarea si utilizarea acestui limbaj revine in exclusivitate programatorului, care este insa deprins cu limbaje mult mai apropiate de masina, astfel incat mare parte din tehnica de utilizare SQL se concentreaza asupra modului de a transforma o cerere din limbajul calculatorului (aflat la indemana programatorului) in limbajul SQL, pentru a o pasa apoi interpretorului care sa o inteleaga si sa o transforme inapoi in limbajul calculatorului.

Fluxul de executie a cererilor intr-un sistem bazat pe SQL

Mai mult decat atat, asa-zisa similaritate cu limbajul natural uman nu se concretizeaza decat intr-un numar restrans de cuvinte cheie, gandite initial ca fiind suficiente pentru realizarea oricarei operatii. Realitatea a dovedit ca pentru prelucrarea datelor sunt necesare multe alte functii – care au fost implementate ulterior –, astfel incat restul limbajului contine denumiri si sintaxe la fel de criptice ca in orice alt limbaj de programare.
Desi a devenit tot mai evident ca marea majoritate a utilizatorilor de SQL sunt programatorii, eforturile au continuat sa se indrepte mai degraba spre a dezvolta limbajul SQL decat spre crea o interfata mai usor de accesat in mod programatic.
In concluzie, in loc sa devina un model al simplitatii si elegantei in utilizare, SQL a reusit sa devina atat spaima utilizatorilor cat si dusmanul producatorilor de soft.

Sa privim cel de-al doilea avantaj major al SQL: generalitatea si portabilitatea. Standardizarea a fost intotdeauna o sursa de progres; stabilirea unui limbaj comun a permis producatorilor din intreaga lume sa isi sumeze eforturile si sa isi bazeze munca pe rezultatele anterioare.
In realitate SQL constituie un standard doar in forma teoretica, descrisa cu multi ani in urma. O data cu avansul tehnologic setul de facilitati oferite de SQL a devenit rapid insuficient. Firmele ce implementeaza motoare de baze de date au pus al dispozitia clientilor noi functii si extensii ale SQL, care permit o utilizare mai eficienta dar care nu mai sunt standardizate. Mai exact spus, componenta SQL denumita limbajul de definire a datelor (DDL) a ramas aproape neschimbata, dar limbajul de manipulare a datelor (DML) a suferit modificari substantiale. DDL nu a putut fi modificat deoarece reprezinta punerea in practica a insasi teoriei bazelor de date relationale. Nu acelasi lucru se poate spune insa despre DML. Metodele in care datele pot fi prelucrate sunt de o varietate infinita si nu au putut fi grupate intr-un set de functii comune, fiecare aplicatie avand cerinte specifice. insa SQL reprezenta singura metoda de interogare a bazelor de date, astfel incat a fost obligatorie implementarea multor functii, oricat de rar folosite ar fi fost.
Aceste noi functii inventate pentru a satisface cele mai variate necesitati, de la simple conversii intre tipuri de date pana la medii geometrice, radicali, logaritmi sau cautari de siruri, nu au mai reprezentat un standard. Au inceput prin a fi extensii venite sa imbogateasca limbajul de baza si sa usureze munca utilizatorului, dar au devenit curand absolut indispensabile si au fost implementate de toate sistemele. Astfel, toate companiile ce dezvolta motoare de baze de date implementeaza aceleasi functii, dar sub denumiri si cu sintaxe diferite.
SQL a ramas portabil la nivelul sau primar si, teoretic, este inca posibila portarea unei aplicatii de pe un motor pe altul fara mari modificari. Pentru aceasta trebuie insa facute eforturi pentru evitarea utilizarii oricarei facilitati oferite de un anumit sistem, daca aceasta nu este implementata si pe celelalte. Aceasta misiune este insa dificila si are ca rezultat o aplicatie ce nu beneficiaza niciodata de ultimele tehnologii; in aceste conditii producatorii de soft prefera sa renunte la portabilitate.
Tot pentru a ramane credincios ideii de portabilitate, SQL a ales cea mai elementara metoda de transmisie a cererilor: formatul text. in ciuda faptului ca nu este economic din punct de vedere al informatiei (contine multa informatie redundanta), a fost ales acest format deoarece este cel mai simplu de interpretat de catre orice sistem de operare. S-a pierdut insa din vedere faptul ca transmiterea inversa de date (aducerea rezultatelor) contine de multe ori informatii ce nu se pot reprezenta in format text, astfel incat canalul de comunicatie deschis intre aplicatie si motorul de baze de date trebuie sa fie mult mai complex.
Exista si alte dezavantaje majore ale SQL, unul dintre ele fiind viteza mult redusa. Cauza principala a pierderii de viteza este interpretorul SQL, care are misiunea de a transforma o fraza dintr-un limbaj apropiat de cel uman in cel al calculatorului, verificand si semnaland eventualele erori de sintaxa. Performantele slabe din punct de vedere al vitezei au ingreunat mult manipularea datelor din cadrul aplicatiei. Cu alte cuvinte nu mai este posibila utilizarea bazei de date pentru stocarea si regasirea informatiilor, urmand ca prelucrarea lor sa se faca din cadrul aplicatiei. A devenit necesara prelucrarea datelor in interiorul motorului de baze de date, prin introducerea conceptului de proceduri stocate. Acestea sunt scrise intr-un limbaj derivat din SQL si sunt stocate impreuna in interiorul bazei de date. Noul limbaj seamana mai putin cu SQL si mai mult cu un limbaj de programare obisnuit, cu instructiuni conditionale si repetitive, sacrificand ideea initiala de simplitate. Fireste, nu se mai pune problema utilizarii unui astfel de limbaj de catre un client al carui domeniu de activitate este altul decat informatica. Deasemenea, e de la sine inteles ca exista multiple variante – foarte diferite – ale acestui limbaj, nimeni neconformandu-se unui standard.
Incet-incet, SQL s-a transformat intr-un limbaj de programare in adevaratul sens al cuvantului, la fel de dificil de insusit ca oricare altul. Portabilitatea a ramas posibila doar la nivel teoretic, deoarece diferentele dintre implementarile actuale ii pun piedici mari. Mai mult, sistemele bazate pe SQL sunt incetinite cu mult de procedurile de interpretare a sintaxei comenzilor si de conversia datelor in formate incomode pentru calculator, dar cerute de limbaj. Implementarea SQL impune crearea mai multor module, iar un motor de baze de date este cu atat mai mare, mai lent si mai costisitor cu cat ofera mai multe facilitati. Din aceste cauze motoarele de baze de date existente nu reprezinta o solutie pentru aplicatiile cu pretentii asupra vitezei de executie, spatiului ocupat pe hard-disk, pretului de vanzare sau asupra dependetei fata de versiunea sistemului de operare.
Problemele initiale privind stocarea si regasirea datelor intr-un mod eficient au ramas aceleasi pentru marea majoritate a aplicatiilor, solutiile existente in prezent fiind nesatisfacatoare.
Putem spune ca orice aplicatie care are nevoie sa isi stocheze date in fisiere externe nu face nici mai mult nici mai putin decat gestionarea unei baze si are nevoie sa utilizeze un motor de baze de date. Faptul ca volumul de date este mic nu inseamna ca nu sunt necesare metode de adaugare, modificare, stergere, cautare si alte metode specifice lucrului cu informatii. Nu se pune insa nici problema utilizarii unui sistem bazat pe SQL, care el singur consuma mai multe resurse si costa mai mult decat intreaga aplicatie. Aceasta este cu atat mai mult problema celor ce ofera aplicatii prin intermediul Internetului si care au ca obiective principale dimensiunea redusa, costul minim si independenta maxima fata de sistemul de operare si alte aplicatii instalate.
Intrebarea care se pune este: Se poate realiza un motor de baze de date care sa implementeze teoria structurilor relationale, dar fara dezavantajele SQL? Raspunsul este ‘Da’. Punctul slab al SQL este alegerea unui limbaj nepotrivit: limbajul natural in lucrul cu datele este cel al programelor, nu cel uman. in zilele noastre, utilizatorul uman prefera o interfata vizuala in locul uneia scriptice, mouse-ul fiind pentru multi mai usor de utilizat decat tastatura. Se poate insa realiza un sistem care sa ofere aplicatiilor posibilitatea de a gestiona datele folosindu-se de limbajul lor specific.

Motorul de baze de date trebuie sa permita introducerea si regasirea datelor cu viteza maxima posibila, astfel incat aplicatiei sa-i ramana timpul necesar prelucrarii efective. Interpretarea datelor este lasata astfel in seama aplicatiei, eliminandu-se nevoia artificiului denumit proceduri stocate.

CAPITOLUL 2. Pipeline-uri pentru comenzi

2.1. Introducere

In acest capitol, se vom prezenta procedeul de creare a unui pipeline de procesare a comenzilor, pipeline care se ocupa de autorizarea cartilor de credit, verificarea stocurilor, expedierea, notificarea prin email, si asa mai departe. De fapt, caracteristicile procesarii cartilor de credit vor fi discutate pe larg in Capitolul 3, dar pana atunci vom discuta despre locul pe care il ocupa acest proces intr-un sistem de comert electronic.

Functionalitatea unui pipeline de comenzi este o capacitate extrem de utila pentru un site de comert electronic deoarece permite prestatorului de servicii sa urmareasca comenzile in fiecare stadiu al procesului, si furnizeaza informatii de auditare la care se poate face referire ulterior sau in cazul aparitiei unor probleme pe parcursul procesului de comanda. Toate acestea se pot efectua fara a apela la un sistem de contabilitate al unui tert, ceea ce poate duce la reducerea costurilor. Prima sectiune a acestui capitol discuta conceptul de order pipeline (pipeline de comenzi), si caracteristicile aplicatiei JokePoint listata in Capitolul 5.

Exista multe moduri de implementare a acestui tip de sistem, multe persoane recomandand utilizarea unui sistem tranzactional cum este MTS (Microsoft Transaction Server) sau COM+ (Component Object Model+) pe sisteme de operare mai recente. Cu toate acestea, aceasta metoda are propria complexitate si nu ofera mult mai multe avantaje decat suita standard .NET. Desi este posibila crearea de componente COM+ folosind .NET, implementarea codului este mult mai complexa, iar depanarea poate fi complicata. Din acest motiv, vom axa aceasta discutie pe platforma .NET, care ofera avantajul de a intelege si depana codul mult mai usor. Acest capitol se va concentra mai mult asupra constructiei unui astfel de sistem, ceea ce implica si o modificarea a modului in care functioneaza actualmente lucrurile, dar si cateva dintre completarile care s-au facut asupra bazei de date folosite. In orice caz, codul folosit in acest capitol este mult mai complicat decat cel care se foloseste actualmente in domeniu. Provocarea reala o constituie proiectarea sistemului.

Sistemul ce va fi prezentat ulterior va putea permite clientilor sa efectueze comenzi prin pipeline, iar administratorul poate sa urmareasca evolutia acestor comenzi pe parcursul numeroaselor etape. Desi nu se va efectua procesarea unor carti de credit reale, sistemul va fi complet, avand inclusiv o pagina web de administrare care poate fi folosita de furnizori pentru a confirma existenta in stoc a anumitor articole sau pentru a confirma expedierea comenzilor. Pentru inceput, vom stabili principiile de baza ale acestui sistem.

2.2. Definirea unui pipeline pentru comenzi

Orice tranzactie comerciala, fie ca are loc intr-un magazin de pe strada, pe Internet sau oriunde altundeva, necesita cateva operatiuni asociate fara de care tranzactia nu poate fi considerata incheiata. De exemplu, un articol de vestimentatie nu poate fi luat dintr-un magazin fara a fi platit spunand ca a fost cumparat – plata este o parte integrala a oricarei achizitii. In plus, o tranzactie se poate incheia cu succes numai atunci cand fiecare dintre operatiuni se incheie cu succes. In cazul in care cartea de credit a unui client nu este acceptata, de exemplu, atunci nu se pot retrage fonduri din aceasta, iar achizitia nu se poate face.

Succesiunea de operatiuni necesare intr-o tranzactie este deseori considerata si definita sub forma unei cai de access (pipeline). In aceasta analogie, comenzile incep la un capat al conductei si ajung la celalalt capat al acesteia atunci cand sunt incheiate. Pe tot acest parcurs, acestea trebuie sa treaca prin cateva seciuni ale acestui pipeline, fiecare fiind responsabila pentru o anumita operatiune sau un grup de operatiuni relationate. Daca oricare dintre aceste sectiuni esueaza, atunci urmatoarea este blocata si poate necesita interactiune exterioara inainte de a permite procesului sa urmaze traseul in pipeline, sau poate fi revocata complet.

De exemplu, pipeline-ul simplu descris in figura 2-1 se aplica la tranzactiile dintr-un magazin de strada.

Insert 2549f1301scrap.doc

Figura 13-1. Tranzactii pentru un magazin de strada

In acest caz, ultima sectiune ar putea fi optionala si ar putea implica operatiuni aditionale, cum ar fi impachetarea. Etapa platii ar mai putea avea una sau mai multe metode de operare, deoarece clientul ar putea plati in numerar, cu carte de credit, bonuri de cadou sau altele.

Asa cum se poate observa in urmatoarea sectiune, un pipeline pentru achizitiile prin comert electronic este mai indelungat, insa nu este cu mult mai complicat.

In JokePoint, pipeline-ul va arata ca in figura 13-2.

Insert 2549f1302scrap.tif

Figura 13-2. Piepline de comanda JokePoint

Operatiile desfasurate in aceste sectiuni de pipeline sunt dupa cum urmeaza:

Notificarea clientului: Se trimite un email care instiinteaza clientul ca procesul de comanda a inceput si confirma produsele care vor fi trimise si adresa la care vor fi trimise.

Autorizarea cartii de credit: Cartea de credit folosita pentru achizitionare este verificata si este retinuta valoarea totala a comenzii (desi plata nu se face in aceasta etapa).

Verificarea stocului: Se trimite catre furnizor un email cu lista produselor comandate. Procesarea continua in momentul in care furnizorul confirma faptul ca produsele sunt disponibile.

Plata: Tranzactia prin cartea de credit este incheiata folosind fondurile rezervate intr-o etapa anterioara.

Expedierea: Se trimite un email catre furnizor pentru a confirma faptul ca plata produselor comandate a fost efectuata. Procesarea continua in momentul in care furnizorul confirma expedierea produselor.

Notificarea clientului: Se trimite un email pentru a instiinta clientul de expedierea produselor comandate si pentru a-i multumi pentru ca a folosit website-ul JokePoint.

In termeni de implementare, asa cum se va putea vedea in urmatoarele randuri, exista mai multe etape, deoarece etapele de verificare a stocului si de expediere sunt compuse din doua sectiuni de pipeline: una pentru expedierea email-ului si una care asteapta confirmarea.

Pe masura ce comenzile curg in pipeline, intrarile sunt adaugate intr-un tabel nou in baza de date numit Audit. Aceste inregistrari pot fi examinate pentru a vedea parcursul unei comenzi si sunt o metoda excelenta de identificare a problemelor in cazul in care acestea apar. De asemenea, fiecare intrare in baza de date Orders va fi semnalizata cu un status, indicand punctul din pipeline a ajuns.

2.2. Stabilirea bazelor in vederea implementari cailor de access

Pentru a procesa un pipeline este necesara crearea unor clase reprezentand fiecare etapa. Aceste clase vor efectua procesarea necesara si apoi vor modifica statusul comenzii in baza de date Orders pentru a inainta comanda. De asemenea, va fi necesara o clasa coordonatoare (sau procesor), care poate fi apelata pentru orice comanda si va executa clasa etapei potrivite. Acest procesor poate fi apelat o data cand o comanda este efectuata, iar intr-o operatie normala, va fi apelat de inca doua ori: o data pentru confirmarea stocului si o data pentru confirmarea expedierii.

Pentru a usura lucrurile, este recomandata definirea unei interfete comune sustinuta de fiecare clasa de etapa din pipeline pentru a permite clasei procesor sa acceseze fiecare etapa intr-un mod standard. De asemenea, se vor defini cateva functii utilitare si se vor expune cateva proprietati comune in clasa procesor, care vor fi folosite in etapele pipeline-ului atunci cand vor fi necesare. De exemplu, ID – ul unei comenzi ar trebui sa fie accesibil in toate etapele, si pentru a evita duplicarea codului, se va plasa aceasta informatie in clasa procesor a comenzii.

Se va contrui o platforma (assembly) numita CommerceLib care contine toate clasele. CommerceLib va contine urmatoarele:

OrderProcessor: Clasa principala pentru procesarea comenzilor.

OrderProcessorConfiguration: Structura care contine multiple detalii de configurare pentru clasa OrderProcessor, inclusiv adresa de email a administratorului, string de conectare SQL, si asa mai departe.

OrderProcessorException: Clasa de custom exception pentru utilizarea in cadrul procesorului de comenzi si a sectiunilor de pipeline.

IPipelineSection: Definitia interfetei pentru sectiunile de pipeline.

Customer, OrderDetails, OrderDetail: Clasele folosite pentru a stoca datele extrase din baza de date pentru a usura accesul.

PSInitialNotification, PSCheckFunds, PSCheckStock, PSStockOK, PSTakePayment, PSShipGoods ,PSShipOK, PSFinalNotification: Clasele sectiunii de pipeline.

Evolutia unei comenzi in pipeline asa cum este intermediata de procesorul de comenzi se refera la pipeline-ul descris anterior (vezi figura 13-3).

Insert 2549f1303scrap.tif

Figura 13-3. CommerceLib procesarea pipeline

Procesul descris in figura 13-3 este divizat in trei sectiuni dupa cum urmeaza:

Clientul efectueaza comanda.

Furnizorul confirma stocul.

Furnizorul confirma expedierea.

Prima etapa se desfasoara astfel:

In momentul in care un client confirma o comanda, Checkout.aspx creaza comanda in baza de date si apelaza OrderProcessor pentru a incepe procesarea comenzii.

OrderProcessor detecteaza o comanda noua si apeleaza PSInitialNotification.

PSInitialNotification trimite un email catre client pentru a confirma comanda si inainteaza comanda in etapa urmatoare. De asemenea, apeleaza OrderProcessor pentru a continua procesarea.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSCheckFunds.

PSCheckFunds verifica daca fondurile necesare sunt disponibile pe cartea de credit a clientului si stocheaza detaliile necesare pentru a incheia tranzactia daca fondurile sunt disponibile. Daca verificarea se incheie cu succes comanda este avansata la OrderProcessor pentru a continua.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSCheckStock.

PSCheckStock trimite un email catre furnizor cu o lista de produse comandate, instruieste furnizorul sa confirme via OrderAdmin.aspx, si avanseaza statusul comenzii.

OrderProcessor incheie.

A doua etapa:

Cand furnizorul confirma ca stocul este disponibil OrderAdmin.aspx apeleaza OrderProcessor pentru a continua procesarea comenzii.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSStockOK.

PSStockOK avanseaza statusul comenzii si OrderProcessor continua.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSTakePayment.

PSTakePayment utilizeaza detaliile tranzactiei stocate anterior de PSCheckFunds pentru a incheia tranzactia, apoi avanseaza statusul comenzii, iar OrderProcessor continua.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSShipGoods.

PSShipGoods trimite un email catre furnizor cu o confirmare a produselor comandate, instruieste furnizorul sa expedieze aceste bunuri clientului si avanseaza statusul.

OrderProcessor incheie.

A treia etapa:

Cand furnizorul confirma ca produsele au fost expediate, OrderAdmin.aspx apeleaza OrderProcessor pentru a continua procesarea comenzii.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSShipOK.

PSShipOK introduce data de expediere in baza de date, avanseaza statusul comenzii si indica OrderProcessor sa continue.

OrderProcessor detecteaza noul status al comenzii si apeleaza PSFinalNotification.

PSFinalNotification trimite un email clientului pentru a confirma expedierea comenzii si avanseaza comanda in etapa urmatoare.

OrderProcessor incheie.

In cazul in care ceva nu merge bine pe parcursul procesarii in pipeline, la oricare din puncte, cum ar fi neacceptarea cartii de credit, un email este trimis catre administrator. Acest administrator are toate informatiile necesare pentru a verifica problema, pentru a contactea clientul implicat si pentru a revoca sau inlocui comanda daca este necesar. Nici un punct din acest proces nu este in mod deosebit complicat, insa sunt necesare destul de multe coduri pentru a pune acest proces in functiune.

Inaintea inceperii construirii componentelor descrise anterior, este necesara efectuarea unor modificari in baza de date JokePoint si asupra aplicatiei web.

Tabelul de audit: in timpul procesarii, una dintre cele mai importante functii ale pipeline-ului este sa mentina un istoric al auditului actualizat. Implementarea acestei functii va implica adaugarea unor inregistrari intr-un nou tabel de baza de date numit Audit. Este necesara crearea acestui tabel avand campurile mentionate in tabelul 13-1.

Tabelul 13-1. Tabelul Audit

Intregistrarile vor fi adaugate prin OrderProcessor si in etape individuale pentru a indica reusite si esecuri. Acestea pot fi examinate anterior pentru a se analiza problema intampinata de o comanda, o functie importanta atunci cand este vorba de verificarea erorii.

Coloana MessageNumber este interesanta pentru ca permite asocierea unor mesaje specifice unui numar de identificare. Este posibila crearea unui alt tabel in baza de date care sa permita atribuirea unor descrieri acestor numere de mesaje, desi acest lucru nu este chiar necesar, deoarece schema folosita pentru numerotare (asa cum se poate vedea mai tarziu in acest capitol) este, prin definitie, descriptiva. Avem in plus, coloana Message cu informatii usor de citit.

Tabelul pentru comenzi: in acest moment, tabelul Orders nu permite adaugarea unui volum de informatii atat de mare pentru implementarea pipeline-ului de procesare a comenzilor. Este necesara adaugarea unor coloane noi asa cum este descris in tabelul 13-2 la tabelul Orders.

Tabelul 13-2. Tabelul Orders

Primele doua coloane din acest tabel nu necesita explicatii aditionale, insa urmatoarele doua sunt asociate cu tranzactii cu carti de credit, care vor fi detaliate in Capitolul 3.

A se retine faptul ca nu se vor folosi unele coloane deja existente in tabelul Orders, cum ar fi Verified si Completed deoarece aceste informatii sunt deja cuprinse in coloana Status. Coloana CustomerID este folosita mai degraba pentru a face legatura cu tabelul Customer, decat pentru a inregistra informatii referitoare la client in campul CustomerName si alte campuri asemanatoare.

Pentru a activa aceasta baza de date in scopul folosirii cu codul prezentat in acest capitol este necesar ca aceste coloane sa fie facute nule, deoarece datele anterioare nu vor asigura valori pentru acestea.

Procedura stocata CreateCustomerOrder: Actualmente, procedura stocata CreateOrder este folosita pentru a adauga comenzi in baza de date:

In momentul in care o comanda este creata baza de date trebuie sa fie pregatita pentru adaugarea mai multor informatii. In acest scop se va folosi o procedura stocata diferita (desi foarte similara), CreateCustomerOrder (diferenta este evidentiata cu bold):

Cei doi noi biti sunt dupa cum urmeaza:

Adaugand o valoare CustomerID comenzii

Setarea coloanei Status la 0, insemnand faptul ca comanda necesita procesare de la inceputul pipeline-ului de comenzi

Definirea claselor utilitare: Primele clase la care ne vom referi sunt clasele pentru tratarea exceptiilor OrderProcessorException si clasele utilitare pentru obiecte ale bazei de date: Customer, OrderDetail si OrderDetails. Vom analiza mai intai aceste clase deoarece sunt folosite de celelalte, iar definirea tipurilor va usura adaugarea de coduri pentru clase ulterioare.

Insert 2549f1304.tif

Figura 13-4: Rezultatul CommerceLibTest

Clasa OrderProcessorException este derivata din System.Exception si adauga proprietatea SourceStage de tip Integer. Acest lucru va fi folosit de etapele pipeline-ului pentru a identifica sursa exceptiei. O valoare de 100 (folosit in clasele Customer si OrderDetails) este aleasa arbitrar, insemnand „nici o etapa”, deoarece numerotarea sectiunilor de pipeline incepe de la 0. Nici un cod din definitia acestei exceptii nu necesita analiza suplimentara.

Clasa Customer este un invelis in jurul unui rand de date din tabelul Customer. Pentru a initializa un obiect Customer, se trece de SqlDataReader pentru a ajunge la clasa constructor, unde acest SqlReader contine toate campurile din tabelul Customer. Codul de aplicatie a consolei de test foloseste procedura stocata GetCustomer discutata anterior.

OrderDetail este o clasa cu proprietati standard care pur si simplu grupeaza la un loc datele unei comenzi. Constructorul pentru aceasta clasa este mai simplu decat cel pentru Customer, deoarece doar preia valorile ce urmeaza a fi folosite pentru aceste date. In cazul clasei Customer, datele expuse nu sunt proprietatile articolului din comanda, ci sunt preluate din acestea. La momentul actual, exista doua astfel de campuri publice, Cost (produsul dintre Quantity si UnitCost pentru articolul respectiv) si ItemAsString (care este un string formatat potrivit pentru afisarea proprietatilor produsului intr-un mod usor de inteles).

OrderDetails mosteneste clasa CollectionBase din namespace System.Collections, ceea ce este un punct de pornire important pentru o colectie puternica de clase. Daca aceasta clasa va este noua, trebuie stiut ca aceasta are un membru protejact numit List care stocheaza o lista de obiecte. Acest membru are metode precum Add, pentru a adauga un obiect unei liste.

Calendarul constructorului verifica fiecare articol din SqlReader, care contine o lista de inregistrari din tabelul OrderDetails. Constructorul adauga in membrul List articolele gasite in SqlReader ca obiecte OrderDetail, si elaboreaza un alt camp public disponibil: ListAsString. De aceasta data, campul public este o combinatie intre campurile ItemAsString ale fiecarei intregistrare OrderDetail si un string „Cost total”. Acestea vor fi disponibile in momentul confirmarii comenzilor de catre clienti si expedierea listelor de articole catre furnizori.

Codul din aplicatia-consola testeaza toate clasele de date adaugate, citind datele continute si afisand cateva proprietati. De asemenea, foloseste un indexer de OrderDetails pentru a recapitula obiectele de OrderDetail continute. Daca se doreste verificarea functionalitatii clasei OrderProcessorException, se alege o valoare pentru customerID sau orderID care nu are date asociate in baza de date – va aparea o exceptie OrderProcessorException.

Clasa OrderProcessor: asa cum ar putea parea acum, clasa OrderProcessor (clasa responsabila pentru transferarea unei comenzi pe parcursul pipeline-ului) contine un cod de mici dimensiuni. Oricum ar parea, se poate incepe simplu prin elaborarea unor functionalitati aditionale necesare. Pentru inceput, se va crea o versiune a clasei OrderProcessor cu urmatoarea functionalitate:

Include configurare completa, unde informatiile cu privire la string-ul de conexiune ce urmeaza a fi folosit, serverul de mail prin care se vor trimite mesajele email, adresele de email necesare si altele, sunt incarcate in procesorul de comenzi.

Selecteaza dinamic o sectiune din pipeline, suportand IPipelineSection.

Adauga date de baza de auditare.

Ofera acces la detaliile comenzii curente.

Ofera acces clientului pentru comanda curenta.

Ofera acces la sistemul de mail administrator.

Trimite mesaje administratorului in caz de eroare

Configurarea este stabilita conform unei structuri numite OrderProcessorConfiguration. Se prefera folosirea unei structuri in favoare unei clase deoarece datele necesare constau in valori simple. Aceasta este cumva o distinctie subtila, insa in acest caz este cea mai buna alegere.

De asemenea, se va crea o singura sectiune de pipeline, PSDummy, care foloseste o parte din aceasta functionalitate.

Pentru a implementa functionalitatea descrisa anterior, va fi necesara si adaugarea a trei noi proceduri:

GetOrderStatus: Returneaza statusul unei comenzi cu ID-ul atribuit comenzii.

AddAudit: Adauga o inregistrare in tabelul Audit.

GetCustomerByOrderID: Returneaza date despre client asociate cu o comanda si cu ID-ul atribuit acesteia.

Codul pentru aceste proceduri stocate poate fi gasit in urmatoare sectiune.

Insert 2549f1305.tif

Figura 13-5: Email de la PSDummy

Insert 2549f1306.tif

Figura 13-6: Inregistrarile efectuate de PSDummy in tabelul de audit

Informatiile stocate in structura OrderProcessorConfiguration, si utilizarea lor, se prezinta astfel:

String de conectare: Folosit in toate bazele de date de comunicare.

Server de mail: Numele serverului SMTP este folosit pentru a trimite mesaje email. Acesta este necesar in campurile-nume ale claselor din System.Web.Mail, care este folosit deoarece este o metoda simpla de a trimite email-uri. Acest parametru poate fi lasat necompletat pentru a se folosi automat serverul local, care este indeajuns in cele mai multe situatii.

Email administrator: Adresa de email la care se pot trimite mesaje in cazul in care ceva nu functioneaza corespunzator in timpul procesarii comenzii. Aceste mesaje pot fi in caz de lipsa de fonduri necesare, permitand administratorului sa ia masuri corective sau sa contacteze clientul direct.

Serverul de mail client: Adresa de raspuns pentru mesajele email trimise catre clienti sau furnizori.

Email procesor de comenzi: Adresa de raspuns pentru mesajele email trimise catre administrator.

Email furnizor: Adresa pentru mesajele email trimise catre furnizor.

Pentru a demonstra, configuram adresele de email ale administratorului si ale furnizorului pe o singura adresa de mail, care va fi si adresa clientului folosita pentru a genera comenzi de testare. In acest fel putem verifica daca totul functioneaza corespunzator inainte de a trimite mesaje catre exterior.

In continuare, vom discuta procedurile stocate mentionate anterior codului. Acestea vor implica coduri mai simple si nu vor necesita prea multa analiza.

Pana acum am inceput construirea backbone-ului aplicatiei si l-am pregatit pentru functionalitatea procesarii in pipeline, procesare ce va fi implementata in Capitolul 3.

Punctual, am analizat:

Modificarile aplicatiei JokePoint pentru a permite dezvoltarea unei procesari proprii.

Cadrul de baza pentru un pipeline de comenzi.

Adaugari in baza de date pentru datele de auditare si stocarea datelor aditionale necesare in tabelul Orders.

2.3. Implementarea unui pipeline pentru comenzi

In sectiunea anterioara am aratat functionalitatea de baza a componentei procesorului de comenzi (OrderProcessor), care este responsabil pentru mutarea comenzilor prin etapele pipeline. Am vazut o demonstratie rapida a acesteia, utilizand o sectiune de pipeline ca model (dummy pipeline section), dar nu ati implementat inca pipeline-ul despre care s-a discutat la inceputul sectiunii anterioare.

In acesta sectiune, vom adauga sectiunile de pipeline necesare pentru a putea procesa comenzile de la inceput pana la final, chiar daca nu vom adauga si functionalitatea completa a tranzactiei de carte de credit pana la urmatorul capitol. Totodata, ne vom uita la administrarea web a comenzilor prin modificarea Order Admin a paginilor din aplicatia JokePoint pentru a lua in vedere noul sistem de procesare a comenzii.

Procesorul de comanda (OrderProcessor) este complet, cu exceptia unei sectiuni foarte importante – stadiul selectiei de pipeline. Decat sa fortam procesorul sa utilizeze PSDummy, trebuie selectata o etapa pipeline, subliniata in sectiunea anterioara, in functie de felul comenzii. Inainte de aceasta, sa aruncam o privire la fiecare cod a sectiunilor de linie, care ne va duce la punctul in care linia de comanda va fi completa, separata de actuala autorizatie de card de credit.

Pe masura ce parcurgem sectiunile urmatoare, cream o noua clasa in proiectul CommerceLib, utilizand numele sectiunii ca denumire a clasei. Rezulta ca acest cod din urma trebuie introdus in clasa. Pana vom ajunge la urmatoarea sectiune ar trebui sa avem opt noi clase cu urmatoarele denumiri:

PSInitialNotification.

PSCheckFunds.

PSCheckStock.

PSStockOK.

PSTakePayment.

PSShipGoods.

PSShipOK.

PSFinalNotification.

In continuare vom discuta pe marginea claselor pe care le vom crea.

PSInitialNotification: PSInitialNotification este primul stadiu al pipeline si este responsabila cu trimiterea de mesaj la client, confirmand ca aceasta comanda a fost plasata. Codul contine asigurarile necesare importurilor; clasa insasi, care implementeaza, interfata sectiunii IPipeline; cateva campuri particulare pentru stocat referinte importante; si apoi procesul metodei de implementare a sectiunii IPipelineSection.Process.. Aceasta metoda incepe prin a stoca referintele in procesorul de comanda (OrderProcessor), lucru pe care toate sectiunile pipeline il vor face pentru ca utilizand metodele se expune (fie in metoda Process sau in alte metode, este esential. O intrare audit este totodata adaugata utilizand schema numerica introdusa anterior (initiala 2 arata ca acesta vine dintr-o sectiune pipeline, urmatoarea 00 arata ca este prima sectiune pipeline, finala 00 arata ca este mesajul de start pentru sectiunea pipeline).

PSCheckFunds: Stadiul de pipeline – PSCheckFunds este responsabil pentru a ne asigura ca clientul are fondurile necesare disponibile pe card-ul de credit. Deocamdata, vom asigura o implementare virtuala (dummy implementation), si vom presupune ca aceste fonduri sunt disponibile. Cand acest stadiu pipeline ajunge la final procesarea merge direct pentru PSCheckStock.

PSCheckStock: Stadiul pipeline PSCheckStock trimite un mesaj cu instructtiuni pentru furnizor de a verifica disponibilitatea stocului. De data aceasta, avem nevoie sa accesam detaliile comenzii, chiar daca nu este foarte necesar sa obtinem detaliile despre client, pentru ca furnizorul nu este interesat in acest stadiu de aceste detalii privitoare la cine a plasat comanda. Mesajul este transmis intr-o forma similara la PSInitialNotification, utilizand o metoda particulara pentru a construi corpul. Cand acest stadiu ajunge la final, procesarea intra in pauza. Mai tarziu, cand furnizorul confirma ca stocul este disponibil, procesarea merge la PSStockOK.

PSStockOK: Sectiunea pipeline PSStockOK nu rezolva multe probleme. Doar confirma ca furnizorul are produsul in stoc si merge inainte. Scopul sau real este de a cauta comenzi care sa aiba un status care sa corespunda cu aceasta sectiune pipeline si sa stie ca acestea sunt la momentul actual in asteptarea confirmarii de stoc. Cand acest stadiu pipeline se finalizeaza, procesarea merge direct la PSTakePayment.

PSTakePayment: Sectiunea pipeline PSTakePayment completeaza tranzactia inceputa de PSCheckFunds. Cu aceasta sectiune, doar asiguram o implementare virtuala (dummy implementation) aici, chiar daca retragem codurile de autorizatie si referinte pentru a verifica acea parte a procesorului de comanda (OrderProcessor). Cand acest stadiu pipeline se finalizeaza, procesarea merge direct la PSShipGoods.

PSShipGoods: Sectiunea pipeline PSShipGoods este remarcabil de similara cu PSCheckStock, datorita faptului ca trimite mesaj furnizorului si opreste pipeline pana cand furnizorul confirma ca stocul este transportat. De data aceasta avem nevoie de informatii despre clienti pentru ca furnizorul trebuie sa stie unde sa trimita comanda. Aceasta sectiune nu ar trebui combinata cu PSCheckStocK pentru ca dupa ce am verificat daca produsele se afla in stoc, trebuie acceptata plata inainte de transportarea produselor. Cand acest stadiu se finalizeaza procesarea intra in pauza. Mai tarziu cand furnizorul confirma comanda ca fiind trimisa, procesarea merge la PSShipOK.

PSShipOK: Sectiunea pipeline PSShipOK este foarte similara cu sectiunea PSStocOK, chiar daca are mai multe responsabilitati. Pentru ca acele produse au fost expediate, o data despre valoarea transportului poate fi adaugata in tabelul de comenzi (Orders). Technic, nu este foarte necesar, pentru ca toate intrarile audit sunt datate. Oricum, aceasta metoda asigura ca toate informatiile sunt usor accesibile intr-un table de baza de date. Cand acest stadiu se finalizeaza procesarea se muta direct la PSFinalNotification.

PSFinalNotification: Ultima sectiune pipeline – PSFinalNotification, este foarte similara cu prima sectiune in faptul ca trimite mesaj clientului. Aceasta sectiune confirma ca produsul a fost expediat. Cand aceasta sectiune se finalizeaza, statusul comenzii se schimba in 8, care reprezinta o comanda completa. Incercarile viitoare de de a procesa comanda utilizand procesorul de comanda (Order Processor) vor duce la o exceptie, fiind stearsa.

In continure vom testa aplicatia dupa cum urmeaza:

Executam codul, accesand procesorul de comanda (OrderProcessor). Procesam pentru prima data.

Verificam contul de mesaje (contul clientului) pentru notificarea transmisa clientului. Un exemplu este aratat in figura 14-1.

Introduceti (Insert) 2549f1401.tif

Figura 14-1. Mesajul de notificare pentru client.

Verificam contul de mesaje pentru mesajul de verificare a stocului. (vezi figura 14-2).

Introduceti (Insert) 2549f1402.tif

Figura 14-2. Mesaj de verificare stoc.

Continuam procesarea in aplicatia CommerceLibTest apasand tasta Enter, accesand procesorul de comanda (OrderProcessor). Procesam pentru prima data.

Verificam contul de mesaje pentru a vedea mesajul despre transportul produselor. (vezi Figura 14-3).

Introduceti (Insert) 2549f1403.tif

Figura 14-3. Mesaj expediere produse

Continuam procesarea in aplicatia CommerceLibTest apasand Enter, accesand procesorul de comanda (OrderProcessor). Procesam pentru a treia data si finalizam aplicatia.

Verificam contul de mesaje pentru a vedea daca am primit mesajul de confirmare a expedierii.(vezi Figura 14-4).

Introduceti (Insert) 2549f1404.tif

Figura 14-4. Mesajul de notificare al expedierii, pentru client.

Examinam noile intrari audit pentru comanda. (vezi Figura 14-5).

Introduceti (Insert) 2549f1405.tif

Figura 14-5. Intrari audit pentru comenzi complete.

Testul codului ne ofera oportunitatea aditionala de a testa aceasta exceptionala generatie, pentru ca daca il vom rula din nou, vom procesa o noua comanda gata finalizata. Executam aplicatia din nou si ar trebui sa obtinem o exceptie ca in Figura 14-6.

Introduceti (Insert) 2549f1406.tif

Figura 14-6. Exceptie comanda completa.

Daca verificam contul de mesaje, vom vedea detaliile.(vezi Figura 14-7).

Introduceti (Insert) 2549f1407.tif

Figura 14-7. Mesaj de eroare in completarea comenzii.

Mesajul de eroare trimis administratorului va fi indeajuns pentru a incepe cautarea posibilelor probleme care au dus la eroare.

Ultimul exemplu a fortat procesorul de comanda (Order Processor). Metoda de procesare a fost accesata de trei ori la rand din testul cod. In practica, aceasta nu se va intampla – metoda va fi accesata o data de Checkout.aspx cand clientul va plasa o comanda, si de doua ori de catre furnizor in OrdersAdminPage.aspx. Vom avea nevoie sa modificam aceste pagini web pentru a angaja interfata web.

Aceste ambe pagini vor avea nevoie de configuratia procesorului de comanda, si deci un bun punct de pornire ar fi sa adaugam detaliile configuratiei din web.config dupa cum urmeaza:

Din nou, vom avea nevoie de modificarea acestor setari pentru a se potrivi configuratiei noastre. Totodata va fi nevoie sa adaugam referinte la noua librarie CommerceLib.

Administrarea comenzilor prin intermediul paginii OrdersAdminPage.aspx: aceasta pagina poate fi implementata in diverse modalitati. In unele setup-uri, ar fi mai bine sa implementam aceasta pagina ca o aplicatie Windows Forms, de exemplu, daca furnizorii se afla in-house sau in aceeasi retea. Sau ar fi bine sa se combine aceste propuneri cu serviciile de web.

Oricare ar fi metoda aleasa, functionalitatea de baza este aceeasi: furnizorii si administratorii ar trebui sa vada o lista de comenzi care cer atentie, si sa le avanseze in pipeline manual. Acesta este un simplu caz de accesare a procesorului de comanda (OrdersProcessor). Metoda de procesare este ca cea descrisa mai devreme.

Pentru a simplifica lucrurile in aceasta sectiune, vom asigura o singura pagina atat pentru furnizori cat si pentru administratori. Aceasta ar putea sa nu fie ideal in toate situatiile, pentru ca nu am vrea sa expunem toate detaliile comenzilor sau informatiile audit furnizorilor externi. In orice caz, pentru scopuri demonstrative, aceasta reduce cantitatea de cod prin care trebuie sa trecem. Totodata vom intari securitatea pentru aceasta pagina prin formele de securitate mentionate mai devreme in manual si care sunt furnizate de catre administrator, presupunand ca persoanele cu permisiune de a edita datele site-ului vor avea totodata permisiunea de administra comenzile. Intr-un setup mai avansat, putem modifica aceasta putin, asigurand categorii pentru diverse tipuri de utilizatori, si restrictionand disponibilitatea functionalitatii utilizatorilor in alte categorii.

Ca punct de start, vom lua pagina existenta OrdersAdminPage.aspx si vom asocia controlul de utilizator si clasele si le vom rescrie sa asigure functionalitatea ceruta. Altfel, putem simplifica codul putin pentru a obtine aceasta , pentru ca nu va fi nevoie sa reactualizam datele comenzilor la fel de complet ca pana acum. In orice caz, sunt destul de multe modificari de cod prin care trebuie sa trecem, ca atare, nu ne vom uita la acest exemplu in contextul unei sectiuni.

Primul lucru care trebuie facut este adaugarea unei noi tabele in baza de date. Tabela se va numi Status si va contine etape modificabile personal ce descriu statutul comenzilor. Cand se filtreaza comenzile, este mult mai bine sa se faca acest lucru prinrt-o descriere a ordinii etapelor decat printr-un numar de status care este mai usor de retinut o descriere ca de exemplu „Order Completed” (Comanda completata) decat numarul 8 de exemplu. Punerea acestei tabele in baza de date da posibilitatea extinderii pe viitor. Sturctura noii tabele este descrisa in Tabelul 14-1.

Populam tabela Status dupa cum am aratat in tabelul urmator:

Tabel continut …

Adaugarea procedurilor de stocare – va fi necesar sa adaugam cateva proceduri stocate noi, care vor fi utilizate de catre obiectul de activitate al managerului de comanda (OrderManager), pentru a obtine datele necesare afisarii informatiilor de comanda.

Trebuie sa avem in vedere faptul ca multe dintre aceste proceduri stocate vor fi folosite in locul catorva proceduri utilizate anterior de catre versiunea mai veche a acestei pagini (sau, mai specific, de catre clasa managerului de comanda). Datorita faptului ca sistemul de stocare a datelor comenzii s-a schimbat putin, acum sunt necesare diferite coloane.

GetStatuses – preia lista statuturilor din tabela Status.

GetOrders – obtine toate comenzile

GetOrder – obtine o comanda specifica.

GetOrdersByRecent – obtine un numar specificat al celor mai recente comenzi.

GetOrdersByCustomer – obtine toate comenzile plasate de catre un client specificat.

GetOrdersByDate – obtine comenzile intre doua date specificate.

GetOrdersByStatus – obtine toate comenzile cu un status specificat.

GetAuditTrail – obtine intrarile tabelei Audit associate cu o comanda specificata.

OrdersAdmin.ascx este controlul utilizator care afiseaza o lista de criterii certe a comenzilor de intalnire, cum ar fi comenzile plasate intre doua date specificate. Acum ca am schimbat felul in care comenzile sunt procesate,exista cateva filtre acum, care nu mai sunt necesare, cum ar fi cautarea pentru comenzi neverificate sau anulate. In loc, adaugam filtre care iau in considerare noua structura a datelor, cum ar fi filtrarea comenzilor prin status sau ID client. Totodata trebuie schimbate ce date vor fi afisate in tiparul de date. Aceasta cere cateva modificari in cadrul codului ASP.NET pentru pagina.

Cateva dintre schimbarile afisate aici sunt schimbari pentru ID-urile obiectelor. Aceasta este pentru a tine lucrurile in linie cu denumirile procedurilor nou stocate pentru a vedea mai usor cu ce relationeaza fiecare component.

OrderDetailsAdmin.ascx, ultimul control de modificat arata detaliile unei comenzi. Anterior, in aplicatie, acest control totodata includea capacitatea de a modifica data comenzii, dar inlocuim asta acum. In locul ei, asiguram capacitatea de a impinge comenzile de-a lungul pipeline cand raman blocate in asteptarea confirmarii de stoc si asteptarea confirmarii etapelor de transport.

Cateva alte modificari sunt necesare. Acum, ca detinem informatii despre client mai detaliate, putem afisa toate datele disponibile (separat de informatiile despre credit card sau parole) pentru clientul care a plasat o comanda intr-un tipar de date noi. Putem afisa totodata toate informatiile audit pentru comenzile plasate intr-un lant nou tipar de date. Pentru ca avem aceste noi surse de informatii, putem anula putin din celelalte informatii afisate pentru comanda, care apar in casetele text doar citibile de deasupra barei de date.

2.4. Testarea paginii de administrare a comenzilor

Tot ceea ce ramane acum de facut este a se verifica daca totul functioneaza cum trebuie. Pentru aceasta, utilizam interfata web pentru a plasa o comanda, apoi o verificam prin legatura OrdersAdmin la default.aspx. Vom vedea ca comanda asteapta confirmarea de stoc, cum este aratat in Figura 14-8.

Introduceti (Insert) 2549f1408.tif

Figura 14-8. Comanda asteapta confirmare de stoc

Dam click pe View Details (Arata Detalii), si derulam pagina in jos pana cand apare butonul pentru confirmare de stoc, cum este aratat in Figura 14-9.

Introduceti (Insert) 2549f1409.tif

Figura 14-9. Confirmare buton de stoc

Apasati butonul de confirmare stoc si comanda se proceseaza. Pentru ca aceasta se intampla foarte repede, vom intra intr-o noua etapa care se refera la promptitudinea confirmarii transportului, cum este aratat in Figura 14.10.

Introduceti (Insert) 2549f1410.tif

Figura 14-10. Gata (Prompt) pentru confirmare transport.

Apasand confirmare transport (Confirm Shipment) va arata ca comanda a fost completata, cum este aratat in Figura 14-11.

Introduceti (Insert) 2549f1411.tif

Figura 14-11. Status comanda completa.

Daca derulam pagina mai in jos (scroll), putem vedea toate mesajele de coada audit care au fost stocate in baza de date privitoare la comanda, cum este aratat in Figura 14-12.

Introduceti (Insert) 2549f1412.tif

Figura 14-12. Mesaje de coada audit (Audit trail messages) pentru aceasta comanda.

2.5. Concluzii

Am facut mari pasi in completarea aplicatiei de e-comert in acest capitol. Acum avem un backbone securizat si auditat complet pentru aceasta aplicatie.

In mod specific, am rezolvat:

Modificari la aplicatia (JokePoint) aplicatia ce va inlocui procesarea propriei pipeline – pentru a angaja propria procesare de linie.

Tiparul de baza pentru linia de comanda.

Bazele de date aditionale pentru datele audit si stocare datele aditionale in tabela pentru comenzi (Orders.)

Implementarea celor mai multe linii de comanda separate de acele sectiuni care se refera la comanda prin card de credit.

O simpla implementare a unei pagini de web administrativa pentru comanda.

Singurul lucru care lipseste dar este necesar a fi adaugat inainte de a inainta aceasta aplicatie in exterior, este functionalitatea procesarii card-ului de credit, la care vom lucra in urmatorul capitol.

CAPITOLUL 3. Tranzactii cu carti de credit

3.1. Introducere

In cadrul acestui capitol, vom analiza modalitatile de dezvoltare a capacitati de procesare a cartilor de credit. Vom incepe odata cu rememorarea teoriei aflate la baza tranzactiilor pe baza de carti de credit, a tipului de organizatii ce faciliteaza accesul la tranzactiile pe baza de carti de credit, si a structurii tranzactiilor posibile. Pe masura ce vom inainta, vom avea ocazia de a analiza exemplul a doua tipuri de organizare si de a discuta elementele specifice pentru fiecare dintre API-urile distincte ale tranzactiilor lor (API reprezentand Interfetele Programului Aplicat, adica mijloacele prin care accesam partea functionala a tranzactiilor pe baza de carte de credit). Dupa care, vom ajunge sa cream o bibliografie de un alt gen, ce ne va ajuta sa utilizam unele dintre API-urile acestor tranzactii prin intermediul unui simplu cod de testare.

In cele din urma, vom integra API-ul in cadrul aplicatiei unei aplicatii de comert virtual si in cadrul sistemului de procesare a comenzilor.

3.2. Elemente Fundamentale ale Tranzactiilor pe baza de Carti de Credit

Bancile si alte institutii financiare utilizeaza retele securizate pentru operarea tranzactiilor lor, retele ce se bazeaza mai mult pe protocolul X.25 si mai putin pe TCP/IP (adica Protocolul de Control al Transmisiei/Protocolul de Internet, reprezentand mijloacele primare prin care datele sunt transmise pe Internet). Protocolul X.25 nu reprezinta un element despre care ar trebui sa stim prea multe, in afara faptului ca reprezinta un protocol diferit pentru retele si ca nu este compatibil cu TCP/IP. Astfel, retelele de tipul X.25 sunt separate complet de Internet, si desi este posibil sa le accesam in mod direct, aceasta nu se constituie intr-o solutie sensibila.

In cazul in care alegem sa o facem, este posibil sa trebuiasca sa antamam niste negocieri serioase cu proprietarul retelei pe care intentionam sa o folosim. Proprietarul va dori sa fie 100% sigur ca reprezentam un client serios, capabil sa asigure masurile de siguranta necesare prevenirii oricaror atacuri la adresa sistemului sau. Proprietarul retelei nu va elibera licentele respective oricaror persoane, dat fiind ca majoritatea oamenilor nu-si vor permite adoptarea masurilor de securitate solicitate (ce pot include inchiderea serverelor intr-o incapere blindata, depozitarea zilnica de casete de siguranta intr-o locatie sigura, asigurarea a trei indivizi distincti cu chei separate de accesare a casetelor respective, s.a.m.d.).

Alternativa este reprezentata de adoptarea unei cai intermediare prin utilizarea unui furnizor de cai de acces. Aceasta ne va permite sa efectuam partea noastra din cadrul protocolului de tranzactionare pe baza de carti de credit de pe Internet (prin intermediul unui protocol securizat), si in acelasi timp sa ne bazam pe calea de acces selectata pentru a comunica cu retelele de tipul X.25. In ciuda faptului ca vor exista mai mult ca sigur costuri aferente, furnizorul are toate sansele sa fi ajuns la vreun acord in relatia sa cu institutiile financiare, ce ii permite sa tina in frau costurile, in timp ce economiile ne vor reveni noua (evident dupa ce „calea de acces” isi va fi incasat cota sa parte), astfel incat exista sansa ca aceasta modalitate sa fie mai rentabila in comparatie cu cazul in care dispunem de propria noastra conexiune X.25.

Aceasta metoda poate de asemenea sa fie mai ieftina fata de cazurile in care utilizam serviciile unor terti precum PayPal, deoarece avem nevoie exclusiv de o functionalitate minima, in momentul in care ne administram propria noastra cale de plasare a comenzilor. De exemplu, nu este nevoie sa utilizam toate functiile de control al comenzii, ce ne sunt oferite de companii precum PayPal, deoarece am atins pe cont propriu acest nivel de functionalitate – pe parcursul sectiunii precedente.

3.3. Administrarea cailor de acces ale platilor efectuate cu ajutorul cartilor de credit

Pentru a putea lucra impreuna cu o organizatie bazata pe cai de acces, va trebui sa deschidem un cont bancar la o banca comerciala. Acest lucru poate fi facut cu ajutorul majoritatii bancilor, acestea oferindu-ne un cod de Identificare comerciala, pe care il vom utiliza in cadrul inscrierii in calea de acces. Pasul urmator va fi constituit de selectarea caii de acces adecvate. Din nefericire, acesta poate fi un proces dureros de lung!

In general, nu este greu sa identifici o cale de acces; este dificil sa o gasesti pe cea potrivita. Piata este saturata la modul literal de sute de companii ce si-au propus sa ia o cota parte din profitul companiilor ce vor sa proceseze carti de credit in aplicatiile lor. O cautare expeditiva pe Internet bazata pe cuvintele cheie „credit card gateway” ne va pune in fata unei liste extrem de consistente. Siteurile de pe Internet ale acestor societati comerciale sunt alcatuite in pure scopuri publicitare, in marea lor majoritate – ne vom ingropa in pagini auto-suficiente la adresa calitatii si sigurantei serviciilor acestor societati, pentru a sfarsi in fata unui formular, pe care va trebui sa il completam astfel incat un reprezentant din partea serviciului clienti al firmei respective sa ne poata contacta pentru „a discuta nevoile noastre”. Pe termen lung, va mai trebui sa repetam procedura cel putin inca o data.

Pana la urma vom observa ca majoritatea organizatiilor ce furnizeaza acest serviciu, ofera de asemenea pachete similare, astfel incat diferentele ce ne vor afecta decizia finala vor fi extrem de mici. Totusi, este bine sa ne asiguram in prealabil in legatura cu cateva puncte de interes precum bancile cu care lucreaza (in ceea ce priveste contul nostru, acesta va trebui deschis la o banca comerciala agreata de firma respectiva), valuta de tranzactionare, si, bineinteles, nivelul costurilor.

Pe parcursul acestui capitol, vom analiza un numar de doua astfel de organizatii, preferate datorita facilitatilor de tranzactionare – si anume DataCash si VeriSign PayFlow Pro.

DataCash reprezinta o organizatie a cailor de acces pentru tranzactii bazate pe carti de credit localizata in Regatul Unit. Din nefericire, aceasta presupune ca noi sa dispunem de un cont deschis la o banca comerciala britanica, in cazul in care intentionam sa il utilizam in cadrul aplicatiei finale, desi aceasta problema nu trebuie sa ne preocupe pentru moment. Motivul pentru care am utilizat exemplul DataCash in cadrul acestui capitol este ca nu suntem obligati sa efectuati prea multe etape pentru a avea acces la un cont de testare destul de util – mai ales ca nici macar nu avem nevoie de un cont bancar deschis in cadrul vre-unei banci comerciale.

Dupa cum o sa observam pe parcursul acestui capitol, vom putea efectua tranzactii de testare cu ajutorul unor numere asa zis „magice”, furnizate de DataCash, care va va accepta sau declina tranzactiile fara a efectua in mod real nici un fel de tranzactii financiare. Acest fapt este extrem de util din ratiuni ce tin de dezvoltare, deoarece este evident faptul ca nu dorim sa folosim propriile noastre carti de credit in cadrul testarii!

Concluziile importante demne de retinut sunt acelea ca tehnicile acoperite in acest capitol se aplica tuturor cailor de acces la tranzactii bazate pe carti de credit. Amanuntele pot diferi usor in functie de organizatiile de pe piata, dar ce-a fost mai dificil de atins a fost atins din punctual nostru de vedere. Inaintea de a ne pune intrebarea, este bine sa stim ca nu suntem reprezentantii cu vanzarile ai DataCash?. Este de ajuns pentru noi sa stim ca am dedicat un numar arhisuficient de ore (sau chiar zile!) analizarii tranzactiilor bazate pe carti de credit, si pana in acest moment nu am reusit sa gasim vreun mod mai prietenos pentru dezvoltatorul de afaceri – pentru ca acesta sa poata antama ocupatia lucrativa.

PayFlow Pro reprezinta un serviciu furnizat de catre societatea comerciala de renume si recunoastere mondiala de pe Internet – VeriSign. Aceasta societate s-a instalat in postura de resursa extrem de bine cotata in domeniul securitatii pe Internet si a aplicatiilor comercial-virtuale, astfel incat intrarea lui VeriSign pe piata concurentiala a cailor de acces la tranzactii bazate pe carti de credit nu a mai reprezentat nici un fel de surpriza.

In realitate, prima editie a acestei carti nu a inclus serviciul PayFlow Pro. Totusi, dat fiind ca cititorii au inregistrat succese cu ajutorul sau, ne-am vazut obligati sa il includem in prezenta.

3.4. Principiile functionale ale tranzactiilor bazate pe carti de credit

Indiferent de tipul caii de acces utilizate, se vor aplica aceleasi principii fundamentale ale tranzactiilor ce utilizeaza carti de credit. In primul rand, felul de tranzactii efectuate de noi in cadrul siteului de Internet al magazinului virtual sunt cunoscute sub titulatura de tranzactii In Lipsa Cardului (CNP), ceea ce presupune faptul ca nu avem cartea de credit la noi, si ca nu putem verifica semnatura clientului. Aceasta constituie un simplu amanunt de care trebuie sa tinem cont, in cazul in care intalnim acronimul CNP.

Exista un numar de servicii avansate ce ne sunt puse la dispozitie de catre diverse cai de acces, inclusiv sisteme de verificare a adresei posesorului de card, verificari ale codului de siguranta, mijloace de prevenire a fraudelor electronice, s.a.m.d.. Fiecare dintre mijloacele de mai jos contribuie prin insumarea de nivele suplimentare de complexitate procedurilor de procesare a cartii noastre de credit, si este mai bine sa ne oprim aici cu dezvoltarea acestui subiect adiacent temei centrale. Acest capitol este menit sa ofere mai mult un punct de plecare, moment in care noi suntem liberi sa adaugam aceste servicii, in cazul in care le vom considera necesare.

Datorita tuturor acestor servicii aditionale, alegerea va fi determinata de cash-flow-ul ce este circulat de sistemul nostru, si de modul in care alegem varianta de echilibrare a riscului asumat (cele doua alternative fiind reprezentate de costurile de implementare si costurile potentiale aferente cazurilor in care sistemul este „deranjat”, iar acest lucru ar fi putut fi preintampinat prin utilizarea initiala a serviciilor suplimentare. In eventualitatea in care suntem interesat de aceste servicii, „reprezentantul serviciului clienti” mentionat anterior va fi incantat sa ne clarifice situatia.

Avem posibilitatea de a efectua mai multe tipuri de tranzactii, printre care:

Autorizare: Tipul de baza, verifica soldul cardurilor si le deduce.

Pre-autorizare: Verifica soldul cardurilor si le aloca in cazul in care acestea sunt disponibile, fara a le deduce instantaneu.

Finalizare Tranzactie: Finalizeaza o tranzactie pre-autorizata, prin deducerea fondurilor alocate in prealabil.

Inapoiere cash: Returneaza fondurile aferente unei tranzactii finalizate, sau pur si simplu depune soldul pe o carte de credit.

Din nou, amanuntele pot fi diferite, dar acestea reprezinta elementele tipologice de baza. In cadrul acestui capitol, vom utiliza modelul de pre/finalizare, prin care nu acceptam plata, decat in momentul in care am dirijat furnizorul sa expedieze bunurile. Acest detaliu a fost prevazut anterior in cadrul structurii caii de acces create pe parcursul capitolului anterior.

3.5. Implementarea procesarii cartii de credit

In acest moment se poate considera ca am acoperit elementele fundamentale, si de aceea este nevoie sa analizam modul in care pot fi antamate lucrurile in cadrul aplicatiilor de tipul siturilor de comert electronic in baza sistemului DataCash. In primul rand, va trebui sa cream un cont de testare in cadrul DataCash la adresa de Internet http://www.datacash.com/. Dupa introducerea informatiilor in formular si expedierea acestora vom primi un email cu numele de utilizator si parola contului, cat si celelalte informatii suplimentare necesare accesarii sistemului de acoperire DataCash.

Pasul urmator ar fi reprezentat in mod normal de descarcarea uneia dintre uneltele informatice de integrare ale DataCash. Totusi, dat fiind ca DataCash nu furnizeaza o solutie de implementare compatibila cu tipul .NET, va trebui sa utilizam XML API in carul tranzactiilor pe care intentionam sa le efectuam. In principiu, aceasta presupune expedierea de solicitari XML la o anumita adresa URL cu ajutorul conexiunii SSL, si descifrarea rezultatului XML. Toti acesti pasi pot fi indepliniti cu usurinta folosind .NET.

3.5.1 Analiza modelului XML API al DataCash

Urmeaza sa efectuati un efort intens de manipulare al XML, in cazul comunicarii cu DataCash, deoarece va trebui sa cream documente XML pe care le vom expedia catre DataCash; de asemenea va trebui sa extragem datele din cadrul raspunsurilor XML. Pe parcursul acestei sectiuni, vom efectua un scurt tur al procedurilor XML necesare operatiunilor pe care le vom efectua, cat si al raspunsurilor la care ne putem astepta.

3.5.1.1 Solicitarea de pre-autentificare

In momentul in care veti expedia o solicitare de pre-autentificare catre DataCash, va trebui sa cuprindeti si informatiile ce urmeaza:

Numele de utilizator oferit de DataCash (cunoscut sub numele de Client al DataCash);

Parola DataCash;

Un numar unic de referinta al tranzactiei (ce urmeaza a fi explicitat mai jos);

Suma de bani ce urmeaza a fi debitata;

Valuta de referinta utilizata de tranzactie (USD, GBP, s.a.m.d.);

Tipul tranzactiei (pentru pre-autentificare, se foloseste codul pre);

Numarul cartii de credit;

Data de expirare a cartii de credit;

Data de eliberare a cartii de credit (in cazul in care este opozabila tipului cartii de credit utilizate);

Numarul de serie al cartii de credit (in cazul in care este opozabil tipului cartii de credit utilizate).

Numarul de referinta trebuie sa fie un numar de 6 pana la 12 cifre, pe care il alegem pentru a putea corobora fiecarei tranzactii comanda aferenta acesteia. Datorita faptului ca nu putem alege un numar scurt, nu este posibil sa utilizam pur si simplu valorile de Identificare ale comenzii. Totusi, putem sa folosim valorile de Identificare ale comenzii ca punct de plecare pentru crearea unui numar de referinta, efectiv prin largirea numarului, prin adaugarea unei cifre, asa cum este 1.000.000. Nu puteti nici sa folositi numarul de referinta in alte tranzactii ulterioare, astfel incat puteti fi sigur ca acest numar nu va mai putea fi folosit dupa finalizarea tranzactiei, deci riscul dublei facturari a clientului a fost complet inlaturat. Aceasta inseamna, pana la urma, ca in eventualitatea in care o carte de credit este respinsa, va trebui sa cream o comanda noua pentru client, dar acest lucru nu ar trebui sa puna nici un fel de probleme, la rigoare.

Solicitarea XML dispune de urmatorul format, avand valorile detaliate, care pana acum au fost reliefate cu caractere bolduite:

3.5.1.2 Raspunsul la Solicitarea de Pre-autentificare

Raspunsul la Solicitarea de Pre-autentificare include urmatoarele informatii:

Un numar de cod al statutului tranzactiei; 1 pentru tranzactiile finalizate correct, sau unul dintre celelalte coduri aferente unor alte stari de procesare.

Un motiv al statutului, care reprezinta de fapt o secventa explicativa, descriptiva pentru statutul procesarii, in limba Engleza. Pentru statutul 1, aceasta secventa a fost ACCEPTATA.

Un cod de autentificare utilizat pentru finalizarea tranzactiei.

Un cod de referinta ce poate fi utilizat de catre DataCash.

Momentul la care tranzactia a fost procesata.

Modul de tranzactionare, care este de TESTARE atunci cand utlizam contul de testare.

Confirmarea tipului cartii de credit utilizate.

Confirmarea statului emitent al cartii de credit.

Codul de autorizare utilizat de catre banca (pentru scopuri ce tin exclusiv de raportare).

XML-ul necesar acestor proceduri este alcatuit dupa cum urmeaza:

3.5.1.3. Solicitarea Finalizarii Tranzactiei

In cazul unei solicitari de finalizare a tranzactiei, avem nevoie de urmatoarele informatii:

Numele de utilizator oferit de DataCash (cunoscut sub numele de Client al DataCash).

Parola DataCash.

Tipul tranzactiei (pentru finalizare, se foloseste codul fulfil).

Codul de autentificare primit anterior.

Numarul unic de referinta al tranzactiei primit anterior.

Optional, putem cuprinde si informatii suplimentare, precum sunt confirmarea sumei ce urmeaza a fi debitate de pe cartea de credit, desi aceasta nu este cu adevarat necesara. Aceasta este alcatuita dupa cum urmeaza:

3.5.1.4. Raspunsul de Finalizare a Tranzactiei

Raspunsul la solicitarea de Finalizare a Tranzactiei include urmatoarele informatii:

Un numar de cod al statutului tranzactiei; 1 pentru tranzactiile finalizate correct, sau unul dintre celelalte coduri aferente unor alte stari de procesare.

Un motiv al statutului, care reprezinta de fapt o secventa explicativa, descriptiva pentru statutul procesarii, in limba Engleza. Pentru statutul 1, aceasta secventa a fost FINALIZATA OK.

Doua exemplare ale codului de referinta ce poate fi utilizat de catre DataCash.

Momentul la care tranzactia a fost procesata.

Modul de tranzactionare, care este de TESTARE atunci cand utlizam contul de testare.

XML-ul necesar acestor proceduri este alcatuit dupa cum urmeaza:

3.5.2. Expedierea Datelor XML

Avem posibilitatea de a acumula documentele XML indicate in prealabil fie unul cate unul, dar platforma .NET ne permite sa punem lucrurile la punct intr-un mod mult mai eficient. Solutia de mai jos implica serializarea XML. Putem sa configuram orice clasa .NET intr-o asemenea maniera incat aceasta sa fie serializata ca document XML, si sa folosim de asemenea documentele XML pentru a forma noi clase. Aceasta presupune convertirea tuturor metodelor si proprietatilor publice in date XML, reprezentand baza functionalitatii serviciilor web din cadrul .NET.

Procedura standard pe care trebuie sa o adoptam este crearea de documente XML cu ajutorul unor elemente denumite identic cu metodele si proprietatile publice pe care intentionam sa le serializam. Spre exemplu, vom putea dispune de urmatoarele clase si membrii ai claselor:

Aceasta va fi serializata dupa cum urmeaza:

Putem suprascrie aceasta procedura cu ajutorul atributelor de serializare XML. De asemenea, putem forta formatarea elementelor datelor sub forma si impreua cu nume personalizate, ca atribute, ca text normal, s.a.m.d..

Spre exemplu, putem suprascrie clasa anterioara prin serializare sub forma de atribut, dupa cum urmeaza:

Partea <XmlAttributeAttribute()> presupune ca membrul ce o succede ar trebui serializat ca atribut, iar parametrul secvential va denumi atributul. Aceasta clasa va fi de acum serializata dupa cum urmeaza:

Putem utiliza mai multe atribute de acest fel, de aceea prezentam o parte dintre ele in exemplul de mai jos. Acest exemplu demonstreaza modul in care putem crea categoriile ce reprezinta solicitarile si raspunsurile DataCash, ce vor putea suporta serializare si deserializare din cadrul unui model XML. Aceasta dispune de doua avantaje:

Faciliteaza considerabil transmiterea datelor catre DataCash.

Putem utiliza la intreaga capacitate clasele .NET pentru a ne asigura un mod inteligent de accesare a datelor.

In cadrul exemplului urmator, avem posibilitatea de a crea clasele necesare schimbului de date cu DataCash, si de a proba aceste clase prin utilizarea unui cod simplu al clientului. Trebuie luat in considerare faptul ca o serie de clase sunt utilizate pentru dezvoltarea XML deoarece structura acestuia implica mai multe elemente integrate si nu doar o structura plata.

Insert 2549f1501.tif

Diagrama 15-1. Rezultatul tranzactiilor DataCashLib

Insert 2549f1502.tif

Diagrama 15-2. Raportul de tranzactionare DataCash

Insert 2549f1503.tif

Diagrama 15-3. Detaliile raportului de tranzactionare DataCash

Tocmai am creat un cod de reprezentare a documentelor XML pe care le-am expediat. Doua clase de extinse – CerereDataCash si RaspunsDataCash – incadreaza solicitarile si raspunsurile XML. Aceste clase includ secvente ale celorlalte clase definite, ce contin secvente ale altor clase, s.a.m.d., in ceea ce priveste structura documentelor XML descrise in prealabil.

Fiecare dintre membrii acestor clase dispune de un atribut asociat de serializare XML, ce coroboreaza datele modului de formatare, la momentul serializarii claselor de solicitare sau de raspuns. Spre exemplu, o buna parte a membrilor String apar dupa cum urmeaza:

Campul Statut va fi alcatuit dupa cum urmeaza:

Scrierea corecta cu majuscula este continuta si in acelasi timp aceasta va permite sa stabilim datele definitorii ale statutului cu ajutorul formatului Reprezentarii Pascal. Reprezentarea Pascal este constituita de modul in care numele variabilelor incep cu o majuscula si fiecare cuvant ulterior de pe parcursul numelui contine la randul sau o majuscula, dupa cum este evidentiat in exemplul AceastaEsteOVariabila. O schema alternativa ar fi reprezentata de reprezentarea camel, prin care nu se scrie primul cuvant cu majuscula, dupa cum este evidentiat in exemplul aceastaEsteOVariabila. Majusculele integrate numelor acestor scheme de reprezentare serveste ca un punct de reamintire a destinatiei lor.

Solicitarile HTTP pot fi expediate in mai multe formate, cel mai intalnit fiind GET si POST. Diferenta dintre cele doua consta in cazul de fata in faptul ca solicitarile GET contin exclusiv adresa URL si informatia din preambul; solicitarile POST contin toate acestea, dar dispun si de un corp de mesaj. Ne raportam la o solicitare HTTP de tipul POST ca si cand ar fi un email, cu raspunsul HTTP pe post de raspuns email. In ambele cazuri, informatia din preambul actioneaza pe post de adresa si subiect al email-ului, iar corpul de informatie va reprezenta corpul mesajului unui email.

3.6. Integrarea Sistemului DataCash cu aplicatia JokePoint

In acest moment dispunem de o arhiva de tip nou, pe care o putem utiliza pentru a efectua tranzactii bazate pe carti de credit. Totusi, va trebui sa modificam o serie de lucruri pentru a o putea integra in cadrul aplicatiilor si caii de acces comercial-virtuale.

3.6.1. Modificarea Configuratiei Modulului de Procesare a Comenzii

In acest moment dispunem de trei noi elemente informative pe care CommerceLib le necesita in vederea functionarii:

Clientul DataCash.

Parola DataCash.

Adresa de URL a DataCash.

Putem incadra toate aceste informatii in cadrul clasei de configurare a procesarii comenzilor, pe care o utilizam pentru a initializa modulul de procesare a comenzii, in felul urmator:

Operarea acestei modificari va strica orice cod ce utilizeaza arhiva CommerceLib, dar pana sa ajungem sa il folosim, vom corecta situatia. Totusi, este bine sa indepartam CommerceLibTest din cadrul solutiei CommerceLib, dat fiind ca nu vom mai avea nevoie de aceasta, si la un moment dat ar putea deveni suparator sa observam cum nu reuseste sa apara de fiecare data. Alternativ, putem modifica CommerceLibTest pentru a-l adapta noii scheme si utiliza in cadrul testelor, in ciuda faptului ca acest lucru nu reprezinta inca o necesitate.

Putem pastra aceasta informatie in cadrul fisierului web.config al aplicatiei JokePoint:

De asemenea, trebuie sa expediam modalitatea de administrare a evenimentelor placeOrderButton_Click din cadrul Checkout.aspx.vb astfel incat sa cuprinda si aceasta informatie:

Aceleasi modificari vor trebui efectuate asupra codului din cadrul OrderDetailsAdmin.aspx.vb.

3.6.2. Modificarea caii de acces

Modificarile finale implica schimbarea claselor sectiunii caii de acces ce faciliteaza tranzactiile bazate pe cartile de credit. Infrastructura de pastrare si accesare a codurilor de autentificare si a informatiilor de referinta a fost deja inclusa, prin intermediul metodei OrderProcessor.SetOrderAuthCodeAndReference si a proprietatilor AuthCode si Reference.

In momentul in care adaugam o referire la DataCashLib si la CommerceLib, modificarile aduse la adresa PSCheckFunds sunt urmatoarele:

Modificarile la PSTakePayment sunt urmatoarele:

3.7. Testarea

In acest moment, dat fiind ca am reusit sa ajungem la acest nivel stabil, este important sa probam sistemul supunandu-l catorva comenzi. Aceasta se poate realiza facil prin asigurarea unui client detinator ale unor detalii „magice” ale cartii de credit. Dupa cum am mentionat in prealabil, la inceputul capitolului, acestea reprezinta numerele pe care DataCash le furnizeaza din ratiuni de testare, si pot fi utilizate in vederea obtinerii unor raspunsuri specifice din partea DataCash. O mostra cu astfel de numere este descrisa in cadrul Tabelului nr; lista integrala este disponibila pe siteul de Internet al DataCash.

Tabelul nr. – Testele Numerelor DataCash efectuate asupra Cartii de Credit

Trecerea de la testarea contului la proba efectiva de functionare a acestuia reprezinta in acest moment o problema facila de inlocuire a informatiilor DataCash in cadrul web.config. Din momentul in care am deschis un cont la o banca comerciala, putem utiliza aceste detalii pentru a deschide un nou cont DataCash, obtine noi date ale clientului si parola necesare pe parcurs. De asemenea, va trebui sa modificam URL-ul la care expediem datele – acesta trebuie sa corespunda serverului operativ. URL-ul necesar este https://transaction.datacash.com/Transaction. In afara faptului ca va trebui sa indepartam conturile de testare ale utilizatorului din cadrul bazei de date, acestia sunt toti pasii pe care trebuie sa ii parcurgem inaintea inaugurarii si darii in folosinta a aplicatiei noastre de comert virtual.

3.8. Utilizarea API-ului serviciului PayFlow Pro

Pentru a utiliza serviciul PayFlow Pro, suntem obligati sa ne inscrieti pe siteul de pe Internet, pe care il putem accesa de la http://www.verisign.com/products/payflow/pro/. Dupa ce am realizat inregistrarea, putem intra pe siteul de Internet VerisSign Manager ca sa descarcam API-ul si documentatia necesare utilizarii serviciului PayFlow Pro.

Unul dintre avantajele pe care PayFlow Pro le detine asupra DataCasheste reprezentat de prevederea unui API .NET, ce simplifica comunicatiile prin intermediul caii de acces la tranzactii bazate pe carti de credit. Totusi, unul dintre dezavantaje este constituit de faptul ca sintaxa de utilizarea a sa este un pic mai complexa. In locul expedierii si primirii de fisiere XML, vom trimite si primi secvente ce sunt alcatuite de binoame valorice nominale, separate prin semnul &. In mod efectiv, vom utiliza o sintaxa similara pentru a interoga secventele atasate URL-urilor.

API-ul .NET este insotit de instructiuni de instalare ale diverselor DLL-uri necesare comunicarii cu calea de acces PayFlow Pro, si include mostre de coduri de testare a functionalitatii sistemului. Aplicatia de testare VB porneste in baza urmatoarelor declaratii:

Aceste variabile sunt utilizate pentru a expedia si receptiona o secventa de autorizare a tranzactiei cu cartea de credit. Un numar de patru dintre acestea, indicate mai jos, trebuie sa fie prestabilite la valorile utilizate in momentul abonarii si inscrierii in cadrul serviciului PayFlow Pro:

Este aproape sigur ca nu vom fi obligati sa modificam urmatoarele definitii de variabile indicate in cadrul exemplului de mai jos, cu exceptia cazului in care utilizam un server proxi. Este bine sa retinem faptul ca portul 443 este utilizat pentru comunicatii, ceea ce este echivalent cu a spune ca „utilizeaza http-uri”; pe scurt, acesta conduce la folosirea conexiunii SSL.

Cea mai importanta variabila la acest moment dat este ParmList, ce include majoritatea parametrilor necesari tranzactiei, inclusiv detaliile referitoare la cartile de credit, la valoarea tranzactiei, si la tipul tranzactiei. O tranzactie de tipul S (prescurtare pentru vanzare) este utilizata, aceasta fiind o tranzactie de tipul celor Autorizate prin intermediul PayFlow Pro. In mod alternativ, putem utiliza tipurile de tranzactii A (de la autorizare) si D (de la captura intarziata) pentru a efectua o tranzactie de tipul pre/fulfil.

Ceilalti parametrii necesari sunt creati din valorile stabilite anterior in cadrul codului, iar cele doua secvente de parametrii sunt inlantuite:

Urmatorul pas, ce este urmat dupa interpretarea rezultatelor informative fundamentale, este constituit de operarea tranzactiei. Aceasta presupune dezvoltarea unui context de implementare a tranzactiei, ceea ce inseamna doar configurarea API-ului cu informatia gazdei, s.a.m.d., prelevarea raspunsului si trecerea sa prin mecanismul de interogare al tranzactiei, si distrugerea contextului:

Rezultatul se va incadra intre valorile:

Pentru a putea opera cu succes o tranzactie, va trebui sa configuram propriul cont in cadrul VerisSign Manager. De regula, majoritatea tranzactiilor de proba vor esua datorita faptului ca nu exista nici un fel de plafon al valorii tranzactionate si din cauza esecului verificarii adresei (AVS). In cazul in care stabilim un plafon adecvat si dezafectam AVS-ul, vom putea efectua cu succes tranzactiile.

Putem utiliza informatiile din cadrul documentatiei PayFlow Pro pentru a descifra acest paragraf dupa cum urmeaza:

RESULT=0: O valoare de 0, precum este cea indicata in acest caz, reprezinta o tranzactie incununata de succes. Orice alt numar va indica o eroare.

PNREF= VXYZ00912465: Un numar unic de referinta atribuit de catre VeriSign.

ERRCODE=00: Cod de eroare.

AUTHCODE=09TEST: Cod de aprobare.

AVSADDR=Y&AVSZIP=N: Informatiile de verificare a adresei.

In momentul in care utilizam tranzactiile pre/fulfil, va trebui sa utilizam valoarea PNREF in calitate de parametru ORIGID pe parcursul etapei de finalizare.

Integrarea PayFlow Pro cu JokePoint

Exact ca si in cazul DataCash, vom fi obligati sa modificam cateva elemente in cateva locuri in vederea utilizarii acestui API. In loc sa expunem codul in intregime, am putea revizui exclusiv cativa pasi a caror urmare este necesara:

adaugam setarile de configurare in cadrul web.config. In cazul PayFlow Pro, va trebui sa stabilim utilizatorul, vanzatorul, partenerul, si setarile parolei pentru verificare, cat si gazda pentru a putea trimite datele (catre test-payflow.verisign.com pentru testare);

optional, avem posibilitatea de a configura si alte informatii contextuale in cadrul acestui pas, prin coroborarea valorilor indicate in cadrul codului de testare din ultima sectiune (portul, pauza, si informatiile legate de serverul proxi);

modificam OrderProcessorConfiguration pentru a accepta aceste valori configurate;

modificam Checkout.aspx.vb si OrderDetailsAdmin.aspx.vb pentru a putea utiliza aceasta noua versiune a configuratiei;

modificam PSCheckFunds si PSTakePayment pentru a putea utiliza aceasta informatie noua in vederea comunicarii cu PayFlow Pro. Acest lucru presupune cladirea unei secvente de solicitare si interpretare a secventelor de raspuns, cat si pastrarea codurilor de autorizare in cadrul bazei de date, ca si in cazul DataCash.

Pe langa toate acestea, pentru a putea utiliza arhivele PayFlow Pro, vom fi obligati sa adaugam o referinta la CommerceLib in vedera folosirii PFProdotNET.dll (a API-ului .NET pentru PayFlow Pro), si sa copiem directorul certs in directorul C:\WINDOWS\system32 (dupa cum ne este indicat in cadrul mostrei documentatiei aplicatiei).

3.9. Primirea platilor utilizand PayPal

In timp ce solutia preferata de catre companiile consolidate este aceea de a deschide un cont comercial, multe afaceri mai mici aleg sa inceapa cu o solutie ce este mai simplu de implementat, unde nu trebuie sa proceseze ele informatiile referitoare la plati sau carti de credit.

Unele companii (ex.: 2Checkout, CCNow, PayPal etc.) si site-uri web pot ajuta persoanele sau afacerile mici care nu au resursele de a se ocupa de procesarea cartilor de credit si a tranzactiilor electronice. Aceste companii pot fi folosite la intermedierea platii dintre afacerile on-line si clientii lor. Unii lucreaza oriunde pe glob, in timp ce altii lucreaza pentru o singura tara. Multe dintre aceste companii ce proceseaza platile sunt relativ noi iar gestionarea oricarui detaliu financiar al clientului este foarte sensibila. O cautare rapida pe Internet va avea ca rezultat relatari atat de la clienti multumiti cat si nemultumiti pentru aproape toate aceste companii.

PayPal este una din cele mai cunoscute companii care asigura in prezent astfel de servicii pe care am ales-o pentru a exemplifica cateva dintre functionalitatile pe astfel de companii le asigura.

In aceast capitol vom trata urmatoarele aspecte:

1. Crearea unui nou cont PayPal.

2. Integrarea PayPal intr-o aplicatie web unde avem nevoie de un cos de cumparaturi si un mecanism verificare a clientilor.

3. Configurarea PayPal pentru a calcula automat costurile de expediere.

PayPal permite sa adaugarea unui cos de cumparaturi ce are functionalitatea de verificare a clientilor. Pentru cazul in care trebuie sa inregistram manual comenzile in baza de date, PayPal are o particularitate numita Single Item Purchases (Cumpararea unui singur produs) care poate fi folosita pentru a trimite vizitatorul direct catre o pagina de plata fara a trece prin pagina intermediara a cosului de cumparaturi.

Probabil cea mai buna descriere a acestui serviciu este cea gasita pe propriul sau site web: “PayPal este un sistem pe baza de conturi care permite oricui are o adresa de e-mail sa trimita si sa primeasca plati on-line folosind propria carte de credit sau un cont bancar”.

PayPal este una dintre companiile care permit unei afaceri mici cum ar fi magazinul nostru electronic de noutati sa primeasca plati de la clientii sai. Vizitatorul, in loc de a-i plati direct clientului, plateste catre PayPal folosind o carte de credit sau un cont bancar. Apoi clientul isi foloseste contul PayPal pentru a colecta banii primiti de la cumparatori. In momentul redactarii acestui document, nu exista nici un cost inclus in crearea unui nou cont PayPal iar serviciul este gratuit pentru cumparator. Se percep taxe doar cand se primesc banii.

Pentru a primi plati pe cartea de credit, trebuie sa deschidem un cont Business pe situl companiei. Dupa ce contul PayPal este configurat, adresa de e-mail pe care am furnizat-o in formularul de inscriere va fi ID-ul contului PayPal. Serviciul PayPal ofera o mare functionalitate – deoarece site-ul este usor de folosit si multe functii sunt foarte explicite. Pentru a accepta plati, trebuie sa adaugam doua elemente importante la partea de interfata a utilizatorilor site-ului: butoanele Pune in cos pentru fiecare produs si un buton Continut cos undeva in pagina. PayPal face ca adaugarea acestor butoane sa fie extrem de facila.

Functionalitatea acestor butoane este indeplinita de catre link-uri securizate catre site-ul web PayPal. De exemplu, urmatorul element reprezinta butonul Pune in cos pentru un produs numit „Mouse optic” ce costa 3,99 USD:

Butonul Pune in cos poate fi generat folosind o structura similara. In site-ul nostru web, deoarece ASP.NET functioneaza implicit folosind un element principal (iar elementele nu pot fi despartite), alegem sa generam butoanele folosind link-uri precum:

După adăugarea butoanelor Add to Cart și View Cart, site-ul web va arăta ca în Figura 7-1.

Insert 2549f0701.tif

Figura 7-1. Adăugarea butoanelor Add to Cart (Pune în coș).

Campurile sunt predefinite iar numele lor sunt foarte explicite. Cel mai important este business, care trebuie sa fie adresa de e-mail pe care am folosit-o atunci cand am inregistrat contul PayPal (adresa de e-mail care va primi banii). Trebuie urmarit ca acest cod HTML sa fie atasat fiecarui produs, astfel ca vom avea butoane Pune in cos pentru fiecare produs. Apoi adaugam butonul Continut cos undeva in pagina, astfel incat va fi accesibil oricand pentru vizitator.Desi nu le vom folosi pentru exemplul nostru, este bine de stiut ca PayPal asigura generatoare de buton care bazate pe anumite date furnizate de noi (numele produsului, pretul produsului), ofera o grupare HTML similara aceleia prezentate anterior.

Figura 7-3 arată coșul de cumpărături PayPal în acțiune.

Insert 2549f0703.tif

Figura 7-3. Coșul de cumpărături PayPal

Dupa ce un client face o plata pe site-ul web, este trimisa o notificare e-mail catre adresa inregistrata la PayPal si de asemenea catre client. Contul nostru PayPal va reflecta plata, putem vedea informatiile privitoare la tranzactie in istoricul contului nostru sau ca parte a registrului istoric al tranzactiei. Dupa ce PayPal confirma efectuarea platii, putem expedia produsele catre clientul nostru. La fiecare plata, trebuie sa verificam cu atentie daca preturile produselor corespund sumelor corecte, deoarece este foarte usor ca cineva sa adauge un produs fals in cosul de cumparaturi, sau un produs existent cu un pret modificat. Acest lucru poate fi realizat prin crearea unuia dintre acele link-uri PayPal folosite pentru butonul Pune in cos si navigarea catre el.

Folosind caracteristica PayPal Single Item Purchases (Cumpaturi de cate un singur articol) este o caracteristica PayPal care permite sa trimitem vizitatorul direct catre o pagina de plata in loc de cosul de cumparaturi PayPal. Pentru gestionarea comenzilor clientilor, vom implementa butonul Faceti comanda in cosul de cumparaturi, care salveaza comanda in baza de date si redirectioneaza clientul catre o pagina de plata a PayPal. Pentru a apela pagina de plata PayPal (ocolind cosul de cumparaturi PayPal), rediretionam catre un link cum ar fi urmatorul:

Trebuie sa avem grija sa inlocuim adresa_noastra de email cu adresa de e-mail inregistrata la PayPal, iar http://www.SitulNostruWeb.ro cu adresa magazinului dumneavoastra electronic. Parametrii return si cancel_return specifica paginile web la care sa se intoarca dupa efectuarea sau anularea platii.

Figura 7.4 prezintă ecranul PayPal Single Item Purchase.

Insert 2549f0704.tif

Figura 7-4. Ecranul PayPal Single Item Purchase

3.10. Concluzii

In mod specific, in cadrul acestui capitol, am analizat teoria aflata in spatele tranzactiilor efectuate cu carti de credit si am analizat una dintre implementarile integrale ale sistemului – DataCash. Am creat o arhiva ce poate fi utilizata pentru a accesa DataCash si am integrat-o propriei aplicatii. De asemenea, ne-am aruncat privirea asupra sistemului PayFlow Pro.

In penultima sectiune am aratat cum putem integra PayPal intr-un site de comert electronic – o soluție simplă de plata pe care o aleg multe afaceri mici pentru a nu trebui să proceseze ele informațiile privitoare la carți de credit sau modalități de plata.

Am acoperit modul de integrare PayPal, discutand mai intai despre un cos de cumparaturi, un mecanism de verificare a clientului, si apoi despre modul de a redirectiona vizitatorul direct catre pagina de plata.

Bibliografie

Cristian Darie and Karli Watson : „Beginning ASP.NET 1.1 e-commerce”

Simon Robinson : „Profesional C#” – Wrox Press

Kevin Hoffman : „ASP.NET E-Commerce , Programming” – Wrox Press

www.pcmagazine.ro

www.chip.ro