This article presents some aspects about a project integrated in a national research and development project "Information society" (INFOSOC) financed by Romanian Government. A iLab called LABVirt is available for use by Universities, college, high-school.The goal of this paper is to present the main components of LABVirt, Romanian solution for remote lab access

Catalin Ionut SILVESTRU

Codrin NISIOIU

Directory of Open Access Journals

Revista Informatica Economică. Nr. 4(40)/2006  98LABVirt – basic components  Asist. Codrin NISIOIU, asist. Cătălin SILVESTRU Catedra de Informatică Economică, A.S.E Bucureşti  This article presents some aspects about a project integrated in a national research and development project "Information society" (INFOSOC) financed by Romanian Govern-ment. A iLab called LABVirt is available for use by Universities, college, high-school.. The goal of this paper is to present the main components of LABVirt, Romanian solution for re-mote lab access. Keywords: iLab, remote lab access, client-server arhitecture, client applet  ntroducere Sistemul educaţional prin Internet repre-zintă un concept utilizat pe plan naţional în activitatea instituţiilor de învăţământ de toate gradele. Alinierea la ultimele tendinţe pe plan mondial în domeniul organizării şi funcţionă-rii reţelelor de calculatoare după modelele de tip intranet/internet(adică revenirea de la mo-delul informatic în care datele şi prelucrările erau distribuite în mod “egal” în toată reţea-ua, la arhitecturi cu servere puternice, deser-vite de soluţii software şi hardware speciali-zate, care să ofere informaţii unor “clienţi” cât mai diverşi, fie aceştia calculatoare fixe sau mobile), creează premizele integrării cât mai apropiate în societatea informatică a vii-torului [1] . Articolul va realiza descrierile arhitecturilor aplicaţiei client, respectiv ser-ver.  Descrierea aplicaţiei client În figura 1 este prezentată comportarea di-namică a APPLET-ului client printr-o succe-siune de stări ale acesteia. Fiecare stare co-respunde unui nou comportament functional al aplicatiei. Applet-ul iniţializează aplicaţia client (Starea 1) cu o prezentare generală a laboratorului virtual, prin care i se explică utilizatorului modul de folosire al aplicaţiei, modul în care se navighează în interiorul laboratorului vir-tual, ceea ce trebuie să facă pentru a duce la bun sfârşit lucrarea de laborator virtual si permite utilizatorului alegerea unei categorii de laboratoare din cele disponibile.  Fig.1. Descriere aplicaţie client  După ce clientul selectează o categorie, apli-caţia client trece în Starea 2 în care utilizato-rului i se prezintă o listă de lucrări din care trebuie să aleagă laboratorul pe care trebuie să-l efectueze. Utilizatorul poate să aleagă orice lucrare doreşte, chiar dacă a mai par-curs-o într-o dată anterioară, sau începe o lu-crare nouă. De asemenea, clientul poate efec-tua lucrările de laborator în ordinea dorită, nu există restricţii de acest fel. În urma acestei selecţii, se trece în Starea 3, unde se presupune că utilizatorul este deja I Revista Informatica Economică. Nr. 4(40)/2006  99familiarizat din Starea 1 cu modul de efectua-re a unei lucrări de laborator virtuale. În acest moment, utilizatorului îi sunt prezentate nu-mai informaţiile legate de evoluţia lucrării de laborator, cum ar fi etapele lucrării, schemele necesare şi modul de lucru. După ce utiliza-torul a parcurs toate aceste informaţii, el poa-te să acceseze partea de simulare a lucrării, aplicaţia client trecând în Starea 4. În aceasta stare utilizatorului i se cere să in-troducă numele utilizator si parola, necesare pentru a se autentifica în sistem. Dacă clien-tul nu dispune de un cont şi o parolă, el nu poate trece la partea de realizare a lucrării de laborator.  După validarea autentificării utilizatorului, se trece în Starea 5, care reprezintă faza pro-priu-zisă de antrenare (training), adică efec-tuează lucrarea de laborator virtuală. Aceasta stare se repetă până ce studentul parcurge toţi paşii lucrării. El nu poate parcurge laborato-rul decât în ordinea proiectată, anumite bu-toane fiind inactive pentru a nu permite sări-rea peste anumite operaţii sau navigare de la un modul la altul al lucrării fără realizarea celui precedent. În cadrul antrenării utilizatorul va interacţio-na cu simulatorul prin intermediul zonelor definite pentru fiecare modul component al lucrării de laborator în parte prin care studen-tul introduce date şi primeşte rezultate sau imagini. Conţinutul si forma datelor ce sunt trimise sunt verificate înainte de transmiterea acestora de către aplicaţia client pentru a se evita generarea unor erori care ar îngreuna comunicaţia client-server. Când simularea lucrării ia sfârşit, aplicaţia client trece în Starea 6 în care utilizatorul îşi verifica cunoştinţele acumulate în laboratorul pe care l-a parcurs. Această fază poartă nu-mele de autoevaluare. Aplicaţia client se termină cu Starea 7, unde utilizatorului i se afişează rezultatul obţinut, întrebările la care a greşit precum şi explica-ţiile rezultatelor corecte. Eventual, el poate primi şi unele recomandări asupra căror mo-dule sa revină pentru o mai bună înţelegere a materialului de studiat. În varianta pilot a sistemului LABVirt starile 6 si 7 nu au fost implementate, urmand ca acestea sa fie implementate într-o versiune ulterioară, am preferat inversarea starilor 3 cu 4 pentru o mai buna securitatea a sistemului si am ales ca incarcarea imaginilor sa se faca intr-o zona separata de cea de introducere a datelor si de obtinere a rezultatelor.  Descrierea aplicatiei server Caracteristicile platformei gazda Aplicatia server este proiectata sa ruleze pe sisteme de operare compatibile Windows NT. Alegerea platformei Windows are ca ar-gument faptul ca exista un numar foarte mare de aplicatii de simulare cu suport pentru acesta platforma. Versiunile compatibile NT sunt de preferat datorita stabilitatii si a supor-tului imbunatatit pt. comunicatia în retea. Separarea sesiunilor de lucru Aplicatia trebuie sa suporte un numar de se-siuni de lucru client-simulator ce se vor exe-cuta în “paralel”, drept pentru care devine necesara o separare a datelor si a codului pentru fiecare client în parte. Astfel, pentru orice conexiune, serverul va lansa pe un fir de executie codul ce asigura legatura client-simulator. Datele vor fi alocate pe o stiva proprie, integritatea lor fiind asigurata de mecanismele de protectie ale sistemului de operare. Pentru cazul în care vor exista spatii de lucru comune, (mediul de lucru al simulatorului daca acesta este unic pentru mai multe sesi-uni), fiecare fir de executie va modifica date-le în asa fel incit acestea sa nu intre în con-flict cu datele celorlalte fire.  Fig.2. Sesiuni de lucru cu simulatorul  Avind la baza ideile susmentionate, se poate proiecta un singur modul, a carui instante vor reprezenta sesiunile si care se vor executate în “paralel”, cu mentiunea ca, daca circum-stantele o cer, datele ce vor fi schimbate cu Revista Informatica Economică. Nr. 4(40)/2006  100simulatorul vor fi independente de la o sesiu-ne la alta. Arhitectura aplicatiei server. Cooperarea cu modulul simulator  Înca de la inceput se disting doua parti func-tionale ale aplicatiei: - un modul de initializare a structurilor apli-catiei si lansarea unei interfete necesara su-pravegherii si gestionarii activitatii pe server - un modul ce va realiza conexiunea client – server – simulator. Acest modul se va lansa pe un fir de executie paralel cu cel precedent, la fiecare cerere de conectare venita din parte unei aplicatii client. Aplicatia debuteaza cu un set de initializari realizate de firul principal. Sunt iniţializate: - un fir de executie pe care va rula socketul de ascultare a retelei pe portul 1500, port ales ad-hoc de catre echipa executive, din care am facut parte. Structura firului de server o voi prezenta ulterior. - un alt fir de executie ce va monitoriza firele de executie corespunzatoare sesiunilor de lu-cru si le va realoca în cazul în care acestea au ajuns la un final. - interfaţa cu mediul de simulare - o interfata cu utilizatorul permitindu-i aces-tuia vizulizarea si gestiunea starii curente a serverului, urmind ca la comanda de iesire sa opreasca toate firele în executie, sa dezaloce datele alocate dinamic si sa termine aplicatia. Firul de server Firul de server are rolul de a asculta reteaua cu rolul depistarii cererilor de conectare veni-te din partea aplicatiilor client, cit si de a ge-nera un fir de executie tip client-server-simulator pentru fiecare conexiune acceptata.  La primirea unei cereri de conectare, socketul firului server creează un nou socket, specific conexiunii în curs de acceptare, care este transmis firului client numai daca el înde-plineste condiţiile de securitate prescrise de administratorul sistemului . Altfel, socketul copie este distrus si se reintră în bucla de asteptare a unei noi conexiuni. Firul de server ruleaza conform schemei din figura 3:  Fig.3. Execuţie fir   Modulul alocator de fire Datorita faptului ca un asemenea sistem nu poate sustine simultan un numar foarte mare de conexiuni client-server-simulator, s-a pre-ferat o alocare statica a datelor, mai eficienta si mai putin pretentioasa decit o alocare di-namica. Pentru a gestiona optim conexiunile ce sunt pornite respectiv oprite s-a recoman-dat realizarea unui simplu alocator pentru fi-rele de executie, care urmareste conexiunile eliberate si le dezaloca, respectiv aloca noile conexiuni în spatiile precedent eliberate si doar în cazul în care acestea nu exista este alocata o noua pozitie. Modulul alocator este compus din doua parti: - un fir ce ruleaza în paralel cu sistemul si elibereaza pozitiile firelor de executie termi-nate; - o functie ce intoarce prima pozitie de la in-ceputul zonei alocate în care se poate porni un nou fir client-server-simulator. Această funcţie este folosită de catre firul de server atunci cind aloca firele de client-server-simulator. Modulul client-server-simulator Acest modul va fi activat la fiecare cerere de conexiune acceptată de către server, având rolul de interfaţă între aplicaţia client şi apli-caţia de simulare. El are de realizat trei acti-vităţi: Revista Informatica Economică. Nr. 4(40)/2006  1011. comunicaţia cu aplicaţia client, ce se va desfăşura pe baza protoculului de comunica-ţie client-server 2. translatarea datelor între formatele simula-tor şi aplicaţia client  3. transmiterea lor către simulator, realizarea simulării şi extragerea datelor rezulatate. Secventa de initializare a datelor firului Se realizează următoarea secvenţă de iniţiali-zări (figura 4): - Într-un prim pas este generat un identifica-tor unic pentru firul în execuţie, identificator pe baza căruia vor fi modificate şi identifica-te datele ce vor fi trimise spaţiului comun al simulatorului, cu scopul precizat anterior, de a nu intra în conflict cu datele scrise de alte fire. Identificatorul este construit pe baza in-formaţiilor legate de conexiunea TCP/IP şi este unic.  - Se alocă spaţii de lucru interne firului - Se aloca variabile şi spaţii de lucru pentru interfaţa cu simulatorul - Se aloca spaţii de lucru pentru fişierele de configurare. Secvenţa de autentificare a utilizatorului În protocolul de comunicaţie, după ce serve-rul trimte sirul de identificare, aplicaţia client trimite şi ea un sir de identificare, unic pentru un utilizator. Acest şir este interpretat şi cautat într-un fisier în care vor fi înregistraţi utilizatorii autorizaţi ai aplicaţiei. În cazul în care respectivul utilizator există, serverul raspunde cu “OK” şi se trece la secventa urmatoare. Altfel sesiunea va fi închisă şi fi-rul terminat. Secvenţa de creare şi comunicare a structuri-lor de date Odata ce autentificarea s-a încheiat cu succes aplicaţia client selectează o lucrare de labora-tor prin comanda din protocol “LAB:xx”, ap-licaţia server realizează următoarele activi-tăţi: - încarca fişierele de configurare, - îşi crează structurile de date funcţie de con-ţinutul lor  - le transmite şi aplicaţiei client. De la acest punct, comunicaţia cu sistemul la distanţă va avea loc sincron, avînd la bază aceste structuri. Interpretarea fisierelor de configurare se va face cu ajutorul unor unor clase predestinate acestui scop.   Fig.4. Starile firului client-server-simulator  Comenzile MOD:xx, SFLAB Începând cu acest pas comunicaţia se va des-faşura sincron între client şi server, în sensul în care fiecare va parcurge structura proprie de date creată la pasul anterior şi va realiza transmisia de date în concordantă cu aceasta.  Comanda “MOD:xx” selectează modulul “xx” din structura lucrarii de laborator, mo-dul ce va conţine datele unei secvenţe com-plete de simulare. Lucrarea de laborator poa-te fi alcătuită dintr-un număr suficient de ma-re de asemena module, ce vor fi parcurse consecutiv, iesirile simulărilor putînd repre-zenta intrari pentru simulări imediat următoa-re. O alta comanda care poate fi trimisă de catre client la acest pas este comanda “SFLAB”, care permite o încheierea sesiunii, în urma ei ambele sisteme încheind conexiunea. Secvenţa încheiere sesiune La acest pas se ajunge în momentul în care serverul a primit comanda “SFLAB”, urma-toarea actiune pe care o întreprinde fiind evi-dent închiderea conexiunii, dezalocarea me-moriei şi iesirea din firul de execuţie. Secvenţa de transmitere a instanţelor obiec-telor Revista Informatica Economică. Nr. 4(40)/2006  102După ce serverul a primit comanda “MOD:xx”, el transmite instanţele obiectelor statice descrise în fişierul de configurare .SCF către client, în ordinea în care acestea apar în fisierul de configurare (serverul este sincron cu aplicatia client din acest punct de vedere, deoarece ele procesează acelasi fisier de configurare). Datele trimise la acest pas vor fi atât textuale cât şi grafice, ele urmând a fi afişate utilizatorului, în cadrul aplicaţiei client. Comenzile DATA, EXEC, SFMOD Datele parcurg traseul applet-server-simulator, în ambele sensuri, avand aceleasi valori dar reprezentări diferite(una la client si alta la simulator). De aceea este nevoie de un "translator" de format (figura 5). Tot aici, re-zultă si necesitatea fisierelor de configurare, asa cum sunt descrise în sectiunea următoare. Pentru utilizarea fisierelor de configurare se utilizeaza un "interpretor" caracteristic fiecarui tip de fisier, care genereaza în me-morie structuri de date.Structurile de date ge-nerate fac obiectul comunicatiei client-server-simulator (in ambele sensuri) ce este gestionata prin comenzile urmatoare: Comanda “DATA” precede sirul instantelor obiectelor de intrare pentru simulare venite de la client. Serverul, după ce recepţionează acestă listă, converteşte datele la formatul cunoscut simulatorului, şi se întoarce în bucla precedentă, asteptînd comanda de începere a simularii “EXEC”. Comanda “EXEC” este executata imediat după ce au fost primite datele de la client. În urma recepţionării ei, serverul da comandă de început simularii, si intră într-o buclă de asteptate, ieşirea fiind condiţionată de termi-narea simularii. Cât timp acesta nu a ajuns la sfârşit, serverul are grija să transmită aplica-tiei client un semnal de prezentă la fiecare 30 de secunde. Cind simularea s-a terminat ser-verul converteşte rezultatele în format inter-pretabil de catre aplicaţia client, şi le transmi-te acesteia tot în ordinea în care apar în fisierul de configurare. Comanda “SFMOD” marchează sfârşitul unui modul, obligând serverul sa se decuple-ze de la modulul curent, şi sa revina în prima buclă de asteptare. Obiecte din fereastra client. (descrise în fişierul .ACF) Obiecte caracteristice simulatorului.(.SCF)Translatare   SI MULAREObiecte caracteristice simulatorului.(.SCF)Obiecte din fereastra client. (descrise în fişierul .ACF) Translatare  Fig. 5.Traseul client-server-simulator pentru un obiect  Fişiere de configurare: „.SCF”, „.ACF”, „.RES” Fiecare lucrare de laborator va fi caracteriza-ta prin următoarele trei tipuri de fişiere de configurare: - „.ACF” (Applet Configuration File) fişierul ce conţine configuraţia aplcaţiei client; Acest fişier este necesar configurării appletu-lui pentru o anumită lucrare. Acest fisier este structurat pe mai multe module corespunza-toare fiecărei etape de simulare în parte. Un asemenea modul conţine obiecte prin inter-mediul cărora se va interacţiona cu utilizato-rul. În definirea obiectelor se va avea în ve-dere un nume unic pentru fiecare obiect, co-ordonatele şi dimensiunile în fereastra utili-zator, tipul de dată pe care îl va vizualiza ( text/imagine), precum şi tipul de acces al uti-lizatorului la ea (citire/scriere).Un exemplu de obiect este descris mai jos: NUME: TIP_DATE: TIP_TR: X0: Y0: DIM_X: DIM_Y  tip_date:T-text tip_tr:D-initializat B-binar I-intrare E-iesire - „. SCF” (Server Configuration File) fişierul ce conţine configuraţia aplicaţiei server. Acest fişier are scopul de a realiza translata-rea obiectelor din „.SCF” într-un format ac-cesibil simulatorului şi invers. Fiecărui mo-dul în parte îi este ataşat un nume de fişier ce va conţine codul interpretabil al simulării. - „.RES” (Resource File) fişierul ce conţine resursele statice ale aplicaţei: texte şi ima-gini. Acestea vor exista pentru fiecare obiect descris în fişierul „.SCF” ca fiind de tipul „D” (iniţializat), şi vor fi afişate în fereastra Revista Informatica Economică. Nr. 4(40)/2006  103aplicaţiei client, pentru fiecare modul în par-te. Fişierele ce conţin codul interpretabil al simularii vor avea structura unei funcţii, în sensul că va avea un numar de date de intra-re, un cod interpretabil, şi un număr de date de iesire. Comunicaţia aplicaţie server–simulator utili-zat În general, pentru a fi apt să se integreze ap-licaţiei LABVirt, un simulator trebuie să aibă două proprietăţi: - să dispună de posibilitatea de a fi multiuser (mai multe sesiuni pot fi deschise simultan)  - să dispună de un mecanism de comunicare care să permită aplicaţiei server să transfere date în mod eficient şi relativ comod şi să comande etapele de similare necesare.  Concluzii În acest articol noi am încercat să arătam tehnologia folosită şi modalitatea de exploa-tare pe care noi o considerăm optimă pentru dezvoltarea sistemului de învăţământ virtual şi mai ales a accesului la distanţă a laboratoa-relor. Mai sunt numeroase posibilităţi de dezvoltare a produsului software pe care noi le prezenta in materialele ce vor urma.   Bibliografie [1] Nisioiu C.(2003) Realizarea aplicatiei cli-ent a sistemului LABVirt-proiect de diploma indrumat de Prof.univ.dr.ing. Minzu V.  [2] Silvestru C.(2003) Biblioteca digitala pentru informatica economica in cadrul con-ferintei nationale “ Universitatea virtuala din Romania “ – Academia de Studii Economice Bucuresti [3] Silvestru C.(2005) E-learning in cadrul conferintei internationale de informatica eco-nomica “ – Academia de Studii Economice Bucuresti.  

LABVirt – basic components

Abstract

Similar works

Full text

Available Versions

Directory of Open Access Journals