138

Capitolul 5. Particularizari

S TUDIU DE CAZ N DEZVOLTAREA BAZATA PE COMPONENTE, PENTRU COMERT ELECTR ONIC

Pentru o prezentare a modului n care se poate desfasura comertul electronic , precum si a

modului n care se poate dezvolta o companie bazata pe acesta se ia n considerare compania ComponentSource (www.componentsource.com ) caracterizata prin:

? Cea mai mare distribuitoare de componente software ? 5% din venit preluat prin Internet ? Pagina Web pentru FT al proceselor economice ale anului ? Catalog cu peste 2000 de componente ? Comert n peste 60 de tari si 6 valute

Serviciile on line oferite: ? Catalogul componentelor software ? Cumpararea si descarcarea de componente ? Arhive de componente ? Datele pentru vnzare relative la autorii de componente ? Abonarea componentelor ? Integrarea instrumentelor ? Managementul conturilor corporatiei (corporate account) ? Centrul de actualizare al componentelor

Arhitectura paginii: ? DNA Microsoft ? DCOM (Distributed COM) ? Server SQL ? Privirea din interior a documentelor XML Componentele software ncapsuleaza expresia cunostintelor si experienta ca o functionalitate

precompilata. Una din caracteristicile care trebuie luate n considerare se refera la: maximum de reutilizari = minim de cost. Acesta va conduce la:

? Preturi mai mici ? Rapiditate de implementat ? Reducerea riscurilor ? Necesitati putine pentru dezvoltare ? Focalizare tare pe competentele de baza

Maximizarea reutilizarii va determina: ? Puritatea functionala ? Independenta fata de mediu ? Independenta fata de implementare ? Persistenta

Problemele care apar cu obiectele traditionale : ? Trierea proprietatilor la distanta este costisitoare ? Componentele tranzactionale trebuie sa fie fara stare ? Fiecare dintre functii trebuie sa fie valida n orice locatie ? Divizarea componentelor n servicii si entitati

Componentele serviciu : ? Cunoscute si sub denumirea de componente ale procesului economic ? Definesc functionalitatea componentei prin metode ? Fara stare nu are proprietati ? Trecerea informatiei prin par ametrii metodei ? Poate fi tranzactionala ? Este utilizata n etajul median

139

Componentele entitate: ? Definesc structura de date a componentei ? Cu stare are proprietati ? Nu are functionalitate ? Poate fi ierarhica ? Valida n orice locatie ? Este capabila de serializare si deserializare

Figura 5.1. Arhitectura componentei pentru componente distribuite Siruri:

? Reprezinta documente ? Formeaza contacte ntre componentele serviciu si clientii acestora ? Pot fi format XML sau format propriu ? Componentele entitate asigura faptul ca s-a ndeplinit contractul

Procesare tranzactiilor prin documente: ? Comenzi de vnzari ? nregistrarea consumatorului ? Tabelele de taxe ? Profilul produsului

Beneficiul bazelor de date relationale ? Stocarea eficienta ? Regasirea rapida ? Duplicare minima ? Realizarea de rapoarte usor

Inconvenientele bazelor de date relationale ? Structuri de date normalizate ? Implementare specifica ? Insecuritatea puritatii componentelor ? Lipsa reutilizarii Dezvoltarea bazata pe componente ridica sever problema reutilizarii functionalitatii. Pe de alta

parte, bazele de date relationale sunt orientate pe reutilizarea datelor. ComponentSource a stabilit o paradigma pentru schimbul de date ale componentelor pentru a maximiza izolarea acestora.

Arhitectura persistentei documentelor Izolarea componentelor din baza de date ? Componentele serviciului comunica prin documente XML ? Serverul de documente livreaza si pastreaza toate documentele

Formul HTML Scripta ASP Serviciul consumator

Entitatea consumatoare

Entitatea consumatoare

Client Serverul Web Serverul proceselor

variabile

Sir de documente

140

? Adaptorii furnizeaza tipuri de documente specifice

Figura 5.2. Arhitectura persistentei documentelor

Serverul de documente :

? Anvelopa nesemnificativa ? Selectarea adaptorului document convenabil ? Trece XML ntre componenta serviciu si adaptor

Adaptoarele de documente: ? Cte unul pentru fiecare tip de document ? Accesarea oricarei date

? RDMS ? Componenta serviciu ? Internet ? ncarcarea sistemelor existente

? Popularea entitatilor din surse externe ? Functii ca liant de componente ? Mascarea detaliilor de implementare

Figura 5.3.

Componenta serviciu

Serverul de documente

Adaptorul de documente

Componenta entitate

Componenta entitate

RDMS

variabile

Sir de documente XML

Componenta serviciu

Serverul de documente

Adaptorul de

Componenta entitate Componenta

entitate

RDMS variabile

Sir de documente

Scripta ASP

