Retele Sociale Digitale Ubicue

9,952 views
9,799 views

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,952
On SlideShare
0
From Embeds
0
Number of Embeds
60
Actions
Shares
0
Downloads
98
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Retele Sociale Digitale Ubicue

  1. 1. Universitatea „Alexandru Ioan Cuza” Facultatea de Informatică Reţele Sociale Digitale Ubicue Coordonator: Lect. Dr. Corneliu Sabin Buraga Absolvent: Mihai Alexandru Serea Iaşi, 2005 1
  2. 2. Cuprins Cuprins..................................................................................... 2 1. Introducere ........................................................................... 4 1.1 Istoric.......................................................................... 6 1.1.1 Reţele de Calculatoare ................................................. 6 1.1.1.1 Internet ........................................................... 8 1.1.1.2 World Wide Web................................................. 10 1.1.1.3 Web Semantic.................................................... 11 1.1.1.4 Web of Trust ..................................................... 12 1.2 Tehnologii Web .............................................................. 13 1.2.1 Markup .................................................................... 13 1.2.2 Aplicaţii Web ............................................................. 14 1.2.3 Servicii Web .............................................................. 15 1.3 Colaborare Digitală .......................................................... 16 1.3.1 Poştă Electronică ........................................................ 16 1.3.2 Mesagerie Instantă ...................................................... 17 1.3.3 Comunităţi On-line ...................................................... 18 1.3.4 Reţele Sociale Digitale.................................................. 18 2. .NET Framework – Prezent şi Viitor ............................................... 20 2.1. Rezumat.......................................................................21 2.1.1. CLR (Common Language Runtime)....................................22 2.1.1.1. CTS (Common Type System) ...................................23 2.1.2. Class Library .............................................................24 2.1.3. Dezvoltare Aplicaţii Client .............................................24 2.1.4. Dezvoltare Aplicaţii Server.............................................25 2.1.4.1. ASP.NET vs. ASP .................................................26 2.2. Inovaţii ale .NET Framework 2.0 ..........................................28 2.2.1. Îmbunătăţiri şi Modificări ..............................................28 2.2.2. Compatibilitate ..........................................................36 2.3.Instrumente pentru Dezvoltare ...............................................37 2.3.1. Visual Studio 2005 „Whidbey” ........................................37 2.3.2. Team System .............................................................37 2.4. Spre „Longhorn” – Viitorul .NET...........................................38 2.4.1. „WinFS” – Semantică pentru Desktop ................................38 2.4.2. „Avalon” – Un Nou Sistem de Prezentare Grafică ..................38 2.4.3. „Indigo” – Viitorul Serviciilor Web ....................................39 3. Reţele Sociale Digitale Ubicue..................................................... 40 3.1. Introducere ................................................................... 41 3.2. Propunere..................................................................... 42 3.2.1. Beneficii................................................................... 43 3.2.2. Problematică ............................................................. 51 4. Sistemul MobiNET – O Nouă Abordare ............................................ 52 4.1. Rezumat....................................................................... 53 4.2. Utilizatori ..................................................................... 53 22
  3. 3. 4.3. Arhitectura Soluţiei ......................................................... 53 4.3.1. Servicii Web - MobiNETService ........................................ 54 4.3.2. Aplicaţii ................................................................... 55 4.3.2.1. Aplicaţie Web - MobiNET....................................... 56 4.3.2.2. Aplicaţie Desktop - MobiNETWinApp ......................... 57 4.3.2.3. Aplicaţie Pocket PC - MobiNETPPCApp ...................... 58 4.4. Inovaţii ........................................................................ 59 5. Concluzii............................................................................... 60 Direcţii Viitoare de Cercetare ......................................................... 62 Referinţe .................................................................................. 63 Glosar ...................................................................................... 64 33
  4. 4. 1. Introducere 44
  5. 5. Introducere În urmă cu ceva timp a fost lansată o teorie, mai mult sau mai puţin controversată, conform căreia numărul mediu de „grade de separaţie” între doi locuitori ai planetei este şase. Cum se traduce această ipoteză? Dacă am considera că fiecare persoană reprezintă un nod într-un graf, iar muchiile reprezintă relaţiile dintre persoane, această teorie s-ar putea traduce prin faptul că, „lungimea” medie a drumului dintre două noduri este şase, astfel, parcurgând, în medie, o distanţă de şase relaţii, putem ajunge de la o persoană, la oricare alta. Lucrarea de faţă nu îşi propune demonstrarea sau infirmarea acestei teorii, în schimb constatăm faptul că, de la lansarea acesteia, tot mai multe „entităţi” sunt interesate de „explorarea” acestui „graf” imaginar, consecinţă directă fiind faptul că, în momentul actual se înregistrează o continuă creştere a popularităţii fenomenului reţelelor sociale digitale. Multitudinea aplicaţiilor Web care abordează acest subiect şi numărul mare de utilizatori oferă un semnal evident asupra dorinţei umane de „conectare”, de atestare a apartenenţei la o comunitate şi de dezvoltare a acestei comunităţi, iar locul cel mai potrivit pentru dezvoltarea acestui fenomen este, categoric, Internet-ul. În domeniul tehnologiilor informaţionale, categoric, Internet-ul reprezintă „entitatea” cu cea mai mare popularitate şi cea mai rapidă evoluţie. Acest „succes” al Internet-ului se datorează, în mare parte, posibilităţilor nelimitate de comunicare şi accesare a datelor şi informaţiilor diverse, oferite utilizatorilor. În evoluţia sa, Internet-ul se îndreaptă către un nou salt major, urmărind îmbunătăţirea experienţei utilizării produselor şi serviciilor disponibile. Acest salt ne va aduce în pragul unei noi ere, în care modelarea datelor va ţine cont de sintaxă, de semantică şi de pragmatică - era Web-ului semantic. Această lucrare îşi propune descrierea următoarei generaţii de tehnologii .NET şi conexe, ca tehnologii care impun standardele dezvoltării viitoare a Internet-ului şi a spaţiului Web, precum şi realizarea unui studiu de caz, cu ajutorul unei aplicaţii ce reprezintă concretizarea unei noi abordări a subiectului interacţiunii persoană-calculator, din perspectiva îmbunătăţirii interacţiunii persoană-persoană, în contextul reţelelor sociale digitale şi al Web-ului semantic. Primul capitol al lucrării conţine o introducere în istoricul dezvoltării „erei informaţionale”, cu accent asupra Internet-ului şi a spaţiului Web, incluzînd evoluţia mediilor, a tehnologiilor Web şi a aplicaţiilor destinate acestei infrastructuri, şi se încheie cu o parcurgere descriptivă succintă a conceptului „reţelelor sociale digitale”. Următorul capitol conţine o descriere a arhitrecturii .NET Framework, mai exact, a modelului platformei, descris abstract, a îmbunătăţirilor aduse de versiunea 2.0, aflată în stadiul Beta 2 la momentul realizării prezentei lucrări, a instrumentelor destinate dezvoltării aplicaţiilor .NET şi a tehnologiilor bazate pe .NET Framework 2.0 specifice următoarei generaţii de sisteme de operare din familia Microsoft® Windows® nume de cod „Longhorn”. Capitolul trei detaliază aspectele cheie ale noţiunii de „reţea socială digitală ubicuă” în contextul tehnologiilor .NET şi al Web-ului semantic, constituind partea cea mai importantă a lucrării de faţă, iar capitolul patru exemplifică afirmaţiile prezentei lucrări, printr-o suită de aplicaţii şi servicii având ca scop crearea şi menţinerea unei „reţele sociale digitale ubicue”, reunite sub denumirea MobiNET. 55
  6. 6. Introducere 1.1 Istoric În prezent, definiţia „erei informaţionale” este sinonimă cu termenul, conceptul şi obiectul Internet, însă, din punct de vedere istoric, formularea corectă ar putea fi: „la început a fost cablul”. În 1831 Joseph Henry descoperă electromagnetul şi foloseşte proprietăţile acestuia pentru a transmite un impuls electric la distanţă, via cablu. Inspirat de invenţia lui Henry, Samuel Morse (1791-1872), pictor profesionist, recunoscut pentru talentul portretistic şi om de ştiinţă amator, dezvoltă prototipul telegrafului (1835), folosit pentru a transmite pattern-uri de impulsuri electrice la distanţă, via cablu, iar câţiva ani mai târziu face public alfabetul de semnale intermitente lungi sau scurte, numite linii, respectiv puncte, cunoscut sub numele de „codul Morse”. La 24 mai 1844, este transmis primul mesaj telegrafic între Baltimore, Maryland şi Washington D.C. având textul „Ce a creat Dumnezeu” (eng. „What has God wrought”), printr-un fir metalic cu lungimea de 37 mile. „Prin metodele electricităţii, lumea întreagă a devenit un mare nerv, vibrând la mii de mile într-un minuscul punct al timpului … Globul este vast… asemeni unei scoarţe cerebrale… pline de inteligenţă.” Aceste cuvinte vizionare aparţin marelui poet Nathaniel Hawthorne şi au fost scrise în 1851, ca urmare a impresiei puternice provocate de observarea funcţionării telegrafului. În 1858 s-a stabilit prima legătură de comunicaţii instantanee transatlantice via cablu („cablul atlantic”). Deşi din punct de vedere social, acest eveniment a fost privit ca unul de importanţă majoră, comparat mai tărziu cu aselenizarea, din punct de vedere tehnic „cablul Atlantic” a reprezentat un eşec, conexiunea fiind activă doar câteva zile. Următoarele seturi de cabluri (1866) au fost puse în funcţiune cu succes, rămânând în uz pentru aproape un secol. 1.1.1 Reţele de Calculatoare În anii ’60 reţelele de calculatoare erau sinonime cu termenul de mainframe, iar diferenţa dintre LAN (Local Area Network) şi WAN (Wide Area Network) nu exista. Mainframe-urile erau conectate la serii de terminale „limitate” (eng. dumb terminals) prin intermediul conectorilor seriali (RS-232 sau alte interfeţe electrice). Pentru conectarea unui terminal aflat într-un oraş, la un mainframe aflat în alt oraş, se foloseau modem-uri care utilizau conexiunile analogice existente ale PSTN (Public Switched Telephone Network). Calitatea serviciilor PSTN s-a îmbunătăţit mult începând cu introducerea în 1962 a PCM (Pulse Code Modulation), folosit la convertirea semnalelor vocale analogice în secvenţe digitale de biţi. Tot în 1962 este produs primul aparat telefonic ce utilizează „tonul” (eng. tone) pentru transmiterea semnalelor vocale, determinând dezvoltarea standardului DS-0 (Digital Signal Zero) , standard de transmisie a datelor pe canale de 64 kilobiţi pe secundă (Kbps), care va sta la baza întregului sistem de telefonie digitală. O dezvoltare ulterioară numită generic „bancă de canale”, combină 20 de canale DS-0 folosind TDM (Time-Division Multiplexing) pentru a forma un singur canal de legătură cu capacitatea de transmitere a 1,544 megabiţi pe secundă (Mbps), 66
  7. 7. Introducere denumit standard DS-1 sau T1. În Europa sunt combinate 30 de legături DS-0 pentru a forma E1. Lansarea primului satelit destinat comunicaţiilor (Telstar), are loc în 1962, dar latenţa mare a legăturilor satelit faţă de cea a cablurilor telefonice, face ca această tehnologie să nu fie adoptată imediat în domeniul reţelelor de calculatoare. Anul 1969 va aduce lansarea primului document RFC (Request For Comments), care descria specificaţiile NCP (Network Control Protocol), primul protocol de transfer folosit de ARPANET. Procesul de specificare informală prin RFC va deveni principala metodă de control a direcţiei de dezvoltare a Internet-ului, fiind folosit şi astăzi. În acelaşi an, Bell Laboratories dezvoltă sistemul de operare UNIX, un sistem multi-aplicaţie, multi-utilizator, capabil de interacţiune reţea, care va deveni sistemul de operare favorit al mediilor academice cu interes în dezvoltarea computaţională. Anii ’60 au fost, de asemenea, responsabili pentru dezvoltarea unor standarde folosite şi acum, printre care codul codul ASCII de reprezentare a caracterelor folosind secvenţe de biţi lansat de ASCII (American Standard Code for Information Interchange) în 1963 şi standardizat formal de ANSI (American National Standards Institute) în 1968. De importanţă majoră pentru dezvoltarea reţelelor de calculatoare, a tehnologiilor LAN şi implicit a Internet-ului, a fost introducerea începând cu anii ’70 a Ethernet-ului. Proiectul iniţial denumit X-wire a fost creat în laboratoarele de cercetare de la Palo Alto, California ale Xerox Corp. (1973). X-wire avea capacitatea de transfer de 2,94 megabiţi pe secundă (Mbps) şi nu a fost intenţionat lansării comerciale, deşi o serie de staţii de lucru Xerox Palo Alto folosite pentru procesarea documentelor text au fost conectate folosind X-wire în interiorul Casei Albe, în timpul administraţiei Carter. De asemenea, câteva centre de cercetare au fost dotate cu staţii de lucru Xerox Palo Alto, Rick Rashid, preşedinte al Microsoft Research şi SVP al Microsoft Corp. amintindu-şi cu plăcere despre experimentele incipiente ale dezvoltării primului „joc” care utiliza capacităţile de conectare la reţea prin X-wire, în timpul ce lucra pentru dezvoltarea sistemului X-Window. În 1979 Digital Equipment Corp. (DEC), Intel Corp. şi Xerox Corp. formează consorţiul DIX, responsabil pentru dezvoltarea specificaţiilor pentru standardul Ethernet de 10 Mbps denumit public thicknet, datorită utilizării cablului coaxial gros ca mediu pentru realizarea conexiunii. În domeniul protocoalelor specializate, anii ’70 au introdus prin RFC specificaţiile pentru Telnet (1972), FTP (1973), iar în 1974 a fost publicată prima specificaţie pentru TCP (Transmission Control Protocol), urmând ca formalizarea arhitecturii de bază a TCP/IP să fie publicată în 1978. Proiectul 802 al IEEE îşi propunea unificarea tehnologiei LAN într-un singur standard coerent. Acest lucru s-a dovedit a fi imposibil, iar proiectul 802 a fost divizat într-o serie de grupuri de lucru separate. Noul indicativ al proiectului pentru standardizarea Ethernet-ului va fi 802.3. Primul standard al grupului 802.3 a fost 10Base5, standard aproape identic cu thicknet-ul dezvoltat de DIX. În 1982 standardul 802.3 a fost extins pentru a include 10Base2 care folosea cablu coaxial subţire ca mediu de transmisie (eng. pop. thinnet). De-a lungul anilor ’80 principala metodă de implementare a reţelelor Ethernet va folosi standardele 10Base5, respectiv 10Base2. 77
  8. 8. Introducere În paralel, o companie numită SynOptics Communications, dezvoltă un „produs” numit LattisNet destinat transmiterii Ethernet-ului de 10Mbps folosind cablu twisted-pair, în topologii de tip stea, având în centru un dispozitiv de regenerare a semnalului numit hub sau repetitor. Datorită folosirii acestui tip de cablu, implementarea reţelelor care utilizau LattisNet reprezenta o soluţie mai puţin costisitoare, iar topologia de tip stea simplifica problema cablării reţelelor destinate clădirilor cu mai multe etaje. Succesul comercial al LattisNet conduce la standardizarea 802.3 a acestui tip de Ethernet sub denumirea 10BaseT (1990). Un alt eveniment de importanţă majoră petrecut la începutul anilor ’90, este standardizarea 802.3 sub denumirea 10BaseFL, a conexiunilor Ethernet, utilizând ca suport fibra optică, dezvoltată de Corning încă din 1970 şi introdusă în domeniul comercial al reţelelor de calculatoare începând cu 1984. O altă realizare importantă este reprezentată de introducerea în 1977 a conceptului de reţea „fără fir” (eng. wireless), prin realizarea unui experiment având ca scop crearea unui serviciu radio de comutare de pachete reţea, acest proiect fiind cunoscut ulterior sub denumirea PRNET (Packet Radio Network). Tehnologia CDMA (Code Division Multiple Access), folosită în prezent pentru realizarea reţelelor de telefonie mobilă de generaţia a treia (3G), este succesor direct al tehnologiilor folosite iniţial în cadrul proiectului PRNET. Odată cu introducerea în 1983 a suportului pentru TCP/IP, standardul de facto al comunicării între sisteme informatice, în versiunea 4.2 a BSD (Berkley Software Distribution), distribuţia UNIX aparţinând Berkley University of California, se crează premisele pentru dezvoltarea pe scară largă a reţelelor de calculatoare şi implicit, a Internet-ului. 1.1.1.1 Internet După lansarea satelitului Sputnik de către Uniunea Sovietică (1957), preşedintele Statelor Unite ale Americii, Dwight D. Eisenhower crează ARPA (Advanced Research Project Agency), agenţia pentru proiecte de cercetare avansată. Agenţia reunea cei mai străluciţi oameni de ştiinţă ai Americii şi nu numai, aceştia dezvoltând primul satelit american în doar 18 luni. Câţiva ani mai târziu ARPA a început să-şi concentreze eforturile către domenii cu aplicaţii în reţelele de calculatoare şi tehnologiile de comunicaţii. În 1962, Dr. J.C.R. Licklider este numit preşedinte al diviziei ARPA responsabilă de dezvoltarea şi aplicarea tehnologiei computerelor în domeniul militar. Acesta consideră ca metodă optimă pentru dezvoltarea rapidă a tehnologiei rezilierea contractelor cu reprezentanţi ai sectorului privat şi antrenarea universităţilor în proiect, punând astfel fundaţiile pentru viitoarea ARPANET. În 1969, UCLA propune ARPA înfiinţarea NMC, un centru de măsurători de reţea (Network Measurement Center). Ca urmare, UCLA primeşte de la BBN (Bolt, Beranek and Newman) o unitate IMP (Interface Message Processor) bazată pe un sistem Honeywell DDP 516, ulterior conectată printr-o interfaţă de 50 Kbps la alte două universităţi – Stanford Research Institute (SRI), respectiv UC Santa Barbara (UCSB), într-o reţea totalizând patru noduri, incluzând şi University of Utah, Salt Lake City. Mai târziu, Leonard Kleinrock, profesor strălucit al UCLA, pionier în comunicaţii digitale, împreună cu un mic grup de studenţi va încerca să se conecteze la computer-ul de la Stanford şi să trimită cuvântul „login”, confirmarea de primire a fiecărei litere fiind realizată 88
  9. 9. Introducere simultan prin convorbire telefonică. Planul era fără precedent, însă la tastarea literei ‚g’ sistemul de la UCLA şi-a terminat „abrupt” execuţia. În Figura 1 este reprezentată arhitectura acestui prim set format din patru noduri, care urma să devină ARPANET, precursorul Internet-ului. Figura 1. UCLA, SRI, UCSB şi UTAH, prima reţea publică, ulterior cunoscută ca ARPANET. În 1971, Larry Roberts de la ARPA decide prezentarea ARPANET la conferinţa internaţională a comunicaţiilor computerizate (ICCC) ce urma să aibă loc în octombrie anul următor. După un an de pregătiri, un comutator de pachete (eng. packet switch) şi un procesor de interfeţe terminal (eng. terminal interface processor, TIP) sunt montate la subsolul hotelului Hilton din Washington iar publicului prezent i se permite folosirea directă a ARPANET pentru „rularea aplicaţiilor din toată America...”. În ciuda scepticismului specialiştilor de la AT&T, prezentarea decurge perfect, acest moment rămânând în istorie ca prima atestare publică a Internet-ului. În Figura 2 putem observa o hartă originală a ARPANET datând din aprilie 1971, care a aparţinut lui Bob Bell, operator suport pentru DEC PDP-10 (DEC Field Service). 99
  10. 10. Introducere Figura 2. Aprilie 1971, arhitectura ARPANET, conform DEC, furnizor al echipamentelor PDP-10. În 1973, ARPANET devine un proiect internaţional prin adăugarea de „noduri” la University College of London, Marea Britanie şi la Royal Radar Establishment, Norvegia. 1.1.1.2 World Wide Web În 1945 Vannevar Bush, directorul Biroului pentru Cercetare şi Dezvoltare Ştiinţifică al Statelor Unite, scrie un articol în Atlantic Monthly, intitulat „Cum am putea gândi...” (eng. „As we may think...”), descriind MEMEX, un dispozitiv foto-electro-mecanic ipotetic, folosit pentru a crea legăţuri între microfişe şi naviga pe baza acestora. În 1968, Douglas Engelbart (Stanford Reaserch Institute) demonstrează oNLineSystem (NLS), sistem ce permitea navigarea (eng. browsing) şi editarea de hypertext, precum şi trimiterea de e-mail-uri. În procesul de dezvoltare al NLS, Engelbart inventează mouse-ul. Pe parcursul a şase luni (iunie-decembrie 1980), în timp ce lucra pe post de consultant pentru CERN (fr. Centre Europeen de Recherche Nucléaire), Tim Berners-Lee, scrie un program de calculator numit „Enquire” (după romanul victorian „Enquire Within Upon Everything”), program care permite crearea de legături între noduri arbitrare. Modelul conceput de Berners-Lee „ataşa” fiecărui nod un nume, un tip şi o listă de legătury bidirecţionale, cu tip. „Enquire” rula pe maşini Norsk Data, sub Sintran-III. În 1989, acelaşi Tim Berners-Lee, scrie lucrarea „Gestiunea Informaţiei: O Propunere” (eng. Information Management: A Proposal), aceasta fiind circulată în cadrul CERN pentru comentarii. Anul următor, în mai, continuă (re)circularea „propunerii”, iar în septembrie, Mike Sendal, superiorul lui Berners-Lee, aprobă achiziţionarea unui sistem NeXT, pentru a-i permite acestuia dezvoltarea „sistemului global pentru hypertext”. În octombrie Berners-Lee începe dezvoltarea unui navigator/editor de hypertext cu interfaţă grafică WYSIWYG (What You See Is What You Get), folosind NeXTStep ca mediu de dezvoltare. Aplicaţia dezvoltată va primi numele WorldWideWeb 1010
  11. 11. Introducere (alternativele includeau: Information Mesh, Mine of Information, Information Mine etc). La sfârşitul lunii octombrie, propunerea va fi reformulată, avându-l drept coautor pe Robert Cailliau (ECP), iar în noiembrie este lansat primul server Web, nxoc01.cern.ch (mai târziu, info.cern.ch), folosind aplicaţia server „httpd”. Tot în noiembrie este lansată prima pagină Web, primul sit Web, la adresa http://nxoc01.cern.ch/hypertext/WWW/TheProject.html, însă din păcate, adresa URL a sitului istoric nu mai este suportată de CERN. În decembrie proiectul WorldWideWeb poate fi demonstrat. În februarie 1993, NCSA (National Association for Supercomputing Applications), University of Illinois, Urbana-Champaign, lansează prima versiune alfa a navigatorului „Mosaic for X” (mai târziu, Netscape Navigator), dezvoltat de Marc Andreessen, urmând ca în septembrie să aibă loc lansarea versiunii finale pentru principalele platforme (e.g. X, PC/Windows, Macintosh). În decembrie 1993 WWW primeşte premiul IMA, John Markov scrie o pagină şi jumătate despre Mosaic şi WWW în The New York Times (US), The Guardian (UK) publică o pagină despre WWW, iar Robert Cailliau primeşte permisiunea de a organiza prima conferinţă având ca temă WWW-ul la CERN. Explozia este uluitoare: numărul de accesări a sit-ului info.cern.ch creşte de 1000 de ori din 1991 până în 1994, iar numărul de situri înregistrate, de la aproximativ 10.000 în 1994, până la 25.675.581 la sfârşitul anului 2000. La 1 octombrie 1994, Berners-Lee înfiinţează consorţiul World Wide Web (W3C) cu sprijinul Massachusetts Institute of Technology (MIT). Consorţiul este compus din reprezentanţi ai diverselor companii, iar principala activitate se concentrează asupra definirii şi implementării de standarde şi recomandări, în scopul îmbunătăţirii calităţii serviciilor disponibile în spaţiul Web. 1.1.1.3 Web Semantic Conceptul de Web semantic se confundă cu conceptul Web-ului originar, acesta găsindu-şi „rădăcinile” în chiar „propunerea” lui Berners-Lee (1989). Cu toate acestea, prima menţiune a termenului ”Web semantic” are loc cu ocazia primei conferinţe internaţionale asupra WWW-ului organizată la sediul CERN (Geneva, 1994), conferinţă suprasolicitată (800 se înscriu, 400 sunt acceptaţi), denumită popular „Woodstock of the Web”. Conform W3C, „Web-ul semantic este un efort colaborativ pentru furnizarea unei platforme unificate care să permită distribuirea şi reutilizarea datelor dincolo de graniţele aplicaţiei, ale organizaţiei sau ale comunităţii”, iar conform însuşi creatorului spaţiului Web, Tim Berners-Lee, „Web-ul semantic reprezintă o extindere a Web-ului curent în care un înţeles bine definit este ataşat informaţiei, permiţând o mai bună cooperare între oameni şi maşini”. O viziune aplicabilă asupra conceptului „pânzei semantice” este aceea de „modalitate eficientă de reprezentare a datelor în spaţiul Web”. Scopul urmărit este acela de a face posibilă publicarea datelor într-o formă inteligibilă de către orice aplicaţie care doreşte utilizarea respectivelor informaţii (implicit, orice platformă, inclusiv dispozitive mobile), precum şi posibilitatea ataşării de logici de inferenţă, astfel încât, aplicaţiile să poată genera noi „cunoştinţe”, pe baza celor acumulate deja. Acestea reprezintă cele două faze ale dezvoltării Web-ului semantic. (Tim Berners-Lee). În februarie 2004, eforturile de standardizare aparţinând primei faze sunt finalmente concretizate, sub forma a două recomandări W3C, care asigură 1111
  12. 12. Introducere fundamentul dezvoltării Web-ului semantic, mai exact, RDF (Resource Description Framework) şi OWL (Web Ontology Language). RDF este un format generic de reprezentare unificată a informaţiilor asociate resurselor, care utilizează triple de URI-uri (Uniform Resource Identifier). RDF are asociată o serializare XML (RDF XML), recomandare a W3C, aceasta constituind formatul standard de schimb de informaţii în cadrul Web- ului semantic. OWL este un limbaj destinat aplicaţiilor care procesează informaţii la nivel de conţinut, facilitând o mai bună interpretabilitate automatizată a conţinutului Web, decât XML sau RDF, prin furnizarea unor elemente adiţionale de vocabular şi prin introducerea unei semantici formale. Conceptual, OWL reprezintă un limbaj de descriere formalizată a terminologiei folosită uzual în documentele Web, utilizând ontologii. O ontologie defineşte termenii folosiţi pentru a descrie şi reprezenta o arie a cunoaşterii, cum ar fi cunoştinţele specifice unui domeniu, ale unui subdomeniu sau ale unui subiect anume. Deşi prima etapă s-a încheiat cu succes, odată cu finalizarea recomandărilor pentru RDF şi OWL, trebuie menţionat faptul că, în momentul actual, Web-ul semantic rămâne un deziderat, stiva de standarde şi recomandări ale W3C fiind insuficientă aplicării pe scară largă a modelului, un impediment fiind şi latenţa procesului de acceptare şi utilizare a recomandărilor existente. Cu toate acestea, există aplicaţii care beneficiază deja de implementări aparţinând domeniului semantic, un exemplu fiind cele şase use-case-uri dezvoltate chiar de grupul de interes dedicat Web-ului semantic, din cadrul W3C. Alte exemple includ Boeing Co., care a început deja explorarea aplicabilităţii soluţiilor semantice pentru integrarea informaţiilor şi a aplicaţiilor, în scopul interoperabilităţii şi al managementului cunoştinţelor (eng. knowledge management) şi Adobe Systems Inc. care a inclus în produsele sale suport pentru XMP (eXtensible Metadata Platform), o aplicaţie a RDF care are rolul de a asocia informaţii contextuale şi de conţinut fişierelor utilizate. Recent, Adobe Systems Inc., dezvoltator al formatului PDF (Portable Document Format) a achiziţionat pachetul majoritar de acţiuni al Macromedia Inc., dezvoltator al formatului SWF (Shockwave Flash), şi a anunţat demararea proiectului pentru dezvoltarea unui „super-format” hypermedia care va încorpora şi tehnologii semantice pentru identificarea datelor în funcţie de conţinut. 1.1.1.4 Web of Trust Web-ul „de încredere” reprezintă o viziune de dezvoltare şi implementare a Web-ului semantic, în care metodele de reprezentare ale datelor şi logicile de inferenţă ataşate permit identificarea şi filtrarea sursei informaţiilor, verificarea credibilităţii sursei, eliminarea informaţiilor false sau a informaţiilor inconsistente, care conduc la contradicţii insolvabile etc. Inovaţiile tehnologice disponibile la momentul actual în domeniul semnăturilor digitale şi al identităţii virtuale oferă un semnal pozitiv vis-a-vis de posibilitatea implementării unui Web of Trust, dar cel mai important pas va fi definirea standardelor care vor sta la baza acestei arhitecturi. 1212
  13. 13. Introducere 1.2 Tehnologii Web Prin noţiunea de „tehnologii Web” vom descrie tehnologiile care au stat la baza dezvoltării spaţiului Web, responsabile pentru funcţionalitatea aplicaţiilor WWW. Principalele categorii de tehnologii pot fi structurate pe trei nivele: markup, aplicaţii Web, respectiv servicii Web. 1.2.1 Markup Tehnologia HTML (Hypertext Markup Language) reprezintă o constantă pe parcursul istoriei spaţiului WWW. Prima pagină Web şi primul sit Web au fost scrise de Berners-Lee folosind navigatorul/editorul WorldWideWeb pentru a genera codul HTML (WWW era un editor WYSIWYG), iar la momentul actual, majoritatea siturilor includ pagini scrise integral sau parţial folosind HTML. Acest limbaj este un subset al SGML constând într-un set de tag-uri care permite descrierea markup a aspectului (eng. layout) şi a conţinutului paginii Web. Cea mai recentă recomandare a W3C pentru HTML a are indicativul 4.01. HTML a fost înlocuit de XHTML, subset al XML care include tag-urile şi atributele HTML 4.01, recomandare a W3C începând cu 26 ianuarie 2000. Exemplu de cod HTML: <html> <head> <title lang="en">HTML</title> </head> <body> <p style="font-family: Tahoma; font-weight: bold"> Pagină <i>HTML</i></p> </body> </html> În Figura 3 se poate observa rezultatul codului de mai sus. Figura 3. Rezultat vizualizat folosind navigatorul Internet Explorer®. 1313
  14. 14. Introducere 1.2.2 Aplicaţii Web Aplicaţiile Web au apărut ca urmare a incrementării necesităţilor de utilizare a spaţiului WWW, introducând noţiunea de pagină Web activă. Principalul scenariu implică diferite nivele de procesare centralizată a datelor legate de utilizator, în contextul dat de activităţile organizaţiei care menţine situl respectiv. Folosind un navigator Web, utilizatorul accesează o pagină conţinând un formular (eng. form), introduce datele necesare şi accesează butonul sau link-ul comenzii server. Datele sunt trimise către server, unde are loc procesarea, iar la finalizarea operaţiunilor efectuate răspunsul este serializat HTML şi transmis către client pentru vizualizare prin intermediul navigatorului. Figura 4 descrie sub formă de diagramă, principiul general al funcţionării aplicaţiilor Web. Figura 4. Arhitectura aplicaţiilor Web. Istoric, prima generaţie de tehnologii Web destinată aplicaţiilor Web, standard de-facto al interacţiunii programatice a clienţilor cu server-ul Web, este reprezentată de CGI (Common Gateway Interface). Prin CGI se pot produce răspunsuri HTTP folosind orice limbaj de programare disponibil pe server, interpretat (e.g., Perl, Python etc), sau compilat (e.g., C, C++). Cu toate că modelul CGI nu este deloc ineficient din punct de vedere al calităţii şi performanţei aplicaţiei dezvoltate, prezintă deficienţe majore în ceea ce priveşte eficienţa productivităţii dezvoltării. În acest context, cele mai importante tehnologii de actualitate sunt PHP (PHP: Hypertext Preprocessor), Microsoft® ASP (Active Server Pages), Sun Java2 Enterprise Edition şi Microsoft® ASP.NET. Se disting două categorii de aplicaţii Web, aplicaţiile scriptate sau interpretate (e.g., PHP, ASP etc) şi aplicaţiile compilate (e.g., Java2, ASP.NET etc), cu avantaje de performanţă pentru categoria aplicaţiilor compilate. Un alt element important al aplicaţiilor Web sunt scripturile client. Acestea constituie cod program, inclus în codul HTML trimis clientului care va fi executat prin interpretare de către navigator sau de către un plug-in al 1414
  15. 15. Introducere acestuia. În general, scripturile client sunt utile pentru reducerea numărului de bucle cerere-răspuns între client şi server prin distribuirea către client a responsabilităţii realizării unor operaţiuni simple de procesare, în general auxiliare (e.g., validarea input-ului etc). Cel mai folosit limbaj de scripting client este JavaScript® (JScript), o alternativă fiind VBScript. 1.2.3 Servicii Web Serviciile Web reprezintă o particularizare a aplicaţiilor Web. Principala diferenţă este dată de faptul că serviciile Web nu sunt destinate direct utilizatorilor umani, ci sunt destinate „consumării” sau exploatării, de către alte aplicaţii, fie Web, fie Internet-enabled (aplicaţii pentru Desktop, care derivă funcţionalitate din posibilitatea conectării la Internet). De asemenea, un serviciu Web poate fi consumat de alte servicii Web pentru a asigura un plus de funcţionalitate şi integrare. Serviciile Web sunt deci componente care oferă capacitate de procesare adiţională, aplicaţiilor consumator. Această diferenţă conceptuală induce un set de diferenţe arhitecturale, dintre care, cea mai evidentă este absenţa (sau rudimentaritatea) interfeţei utilizator. O altă caracteristică de bază a serviciilor Web derivă din necesitatea de interoperabilitate (capacitatea de colaborare între componente, aplicaţii şi sisteme eterogene). Pentru a adresa această necesitate serviciile Web trebuie să deţină abilitatea de a comunica folosind standarde ale industriei precum SOAP (Simple Object Access Protocol, explicitare depreciată) şi WSDL (Web Services Description Language), ambele recomandări ale consorţiului Web. În Figura 5 se poate observa o descriere schematică a interacţiunii serviciilor Web cu aplicaţiile consumator şi, de asemenea, cu alte servicii Web. Figura 5. Interacţiunea serviciilor Web cu aplicaţiile consumator, respectiv alte servicii. SOAP reprezintă un standard ce utilizează paradigma XML-RPC pentru a transporta mesaje serializate XML într-o manieră extensibilă, utilizabil 1515
  16. 16. Introducere indiferent de infrastructura conexiunii (protocoale de reţea etc) şi independent de modelul programatic utilizat de aplicaţie (limbaj de programare etc). WSDL reprezintă o modalitate standardizată de descriere a serviciilor Web, a funcţiilor pe care le implementează şi a tipurilor de date vehiculate, bazată pe sintaxa XML (XML Schema), care permite aplicaţiilor exploatarea acestora. Conceptual, WSDL constituie o modalitate de specificare a sintacticii serviciilor Web, nu a semanticii acestora. O aplicaţie a serviciilor Web, destinată serviciilor Web şi aplicaţiilor consumator, este UDDI (Universal Description Discovery and Integration), reprezentând un registru universal al listei de servicii Web disponibile (descrise folosind WSDL), iniţiativă în dezvoltare sprijinită de IBM Corp., Microsoft Corp. etc. Deşi nu implementează implicit funcţionalitate semantică, serviciile Web, reprezintă infrastructura de bază pentru dezvoltarea Web-ului semantic, permiţând interacţiunea coerentă a colecţiilor de sisteme eterogene, pentru realizarea unui scop funcţional augmentat, în beneficiul utilizatorului uman. Tehnologiile destinate dezvoltării de servicii Web sunt multiple cu exemple de la IBM Corp. (IBM Web Services Toolkit), Apache Org. (Apache SOAP) sau Borland Software Corp. (Borland JBuilder Web Services), însă cele mai importante tehnologii, care oferă perspectivă asupra direcţiilor viitoare de dezvoltare aparţin Sun Microsystems Inc. (Java2 Enterprise Edition), respectiv Microsoft Corp. (.NET Framework Web Services). 1.3 Colaborare Digitală Evoluţia reţelelor de calculatoare şi a Internet-ului a permis apariţia unui nou tip de comunicare interpersonală având ca principală interfaţă calculatorul personal. Poşta electronică a fost prima manifestare în acest sens, urmată la scurt timp de apariţia aplicaţiilor de mesagerie instantă, asigurând infrastructura pentru dezvoltarea comunităţilor on-line. La momentul actual, adoptarea pe scară largă a stilului de viaţă digital încurajează evoluţia fenomenului către o nouă etapă, cea a „reţelelor sociale digitale”. 1.3.1 Poşta Electronică Poşta electronică (e-mail) a apărut şi s-a dezvoltat concomitent cu sistemele informatice, iniţial fiind gândită ca o aplicaţie de mesagerie între utilizatorii aceluiaşi sistem de calcul. Ulterior, acest sistem a fost adaptat pentru a exploata posibilitatea de conectare la reţea a calculatoarelor, permiţând transmiterea mesajelor între utilizatori ai sistemelor de calcul diferite. Prima aplicaţie e-mail care utiliza conectivitatea la reţea a fost dezvoltată în 1971 folosind ARPANET, de către Ray Tomlinson (BBN Technologies), în timp ce lucra pentru Cambridge. Programul intitulat SNDMSG a fost scris pentru platforma TENEX, un sistem de operare de tip timesharing dezvoltat de BBN pentru DEC PDP-10. SNDMSG reprezenta combinarea altor două aplicaţii, prima dintre acestea fiind destinată mesageriei intra-computer, 1616
  17. 17. Introducere iar cea dea doua reprezentând un program de filesharing numit CPYNET. Primul mesaj a fost trimis de Tomlinson către el însuşi pe alt calculator, iar conţinutul mesajului este necunoscut (posibil „qwertyuiop” sau „testing 1-2- 3”). Cel de-al doilea mesaj, expediat către ceilalţi utilizatori ai reţelei, a beneficiat de un conţinut mai interesant, în care Tomlinson explica utilizarea SNDMSG prin sufixarea numelui utilizatorului cu „@hostname”, standard de adresare folosit şi astăzi. Lansarea comercială a serviciului de e-mail a avut loc în 1988, când Vinton Cerf, om de ştiinţă afiliat DARPA (în 1972 ARPA devine DARPA), coautor al specificaţiei TCP/IP, aranjează conectarea MCI Mail la NSFNET (National Science Foundation Network) prin CNRI (Corporation for the National Research Initiative), în scop experimental, aceasta constituind prima utilizare comercială a Internet-ului. În 1989 CompuServe este conectat la NSFNET prin reţeaua University of Ohio, iar e-mail-ul devine accesibil publicului larg. Cu toate acestea, adevătata explozie a tehnologiei e-mail va avea loc la 5 iunie 1996, momentul lansării HoTMaiL, sit Web care oferea servicii gratuite de e-mail, creaţie a lui Sabeer Bhatia. Se introduce astfel conceptul de Web- mail. Potenţialii competitori observă popularitatea perpetuu ascendentă a fenomenului şi decid să intervină. Astfel, aproape orice portal Web modern oferă acces gratuit utilizatorilor la o adresă de e-mail, calitatea serviciilor este îmbunătăţită constant, iar cantitatea spaţiului de stocare oferit utilizatorilor se află într-o continuă creştere, culminând în 2005 cu atingerea cotei de 2,2 gigaocteţi (GB) pentru utilizatorii Gmail, viziunea Google asupra e-mail-ului. Ca indicator al popularităţii acestui gen de comunicare interpersonală se estimează faptul că, în medie, 50% din timpul petrecut on-line de un utilizator are legătură directă sau indirectă cu e-mail-ul. 1.3.2 Mesagerie Instantă Nevoia de comunicare rapidă între utilizatorii aflaţi on-line va da naştere unui nou sistem de transmisie a mesajelor, numit „mesagerie instantă” (eng. instant messaging, IM). Tentativele de realizare a unui asemenea sistem datează tot din perioada ARPANET, însă primul eveniment de importanţă majoră pentru acest fenomen va fi lansarea în noiembrie 1996 de către Mirabilis, a serviciului ICQ (I Seek You), serviciu public de mesagerie instantă. Anterior furnizorul american de servicii Internet, AOL (America On Line) oferea un serviciu similar abonaţilor săi, însă lansarea ICQ oferă acest tip de serviciu oricărui utilizator al Internet-ului lansând o explozie a acestei metode de interacţiune digitală. Ca şi în cazul serviciilor de Web mail popularitatea mesageriei instante a condus la implementarea mai multor astfel de sisteme, astăzi cele mai importante fiind AIM (AOL), MSN Messenger (Microsoft Network, MSN) şi Yahoo! Messenger (Yahoo!). Un aspect problematic este acela că fiecare dintre sistemele existente utilizează un format de comunicaţii proprietar care nu permite interoperabilitatea cu alte sisteme similare. Există aplicaţii client care implementează mai multe formate de mesagerie instantă (e.g., Trillian, Kopete etc), simulând astfel un grad de interoperabilitate. De asemenea, există o iniţiativă de implementare a unui standard bazat pe XML cunoscut ca XMPP (eXtensible Messaging and Presence Protocol), popular cunoscut ca Jabber. Jabber simplifică natura aplicaţiilor client, transferând responsabilitatea interoperabilităţii către server, însă această abordare nu 1717
  18. 18. Introducere reprezintă o soluţie viabilă în contextul interoperabilităţii caracterictice viziunii Web-ului semantic. 1.3.3 Comunităţi On-line O comunitate reprezintă un set de persoane sau agenţi, într-un sens mai abstract, care prezintă un element comun, specific. În particular, o comunitate reprezintă un grup de persoane aflate într-o formă de interacţiune. Comunităţile virtuale (on-line), reprezintă o transpunere digitală a unei comunităţi, în acest caz elementul comun fiind, în general, un interes comun, iar principala formă de interacţiune între membrii acestui tip de comunitate fiind asigurată de schimbul de informaţii. Dezvoltarea Internet-ului, a poştei electronice şi a sistemelor de mesagerie instantă asigură infrastructura ideală pentru acest tip de comunitate, iar avantajul principal este eliminarea graniţelor spaţiale care facilitează colaborarea. 1.3.4 Reţele Sociale Digitale O „reţea socială” constituie o reprezentare a relaţiilor dintre indivizi, indicând natura legăturilor dintre aceştia (e.g., familie, coleg, cunoştinţă etc). Termenul de „reţea socială” a fost introdus în 1945 de J. A. Barnes, într-un studiu ce trata natura relaţiilor interumane. Deşi prezenta lucrare nu are ca scop detalierea acestui aspect, vom menţiona faptul că analiza reţelelor sociale, cunoscută sub denumirea de „teorie a reţelelor” (eng. network theory), s-a impus ca tehnică de bază în ştiinţele sociale moderne, demonstrând dinamica reţelelor sociale pe mai multe nivele, de la cel familial, la cel organizaţional şi respectiv, naţional. Dinamica reţelelor sociale joacă un rol important în determinarea manierelor de rezolvare a problemelor, de conducere a organizaţiilor, cu implicaţii directe asupra gradului în care indivizii unei asemenea reţele au succes în realizarea obiectivelor propuse. Pentru a reprezenta reţelele sociale digitale putem considera un graf, ale cărui noduri corespund actorilor, indivizilor aparţinând reţelei, arcele reprezentând relaţiile existente între indivizi. Opţional, arcele pot fi etichetate pentru a reprezenta natura relaţiei existentă între nodurile grafului, respectiv între indivizii implicaţi. Studiul reţelelor sociale relevă faptul că „forma” reţelei sociale, este direct responsabilă de determinarea utilităţii acesteia pentru indivizii implicaţi. Astfel, reţelele compacte, cu legături „scurte” şi puternic redundante, sunt mai puţin utile membrilor acestora, iar reţelele sociale „largi”, cu multiple legături „slabe” (conexiuni către indivizi din exteriorul centrului reţelei), permit introducerea unui grad sporit de idei, inovaţii şi oportunităţi, în benficiul tuturor membrilor acestora. Cu alte cuvinte, un grup apropiat de indivizi puternic conectaţi intr-o reţea socială compactă deja împărtăşesc majoritatea cunoştinţelor (eng. common knowledge) şi, implicit, a oportunităţilor disponibile. În paralel, un grup de indivizi cu multiple conexiuni slabe către alte reţele sociale are acces la o masă mai mare de informaţii şi cunoştinţe disponibile în cadrul tuturor reţelelor sociale cu care se află în contact (eng. shared knowledge). Din perspectiva individului, este mai profitabilă exploatarea unei cantităţi mai mici de conexiuni cu reţele diferite, decât exploatarea unei cantităţi mari de conexiuni cu aceeaşi reţea. Un aspect important în extinderea reţelelor sociale 1818
  19. 19. Introducere sunt indivizii cu conexiuni la multiple reţele sociale, aceştia intermediind interacţiunea reţelelor din care fac parte, facilitând crearea de noi conexiuni. Revenind, aspectul „reţelelor sociale digitale” care face obiectul prezentei lucrări se referă la o categorie de aplicaţii care utilizează Internet-ul pentru a realiza o conectare interactivă între prieteni, cunoştinţe, parteneri de afaceri sau alte categorii de indivizi. În capitolul trei al prezentei lucrări se vor detalia principiile unui nou tip de aplicaţie a „reţelelor sociale” în lumea digitală, prin introducerea conceptului de „reţea socială digitală ubicuă”. 1919
  20. 20. 2. .NET Framework Prezent şi Viitor 2020
  21. 21. .NET Framework – Prezent şi Viitor 2.1 Rezumat Apărută oficial în 2002, .NET Framework se află acum în pragul lansării celei dea treia versiuni finale, având indicativul 2.0. Pe scurt, .NET Framework este o parte integrantă a sistemelor de operare din familia Windows® care permite dezvoltarea şi rularea noilor generaţii de aplicaţii şi servicii Web bazate pe XML (XML Web Services). Obiectivele principale ale acestei platforme sunt acelea de a oferi un mediu consistent pentru programarea orientată obiect fie că acel cod este destinat execuţiei locale, distribuţiei prin intermediul Internet-ului sau execuţiei la distanţă (eng. remote execution), de a permite execuţia codului cu minimizarea eforturilor de implementare (eng. deployment) şi cu eliminarea conflictelor între versiuni, de a asigura execuţia „în siguranţă” a aplicaţiilor, inclusiv a acelor aplicaţii create de terţe entităţi (eng. third-parties), de a elimina problemele legate de performanţă prezente în cazul aplicaţiilor interpretate sau de tip script şi de a realiza comunicarea între aplicaţii pe baza standardelor industriei de specialitate, asigurand posibilitatea de interoperabilitate cu aplicaţii dezvoltate folosind alte tehnologii. Principalele două componente ale .NET Framework sunt runtime-ul CLR (Common Language Runtime) şi biblioteca de clase .NET (eng. class library). CLR-ul reprezintă fundamentul platformei .NET, putând fi privit ca un agent care gestionează execuţia codului, asigurând serviciile fundamentale necesare (eng. core services) precum gestiunea memoriei, a firelor de execuţie (eng. thread) şi a execuţiei la distanţă (eng. remoting). Simultan CLR-ul impune adoptarea unor politici de siguranţă a tipurilor (eng. type-safety) şi a altor „restricţii” la nivel de cod executabil pentru a asigura un mediu robust şi de încredere (eng. trustworthy environment). De altfel, conceptul de management al codului este un principiu fundamental al .NET Framework, motiv pentru care codul nativ .NET este cunoscut sub denumirea de cod gestionat, iar codul care se execută „în exteriorul” platformei, sub denumirea de cod negestionat (eng. managed code vs. unmanaged code). Cea de-a doua componentă de bază a platformei .NET este biblioteca de clase .NET – o colecţie de tipuri reutilizabile orientate obiect care pot fi folosite pentru dezvoltarea tuturor aplicaţiilor .NET, de la aplicaţii tradiţionale ce folosesc linia de comandă sau interfaţa grafică a sistemului de operare (eng. GUI) până la aplicaţii care folosesc cele mai noi tehnologii, precum ASP.NET WebForms sau ASP.NET XML Web Services. Un alt aspect care trebuie luat în considerare este reprezentat de capacitatea runtime-ului .NET de a fi găzduit (eng. hosted) de o aplicaţie sau componentă unmanaged. Procesul de execuţie unmamaged încarcă CLR-ul în propriul proces şi poate astfel iniţia execuţia de cod managed. Se crează astfel un mediu de execuţie care poate exploata soluţii eterogene, compuse din aplicaţii unmanaged si din cod nativ .NET. Un exemplu de aplicaţie unmanaged care acţionează ca host pentru runtime-ul .NET în scenarii foarte frecvente este Internet Explorer®. Acesta „găzduieşte” CLR-ul sub forma unei extensii MIME, permiţand vizualizarea componentelor managed incluse în documentele HTML. 2121
  22. 22. .NET Framework – Prezent şi Viitor Acest model de execuţie face posibilă existenţa noţiunii de „cod mobil” intr-un mod similar cu cel oferit de tehnologia ActiveX®, dar cu imbunătăţiri semnificative la nivel de siguranţă a execuţiei, într-un mediu „parţial de încredere” (eng. semi-trusted). Figura 6 ilustrează relaţiile dintre CLR, .NET class library, aplicaţii şi sistemul de operare, totodată exemplificând abilitatea de interacţiune a codului unmanaged cu codul .NET, scopul final fiind acela de a realiza un nou sistem interoperabil, fiabil şi robust. Figura 6. Integrarea .NET Famework în sistemul de operare şi interacţiunea dintre aplicaţii. 2.1.1 CLR (Common Language Runtime) CLR-ul gestionează memoria, firele de execuţie, execuţia codului, verificarea nivelului de siguranţă al codului, compilarea şi alte servicii ale sistemului. Aceste funcţionalităţi sunt intrinseci codului managed care rulează „peste” CLR. La nivel de securitate, componentele managed primesc diverse grade de încredere (eng. degrees of trust), depinzând de un număr de factori, printre care şi originea codului (e.g., Internet, reţea enterprise, sistem local etc). Rezultă de aici faptul că o componentă managed poate sau poate să nu fie capabilă să realizeze anumite operaţiuni (e.g., acces la sistemul de fişiere, acces la registry etc) chiar dacă aplicaţia din care face parte este activă. Runtime-ul „impune” anumite politici de securitate la nivel de acces al codului executat. 2222
  23. 23. .NET Framework – Prezent şi Viitor Exemplul clasic este cel al executabilului inclus (eng. embedded) intr-o pagină Web care deţine permisiunile necesare renderizării unei animaţii, dar care nu poate accesa date personale, cu caracter privat, despre utilizatorul sistemului, despre sistem sau despre reţea. Funcţionalităţile .NET privind siguranţa permit deci software-ului „legitim”, accesibil via Internet implementarea unui set bogat de funcţii, eliminând riscul ca aceste funcţii să poată fi folosite în scopuri negative (eng. mallicious purposes). 2.1.1.1 CTS (Common Type System) De asemenea, runtime-ul .NET impune caracterul robust al codului prin implementarea unei infrastructuri de verificare strictă a codului şi a tipurilor utilizate (eng. type-and-code-verification infrastructure) numită common type system (CTS). CTS-ul impune codului managed anumite proprietăţi de auto- descriere (eng. self-describing code). Diversele compilatoare Microsoft® sau ale unor terţe entităţi generează cod managed conform cu specificaţiile CTS- ului. Acest fapt se traduce prin posibilitatea codului managed de a consuma tipuri (clase) şi instanţe (obiecte) managed, impunând simultan mai multe grade de siguranţă şi de fidelitate a tipurilor (eng. type fidelity, type safety). Revenind la funcţionalităţile CLR-ului, mediul managed asigurat de runtime elimină multe probleme comune ale software-ului (eng. common software issues). De exemplu, prin capacitatea de manipulare automată a dispunerii obiectelor şi a referinţelor la acestea (eng. object layout, object reference) se rezolvă două dintre cele mai comune defecte ale aplicaţiilor – „scurgerile” de memorie şi referinţele invalide (eng. memory leaks, invalid memory references). Un alt aspect foarte important al .NET Framework asigurat de CLR este reprezentat de accelerarea productivităţii dezvoltării prin posibilitatea utilizării „oricărui” limbaj de programare fără a renunţa la avantajele platformei şi prin posibilitatea utilizării în cadrul aplicaţiei dezvoltate, a unor componente „scrise” folosind alt limbaj de programare. Se facilitează astfel migrarea aplicaţiei către .NET Framework sau implementarea de noi funcţionalităţi bazate pe .NET. Încă o facilitate importantă este aceea că, deşi .NET Framework este o platformă destinată aplicaţiilor software ale viitorului, aceasta oferă suport pentru interacţiunea cu software-ul actual şi cu cel al trecutului, interoperabilitatea fiind una dintre cele mai importante caracteristici asigurate de .NET. Interoperabilitatea dintre codul managed şi codul unmanaged dă posibilitatea dezvotatorilor de software să continue să utilizeze componentele COM şi DLL-urile necesare, implementate anterior. .NET Framework a fost concepută având permanent în vedere considerente de performanţă. Astfel, deşi CLR-ul furnizează multe servicii de runtime, codul managed nu este cod interpretat. Codul sursă „scris” in oricare dintre cele peste 30 de limbaje de programare disponibile este compilat intr- un assembly conţinând limbaj intermediar (MSIL). După compilare, o altă funcţionalitate a CLR-ului numită compilare just-in-time (JIT) asigură „traducerea” codului managed în limbajul nativ al sistemului host. 2323
  24. 24. .NET Framework – Prezent şi Viitor Simultan, modulul de management al memoriei „elimină” posibilitatea fragmentării memoriei şi asigură un nivel ridicat la localizării referinţelor (eng. memory locality-of-reference) pentru îmbunătăţirea performanţei aplicaţiei. De asemenea, o capabilitate imposibil de neglijat a platformei .NET este aceea de integrare în aplicaţii server-side de înaltă performanţă (e.g., Microsoft® SQL Server™, IIS - Internet Information Services™). Această infrastructură permite utilizarea codului managed pentru a „scrie” logica business a aplicaţiei, fără a renunţa la avantajele la nivel de performanţă ale unor aplicaţii server din segmentul enterprise. 2.1.2 Class Library Biblioteca de clase .NET Framework reprezintă o colecţie de tipuri reutilizabile integrată „puternic” (eng. tightly) în CLR. Biblioteca de clase este orientată obiect, furnizând tipuri (clase) cu ajutorul cărora propriul cod managed poate obţine funcţionalitate. Principalele obiective avute in vedere în design-ul acestei componente a platformei sunt legate de imbunătăţirea productivităţii dezvoltării aplicaţiilor, prin oferirea unui suport consistent şi uşor de învăţat. În plus, componentele realizate de terţe entităţipot fi integrate „fără efort” propriilor clase (eng. seamless integration). Un exemplu, este reprezentat de clasele „colecţie” (eng. collection) care implementează un set de interfeţe care pot fi folosite în dezvoltarea propriilor clase colecţie, asigurand „comunicare” fără efort cu clasele native .NET (eng. seamless blending). Cum ne puteam aştepta de la orice bibliotecă de clase orientată obiect, tipurile .NET Framework permit realizerea tuturor activităţilor comune limbajelor de programare, incluzând managementul string-urilor, al colecţiilor de date, al conectării la bazele şi la sistemul de fişiere. Adiţional, biblioteca .NET include tipuri care suportă o varietate de scenarii de dezvoltare specializate. Exemplele de aplicaţii pe care le putem dezvolta folosind tipurile oferite de biblioteca de clase .NETinclud, dar nu se limitează la: • Aplicaţii consolă. • Aplicaţii cu interfaţă Windows® (GUI) folosind Windows Forms. • Aplicaţii Web flosind ASP.NET şi Web Forms. • Servicii Web XML folosind ASP.NET. • Servicii Windows®. 2.1.3 Dezvoltare Aplicaţii Client Aplicaţiile client sunt cele mai apropiate de noţiunea tradiţională de aplicaţie nativă sistemelor Windows® şi modelului de programare implicat. Aceste aplicaţii permit vizualizarea ferestrelor interfeţei grafice, permiţând utilizatorului realizarea acţiunilor dorite. Aplicaţiile client pot varia de la procesoare de text, vizualizatoare de documente cu diferite formate sau alte aplicaţii de birotică, până la aplicaţii business care manipulează date („inteligenţă”) în scopul stocării, creării de rapoarte etc (eng. data-driven applications, business intelligence aplications etc). Interfaţa aplicaţiilor client este compusă din ferestre meniuri, butoane, câmpuri de introducere a datelor şi alte elemente grafice şi, de obicei, pot accesa resurse locale, precum sistemul de fişiere sau echipamentele periferice (e.g., imprimante etc). Un alt tip de aplicaţie cu caracter tradiţional este reprezentat de controalele de tip 2424
  25. 25. .NET Framework – Prezent şi Viitor ActiveX® (înlocuite de cod managed şi controale Windows Forms) accesibile prin intermediul Internet-ului sub formă de pagini Web. Acest gen de aplicaţie respectă deplin modelul aplicaţiei client, execuţia fiind locală cu potenţial acces la resurse locale, prezentarea folosind elemente de interfaţă grafică. În trecut, acest gen de aplicaţie era dezvoltat folosind C/C++, cu ajutorul tehnologiilor de gen Microsoft® Foundation Classes (MFC) sau cu ajutorul unui mediu RAD (Rapid Application Developement) precum Microsoft® Visual Basic®. .NET Framework încorporează toate aspectele conceptuale ale acestor tehnologii, într-un mediu de dezvoltare consistent, simplificând „drastic” realizarea de aplicaţii client. Clasele Windows Forms aparţinând bibliotecii .NET Framework au fost concepute pentru a facilita dezvoltarea aplicaţiilor care „beneficiază” de prezenţa unei interfeţe grafice (GUI), toate acestea într-o manieră pur orientată obiect, bazată pe proprietăţi care ajustează aspectul şi comportamentul elementelor grafice. Facilităţile depăşesc graniţa vizuală, în anumite cazuri, spre exemplu, fiind necesară regenerarea dinamică a form-ului de către platformă, pentru a acomoda anumite modificări, deoarece sistemul de operare peste care rulează aplicaţia nu permite modificarea directă a unor anumite proprietăţi vizuale sau de comportament. Acest set de capabilităţi „ascunse” permit îmbunătăţirea drastică a calităţii experienţei de dezvoltare software şi asigurarea unui mediu consistent şi robust. Spre deosebire de controalele ActiveX®, controalele Windows Forms deţin privilegii pentru accesul semi-trusted la sistemul utilizatorului. Acest fapt permite executarea „în siguranţă” a codului nativ cu acces la resursele sistemului local fără riscul de compromitere a altor resurse potenţial confidenţiale, de importanţă pentru utilizator. Datorită acestui sistem de seurizare a accesului codului managed, se facilitează livrarea via Internet/Web a unor aplicaţii care în trecut necesitau instalare pe sistemul utilizatorului (eng. deployment). Aplicaţiile client pot implementa funcţionalităţi caracteristice unei aplicaţii instalate local deşi accesul utilizatorului la aplicaţie este asigurat prin intermediul unei pagini Web. 2.1.4 Dezvoltare Aplicaţii Server Aplicaţiile server sunt implementate folosind host-uri pentru runtime-ul .NET. Aplicaţii unmanaged acţionează ca „gazdă” pentru CLR, acest fapt permiţând codului managed control asupra comportamentului serverului. Acest model face accesibile toate facilităţile .NET CLR, CTS şi class library asigurând simultan performanţa şi scalabilitatea soluţiei server. Figura 7 ilustrează capacitatea CLR-ului de a executa cod managed din postura de guest pentru diferite medii server host. Diferite aplicaţii server pe care experienţa le-a impus ca standard al industriei, precum Microsoft® Internet Information Services™ şi Microsoft® SQL Server™ pot realiza operaţiuni standard în timp ce logica aplicaţiei se execută prin cod managed. 2525
  26. 26. .NET Framework – Prezent şi Viitor Figura 7. Mecanismul unmanaged server host/managed guest. ASP.NET este platforma suport pentru dezvoltarea şi execuţia aplicaţiilor şi serviciilor Web ce au ca ţintă .Net Framework. Acestea fiind spuse, trebuie menţionat faptul că ASP.NET reprezintă mai mult decât un runtime gazdă; reprezintă o arhitectură completă pe baza căreia se pot dezvolta soluţii Web , incluzănd site-uri Web, servicii Web bazate pe XML şi obiecte distribuite via Web care execută cod managed. Atât componentele Web Forms, cât şi serviciile Web bazate pe XML utilizează infrastructura IIS/ASP.NET pentru a realiza mecanismele de „publicare” (eng. publishing) şi execuţie a aplicaţiilor, ambele beneficiind de namespace-uri de clase specializate în biblioteca .NET Framework. Serviciile Web bazate pe XML reprezintă o importantă evoluţie a tehnologiilor Web (eng. Web-based technology). Acest tip de aplicaţie se execută pe server (eng. server-side) şi conţine componente similare cu cele ale unui sit Web obişnuit (aplicatie Web). Diferenţele sunt însă mari, serviciile Web prezentând componente fără interfaţă utilizator (UI) accesibilă via aplicaţii navigator (eng. browser). În schimb, serviciile Web se constituie din colecţii de componente reutilizabile destinate „consumului” de către alte aplicaţii, cum ar fi aplicaţii client tradiţionale, aplicaţii Web, sau chiar alte servicii Web. Ca rezultat, tehnologia serviciilor Web accelerează transferul aplicaţiilor uzuale către zona aplicaţiilor distribuite via Internet. 2.1.4.1 ASP.NET vs. ASP Făcând o comparaţie între ASP.NET şi versiuni anterioare ale tehnologiilor Web, vom observa imediat îmbunătăţirile calitative şi de performanţă pe care le introduc noile facilităţi (e.g., Web Forms etc). Un exemplu clar este cel al tehnologiei ASP (Active Server Pages), precursoare a ASP.NET. În cazul ASP.NET este posibilă dezvoltarea aplicaţiilor Web folosind oricare dintre cele peste 30 de limbaje de programare suportate de .NET Framework, faţă de ASP, care permitea folosirea a doar două. În plus, codul scris în limbajul de programare adoptat se află într-un fişier special dedicat acestuia, total separat de fişierul ce conţine codul HTML (se poate opta şi pentru includerea codului sursă în fişierul conţinând codul HTML, în 2626
  27. 27. .NET Framework – Prezent şi Viitor funcţie de preferinţele utilizatorului). Se realizează astfel o separare completă a nivelului de prezentare al aplicaţiei, de nivelul logic, funcţional. Acest fapt are efecte pozitive şi asupra productivităţii aplicaţiilor Web, asigurând o mai bună interacţiune între programator şi designer. Pe langă o îmbunătăţire a calităţii experienţei de dezvoltare şi a productivităţii, marele avantaj al paginilor Web Forms este dat de îmbunătăţirile de performanţa aduse prin compilarea codului sursă într-un assembly conţinând cod intermediar (MSIL) şi metadate, acesta executându-se în formatul nativ al sistemului host, prin compilarea just-in-time (JIT), într-o manieră similară oricărui alt cod managed. Se permite astfel accesul aplicaţiilor Web la funcţionalitatea şi avantajele .NET Framework. În contrast, codul unmanaged al paginilor ASP este întotdeauna scriptat şi interpretat (eng. scripted, interpreted). Astfel, aplicaţiile ASP.NET sunt mai rapide, mai funcţionale şi mai confortabil de dezvoltat decât aplicaţiile unmanaged care folosesc tehnologii ASP sau orice tehnologii similare (e.g., PHP etc). Revenind la suportul pentru servicii Web oferit de .NET trebuie menţionată existenţa unei colecţii de clase şi instrumente (eng. tools) care facilitează dezvoltarea şi consumarea serviciilor Web bazate pe XML. Serviciile Web sunt construite pentru a utiliza şi respecta standarde ale industriei, precum SOAP (un protocol care utilizează paradigma RPC pentru transmisia de date folosind un subset al XML), XML (un format de date extensibil, recomandare a W3C) şi WSDL (Web Services Description Language, un limbaj bazat pe XML, folosit la descrierea capabilităţilor serviciilor Web pentru a facilita consumul acestora de către aplicaţii). Motivul principal al construirii .NET Framework într-o manieră în care se utilizează şi se respectă standardele industriei este dat de necesitatea de interoperabilitate între diferite soluţii software precum şi nevoia de accesare a plicaţiilor din medii hardware eterogene. Spre exemplu, aplicaţia de suport pentru WSDL inclusă în kit-ul de dezvoltare .NET (.NET Framework SDK) poate interoga un serviciu Web publicat şi, prin parsarea descrierii WSDL obţinute, poate produce cod C#™ (eng. see sharp) sau Visual Basic® .NET, cod pe care orice aplicaţie îl poate utiliza pentru a deveni client al respectivului serviciu Web. Acest cod sursă implementează clase derivate din clase aparţinând bibliotecii de clase .NET care pot realiza comunicarea „de dedesubt” (eng. underlying communication) folosind SOAP şi XML. Într-un scenariu de dezvoltare şi publicare al propriului serviciu Web, .NET Framework oferă acces la un set de clase conforme standardelor de comunicare underlying, precum SOAP, WSDL şi XML. Folosirea acestor facilităţi permite concentrarea eforturilor de dezvoltare către logica aplicaţiei, fără preocupari adiţionale vis-a-vis de infrastructura de comunicare necesară dezvoltării aplicaţiilor distribuite via Internet/Web. 2727
  28. 28. .NET Framework – Prezent şi Viitor 2.2 Inovaţii ale .NET Framework 2.0 Microsoft® .NET Framework versiunea 2.0 Beta extinde versiunea 1.1 a platformei .NET adăugând noi facilităţi, îmbunătăţiri ale facilităţilor existente şi îmbunătăţiri ale documentaţiei aferente. Această secţiune a prezentei lucrări îşi propune enumerarea succintă a celor mai importante modificari şi îmbunătăţiri. 2.2.1 Îmbunătăţiri şi Modificări x86-64 Noile generaţii de calculatoare folosesc arhitecturi pe 64 de biţi (x86-64) care facilitează execuţia mai rapidă a aplicaţiilor şi oferă capacitatea de a adresa o cantitate mai mare de memorie. Începand cu această versiune .NET Framework permite dezvoltarea şi execuţia de aplicaţii managed care să „profite” de avantajele arhitecturii x86-64. Access Control List O listă de control a accesului (ACL) este utilizată pentru a oferi sau a revoca anumite permisiuni de acces asupra unei resurse existente pe sistemul host. Noi clase au fost adăugate în biblioteca .NET Framework care permit codului managed creerea şi modificarea ACL-urilor. Noi membri ce utilizează ACL au fost adăugaţi în registrul I/O (eng. I/0 registry) şi în clasele care gestionează sau utilizează fire de execuţie (eng. threading classes). ADO.NET Noile facilităţi incluse în ADO.NET includ suport pentru tipuri definite de utilizator (eng. user-defined types, UDT), operaţii asincrone asupra bazelor de date, tipuri de date XML, tipuri ce permit manipularea valorilor mari şi noi atribute ce permit aplicaţiilor capacitatea de suport a seturilor de rezultate active multiple (eng. multiple active result sets, MARS) în corelaţie cu SQL Server™ 2005. ASP.NET Microsoft® .NET Framework 2.0 Beta include îmbunătăţiri semnificative asupra tutror aspectelor aplicaţiilor ASP.NET. Există un set de noi controale care fac posibilă realizarea rapidă a task-urilor comune în cazul dezvoltării aplicaţiilor Web. Noile controale destinate datelor fac posibilă afişarea şi editarea informaţiilor conţinute într-o pagină Web fără a scrie cod. Un model îmbunătăţit pentru fişierele de cod asociate paginilor Web (eng. code-behind files) asigură dezvoltarea mai rapidă a aplicaţiilor. De asemenea, au fost introduse noi modalităţi de gestiune a caching-ului, inclusiv abilitatea de a construi dependenţa cache-ului în funcţie de datele din tabelele incluse în bazele de date utilizate de aplicaţie (SQL Server™). Au fost introduse de asemenea, mecanisme de personalizare (eng. customize) a paginilor şi siturilor Web accesibile via proprietăţi de profil utilizator. Acest mecanism permite runtime-ului ASP.NET să identifice automat valori ale proprietăţilor din profilele utilizatorilor. 2828
  29. 29. .NET Framework – Prezent şi Viitor O nouă funcţionalitate a ASP.NET, numită Web Parts, permite realizarea de aplicaţii pe care utilizatorii le pot modifica/personaliza direct în navigator. Paginile şablon (eng. master pages) permit realizarea unui layout consistent pentru toate paginile Web ale sitului, iar temele (eng. themes) permit realizarea unui look consistent pentru controale şi text. Pentru facilitarea protecţiei sit-ului, există acum posibilitatea precompilării aplicaţiei Web (atât a codului sursă, cât şi a fişierelor markup) pentru a produce cod executabil, îmbunătăţind drastic şi performanţa execuţiei. Codul astfel obţinut poate fi „găzduit” de IIS. Îmbunătăţirile ASP.NET includ, de asemenea, noi instrumente şi clase care facilitează managementul siturilor Web. Un alt aspect care a fost îmbunătăţit se referă la capacitatea ASP.NET de a viza o gamă largă de navigatoare şi dispozitive (eng. browsers, devices). Setările default ale ASP.NET renderizează output compatibil standardului XHTML 1.1, dar se pot folosi filtre pentru a facilita renderizarea aceluiaşi conţinut cu diferite proprietăţi specifice anumitor navigatoare. Autentificarea fluxurilor (eng. stream authentication) Aplicaţiile pot folosi noile clase NegotiateStream şi SslStream pentru autentificare şi pentru a facilita transmiterea de informaţii securizate. Aceste clase de autentificare a fluxurilor suportă autentificarea mutuală, criptarea datelor transmise (eng. data encryption) şi „semnarea” datelor (eng. data signing). Pentru autentificare, clasa NegotiateStream utilizează protocolul de securitate Negotiate, iar clasa SslStream utilizează protocolul de securitate SSL (Secure Socket Layer). COM Interop Patru mari îmbunătăţiri au fost introduse pentru clasele şi instrumentele care asigură interoperabilitatea dintre .NET Framework şi COM. Cea mai importantă are ca ţintă capacitatea de manipulare a handle- urilor menţinute de sistemul de operare. Sistemul de operare menţine un număr limitat de handle-uri folosite pentru a referenţia resurse critice. Noile clase SafeHandle şi CriticalHandle, precum şi clasele specializate derivate din acestea asigură metode sigure de manipulare a handle-urilor sistem. O a doua îmbunătăţire se referă la mecanismul de marshaling care facilitează interoperabilitatea cu codul nativ. Două modificări majore ale marshaler-ului adresează două dintre cele mai comune necesităţi ale dezvoltatorilor: abilitatea de „împachetare” (eng. wrapping) pointerilor la funcţii native în delegate-uri şi capacitatea de marshaling a şirurilor de dimensiune fixă conţinând structuri de structuri. A treia modificare majoră adresează performanţa apelurilor dintre aplicaţii aflate în domenii de aplicaţie diferite, aceasta fiind acum mult mai rapidă pentru apelurile tipurilor comune (eng. common call types). Şi, nu în ultimul rând, au fost introduse noi opţiuni (eng. switches) pentru Type Library Importer (Tlbimp.exe) şi Type Library Exporter (Tlbexp.exe) pentru a elimina dependenţa de regiştri (eng. registry) pentru a rezolva referinţele la bibliotecile de tipuri (eng. type library references). 2929
  30. 30. .NET Framework – Prezent şi Viitor Clasa Console Noii membri ai clasei Console permit aplicaţiilor un mai mare grad de libertate în manipularea proprietăţilor acesteia, precum dimensiunile ferestrei consolă şi a buffer-ului ecran, parametrii mişcării zonelor rectangulare pentru realizarea fină a animaţiilor simple, timpul de aşteptare cu citire a input-ului până la apăsarea unei taste etc. DPAPI (Data Protection API) Noua interfaţă de programare vizând protecţia datelor (DPAPI) include patru metode care permit aplicaţiilor criptarea parolelor, a cheilor, a string- urilor de conectare (eng. connection string) etc, fără apeluri de tip PInvoke (Platform Invoke). Este posibilă de asemenea criptarea blocurilor de memorie pentru maşini care rulează Windows® Server™ 2003. Debugger Edit and Continue .NET Framework 2.0 Beta reintroduce capacitatea de editare şi continuare a execuţiei în timpul procesului de depanare (eng. debugging) a aplicaţiei dezvoltate. După editarea codului execuţia poate fi reluată, utilizatorul având astfel capacitatea de a urmări exact efectul modificărilor codului sursă. Mai mult, prin includerea în platformă acestui mecanism este posibilă utilizarea sa în oricare dintre limbajele de programare suportate de Visual Studio®. Detecţia modificărilor stării conectivităţii reţelei Clasa NetworkChange permite aplicaţiilor recepţionarea notificărilor referitoare la modificări ale stării interfeţei reţea la nivel IP (Internet Protocol). Defecţiunile hardware, deconectarea cablului de reţea, reconfigurarea via DHCP (Dynamic Host Control Protocol) sau părăsirea razei de acţiune a unui punct de acces WiFi pot fi cauze ale modificărilor adresei IP ale unei interfeţe reţea, iar aplicaţiile pot folosi clasa NetworkChange, pentru a fi notificate de aceste schimbări şi a putea acţiona în consecinţă. Cereri disjunctive (eng. disjunctive demands) În versiunile anterioare ale .NET Framework, nu exista opţiunea accesului la o clasă sau la o metodă, de către multiple identităţi cod (eng. code identities). De exemplu, doar un singur „nume tare” (eng. strong name) putea fi cerut la un moment dat, fapt care crea o problemă în scenarii în care se testau mai multe assembly-uri strong-named provenind din diferite surse. Era, deci necesară o modalitate de combinare a identităţilor mai multor elemente (spre exemplu, folosind un SAU logic pe biţi). Astfel, s-au creat noi acţiuni disjunctive de securitate care permit cererea simultană, cererea via moştenire sau cererea via legătură a permisiunilor asociate unor identităţi multiple. În cazul assembly-urilor strong-named, folosirea acţiunii DemandChoice permite cererea mai multor identităţi strong-named, prezenţa oricăreia dintre acestea permiţând parcurgerea cu succes a stivei. Cele trei noi acţiuni de securitate care permit cereri disjunctive sunt DemandChoice, InheritanceDemandChoice şi LinkDemandChoice. 3030
  31. 31. .NET Framework – Prezent şi Viitor Distributed Computing În namespace-ul System.Net, a fost adăugat suport pentru cereri client vizând FTP (File Transfer Protocol), pentru caching al resurselor HTTP (Hypertext Transfer Protocol), pentru descoperirea automată a proxy-urilor şi pentru obţinerea de informaţii statistice referitoare la traficul de reţea. System.Net include, de asemenea, o clasă ce oferă funcţionalităţi de bază pentru aplicaţii de tip server Web (HttpWebListener). În plus, clasele generatoare de trafic de reţea au fost instrumentate în vederea output-ului informaţiilor de tracing în scopul depanării şi diagnosticării aplicaţiilor care le utilizează. Noi îmbunătăţiri ale securităţii şi performanţei au fost aplicate claselor System.Net.Sockets.Socket şi System.Uri. În namespace-urile System.Web.Services, a fost adăugat suport pentru SOAP 1.2 şi pentru elemente nullable. În namespace-urile System.Runtime.Remoting.Channels, au fost adăugate funcţionalităţi care asigura securitatea canalelor. Canalul TCP suportă autentificare şi criptare, precum şi câteva noi funcţionalităţi pentru îmbunătăţirea calibrării solicitării (eng. load balancing). EventLog În noua versiune .NET Framework se pot folosi DLL-uri proprii (eng. custom) pentru mesajele, parametrii şi categoriile EventLog. Extinderea capacităţii de gestiune a certificatelor .NET Framework 2.0 Beta include suport pentru depozite, lanţuri şi extensii de certificate X.509. În plus, există posibilitatea semnării şi verificării XML folosind certificate X.509 fără a folosi PInvoke. De asemenea, a fost introdus suport pentru semnături şi criptări folosind standardele PKCS7 (formatul care stă la baza S/MIME - Secure/Multipurpose Internet Mail Extensions pentru semnarea şi criptarea datelor) şi CMS (un superset al standardului PCKS7 disponibil în sistemele de operare din familia Microsoft® Windows® începând cu versiunea 2000). FTP Aplicaţiile pot accesa resurse FTP folosind clasele WebRequest, WebResponse şi WebClient. Generice şi colecţii de generice (eng. generics) .NET Framework 2.0 Beta introduce suport pentru generice în scopul facilitării „scrierii” de cod flexibil şi reutilizabil. Acestea acţionează ca template-uri, permiţând claselor, structurilor, interfeţelor, metodelor şi delegate-urilor să fie declarate şi definite cu specificarea parametrilor de tip generic, specificarea exactă a tipului realizându-se la utilizarea genericului. Diferite namespace-uri precum System.Collections.Generic furnizează clase şi metode generice şi pentru colecţii de „tipuri tari” (eng. strongly typed collections). System.Nullable<T> este reprezentarea generală pentru valori opţionale. Genericele sunt suportate de trei limbaje de programare: Visual Basic, C# şi C++. 3131
  32. 32. .NET Framework – Prezent şi Viitor În plus, mecanismul de reflexie (eng. reflection) a fost extins pentru a permite examinarea şi manipularea tipurilor şi metodelor generice în timpul execuţiei. Pentru identificarea şi obţinerea parametrilor de tip generic, precum şi pentru crearea unui tip specific dintr-un tip generic, noi membri au fost adăugaţi claselor System.Type şi System.Reflection.MethodInfo (e.g., HasGenericArguments, GetGenericArguments, BindGenericParameters etc). Globalizare Cinci noi funcţionalităţi au fost adăugate pentru a oferi un suport înbunătăţit pentru dezvoltarea aplicaţiilor destinate mai multor culturi sau limbaje. Un exemplu este reprezentat de clasa CultureAndRegionInfoBuilder. Encodarea şi decodarea caracterelor Unicode a fost îmbunătăţită prin implementarea unui sistem de revenire, în cazul apariţiei unei exceptii (eng. fallback mechanism) disponibil în diverse clase din namespace-ul System.Text. Membrii clasei UTF8Encoding, responsabilă de realizarea encodării UTF-8 (metoda cea mai des folosită pentru transformarea caracterelor Unicode în octeţi, pentru stocare şi/sau procesare digitală), au fost imbunătăţiţi pentru a obţine un spor de performanţă considerabil. .NET Framework 2.0 Beta suportă cel mai recent standard de normalizare definit de Unicode Consortium. I/O Diverse îmbunătăţiri au fost operate asupra funcţionalităţii şi utilizabilităţii diverselor clase responsabile pentru operaţii I/O. Facilităţile pe care s-a pus accent se referă la citirea şi scrierea fişierelor, la obţinerea informaţiilor despre sistemul de fişiere (e.g., informaţii despre drive-uri etc). O altă facilitate este oferită de namespace-ul System.IO.Compression, care permite citirea şi scrierea datelor folosind standardele GZIP pentru compresie şi decompresie (arhivare/dezarhivare). Activarea via Manifest (eng. manifest-based activation) Această facilitate permite încărcarea şi activarea aplicaţiilor prin folosirea unui manifest. Activarea via manifest este o facilitate necesară pentru suportul aplicaţiilor ClickOnce. În mod normal, o aplicaţie este activată folosind o referinţă la un assembly care conţine principalul punct de acces al acesteia (eng. main entry point). De exemplu, activarea fişierului .exe al aplicaţiei din mediul Windows®, cauzează încărcarea CLR-ului şi apelul punctului de intrare, bine cunoscut, conţinut in assembly-ul corespunzător respectivului fişier .exe. Modelul activării via manifest foloseşte un fişier .manifest, în locul assembly- ului. Acest manifest descrie în totalitate aplicaţia, dependenţele, necesităţile aplicaţiei referitoare la securitate etc. Modelul manifest are câteva avantaje majore faţă de modelul bazat pe assembly, în special în cazul aplicaţiilor Web. .NET Framework Remoting În noua versiune, .NET Framework remoting suportă adrese IPv6 şi interschimbul tipurilor generice. Clasele din namespace-ul 3232
  33. 33. .NET Framework – Prezent şi Viitor System.Runtime.Remoting.Channels.Tcp suportă autentificare şi criptare folosind SSPI (Security Support Provider Interface). Clasele din noul namespace System.Runtime.Remoting.Channels.Ipc permit aplicaţiilor remoting, care se execută pe acelaşi host o comunicare rapidă, fără a folosi infrastructura de reţea. În plus, în noua versiune, se poate configura timpul de viaţă al cache- ului (eng. time-out) şi numărul maxim de reîncercări ale unei metode, acestea îmbunătăţind mult performanţa cluster-elor „la distanţă”, care comunică folosind reţele cu gestiune echilibrată a solicitării (eng. network load-balanced remote clusters). Procesarea cererilor HTTP din interiorul aplicaţiilor Aplicaţiile .NET Framework 2.0 pot utiliza clasa HttpListener pentru a crea un server Web simplu, care să răspundă la cereri HTTP. Acest server va fi activ pe intreaga durată de viaţă a obiectului HttpListener, funcţionând în interiorul aplicaţiei, cu permisiunile acesteia. Excepţii de securitate (eng. security exceptions) Clasa System.Security.SecurityException a fost extinsă în scopul furnizării de date ce facilitează investigarea cauzelor excepţiilor generate din motive de securitate. Noile proprietăţi oferă informaţii despre metoda care a lansat excepţia, primul privilegiu care a fost încălcat, zona sau URL-ul assembly-ului, acţiunea de securitate care a eşuat şi acţiunea de securitate prezentă pe stiva de apeluri care a generat excepţia (e.g., Deny, PermitOnly etc). Suport pentru dispozitive I/O seriale Noua clasă SerialPort furnizează aplicaţiilor abilitatea de accesare a porturilor seriale ale sistemului host şi de comunicare cu dispozitive I/O seriale. Serializare Clasele BinaryFormatter şi SoapFormatter au fost extinse pentru a suporta serializare tolerantă la modificări de versiune (eng. version-tolerant serialization), fapt ce permite deserializarea obiectelor care au fost serializate folosind o versiune diferită de serializare. În plus, în noua versiune a platformei, serializarea XML suportă utilizarea proprietăţilor în locul câmpurilor pentru reprezentarea elementelor schemei, serializarea tipurilor generice şi utilizarea structurii Generic Nullable pentru reprezentarea elementelor nullable. Interfaţa IXmlSerializable suportă generarea de scheme custom, iar SchemaImporterExtension permite controlul generării de cod proxy pentru acces la servicii Web, prin alterarea schemei în timpul importării acesteia. De exemplu, se poate altera codul proxy generat folosind funcţia Add Web Reference a Visual Studio® sau folosind WSDL.exe. De asemenea, noua XML Serializer Generator Tool (Sgen.exe) permite precompilarea codului folosit de clienţii serviciilor Web pentru a serializa 3333
  34. 34. .NET Framework – Prezent şi Viitor informaţia transmisă, îmbunătăţind drastic timpul de pornire al aplicaţiei client. SMTP Folosind clasele din namespace-urile System.Net.Mail şi System.Net.Mime, aplicaţiile pot expedia mesaje e-mail unuia sau mai multor recipienţi folosind modele de prezentare alternative (e.g., text, HTML etc), copii indigo sau copii indigo oarbe (eng. carbon copies, blind carbon copies). Fire de execuţie (eng. threading) .NET Framework 2.0 Beta include posibilitatea numirii evenimentelor de comunicare care depăşesc graniţele proces (eng. cross-process) create doar în cod managed. De asemenea, clasa Semaphore suportă numărarea resurselor (eng. resource counting). Tracing Noua versiune a platformei .NET oferă clase de tracing şi loging al evenimentelor din sistem (e.g., I/O, startup, shutdown etc). Cu toate acestea, volumul imens de date şi diversitatea acestora fac aproape imposibilă analiza informaţiei. Extinderea acestora pentru a suporta filtrarea datelor permit utilizatorului specificarea exactă a tipului informaţiilor ce urmează a fi înregistrate. Servicii Web (eng. Web services) În .NET Framework 2.0 Beta, serviciile Web suportă SOAP 1.2 şi WS-I Basic Profile 1.0 (documentat la http://www.ws-i.org/Profiles/Basic/2003- 08/BasicProfile-1.0a.html). În scenarii în care aplicaţia client consumă mai multe servicii Web care partajează tipuri, codul proxy generat pentru acele servicii Web distribuie aceste tipuri către aplicaţia client. Acest fapt permite clienţilor să interschimbe instanţe ale acelor tipuri partajate între servicii Web. O altă funcţionalitate nou introdusă permite clienţilor apelarea asincronă a metodelor serviciului Web folosind un şablon programatic bazat pe evenimente (eng. event-based programming pattern). Windows Forms ClickOnce reprezintă o nouă tehnică de deployment al aplicaţiilor care pemite distribuirea de aplicaţii Windows cu capabilităţi de auto-actualizare (eng. self-updating) care pot fi instalate şi executate într-o manieră simplă până acum caracteristică doar aplicaţiilor Web. Application settings pentru aplicaţii Windows Forms face posibilă crearea, stocarea şi menţinerea setărilor aplicaţiilor şi a preferinţelor utilizatorilor (e.g., poziţia elementelor interfeţei utilizator etc). Noul model de conectare la baze de date este simplificat de introducerea componentei DataConnector, aceasta acţionând ca intermediar între controlul „legat” la baza de date şi aceasta, având rolul de manager al evenimentelor legate de procesul de data-binding. Un alt scop al acestei 3434
  35. 35. .NET Framework – Prezent şi Viitor componente este acela de interoperare cu alte controale implicate in procese data-related (e.g., DataNavigator, DataGridView etc). .NET Framework 2.0 Beta introduce noi controale Windows Forms. Controlul DataGridView asigură o modalitate puternică de afişare a datelor în format tabelar, cu suport pentru paginare, sortare, filtrare, editare şi ştergere. Controalele ToolStrip sunt o extindere a conceptului de toolbar care permite acomodarea de meniuri şi controale utilizator permiţând crearea de interfeţe utilizator într-o manieră consistentă cu stilul sistemului de operare şi al aplicaţiilor consacrate (e.g., Windows XP, Microsoft Office, Internet Explorer etc). Controlul MaskedTextBox utilizează o definiţie de tip „mască” pentru validarea datelor introduse de utilizator. Componenta SoundPlayer facilitează includerea de clipuri sonore în aplicaţii. Aceasta poate reda fişiere media în formatul .wav, fie dintr-o resursă, fie folosind locaţii UNC (Universal Naming Conventions) sau HTTP. Controlul ListView suportă trei elemente de funcţionalitate introduse de familiile de sisteme de operare Windows XP, respectiv Windows Server 2003: tile view, grupare şi repoziţionare a elementelor conţinute folosind interacţiune de tip drag-and-drop. Controlul ActiveDocumentHost permite afişarea documentelor active (e.g., documente Microsoft Office etc). Controlul WebBrowser permite acomodarea paginilor Web în propria aplicaţie Windows Forms, putând fi foosit pentru afişarea documentaţiei HTML sau pentru a oferi capabilităţi de navigator Web. Controlul FlowLayoutPanel îşi renderizează conţinutul într-o dispunere de tip flow orientată vertical sau orizontal. În contrast, controlul TableLayoutPanel îşi aranjează conţinutul folosind modelul grid. Componenta BackgroundWorker permite realizarea în fundal (eng. background) a operaţiilor consumatoare de timp, fără relevanţă vis-a-vis de interfaţa aplicaţiei. Nu în ultimul rând, trebuie menţionată introducerea în modulul Windows Forms al .NET Framework 2.0 Beta, a şablonului asincron pentru componente (eng. the asynchronous pattern for components), un model bazat pe evenimente care beneficiază de toate avantajele aplicaţiilor cu multiple fire de execuţie, împachetând aspectele complexe inerente design-ului multi- thread. XML .NET Framework 2.0 Beta furnizează o multitudine de îmbunătăţiri, incluzând un nou procesor pentru XSL Transformation (XSLT), suport pentru tipuri în clasele XmlReader, XmlWriter şi XpathNavigator şi o multitudine de capabilităţi de editare ale clasei XPathNavigator. În plus, există un nou model pentru crearea obiectelor de tip XmlReader şi XmlWriter, precum şi multe îmbunătăţiri la nivel de performanţă. 3535
  36. 36. .NET Framework – Prezent şi Viitor 2.2.2 Compatibilitate Platforma .NET este dezvoltată având ca prioritate de importanţă majoră menţinerea compatibilităţii forward şi backward între versiuni. Cu toate acestea, modificările destinate îmbunătăţirii anumitor aspecte ale platformei, cum ar fi securitatea, corectitudinea sau funcţionalitatea, pot fi sursa unor incompatibilităţi. Compatibilitatea backward a platformei .NET se referă la posibilitatea de execuţie a unei aplicaţii scrise folosind o versiune anterioară, pe un sistem care utilizează versiunea curentă. .NET Framework suportă un grad ridicat de compatibilitate backward. Astfel, majoritatea aplicaţiilor dezvoltate folosind versiunea curentă vor funcţiona în versiunea viitoare. Compatibilitatea forward se referă la posibilitatea execuţiei unei aplicaţii scrise în versiunea curentă a .NET Framework, pe un sistem care utilizează versiunea anterioară. Deşi .NET Framework suportă compatibilitate forward, o aplicaţie care foloseşte un tip (o clasă) sau un membru specific versiunii curente nu va funcţiona niciodată corect, folosind o versiune anterioară. Acest fapt nu reprezintă o incompatibilitate forward, deoarece acest tip de aplicaţie nu este conceput pentru a rula pe versiuni anterioare ale platformei. Pentru a crea o aplicaţie compatibilă cu două versiuni ale .NET Framework, aceasta trebuie să utilizeze doar tipuri şi membri specifici versiunii inferioare. Modificările apărute în dezvoltarea platformei, generatoare de incompatibilităţi între versiuni ale acesteia, pot fi catalogate sub două tipuri: modificări binare, respectiv modificări comportamentale ale unor tipuri sau membri. Aceste modificări responsabile pentru apariţia unor incompatibilităţi, pot fi de asemenea catalogate ca fiind modificări backward sau modificări forward, după tipul de incompatibilitate generat. În general, modificările backward, sunt create pentru a îmbunătăţi securitatea platformei, iar modificările forward, pentru a elimina erorile comportamentale identificate în versiunea anterioară. Modificările binare reprezintă modificări ale signaturii unui tip sau ale unui membru, iar modificările comportamentale se referă la modul de operare al unui tip sau al unui membru. Pentru a putea rula aplicaţii folosind diferite versiuni ale platformei se folosesc redirectările prin intermediul fişierelor de configurare. Implicit, aplicaţiile sunt configurate pentru a folosi versiunea .NET Framework pentru care au fost dezvoltate, mai exact, versiunea pe care au fost compilate. În acest caz, nu este necesară crearea unui fişier de configurare auxiliar. Dacă totuşi se doreşte rularea aplicaţiei folosind una sau mai multe versiuni ale platformei .NET, se poate specifica acest lucru într-un fişier de configurare auxiliar. Fişierele de configurare au extensia .config şi pot fi create automat, folosind Visual Studio®, sau manual, folosind un editor text. Aceste fişiere vor conţine setul de versiuni candidat specificate prin indicativ în ordinea preferinţei de utilizare. Un exemplu de fişier de configurare poate conţine: <startup> <requiredRuntime imageVersion="v2.0.50215" version="v1.1.4322" /> <supportedRuntime version="v2.0.50215" /> <supportedRuntime version="v1.1.4322" /> </startup> 3636

×