* OPTUS *
Operator Turism
Rezumat
Programul OPTUS reprezinta un program ce furnizeaza utlizatorilor sai informatii despre locurile de cazare din diferite hoteluri ale unor diverse statiuni. Aceste informatii sunt preluate la randul lor de la diferite agentii de turism. Agentiile isi pun la dispozitia publicului datele care vor fi preluate de cate un server central, vor fi centralizate, interpretate si apoi furnizate solicitantului.
OPTUS este un sistem distribuit care va consta dintr-un Server central - Server Manager – numit in terminologia OPTUS SM_Server. Acest server va rula in stransa legatura cu niste servere secundare distribuite la agentiile care furnizeaza date. Aceste servere vor purta denumirea de SS_Server-e. Prin urmare utilizatorul va cere informatiile necesare SM_Server-ului. Acesta nu va avea acces direct la datele solicitate, deoarece aceste date sunt furnizate de ficare agentie de turism in parte. Dar fiecare agentie care doreste sa-si faca publice datele prin intermediul sistemului OPTUS va rula local un SS_Server care va comunica cu SM_Serverul.
Dupa cum se poate observa din cele amintite anterior pentru ca sistemul sa poata functiona in parametrii normali este necesar ca serverul central SM_Server sa aiba in orice moment o situatie reala in ce priveste agentiile care furnizeaza date. Cu alte cuvinte fiecare agentie trebuie sa ruleze un SS_Server care in prealabil trebuie sa se inregistreze la manager. In realitate fiecare SS_Server se va inregistra la un server independent de SM_Server. Acest server numit Register_Server va fi o aplicatie independenta ce va rula in permanenta “ascultand” pentru noi cereri din partea unor SS_Servere. In urma unor astfel de cereri Register_Serverul va inregistra respectivul solicitant intr-o tabela care ulterior va fi accesibila SM_Serverului.
Cuprins
Proiect Sisteme Distribuite. 1
Functionalitatea Register Server 6
Implementare Register_Server 9
Introducere
Operatorul de turism OPTUS reprezinta un forte bun exemplu de utilizare al programarii distribuite.
Scopul aplicatiei este: preluarea de informatii de la mai multe agentii de turism, prelucrarea lor intr-un format accesibil si furnizarea acestori informatii utilizatorilor.
Orice agentie care doreste sa-si faca publice datele prin intermediul sistemului distribuit OPTUS va trebui sa ruleze o aplicatie speciala care va comunica cu un server central care va fi cel ce furnizeaza in realitate datele utilizatorului. Orice astfel de agentie de turism va trebui in primul rand sa se inregistreze intr-o baza de date.
Utilizatorul prin intermediul unei pagini de Web va putea vedea agentiile ce isi ofera servicii si selectand una sau toate agentiile precum si diferite aspecte ce il intrereseaza (pret, servicii oferite, categorie) va efectua interogari asupra datelor existente. Serverul central va trimite cererile agentiilor respective. Acestea raspund solicitarii serverului trimitand datele care vor fi prelucrate si furnizate utilizatorului ca pagina Web.
Analiza si Proiectare
Analiza efectuata asupra acestei aplicatii trebuie sa inceapa de la scopul aplicatiei. Schitat in cateva cuvinte scopul aplicatiei este : furnizarea de informatii actuale provenite de la cat mai multe agentii de turism unui utilizator care va apela la un moment dat la serviciile sistemului. Acesta este in cateva cuvinte sistemul distribuit OPTUS.
Asadar, cele afirmate anterior ne duc la o concluzie cat se poate de clara. Un utilizator va accesa dintr-un singur loc, datele furnizate de oricate agentii, date ce intai de toate vor trebui centralizate. Aceasta implica existenta unui manager central de informatii. Acest manager poarta numele in terminologia OPTUS de SM_Server. Rolul SM_Serverului este de a accepta cereri de la un utilizator, cereri facute sub un anumit format. In acest sens este necesara punerea la dispozitia utilizatorilor a unei interfete standard prin intermediul careia se vor face cererile.
Pentru a efectua o cerere utilizatorului va trebui sa i se puna la dispozitie o interfata intuitiva in care acesta va putea alege criterii dupa care sa aiba loc cautarea. Cele mai frecvente criterii dupa care un client alege o oferta hoteliera au fost si cele utilizate in interfata oferita de sistemul OPTUS. Astfel utilizatorul va putea alege dupa criterii de genul : numar de camere, pret, categoria hotelului. Pe langa aceste atribute ale cautarii utilizatorul ar trebui sa poata selecta si daca vrea sa caute informatiile doar in baza de date a unei agentii sau in bazele de date ale toate agentiilor. Astfel in orice moment Serverul Manager va trebui sa aiba o statistica reala cu Serverele Secundare care sunt on-line. Desi la prima vedere aceasta pare o problema simpla in relitate ea este mult mai sensibila dupa cum se va vedea in analiza ce urmeaza.
Intrarea in sistemul OPTUS a oricarui SS_Server apartinand unei agentii este una deschisa. Adica orice server care cunoaste protocolul OPTUS de comunicare poate deveni furnizor de date in sistem. Asadar in orice moment o agentie poate lansa in sistem un server care sa transmita date. Pentru a fi recunoscut insa de catre Server Manager el trebuie sa-si semnaleze cumva prezenta, mai corect spus sa-si “inregistreze” intrarea in sistem.
In implementarea sistemului s-a ales ca responsabil de aceasta inregistrare sa fie un daemon, un program care ruleaza in fundal pe masina SM_Serverului. Acest program va gestiona o tabela care in care vor fi inregistrate serverele SS_Server active. Programul poarta denumirea de Register_Server. El va asculta pe un port pe care va astepta conexiuni de la SS_Servere.
Fig.1 – Schema functionala a sistemului OPTUS
Functionalitatea Register Server
In momentul in care un SS_Server va dori se sa inregistreze in sistem el va trimite pe acest port date intr-un format special. Aceste date vor contine si identificatori speciali prin care Register_Serverul va recunoaste ca este vorba de un SS_Server, dar totodata cel care va lansa in executie SS_Serverul va trebui sa se ocupe de veridicitatea informatiilor transmise. Pe langa semnatrura specifica fiecare SS_Server va trimite informatii despre propria adresa, despre portul pe care opereaza precum si un nume cu care va fi identificat si prezentat clientilor. Acest nume trebuie sa fie unic intre toate agentiile de aceasta trebuind sa se ocupe tot cel care initiaza conexiunea intre SS_Server si Register_Server.
La lansarea in executie a Register_Serverului pot exista doua situatii total diferite. O situatie este de exemplu dupa o oprire intenntionata a sistemului datorata unei up-gradari sau a unei caderi de sistem. In acest caz este foarte probabil ca agentiile inregistrate sa se doreasca sa ramana inregistrate. Daca insa are loc o schimbare la un nivel mult mai mare , de exemplu se schimba protocolul de inregistrare sau pur si simplu se doreste initializarea respectiv reinitializarea sistemului, atunci este posibila lansarea Register_Serverului cu un parametru in linia de comanda ce va curata tabelele de toate informatiile despre oricare dintre agentiile inregistrate anterior. In acest caz pentru a reintra in sistemul OPTUS agentiile vor trebui notificate printr-o oarecare metoda deoarece este necesara o noua inregistrare in Baza de date probabil folosind noi versiuni de SS_Server.
Fig. 2 - Cazuri de utilizare asupra Register Serverului.
Dupa cum se poate observa este foarte bine determinat momentul in care un SS_Server al unei agentii intra in sistemul OPTUS. Dar cand va fi scos din sistem un asemenea server? Raspunsul la aceasta intrebare in varianta OPTUS este: Tinand cont ca tot ceea ce trebuie sa faca o agentie pentru a nu mai pune la dispozitia sistemului OPTUS propriile date este sa opreasca SS_Serverul care ruleaza local, stergerea propriuzisa din baza de date se va realiza manual pe partea Register_Serverului sau intr-u cat nu este o prioritate, inregistrarea poate ramane in tabela pana la prima reinitializare, astfel avand si o situatie cu toate agentiile inregistrate la un momenta dat, active sau nu.
La un moment dat in dezvoltarea aplicatiei a existat teoria de a mentine tabela cu SS_Serverele in actualitate prin mai multe metode care sa asigure utilizatorul ca nu va vedea ao agentie ca activa in timp ce aceasta nu furnizeaza de fapt informatii. Acesata conditie ar fi putut realizata de exemplu prin existenta unui semnal ce se trimite periodic intre Register_Server si SS_Server. Dar aceasta insemna o incarca a retelei . De asemneea o cadere temporara de retea poate fi interpretata ca o iesire voita din sistem. Acesta plus complicarea SS_Serverului au dus la solutia amintita anterior.
Functionalitatea SS_Server
In viata fiecarui SS_Server se disting doua etape esentiale. Prima etapa o reprezinta inregistrarea in sistemul OPTUS. Aceasta inregistrare presupune transmiterea propriilor informatii Register_Serverului, informatii unice in sistemul OPTUS. Pentru a realiza aceasta orice SS_Server va trbui sa stie adresa Register_Serverului si respectiv portul pe care acesta asculta. Portul fiind unul static, doar adresa va trebui data din linia de comanda. Tot ca argumente in linia de comanda vor trebui transmise SS_Serverului si portul, pe care acesta ca asculta pentru cereri de la SM_Server, precum si numele Agentiei de partea careia va functiona respectivul SS_Server.
O data inregistrat SS_Serverul trece in etapa a doua a vietii sale: accea in care va astepta cereri de la SM_Server. Dupa ce este inregistrat in sistem un SS_Server este pasibil de a primi cereri de date de la Server Manager. In aceasta etapa SS_Serverul devine un thread numit SSDaemon. Aceste cereri vor fi trimise pe portul specificat la inregistrare, responsabilitatea pentru corectitudinea datalor de inregistrare revine in totalitate celui care a a lansat in executie SS_Serverul. Cererile sosite din partrea SM_Serverului nu sunt altceva decat niste interogari SQL. Servrele Secundare nu au altceva de facut decat eventual sa specializeze aceste interogari. Apoi aceste interogari sunt aplicate asupra bazelor de date care in mod evident vor trebui sa aiba formate standard sau cel putin sa suporte interogarile sosite din partea SM_Serverului. O data efectuate aceste interogari se vor obtine niste date care vor fi mai apoi transmise ca raspuns SM_Serverului. Dupa acest pas SS_Serverul va intra din nou in asteptare asteptand alte cereri. De retinut ca fiecare SS_Server va accepta mai multe cereri simultan, pentru fiecare cerere lansandu-se un thread separat. Un astfel de thread poarta denumirea
Fig. 3 – Cazurile de utilizare ale unui SS_Server.
Functionaltitatea SM_Server
Principala componenta a sistemului OPTUS o reprezinta Server Managerul sau SM_Serverul. Rolul SM_Serverului este de a primi cereri de la utilizatori, de a procesa aceste cereri care apoi sunt convertite intr-un format inteligibil OPTUS si transmise mai departe SS_Serverelor de la care se solicita informatii de catre utilizator. Raspunsurile primite apoi de la SS_Servere sunt interpretate si apoi trimise utilizatorului intr-un format human-readable, mai exact html. Iata mai exact care sunt pasii pe care ii efectueaza un Server Manager.
Intai de toate trebuioe reamintit ca in interfata oferita de catre SM_Server utilizatorului in vederea efectuarii de interogari se vor afisa si toate agentiile inregistrate la momentul respectiv in cadrul sistemului OPTUS.
Astfel, un utilizator pe langa atribute specifice unei cautari intr-o agentie hoteliera, de genul: pret, categorie, etc, poate selecta si agentia asupra careia sa fie efectuata interogarea. O alta optiune este accea de a efectua interogarea asupra tuturor agentiilor inregistrate la un moment dat.
Sa presupunem ca utilizatorul va selecta sa efectueze interogari asupra tuturor agentiilor si ca in sistem sunt inregistrate 3 agentii, adica de partea a trei agentii va rula cate un SS_Server. SM_Serverul interpreteaza cerinta utilizatorului si va lansa in executie 3 threaduri cate unul pentru fiecare SS_Server. Un astfel de thread poarta denumirea de SMDaemon. Aceste threaduri fiecare in parte se va ocupa de ducerea la bun sfarsit a interogarii. Dupa cum am amintit si la punctul anterior cererile sunt trimise de la SM_Server la SS_Server sub forma unor interogari SQL. Astfel, dupa ce fiecare thread a fost lansat in executie specificandu-i-se SS_Serverul/agentia cu care va comunica, precum si adresa agesteia si portul, va trimite interogarea SQL dupa care va astepta raspunsul de la SS_Server. Raspunsul va sosi sub forma unui fisier XML. Acest fisier va fi scris de SMDaemon pe disc dupa care threadul isi va inceta viata. O data terminate toate threadurile, controlul va fi preluat de SM_Server. In cazul in care nu a reusit comunicarea cu niciuna dintre agentii, datorita unor erori in retea sau datorita faptului ca serverele secundare erau oprite se va afisa un mesaj utilizatorului cu explicarea problemei. In cazul in care cel putin una din agentii raspunde se va trece la pasul urmator.
Avand raspunsurileprimite de fiecare SMDaemon sub forma unor fiesiere XML tot ce mai trebuie sa faca SM_Serverul este sa concateneze aceste rezultate intr-un XML rezultat, care mai apoi va fi convertit in format HTML. Acest fisier va fi trimis utilizatorului. Iata in continuare schema detaliata de interactiune a elementelor SM_Serverului.
Fig. 4 – Schema detaliata a elemetelor SM_Serverului.
Implementare
In prima parte a acestui capitol se vor prezenta in mare aspectele de implementare ale sistemului OPTUS pentru ca mai apoi sa se treaca la prezentarea amanuntita a implementarii fiecarei componente in parte.
Interactiunea intre utilizator si sitem se va realiza prin intermediul unor pagini html si jsp. Alegerea de a folosi jsp s-a dovedit ideala in cazul acestei aplicatii, dupa cum se va putea vedea si in cele ce urmeaza. Din aceste pagini JSP se va controla un Java Bean care de fapt va reprezenta “sufletul” SM_Serverului. Partea de interactiune cu utilizatorului consta din doua pagini: una in care se realizeaza interogarea si una in care se vor afisa rezultatele.
Acestea fiind spuse si pentru a asigura o continuitate in elementele prezentarii, voi incepe descrierea implementarii cu Register_Serverul.
Implementare Register_Server
Dupa cum am amintit si in capitolul anterior, rolul acestui program de sine statator este de a asigura inregistrarea SS_Serverlor, ce ruleaza la nivelul fiecarei agentii de turism, in baza de date ce se ocupa cu aceasta gestiune. Iata in continuare diagrama de clase pentru Register_Server.
Implementarea Register_Serverului este una destul de simpla si intuitiva. Astfel din cadrul clasei de baza se va lansa un Thread separat care va rula asteptand conexiuni de la servere secundare. Acest thread va fi astfel un Daemon, denumit in terminologia OPTUS RegDaemon. In partea de initializare a daemonului, respectiv in constructor, are loc initializarea ServerSocketului pe care se va “asculta”, initializarea debuggerului, urmand ca apoi threadul sa treaca in starea run. In aceasta stare ServerSocketul va accepta conexiuni de la SS_Servere. De indata ce este primita o astfel de conexiune, se va citi un string transmis de catre SS_Server pe socket.
Fig. 1 – Diagrama de clase pentru Register_Server.
Acest string este parsat in cadrul metodei tokenizeInput. In cazul in care apare o eroare la parsare se anuleaza conexiunea dupa ce in prealabil SS_Serverul a fost anuntat de tipul de eroare aparuta. In caz contrar, inseamna ca informatiile sosite sunt valide, prin urmare agentia corespunzatoare va fi adaugata in BD daca nu exista, in cazul in care exista, informatiile sale fiind actualizate.
Atat la pornirea serverului daca se doreste “resetarea” bazei de date, cat si in momentul in care se inregistreaza un nou SS_Server este necesar lucrul cu baza de date asociata acestui scop. Lucrul cu baza de date va fi efectuat in intregime in cadrul clasei SQLSolver. Aceasta clasa contine o metoda prin care se va efectua orice interogare transmisa din exterior ca un String, precum si o metoda care va curata tabela “ss_servers”.
Fig .2 – Diagrama de activitate a Register_Server-ului.
Implementare SS_Server
Modul in care este structurat un SS_Server este foarte intuitiv in ce priveste “etapele” din “viata” acestui tip de server.
Clasa de baza, cea care contine metoda main este SS_Server. La lansarea aplicatiei se vor transmite din linia de comanda adresa Register_Serverului la care se va inregistra, portul pe care va asculta, precum si numele sub care va figura in sistemul OPTUS, unicitatea acestui nume fiind esentiala.
Fig. 3 – Digrama de stare a SS_Server
O data lansat in executie serverul, prima etapa prin care va trece va fi accea de inregistrare efectuata de metoda registerMeself. In functie de rezultatul acestei operatii se va trece sau nu in urmatoarea etapa, accea de “ascultare” de interogari din partea SM_Serverului. La fel ca in cazul Register_Serverului in momentul in care se trece in faza de “ascultare”, sarcinile vor fi preluate de un thread-daemon implementat in cadrul clasei SSDaemon.
De fapt in cadrul acestui daemon se va efectua doar initializarea SocketServer-ului si a debuggerului, dupa care in cadrul metodei run se va trece in starea de accept. In momentul in care este primita o conexiune, un nou thread va fi lansat in executie pentru fiecare astfel de conexiune. Acest thread este implementat in cadrul clasei SSThread, aceasta clasa reprezentand de fapt “inima” SS_Server- ului. In corpul SSThread – ului se va citi de pe socket interogarea trimisa de catre SM_Server.
Fig. 4 – Digrama de clase a SS_Server
Daca este necesar interogarea va fi specializata dupa care la fel ca in cazul Register_Server se vor folosi facilitatile oferite de un obiect de tip SQLSolver pentru efectuarea interogarii si obtinerea rezultatelor. Rezultatele obtinute de la obiectuld de tip SQLSolver vor fi stocate in fisiere XML continutul carora va fi trimis mai apoi pe socket la SM_Server.
In cazul acestui tip de server functionalitatea clasei SQLSolver este mult mai complexa decat in cazul Register_Serverului. Astfel ca metoda doQuery nu se va limita doar la a efectua o interogare SQL. In corpul ei se vor apela si trei metode care au ca finalitate stocarea rezulatelor interogarii intr-un fisier XML. Pentru inceput metoda determineFields se va ocupa de determinarea nodurilor fisierului XML, mai exact a campurilor din ResultSet-ul obtinut dupa interogare. Am recurs la stabilirea dinamica a acestor campuri pentru a permite o mai usoara modificare ulterioara a structurii tabelelor folosite. O data determinate aceste campuri metoda writeDTD va scrie DTD-ul in fisierul XML, pentru ca mai apoi metoda dispResultSet sa realizeze transprotarea propriu-zisa a datelor obtinute din interogare in fisierul XML.
Implementare SM_Server
Server Managerul sau SM_Server-ul reprezinta principala aplicatie in cadrul sistemului OPTUS, fiind principalul intermediar intre utilizator si furnizorii de servicii. Iata in continuare structura de clase a SM_Server-ului.
Dupa cum am spus interfata intre sistem si utilizator este realizata prin intermediul de pagini JSP. Cererile facute de utilizator sunt transmise din pagina de jsp unui Java bean numit QueryBean.
In urma alegerilor criteriilor din pagina jsp de catre utilizator, HttpServletRequest-ul va fi trimis ca si parametru metodei doQuery apartinand QueryBean-ului. O data primita cererea de la pagina de web prin intermediul ServletRequest-ului, in cadrul metodei doQuery se va transforma HttpServletRequest intr-o interogare SQL. Acesta se realizeaza prin intermediul metodei request2SQL. In continuare pentru o usurinta mai mare a prelucrarii se vor genera din acest punct threaduri separate, cate unu pentru fiecare SS_Server care se vor ocupa de transmiterea interogarii si preluarea rezultatelor de la SS_Servere. Pentru a face asta, este necesar ca mai intai sa se stie serverele SS care sunt implicate in interogarea curenta, deoarece dupa cum am spus utilizatorul poate selecta toate serverele sau doar unul din ele. Serverele de tip SS care sunt vizate de interogare sa gasesc in tabela ss_servers de gestiunea careia se ocupa Register_Serverul.
Fig. 5 – Structura de clase a SM_Server
Tot lucrul cu tabelele SQL este realizat si in acest caz de catre obiecte instante a unei clase SQLSolver. Metoda getNeededSS_Servers va returna un vector ce contine toate SS_Server- ele implicate in tranzactie respectiv si informatii despre fiecare astfel de server de tipul: adresa, port. Toate aceste informatii despre fiecare SS_Server vot fi stocate intr-o structura numita SS_ServersStruct. Asadar metoda getNeededSS_Servers a clasei SQLSolver va returna un vector ce contine obiecte instante ale clasei SS_ServersStruct. Dupa cum aratam si inainte, avand informatiile necesare despre fiecare SS_Server vizat, se va trece la crearea unor threaduri care sa se ocupe fiecare de cate un SS_Server. Un astfel de thread poarta numele de SMDaemon. O data lansate aceste threaduri in bean se va astepta finalizarea executiei lor.utilizand metoda activeDaemons care va verifica starea fiecarui SMDaemon lansat in executie. Dar sa vedem ce se intampla in cadrul fiecarui SMDaemon.
Fig. 6 – Diagrama de secventa corespunzatoare unei interogari
In cadrul contructorului acestei clase, pe langa operatiile asteptate de genul initializarea debuggerului are loc si initializarea unui timer al carui timeout este transmis ca parametru din bean. Rolul acestui timer este de a evita asteptarea la infinit a unui raspuns de la un SS_Server. De exemplu sa presupunem ca raspunsul de la un SS_Server intarzie un timp prelungit datorita unor probleme locale in cadrul serverului agentiei. In acest caz ar fi critic ca utilizatorul sa nu primeasca nici un rezultat la interogarea sa din moment ce toate celalalte servere au trimis raspunsul cu exceptia celui cu probleme.
Tot in cadrul contructorului are loc si trimiterea pe socket a interogarii. O data trimisa interogarea threadul poate trece in starea run. In aceasta stare daemonul va astepta raspunsul din partea SS_Serverului. Daca raspunsul va sosi inainte de expirarea timeout-ului atunci acesta va fi scris intr-un fisier XML. De fapt acum ceea ce este primit pe socket pur si simplu trebuie scris intr-un fisier deoarece SS_Serverul deja trimite un XML valid. S-a ales contruirea XML-ului la nivelul SS_Serverului pentru a mai usura munca SM_Serverului. O data scris rezultatul in fisier XML se revine in QueryBean.
In QueryBean dupa ce se verifica faptul ca toate Daemon-urile si-au incheiat executia se va trece la prelucrarea rezultatelor. Pentru inceput prin apelul metodei processResultsTXT, fisierele XML rezultate de la fiecare SMDaemon vor fi concatenate intr-un fisier XML. Cu aceasta metoda doQuery isi termina lucrul, lasand rezultatul interogarii utilizatorului sub forma unui fisier XML. Este foarte probabil insa, ca ceea ce va fi prezentat utilizatorului sa fie de fapt un fisier HTML.
Conversia fisierului XML rezultat in fisier HTML se realizeaza prin apelul metodei publice XML2HTML. In urma executiei acestei metode va rezulta un fisier HTML ce contine datele solicitate de utilizator, tot ce mai trebuie este ca acest fisier sa fie trimis si celui care a solicitat datele.
Pentru aceasta am ales alternativa folosirii unui servlet, numit SM_Servlet care pe metoda doGet va transmite fisierul HTML utilizatorului.
Caiet de sarcini
Pentru rularea sistemului OPTUS sunt necesare configurari suplimentare doar de partea SM_Serveru-lui. Pentru a rula Register_Server-ul si SS_Server pe o masina oarecare trebuie doar creat doar un DSN numit optus pe masina pe care ruleaza respectivul server pentru a avea acces la baza de date corespunzatoare fiecarui tip de server.
Toate sugestiile urmatoare pornesc de la premisa ca atat Register_Serverul, cat si SS_Serverul si SM_Serverul ruleaza pe aceeasi masina (rulare demonstrativa).
In continuare prezint o sugestie cu configurarile care trebuie facute pentru a rula cu succes SM_Serverul, presupunand ca sistemul ruleaza catalina.
Pas 1.
Se creeaza un fisier start.bat care contine urmatoarele linii:
call <dir_tomcat>/bin/setclasspath.bat
call <dir_tomcat>/bin/catalina.bat run
sau
Copiati fisierul startCatalina.bat in <tomcat>/bin. Daca nu exista fisierul <dir_tomcat>/bin/setclasspath.bat copiati fisierul setclasspath.bat in directorul dir_tomcat >/bin/
Pas 2.
In fisierul < dir_tomcat >/conf/server.xml se introduc urmatoarele linii:
<!-- OPTUS -->
<Context path="/OPTUS" docBase="<dir_optus>/OPTUSJSP"
debug="0" privileged="true"/>
<dir_optus> reprezinta calea completa pana la directorul OPTUS
Pas 3.
Creati o Baza de Date OPTUS. Rulati CreateTables.sql si PopulateHotels.sql pe aceasta baza de date.
Folosind ODBC Data Source Administrator sau orice alt utilitar creati un User DSN pentru BD OPTUS cu Login ID: sa si fara Password numit optus.
Pas 4.
Pentru a rula Register_Serverul lansati run_jar.bat din bin/Register_Server/.
Inainte de rulare nu uitati sa editati fisierul IniFile.ini din directorul aplicatiei.
Pentru a crea jar-ul utilizati unealta build_jar din directorul aplicatiei.
Pas 5.
Pentru a lansa doua SS_Servere de exemplu rulati run_jar1.bat si run_jar2.bat din bin/SS_Server.
Inainte de rulare nu uitati sa editati fisierul IniFile.ini din directorul aplicatiei.
Pentru a crea jar-ul utilizati unealta build_jar din directorul aplicatiei.
Pas 6.
Editati fisierul OPTUSIniFile.ini cu date valide si apoi copiati-l in <tomcat>/bin.
Pas 7.
Porniti serverul catalina folosind batch-ul de la Pasul 1.
Pas 8.
Lansati IE. Accesati adresa: http://localhost:8080/OPTUS/
Cerinte de sistem:
Java2SDK 1.4.1
SQL Server 7
Catalina Server