Componenta entitate

141

n rezumat se poate conchide ca propunerile ComponentSource se refera la arhitectura documentelor XML, a faptului ca, n acest studiu de caz componentele economice contin functionalitatea ideala si sunt capabile de reutilizarea n piata libera.

PROTOCOLUL FIX Ce este acest protocol:

? FIX este un protocol de retea cu o orientare severa pe tranzactiile vnzarii cu ridicata. ? FIX a fost creat nainte ca toate companiile sa fie interconectate prin Internet si retele private. ? Fix a fost creat cu doua obiective fundamentale:

? Fiabilitate si reducerea timpului de comunicare ? Flexibilitatea contextului proceselor economice

Pe de alta parte FIX este un protocol la nivelul sesiune, independent de nivelul transport, care

garanteaza livrarea n timp real, fiabila, a datelor ntre doua puncte direct conectate. De altfel, FIX reprezinta o multime de formate de mesaje economice, flexibile si extensibile. Masina FIX este simplu, o piesa software. Aceasta ntretine conectarea n retea, creeaza si analizeaza sintactic mesajele si le restabileste, n forma necesara, daca ceva merge rau.

Figura 5.4.

? n acest sens numarul de cmpuri a fost dublat fata de versiunea 4.1 ? Numarul de pagini a crescut mai mult dect dublu ? S-a dublat de asemenea numarul anexelor ? S-au constituit 18 mesaje economice noi

Elementele suplimentare introduse: ? Anvelope XML pentru a nveli datele FIXML ? Transformari, derivate, optiuni, legari ? Sustinerea schimburilor piata de date, stari ? Comertul japonez

FIXML apare ca o cale mai structurata pentru formatarea mesajelor economice ale FIX . Prin FIXML, comitetul FIX a confirmat public necesitatea a lua n considerare separat nivelele

aplicatie si sesiune ale FIX. n acest sens : ? FIX poate transporta mesaje de orice format ? Mesajele aplicatie pot fi livrate pe o cale diferita de sesiunea FIX

Interfata cu

aplicatia

Interfata cu

reteaua

Analiza sintactica a mesajelor

Receptie mesaje

Crearea

mesajelor

Emitere mesaje

Definirea mesajelor

142

Aceasta apare si ca o posibilitate facila de migrare din FIX: vechea valoarea etichetei formatului poate fi utilizata ca o anvelopa pentru un mesaj FIXML (sunt date astfel, noi cmpuri n 4.2)

Definitia tipului documentului (DTD) descrie conditiile necesare pentru un document bine format n sensul XML: ? Elementele cerute si cele optionale ? Structura si gruparea documentelor ? Atributele asociate documentelor (de exemplu documentele HTML sunt conforme cu un DTD)

Un parser de validare (cum ar fi un browser web) poate utiliza un DTD pentru a verifica un document XML pentru a verifica corecta constructie a acestuia.

XML introduce o structura n mesajul aplicatie. Pentru lucruri cum ar fi grupuri care se repeta ale cmpurilor relationale, acest fapt devine foarte important.

Luate lucrurile strict, un parser XML poate valida ca un mesaj FIX este conform cu un DTD n termeni de structura si numai n acest tip de termeni. XML nu ntelege tipurile de date.

XML nu poate aduce un sprijin semnificativ n validarea datelor n cadrul documentului XML priveste totul ca pe un sir. Schema initiativelor, n acest sens si propune realizarea validarii continutului prin definirea tipului de date. Pentru acesta sunt utilizate limbaje de definire a tipului de date (fara a o optiune speciala, dar una trebuie sa predomine)

- X ML Data (Microsoft) - DDML (Data Definition ML) - DCDs (Document Content Definitions) - SOX (Schema for Object-oriented XML)

Masinile FIX si Bibliotecile FIX

? Multe dintre masinile FIX apar, n realitate ca fiind biblioteci FIX ? Masinile FIX sunt aplicatii separate care furnizeaza o interfata aplicatiilor interne ? Bibliotecile FIX necesita ca fiecare att ca interfata, ct si aplicatia sa fie construite n jurul lor.

Acestea nu sunt aplicatii izolate, ele nsele.

Mai multi furnizori ofera versiunile HA pentru serverele proprii. Acestea sunt construite n linii mari similar:

- la receptia sau trimiterea mesajelor acestea sunt scrise ntr-o memorie persistenta comuna si de asemenea propagate prin conectori (stari consistente)

- redundanta pentru masinile FIX si nivelele software garanteaza ca acestea sunt totdeauna o intrare pentru sistemele FIX.

Figura 5.5. Una dintre problemele care trebuie analizate se refera la decizia relativa la constructie sau la

achizitie. Pentru plusurile care sunt de luat n considerare n sensul deciziei de achizitie ar fi: - se realizeaza un cstig de timp si costuri - furnizorul este responsabil pentru sustinere, crestere si actualizare

Partile negative se pot sintetiza n: - un control mic sau deloc a codului sursa sau a accesului la acesta - clientul devine dependent de furnizor

Conector FIX (fara stare)

Conector FIX (fara stare)

Stare partajata* *Poate sa nu fie persistenta

Manevrarea mesajelor

143

De altfel din ce n ce mai multi furnizori si fac disponibil codul sursa ceea ce reduce, pe de o

parte costul si timpul aferent dezvoltarii, iar pe de alta parte clientul trebuie sa nvete si sa sustina pe altcineva relativ la cod.

N LOC DE CONCLUZIE Serviciul Web va deveni, eventual mecanismul predominant prin care resursele de date si

aplicatii vor fi furnizate si consumate. n fazele de nceput ale utilizarii Serviciului se vor gestiona, ca anexe ale sistemelor conventionale de livrare a proceselor (cum ar fi proiectarea proceselor, dezvoltarea aplicatiilor, configurare si expunere etc.) Cu toate acestea, faptul ca Serviciul devine mecanismul principal pentru comunicarea intercompanii, acesta va fi esential pentru o aliniere a proceselor participante.

Un proces WS se poate defini ca:

1. Deoarece Serviciul apare mai n centrul arhitecturilor economice si TI, este esential un proces holistic care sa gestioneze ciclul de viata al Serviciului. Managementul specificatiilor, livrarilor, achizitiilor si consumului de componente trebuie sa fie coordonate din perspectiva ciclului de viata al serviciului.

2. Serviciile vor fi furnizate si consumate pe nivele din ce n ce mai de interior ale proceselor economice. Pentru a facilita aceasta, anumite aspecte ale proceselor livrarii Serviciului, implementate n fiecare dintre organizatiile participante trebuie sa fie comune pentru a asigura o productivitate rezonabila si a asigura livrarea nivelelor cerute de ncredere si securitate.

3. Serviciile vor fi proiectate din ce n ce mai intens pe colaborarea de participanti multipli, care vor creste expunerea standardizarea industriei pe verticala a Serviciului economic si a Serviciului bazat pe procesele economice. O ntelegere mutuala a procesulu i de livrare a Serviciului este esentiala pentru asigurarea colaborarii.

4. Odata cu cresterea colaborarii ntre entitatile economice fundamental separate, se impune o cresterea a formalismului specificarii serviciilor, a contractelor etc. Realizarea acestor deziderate vor conduce va conduce la formalizari ale procesului de livrare a Serviciului si ntelegerea mutuala a entitatilor livrate.

5. Odata cu furnizarea Serviciului catre organizatiile externe, deseori pe baze comerciale, o mare atentie se va acorda gestiunii riscului si a calitatii serviciului. Procesul de livrare a Serviciului trebuie sa tina cont de aceasta pe ntregul ciclu de viata, de exemplu ca parte a strategiei si proiectarii Serviciului, nu numai ca o fateta a operatiilor

Domeniul Procesului WS va include urmatoarele entitati: - definirea procesului (proceselor) de livrare a Serviciului, generic; - relatiile definite cu (si reutilizarea a) proceselor deja utilizate pe scara mare, incluznd

BPM (Business Process Design and Management); SOA, Application Development, Application Management, etc.;

- definirea proceselor comerciale, generice; - identificarea entitatilor livrabile; - clarificarea rolului organizational cum ar fi: furnizor, consumator /solicitant, intermediar. - clarificarea responsabilitatilor :

- specificarea serviciilor - arhitectura contractului - publicarea Serviciului - managerul serviciului

- definirea publicarii bunelor practici; - ghidul gestiunii contractului Serviciului procesului economic ; - ghidul gestiunii contractului Serviciului operational; - sabloane de ncredere si ghidul aplicatiilor; - dezvoltarea de bune practici ale Serviciului; - sabloane de integrare a Serviciului si ghidul aplicatiilor; - bune practici si ghiduri pentru monitorizarea Serviciului;

144

- bunele practici n manevrarea exceptiilor, erorilor si a esecurilor; - bunele practici pentru diagnosticare; - bunele practici pentru testare si asigurarea calitatii; - ghidul pentru realizarea de acorduri semantice; - bune practici si ghiduri pentru acorduri la nivel Serviciu; - managementul schimbarii si a versiunii; - sabloane pentru proiectarea proceselor economice pentru schimbul ntre companii;

Se propune stabilirea unui proiect pentru a dezvolta un cadrul de proces care furnizeaza parti

ale Serviciului cu un cadru comun de referinte care optimizeaza aprovizionarea si consumarea Serviciului inter companii. Nu se asteapta de la acest proiect sa livreze un proces unificat sau o tehnica specifica. Mai de graba este vorba despre o perspectiva comuna care faciliteaza interoperabilitatea.