Servicii Web Xml. Aplicatii
Argument
Am ales lucrarea „Servicii Web XML. Aplicații” deoarece consider că tema este una practică și de actualitate, web-tehnologiile de bază ca TCP/IP, HTML, XML având o dezvoltare explozivă, iar XML ca limbaj permițând lucrul cu orice tip de date.
Serviciile Web prezintă un uriaș potențial de utilizare într-o mare varietate de aplicații folosite în Internet, cum ar fi cele pentru serviciile meteorologice, pentru știri bursiere, pentru serviciile de știri, pentru serviciile de urmărire a pachetelor și pentru serviciile asociate, și multe alte aplicații practice.
Structura lucrării este gândită astfel :
INTRODUCERE
CAPITOLUL 1 Servicii Web
CAPITOLUL 2 Servicii Web XML-Aplicații
CAPITOLUL 3 XML va bază de date
BIBLIOGRAFIE
Domeniul temei
Domeniul web-service XML este unul vast, existând o multitudine de aspecte, o parte din acestea încercînd a le detalia în lucrare.
Există avantaje dar și limitări ale serviciilor web XML dar putem observa că plusurile sunt de domeniul strategic, pe când minusurile au caracter tehnic, datorită noutății tehnologiilor serviciilor Web. Rezolvarea acestor probleme este doar o problema de timp.
Plusurile web-service sunt:
Web-services permit companiei integrarea propriilor business-procese cu business-procese ale partenerilor si clienților săi cu costuri mult mai mici, decât cu alte tehnologii. Costurile unor asemenea soluții este accesibilă si IMM-urilor, ceea ce va deschide companiei noi orizonturi;
Întrucât serviciile web se organizează în regiștri publici (UDDI, ebXML), accesibili persoanelor interesate din toată lumea, pragul ieșirii companiei pe piețe noi se micșoreaza, posibilitatile cresterii bazei de clienți însa, cresc.
Serviciile web asigură compatibilitatea in relația cu sisteme informationale deja existente în companie. Astfel, se păstrează investițiile făcute anterior și nu sunt necesare schimbări radicale.
Construirea soluțiilor noi cu aplicarea serviciilor web se realizează mai rapid și mai puțin costisitor.
Neajunsurile serviciilor web:
Standardele de integrare a aplicațiilor, crearea politicilor IT si business ce pot interacționa prin intermediul serviciilor web se află încă în stadiul de continuă dezvoltare și elaborare. Mai multe companii lucrează în paralel asupra serviciilor web (Web Services Flow Language (WSFL), Business Process Execution Language 4 Web Services (BPEL4WS)) de la IBM, XLANG de la Microsoft și specificațiile WS-Coordination și WS-Transaction – rezultatul colaborării IBM, Microsoft și BEA). Evident, fără formularea strictă a lor construirea sistemelor informatice pe baza tehnologiei web-service poate merge doar cu succes intermitent.
Folosirea dinamică a informațiilor din regiștrii serviciilor web, apelul serviciilor concomitent cere rezolvarea problemelor relației de încredere între diferiți regiștri. În plus, sunt probleme în utilizarea concomitentă a regiștrilor de formate diferite.
Specificația WS-Security – produsul colaborării IBM și Microsoft – este destul de “tânără” și este mereu înnoită. Se pregătesc deja specificațiile destinate securității serviciilor Web: Web Services Policy Assertions, Web Services Policy Attachments, Web Services Policy Framework, Web Services Trust, Web Services Secure Conversation, Web Services Federation.
Există mai multe avantaje ale serviciilor web față de alte tehnologii dar cele mai importante sunt suportul total primit de la industria IT și flexibilitatea. Pe de altă parte, cei care sunt familiari cu specificațiile organizațiilor de standardizare știu că de multe ori se folosesc cuvinte ca ”ar trebui” sau ”este posibil ca”. Pentru serviciile web, însă, s-a creat o organizație care se luptă pentru înlocuirea acestor expresii cu unele ca ”trebuie” sau ”va trebui”, ceea ce aduce o puternică reducere a ambiguităților din standarde și duce la evitarea ”interpretărilor” proprietare ale textelor. Această organizație este WS-I, care are drept scop ca implementările diferite ale suitelor de servicii web să fie interoperabile.
Capitolul I. Serviciile Web
1.1 Apariția și dezvoltarea serviciilor Web
La început a fost TCP/IP-ul, acesta a avut o evoluție foarte rapidă: a apărut în primele rețele din anii ’70 și până în zilele noastre a reușit să cucerească toată lumea. Suita de protocoale TCP/IP a evoluat, mereu s-au adus îmbunătățiri la el fără să i se întrerupă prezența în rețele și, poate mai important, fără să i se blocheze evoluția. Încă de la început, TCP/IP-ul a fost și a rămas protocol deschis, guvernat de organizații de standardizare independente ca IETF sau W3C. Oricine putea să aducă îmbunătățiri. Bineînțeles că aceste organizații se ocupă de multe alte standarde fără de care internetul de azi nu ar mai fi la fel.
Dezvoltatorii de software au fost mulțumiți o vreme, până când nu a mai fost de ajuns să construiască aplicații care să aibă drept consumator omul. Era nevoie ca aplicațiile să comunice între ele. Astfel că, între marile companii furnizoare de tehnologie nu a mai fost același consens la problemele de comunicație între aplicații cum a fost odinioară la problemele de comunicație între calculatoare. Au fost câteva încercări dintre care s-au detașat DCOM (Distributed Component Object Model) de la Microsoft, RMI (Remote Method Invocation) de la Sun și CORBA (Common Object Request Broker Architecture) de la OMG (Object Management Group). Nici una din cele trei tehnologii nu a fost adoptată de toată lumea.
Era nevoie ca toți să urmeze modelul standardelor deschise. Fiindcă TCP/IP-ul a fost al nimănui și a avut succes tocmai prin caracterul deschis, trebuia găsit ceva asemănător (la nivelul aplicațiilor) care să fie tot al nimănui și să fie bazat pe standarde. Acel ceva este reprezentat de serviciile web. Dacă lumea IT reușește să impună serviciile web bazate pe standarde, s-a rezolvat problema, fiindcă furnizorii de produse software vor îmbrățișa ideea de servicii web realizând produse care știu să comunice astfel cu orice alt produs indiferent de platforma pe care rulează, indiferent de cine le-a creat și indiferent cu ce tehnologie le-a construit.
În ultimii ani s-au definitivat zeci de standarde în acest domeniu și suntem în faza în care putem spune că serviciile web vor avea succes cel puțin la fel ca TCP/IP. Mai mult, pentru accelerarea standardizării și pentru oferirea unei garanții că prin serviciile web se va asigura interoperabilitatea mult dorită, s-a creat și WS-I, un organism care furnizează documente mature pentru W3C și IETF.
Comunitatea IT a ajuns la consens în ceea ce privește caracteristicile acelui ceva care va rezolva comunicația între aplicații. Acel ceva trebuie să fie:
independent de mașină (PC-uri, mașini mari sau dispozitive mobile), de sistemul de operare, de limbajul de programare, de baza de date sau de arhitectură,
modular,
să suporte comunicație între aplicații slab cuplate (cu gândul la internet),
utilizabile în orice domeniu, de la soluții simple P2P (Peer to Peer) la sisteme EAI (Enterprise Application Integration) și până la sisteme B2B (Business to Business) de anvergură.
Toate soluțiile de până acum (DCOM, RMI sau CORBA) au probleme majore cu cel puțin două dintre cerințele de mai sus. Trebuie să amintim aici și o soluție mai exotică numită EDI (Electronic Data Interchange), care părea să rezolve problema.
Ca să putem înțelege gândirea specialiștilor în IT când a apărut concepția de web-service, prin ce ea diferă de celelalte încercări de a crea tehnologii de dezvoltare a sistemelor informatice și, cel mai important, de ce e atât de bună, cum spun experții companiilor-vendori și analiștii sectorului IT, e necesar să ne intoarcem cu câțiva ani în trecut și să privim cum se dezvoltau tehnologiile creării sistemelor informatice, ce a fost creat si ce probleme au apărut. Cum se întîmpla de obicei, în totul sunt “vinovați” banii. Când rețelele de calculatoare au ieșit din cadrul organizațiilor strict militare si științifice(cum ar fi ARPAnet), ele au ajuns in mâna particularilor. În momentul în care numărul utilizatorilor a crescut a apărut ideea că rețelele de calculatoare pot fi folosite în afaceri. Astfel, rețelele de calculatoare de uz comun, principala și cea mai răspândită din care astăzi se numește Internet, au ajuns business-instrument. Dar ca să conduci un business cu un astfel de instrument, el trebuie să corespundă unui set de cerințe, cele mai importante dintre care sunt – securitatea și viteza de transfer a informației. Problema rezolvării acestor cerințe au început să o rezolve la nivelul cel mai de jos – nivelul protocoalelor de transport. Diferite companii au propus diferite realizări a protocoalelor de rețea. Protocoalele de rețea, dupa cum se știe, conțin regulile de formare a pachetelor si schimbul dintre ele. Aplicațiile ce folosesc aceste reguli (diferite pentru diferite protocoale) sunt strîns legate de aceste protocoale. Între timp relațiile B2B (Business–to–Business) cereau ca aplicațiile de rețea ce foloseau protocoale diferite să poata comunica între ele – în asa fel a aparut problema integrării aplicațiilor.
Pe parcursul câtorva ani au fost elaborate câteva tehnologii de interacționare între aplicații care permiteau, intr-un fel sau altul, realizarea schimbului de date intre aplicații (cele mai răspândite dintre care – Remote Procedure Calls (RPC), Distributed COM (DCOM), Remote Method Invocation (RMI) si Common Object Request Broker Architecture (CORBA)), însa fiecare dintre ele a fost destul de greu realizabilă, nu dispunea de universalitate necesară (De exemplu: Toti utilizatorii trebuiau sa aibă același sistem de operare) si, cel mai rau, aceste tehnologii erau greu compatibile intre ele. Aceasta situatie nu putea sa mulțumeasca nici business-ul, nici pe specialiștii IT.
Atunci s-a apelat la web-tehnologii de bază, s-a încercat gasirea acelui puțin, ce se afla la baza Internetului. Dar această bază e constituită din urmatoarele tehnologii:
TCP/IP – protocolul universal, acceptat de către toate dispozitivele de rețea, de la mainframe-uri la telefoane mobile si PDA;
HTML – limbaj universal, folosit pentru redarea informației cu dispozitivele utilizatorilor;
XML( eXtensible Markup Language) – limbaj universal pentru lucrul cu orice tip de date.
1.2 Serviciile Web
Definiția dată de organizația W3C este: un web-service este un sistem software identificat de URI [RFC 2396], a cărui interfețe publice și legăturile sunt definite și descrise folosind XML. Definirea să poată fi gasită și de alte sisteme software. Aceste sisteme pot ulterior interacționa cu web-service în acord cu definirea sa, folosind mesaje bazate pe XML transmise cu ajutorul protocoalelor Internet.
Din definiția de mai sus, observăm că unica tehnologie ce este folosită cu strictețe este XML. Nu se amintește nici de protocolul de rețea folosit, nici de limbajul de programare, nici de platforma pe care se realizează. Unica condiție – folosirea mesajelor XML (mai precis SOAP), întrucât alternativă reală pentru XML, ca limbaj ce permite lucrul cu orice tip de date, în ziua de azi nu există.
Web Services este o tehnologie .NET folosită pentru crearea de componente programabile. Multe aplicații folosesc tehnologii de componente distribuite, cum ar fi Distributed Component Object Model (DCOM) și Remote Procedure Call (RPC). O problemă comună a acestor tehnologii este dependența de platformă. Web Services folosește tehnologii de Internet standard, cum ar fi HTTP și XML. Independența de platformă creează posibilitatea și pentru sistemele eterogene de a folosi aceste aplicații. Utilizatorii nu mai trebuie să știe în ce limbaj a fost creată o aplicație sau un serviciu. Nu mai trebuie să știe decât care sunt facilitățile pe care le oferă și cum le pot utiliza în propriile lor aplicații.
Web Services folosește tehnologiile de Internet obișnuite, ca HTTP și XML, pentru a realiza comunicarea între furnizor și consumator. În acest caz, furnizorul este cel care creează componenta Web Service și o distr tehnologie ce este folosită cu strictețe este XML. Nu se amintește nici de protocolul de rețea folosit, nici de limbajul de programare, nici de platforma pe care se realizează. Unica condiție – folosirea mesajelor XML (mai precis SOAP), întrucât alternativă reală pentru XML, ca limbaj ce permite lucrul cu orice tip de date, în ziua de azi nu există.
Web Services este o tehnologie .NET folosită pentru crearea de componente programabile. Multe aplicații folosesc tehnologii de componente distribuite, cum ar fi Distributed Component Object Model (DCOM) și Remote Procedure Call (RPC). O problemă comună a acestor tehnologii este dependența de platformă. Web Services folosește tehnologii de Internet standard, cum ar fi HTTP și XML. Independența de platformă creează posibilitatea și pentru sistemele eterogene de a folosi aceste aplicații. Utilizatorii nu mai trebuie să știe în ce limbaj a fost creată o aplicație sau un serviciu. Nu mai trebuie să știe decât care sunt facilitățile pe care le oferă și cum le pot utiliza în propriile lor aplicații.
Web Services folosește tehnologiile de Internet obișnuite, ca HTTP și XML, pentru a realiza comunicarea între furnizor și consumator. În acest caz, furnizorul este cel care creează componenta Web Service și o distribuie prin serverul său pentru a putea fi folosită în aplicații de către consumatori.
De asemenea, Web Services folosește un nou protocol redus numit SOAP (Simple Object Access Protocol). A fost nevoie de un nou protocol fiindcă o mare parte din tehnologiile de componente distribuite existente în prezent sunt legate de un sistem de operare, obligându-ne să rescriem obiecte pentru diferiți clienți. Problema devine mai serioasă când se distribuie obiecte prin Internet, din cauza problemelor de securitate: majoritatea aplicațiilor de Web folosite de firmele comerciale au firewall. Dacă se folosește SOAP, care utilizează protocolul HTTP ca purtătoare, nu mai este necesară deschiderea de noi porturi în firewall. Comunicarea dintre furnizorul serviciului de Web și consumator se va face printr-un mesaj SOAP în format XML. Ca să le permită consumatorilor să folosească un serviciu de Web în aplicațiile lor, programatorul serviciului respectiv trebuie să furnizeze informații, cum ar fi metodele definite de serviciul Web, parametrii solicitați și valorile generate de metode.
Limbajul WSDL (Web Service Description Language) este cel care realizează acest lucru, furnizând informații despre serviciul de Web în format XML. WSDL este generat de ASP.NET
Nota: Pentru a vedea contractul WSDL, scrieți URL-ul pentru apelarea fișierului .asmx cu sufixul ?WSDL. De exemplu, dacă veți crea un fișier myWebService.asmx în http://localhost/, ați putea folosi adresa http://localhost/myWebService.asmx?WSDL pentru a vedea contractul WSDL.
Discovery of Web Services (DISCO) este mecanismul folosit pentru localizarea unui serviciu din Web. Când se crează în VS.NET serviciul de Web este generat și un fișier XML cu extensia .disco.
Toate serviciile de Web au extensia de fișier .asmx. Scrierea unei componente Web Service poate dura de la câteva minute la câteva zile, în funcție de funcționalitatea oferită. ASP.NET se ocupă de crearea contractului WSDL și de mesajul SOAP pentru comunicare.
1.2.1 Metodele serviciilor Web
Componenta Web Services conține, de regulă, una sau mai multe funcții publice sau private interne. WebMethod este un atribut individualizat aplicat funcțiilor publice pentru a permite accesul la funcția respectivă clienților de Web de la distanță. După cum sugerează și numele, funcțiile private nu pot fi apelate de clienții de Web de la distanță.
Funcțiile publice dintr-un serviciu de Web care nu are atributul WebMethod nu pot fi apelate de clienții de Web de la distanță.
Următorul cod definește o metodă numită TestMethod, care are o valoare String ca intrare și generează o valoare String ca ieșire.
Public Function <WebMethod()> TestMethod(strInput as String) as_String
‘aici vine codul de implementare’
End Function
Când se aplică atributul WebMethod() unei funcții publice, pot fi introduse și proprietăți pentru controlul temporizării, a stării sesiunii și a sectoarelorde cache. Astfel, prorietățile care pot fi specificate când se aplică atributul WebMethod() sunt:
BufferResponse: Stabilește dacă răspunsul este temporizat în memorie înainte de a fi transmis clientului. Introducerea valorii True pentru această proprietate determinată temporizarea răspunsului; intruducerea valorii False determină transmiterea răspunsului către client în momentul generării sale. Valoarea prestabilită este False.
CacheDuratioa: Stabilește durata (în secunde) de plasare în cache a răspunsului. Valoarea prestabilită este 0, astfel că răspunsul nu este salvat în cache. Dacă introduceți o valoare mai mare de 0, răspunsul va fi salvat pe durata indicată. O solicitare ulterioară în limita duratei stabilite va genera un răspuns din cache.
Description: Furnizează o instrucțiune descriptivă despre WebMethod pentru utilizatorii serviciului. această instrucțiune este afișată în dreptul de atribuire WebMethod în pagina Service Description sau Service Help.
Figura 1.1 Valoarea proprietății Description afișată în pagina Service Help.
EnableSession: Stabilește dacă este activată funcția pentru starea sesiunii a serviciului de Web. Introducerea valorii True determină activarea acestei funcții; introducerea valorii False o dezactivează. În configurația prestabilită, funcția pentru starea sesiunii este dezactivată.
MessageName: Numele folosit pentru metoda Web Service în datele transmise și primite de la o metodă Web Service. Este util când există două sau mai multe metode cu aceeași denumire.
TransactionOptions: Indică facilitățile pentru tranzacții ale metodei de Web.
1.2.2 Arhitectura soluției. Suita de tehnologii din serviciile Web (XML, SOAP, WSDL, UDDI ș.a.)
Folosirea Web Services se extinde rapid o dată cu creșterea necesităților de comunicație intre aplicații. Web Services oferind un standard de comunicare între diverse aplicații software rulând pe platforme diferite. Un Web Service este un sistem software unic identificat (URI), ale cărui interfețe publice și metoda de conectare sunt definite și descrise folosind XML. Definirea unui Web Service poate fi descoperită de către alte sisteme software. Aceste sisteme pot apoi interacționa cu Web Service-ul respectiv în maniera descrisă de definire, folosind mesaje XML.
Nevoia sistemelor IT de a comunica cu organizația din care fac parte a condus la evoluția Integrării Aplicațiilor unei Organizații (EAI). Această integrare foarte complexă poate fi realizată într-o manieră dinamică folosind Web Services.
Arhitectura soluției
Arhitectura de bază definește interacțiunea dintre agenții software ca un schimb de mesaje dintre consumatorii de servicii și producătorii de servicii. Agentii software pot juca 3 roluri: cel de producător de servicii, cel de consumator de servicii, respectiv cel de agenție de descoperire de servicii. Prin intemediul agentiei de descoperire, serviciile sunt publicate și pot fi găsite de consumatori.
Consumatorii și producatorii interacționează folosind unul sau mai multe modele de schimb de mesaje (Message Exchange Protocol). Componentele care respectă arhitectura de baza sunt de obicei definite folosind aplicații XML, folosesc definiții XML infoset pentru structura și tipul de date ale mesajelor și folosesc HTTP pentru transport.
Facilitățile oferite de arhitectura extinsă cuprind:
Schimb asincron de mesaje
Atașare de documente binare
Tranzacții pe durată lungă
Autentificarea mesajelor
Integritatea mesajelor
Confidențialitatea mesajelor
Specificarea căilor de urmat pentru mesaje
Gestionarea mesajelor – se permite organizarea mesajelor după anumite criterii.
Crearea de sesiuni de comunicație
Web Services pot fi implementate cu diferite formate de împachetare a datelor sau diverse modele de procesare. Datorită ubicuității standardului SOAP, acesta este folosit cu precădere în Web Services. SOAP este un protocol de schimb de informație într-un mediu descentralizat și este bazat pe protocolul XML. Deși poate sa folosească diverse metode de conectare, cel mai des folosită este HTTP.
Suita de tehnologii
Suita de tehnologii din serviciile web conține patru actori principali. Primul membru este XML iar ceilalți sunt SOAP, WSDL și UDDI.
XML eXtensible Markup Language
XML este o modalitate de descriere a informației și a fost creat pentru a avea un limbaj universal de a descrie orice fel de date în internet. A fost primul pas către serviciile web. Trebuia imaginat ceva simplu și ușor de transportat prin internet. Fiindcă prin rețeaua globală circulă tone de informație sub formă de HTML (web-ul nostru cel de toate zilele) a fost firesc să vină cineva cu ideea: hai să creăm un HTML extensibil, care să fie capabil să descrie orice informație. Când spunem informație, nu înseamnă numai pagini web sau documente cum este acesta ci și imagini vectoriale, tranzacții de comerț electronic, operațiuni matematice, metadate ale obiectelor etc. Așa s-a născut XML, care a devenit în scurt timp standard adoptat de W3C și este omniprezent în produsele marilor furnizori IT.
În prezent prima versiune de XML este standard și sunt definitivate specificațiile (sep. 2002) pentru XML versiunea 1.1 (Candidate Recommendation).
Documentele care sunt destinate să devină standarde în internet trebuie să treacă prin 5 faze în cadrul W3C. Documentele pot fi blocate la orice fază:
Notă – faza de idee
Draft – faza de lucru, de dezvoltare
Candidate Recommendation – faza în care se cere deja feedback de la alte grupuri de lucru sau din afara W3C
Proposed Recommendation – faza în care s-a atins consensul și se propune documentul spre aprobare
Recommendation – faza în care W3C își asumă responsabilitatea de a ”da liber” pentru implementare globală. Spunem că aici documentul devine standard de internet. Asta nu înseamnă că este obligatorie implementarea tehnologiei descrise, însă piața IT a demonstrat-o că recomandările W3C sunt adoptate pe larg de furnizorii de tehnologie IT.
XSD: Spre deosebire de HTML, XML ne permite să creăm elementele noastre așa cum vrem noi. Descrierea acestor elemente se face în documente numite XML Shema.
Aceste documente sunt tot XML însă folosesc un limbaj specific numit XSD (XML Schema Definition) a cărei primă versiune este descrisă de mai multe recomandări W3C.
Xpath: XPath (XML Path Language) este un limbaj de interogare (query) a documentelor XML. Asa cum limbajul SQL este un limbaj de interogare a bazelor de date relaționale, XPath poate și el să extragă informație din documente XML considerându-le structuri arborescente (elemente în elemente ș.a.m.d.). Aceste structuri arborescente, care abstractizează documentul XML, se numesc Information Set (pe scurt: Infoset).
În prezent, prima versiune de XPath este recomandare W3C.
XSLT: XSLT (Extensible Stylesheet Language Transformation) este o altă tehnologie care se bazează pe ideea de abstractizare a documentelor XML prin Infoset-uri și care se bazează în mare parte pe XPath. XSLT este un mecanism de transformare a documentelor XML, de exemplu de la o schema la alta.
SAX și DOM: Procesarea (extragerea) informației (datelor) din documente XML se poate face în mai multe moduri. Una din soluții este extragerea secvențială a datelor traversând structura arborescentă a documentelor XML. Această abordare se numește SAX (Streaming API for XML) și nu este prezent în nici un document al W3C însă fiindcă este o metodă performantă de citire a datelor, soluția este implementată de majoritatea furnizorilor IT. O a doua soluție este una prin care aplicațiile pot ”naviga” înainte și înapoi în documentele XML.
Putem vedea deci, că XML conduce la realizarea multor aplicații software. Una din aceste aplicații este ebXML (electronic business XML), care este rezultatul unui proiect al UN/CEFACT în colaborare cu OASIS (Organization for the Advancement of Structured Information Standards). Proiectul dorea trecerea soluțiilor EDI spre XML, ceea ce a și reușit, ba mai mult, a născut o strategie solidă în domeniul tranzacțiilor B2B însă fără aplicabilitate în EAI sau P2P. Motivul este rigiditatea sistemului de mesagerie la care dacă adăugăm scăpările de securitate, vom înțelege de ce marii furnizori de tehnologie IT și-au îndreptat atenția spre o altă tehnologie: serviciile web (XML Web Services).
Serviciile web au fost gândite de la început utilizabile în orice domeniu, să satisfacă orice cerință de mesagerie indiferent de scenariu. Arhitectural au fost gândite să fie modulare, funcționale în soluții slab cuplate și conforme cu toate specificațiile standard.
XML pare să schimbe lumea și o schimbă într-o direcție bună. Este vremea consensului. Dorința beneficiarilor de soluții IT de a avea o modalitate comună de comunicare, a determinat marii furnizori de tehnologie IT (Microsoft, IBM, Oracle, Sun, BEA, SAP, Siebel etc.) să investească miliarde de dolari în construirea de produse și soluții bazate pe servicii web. Suportul total primit de la furnizorii de platforme, de la telefoane mobile la PC-uri, servere și mașini mari (mainframe-uri), conduce la dezvoltarea unei multitudini de produse ce suportă servicii web. Aceasta înseamnă că din rețeaua virtuală globală, orice componentă (orice client, orice server, orice aplicație) poate trimite sau primi mesaje de tip XML Web Services.
Un exemplu de reprezentare în XML a descrierii unui serviciu Web care returnează HelloWorld:
<?xml version="1.0" encoding="utf-8" ?>
– <definitions xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" targetNamespace="http://tempuri.org/" xmlns="http://schemas.xmlsoap.org/wsdl/">
– <types>
– <s:schema elementFormDefault="qualified" targetNamespace="http://tempuri.org/">
– <s:element name="HelloWorld">
<s:complexType />
</s:element>
– <s:element name="HelloWorldResponse">
– <s:complexType>
– <s:sequence>
<s:element minOccurs="0" maxOccurs="1" name="HelloWorldResult" type="s:string" />
</s:sequence>
</s:complexType>
</s:element>
</s:schema>
</types>
– <message name="HelloWorldSoapIn">
<part name="parameters" element="s0:HelloWorld" />
</message>
– <message name="HelloWorldSoapOut">
<part name="parameters" element="s0:HelloWorldResponse" />
</message>
– <portType name="Service1Soap">
– <operation name="HelloWorld">
<input message="s0:HelloWorldSoapIn" />
<output message="s0:HelloWorldSoapOut" />
</operation>
</portType>
– <binding name="Service1Soap" type="s0:Service1Soap">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" />
– <operation name="HelloWorld">
<soap:operation soapAction="http://tempuri.org/HelloWorld" style="document" />
– <input>
<soap:body use="literal" />
</input>
– <output>
<soap:body use="literal" />
</output>
</operation>
</binding>
– <service name="Service1">
– <port name="Service1Soap" binding="s0:Service1Soap">
<soap:address location="http://localhost/HelloWorld/Service1.asmx" />
</port>
</service>
</definitions>
SOAP (Simple Object Access Protocol)
Inițial SOAP se descifra ca Simple Object Access Protocol. Dacă, în urmă cu câțiva ani, întrebați pe cineva ce înseamnă SOAP primeați un asemenea răspuns: este pentru lucrul DCOM și CORBA prin Internet. Primii autori au recunoscut atunci ca ei au focusat asupra ‘accesului la obiecte’, dar cu timpul s-a dorit ca SOAP să asigure mai multe. Astfel, obiectul specificației s-a deplasat de la obiecte la schimbul cu mesajele XML. Această deplasare a creat o mică problemă cu litera O in abrevierea SOAP. Echipa de lucru SOAP 1.2 a păstrat numele SOAP, dar s-a decis să nu se mai descifreze această abreviere, ca să nu inducă în eroare dezvoltatorii. Astăzi, în definiția oficială, folosită în ultimele specificații SOAP 1.2, obiectele nici nu sunt pomenite.
SOAP (Simple Object Access Protocol) reprezintă un strat important din suita de tehnologii din serviciile web și fiindcă de la apariția sa a avut o evoluție fulminantă și fiindcă în engleză sună haios, multă lume deja ignoră că numele reprezintă inițiale și îi spun simplu: SOAP (săpun).
Dacă XML este o modalitate de descriere a informației prin text simplu (documente XML), trebuia imaginat un protocol capabil să transporte aceste documente peste Internet. Acesta este SOAP, care este o tehnologie de comunicare bazată pe un mecanism de ”împachetare” a documentelor XML în plicuri SOAP (envelope – în engleză). Ideea de împachetare este asemănătoare cu ceea ce se întâmplă cu frame-urile care se împachetează în pachete IP la nivel de rețea, numai că la SOAP header-ul este – firesc – un text care se adaugă la începutul documentului XML. SOAP a fost gândit să permită conectivitatea sistemelor peste web, independent de platforma folosită. El permite ca sisteme diferite să citească, să înțeleagă și să ruteze informația din mesaje iar pentru transport poate folosi protocoale ca HTTP, HTTPS sau SMTP.
În prezent, SOAP este suportat de majoritatea furnizorilor IT și este menținut de W3C. Versiunea 1.2 este descrisă în trei documente care au devenit ”Candidate Recommendation” în decembrie 2002.
SOAP este format din 3 părți:
Învelișul SOAP care definește ce există în mesaj, cine trebuie să-l primească și dacă este opțional sau obligatoriu.
Regulile de împachetare SOAP care definesc un mecanism de serializare folosit pentru transferul de tipuri de date definite de aplicații.
Reprezentarea RPC SOAP care definește o convenție folosită pentru executarea de proceduri la distanță.
Această noua tehnologie, considerată de majoritatea specialistilor urmatoarea revoluție în Internet, permite atingerea unui nou nivel de performanță în crearea, menținerea și actualizarea conținutului în Internet.
SOAP creează metodele necesare accesării unui anumit conținut, fie că este vorba de un mesaj email, fie de rezultatul unei cautări intr-o bază de date. Printr-o interfață unică, același conținut poate fi folosit pe mai multe medii (de exemplu, cursul valutar poate fi afișat pe o pagină WEB, pe un PDA sau pe un telefon celular compatibil WAP). Implementările acestui protocol sunt diverse.
SOAP decide metoda transferului mesajelor XML din punctul A în punctul B(ca în imagine).
Figura 1.2 Schimb simplu de mesaje SOAP
SOAP este compatibil cu toate modelele de programare si nu este legat de RPC. SOAP definește modelul prelucrării mesajelor separate și unidirecționale. Mai multe mesaje se pot întruni într-un proces de schimb de mesaje. Figura 1.2 ilustrează un mesaj simplu unidirecțional, în care emitentul nu primește răspuns. Dar destinatarul îi poate trimite emitentului răspuns (Figura 1.3).
Figura 1.3 Schema schimbului de mesaje cerere/răspuns
Stratul de schimb de mesaje
SOAP determină modelul prelucrării, care conține regulile esențiale de prelucrare a mesajelor SOAP pe parcursul transportului lor de la SOAP emitent către SOAP destinatar. Figura 1.2 ilustrează un scenariu simplu de schimb de mesaje SOAP, în care o aplicație (SOAP Sender) trimite un mesaj SOAP către o altă aplicație (SOAP Receiver). Dar modelul prelucrării admite și arhitecturi mai interesante, asemănătoare cu cea arătată în figura 1.4, care conține o mulțime de noduri intermediare.
Figura 1.4 Schimb complex de mesaje SOAP
Figura 1.5 Forma mesajelor SOAP
Un mesaj SOAP constă într-un plic format dintr-un antet (header) opțional, plus un corp (body) obligatoriu. Antetul conține blocuri de informații relevante pentru modul cum va fi procesat mesajul (date despre expeditor, despre destinatar, date de autentificare și autorizare a transmisiei etc.). Corpul va conține mesajul care va fi efectiv trimis și procesat. Se poate face analogia cu sistemul de poștă electronică folosit pe Internet, dar aici lucrurile capătă un aspect obiectual, abstract. Dacă creăm un simplu serviciu Web care returnează textul Hello + nume și îl apelăm vom obține o imagine ca acea de mai jos:
Dând clic pe legătura HelloWorld se poate vedea o descriere detaliată despre cum are loc invocarea operației implementate. Ca în captura de mai jos:
SOAP reprezintă un protocol care se comportă ca un “lipici” între componentele software eterogene, aflate pe mașini diferite. SOAP este definit să utilizeze XML și HTTP. SOAP poate fi utilizat să acceseze servicii, obiecte și servere într-o manieră independentă de platformă. Principalul său scop este tocmai facilitatea interoperabilității.
Ca concluzie se poate observa că: SOAP oferă o manieră independentă de platformă pentru vehicularea datelor marcate în XML, printr-o manieră orientată-mesaj, peste protocolul HTTP. SOAP reprezintă deci un summum între HTTP, XML și RPC, putând fi privit în acest sens ca o abordare la nivel înalt a paradigmei RPC, mai general decât RMI din Java.
WSDL
Un document WSDL (Web Services Description Language) poate fi considerat manualul de utilizare pentru serviciile web deoarece este o descriere completă a serviciului web în cauză. Mai poate fi privit ca un contract prin care serviciul web se angajează să funcționeze într-un anumit fel. De fapt este un document XML – deci independent de platformă – care descrie metodele sau funcțiile (rutinele) utilizabile în aplicațiile noastre, descrie locația serviciului web, forma datelor pe care le primim de la funcțiile expuse și alți parametri de comunicare.
În prezent WSDL este suportat de majoritatea furnizorilor IT și este menținut de W3C. Versiunea 1.2 este descrisă de mai multe documente „Draft” aflate în lucru la W3C.
UDDI
UDDI (Universal Description, Discovery and Integration) este cel mai exotic dintre cei patru membri. Dacă putem deja să descriem datele noastre cu XML, să le transportăm cu SOAP, să construim servicii web cu Visual Studio .NET sau – nu contează cu ce – apoi să folosim WSDL pentru a descrie aceste servicii web, va trebui să găsim o soluție pentru a publica undeva serviciile web, pentru a căuta, pentru a localiza ușor servicii web care ne interesează. Acesta este UDDI și am văzut deja că seamănă cu un ”directory” de servicii web. Acest depozit de servicii web poate fi intern într-o companie sau poate fi public, în internet. Problema pare să fie simplă însă UDDI se vrea mult mai mult decât atât. De exemplu, să presupunem că am putea construi o aplicație care să consume un anumit serviciu web iar dacă acel serviciu web cade din diferite motive, aplicația noastră să fie capabilă să caute un alt serviciu web (folosind UDDI) găzduit probabil pe o altă mașină sau chiar altă platformă, să-l integreze și să continuie să funcționeze. Utilizatorul nici nu observă. Pare să fie SF, dar astfel de soluții se pot construi deja.
În prezent UDDI este suportat de majoritatea furnizorilor IT și este în lucru la OASIS.
Pentru a ușura viața dezvoltatorilor care lucrează la soluții în interiorul companiilor, Microsoft a implementat pe lângă UDDI și o variantă mai simplă, numită Disco, care nu este o soluție standard.
Până acum, serviciile web (XML Web Services) reprezintă unica suită de protocoale care satisface cele patru cerințe enumerate. Chiar dacă furnizorii din industria IT – cu câteva excepții – trec printr-o perioadă de recesiune, au făcut totuși investiții de miliarde de dolari în dezvoltarea de produse care vor furniza suite de servicii web, servere, dispozitive mobile, aplicații și unelte pentru a dezvolta aceste servicii web sau aplicații conectate.
Microsoft împreună cu alți furnizori de platforme și experți în domeniu, continuă să investească în dezvoltarea de noi specificații pentru XML Web Services. În documentele tehnice ale Microsoft, aceste noi specificații se numesc GXA (Global XML Web Services Architecture). Aceste specificații sunt rezultatul colaborării cu alți furnizori și pe măsură ce au fost elaborate, au fost supuse organizațiilor de standardizare.
CAPITOLUL 2 Servicii Web XML-Aplicații
2.1. .NET Remoting
Remoting-noțiuni generale
In cazul cel mai general, termenul de remoting se refera la utilizarea acelor tehnologii ce permit apelul de metode pe date partajate cu obiecte ce ruleaza in alt proces.COM este una din aceste tehnologii.
DCOM extinde aceasta notiune pentru a include obiecte ce ruleaza in procese diferite pe masinidiferite. Atat COM cat si DCOM presupun anumite configurari in registri, drepturi asupra
codului executat, probleme de securitate. Modelul .NET remoting foloseste aceste idei din COM/DCOM, dar cu o implementare complet diferita. De exemplu, informatia despre obiectul remote poate fi plasata intr-un fisier deconfigurare si nu in registri.
.NET introduce o alta notiune, cea de application domains, ce constituie un mediu izolat unde seexecuta aplicatia, le putem asimila ca fiind subprocese ce ruleaza in cadrul unui proces. Un process poate contine mai multe AppDomain iar intr-un AppDomain se poate incarca un
assembly pentru executie.
In .NET frontiera unei aplicatii nu o mai constituie procesul ci application domain.
In acest context, .NET remoting foloseste servicii runtime pentru a invoca metode pe date
partajate intre obiecte ce ruleaza in application domain separate.
Programarea cu AppDomain
Clasa AppDomain
Application domains, reprezentate de obiecte AppDomain, furnizeaza izolare, descarcare si securitate pentru codul managed ce se executa.
AppDomai sunt folosite pentru a izola taskuri ce pot bloca sau termina un proces. Daca un AppDomain devine instabil, acesta poate fi descarcat din memorie fara a afecta procesul. Acest lucru e important cand un proces trebuie sa ruleze o perioada indelungata de timp fara a fi
restartat. Se poate folosi AppDomain pentru a izola taskuri ce nu partajeaza date.
Daca un assembly este incarcat in AppDomain implicit, cel creat la startarea procesului, acesta nu poate fi descarcat din memorie atata timp cat procesul ruleaza.
Observatie:
Nu exista o relatie de unu-la-unu intre AppDomain si fire. Mai multe fire pot rula simultan in acelasi AppDomain. Un fir se executa intr-un singur AppDomain.
Despre contextul unui application domain
Context agile. Context bound.
Un appdomain poate contine mai multe contexte, dintre care unul este contextul implicit.
Contextele furnizeaza urmatoarele:
un mediu ce consta din o multime de proprietati, partajate de toate obiectele din acelasi
context;
runtime-ul poate aplica pre si post-procesari pentru toate apelurile metodelor din afara
contextului;
“host” pentru obiectele cu cerinte runtime similare (sincronizare, afinitate la fir sau
activare just-in-time ).
Cand runtime-ul creaza un obiect, acesta investigheaza cerintele obiectului si-l plaseaza intr-un context compatibil. Daca acest context nu exista atunci runtime-ul il creaza. Majoritatea
obiectelor sunt create in contextul implicit. Aceste obiecte sunt numite “context agile” pentru ca ele pot fi accesate in mod direct de oriunde din interiorul unui application domain.
Obiectele ce au cerinte de context sunt numite “context bound” si trebuiesc sa fie derivate din clasa ContextBoundObject.
Codul ce se executa in afara unui context nu va retine niciodata o referinta directa la obiectele
continute intr-un “context bound”.
Accesul in afara limitelor contextului este realizat printr-un proxy construit de runtime, proxy ce imita obiectul actual.
Proxy permite runtime-ul de a intercepata apleuri in afara contextului si sa aplice cerintele de pre si post-procesare.
Exemplu cu context: Syncronization
Putem defini pentru un tip cerinte asupra unui anumit context folosind atributele. Un exemplu de atribut de context este clasa SynchronizationAttribute. Cand se aplica acest atribut la o clasa, runtime-ul asigura ca numai un fir la un moment dat de timp poate accesa orice instanta a clasei.
Pentru a realiza acest lucru, runtime-ul va crea obiectul intr-un anumit context si va intercepta orice cerinta de apel venita din afara contextului. Daca un fir se executa in cadrul unui context, runtime-ul forteaza toate apelurile din alte fire sa astepte pina cand firul respectiv se termina.
Exemplu:
namespace SimpleContext
{
using System.Runtime.Remoting.Contexts;
// Synchronization attribute
// O clasa “context bound”
[Synchronization]
public class MyContextBoundClass : ContextBoundObject
{ }
// Clasa in context “agile”
public class MyAgileClass
{ }
}
Test pentru cele doua clase
namespace SimpleContext
{
using System;
using System.Runtime.Remoting;
// RemotingServices class
class SimpleContextMain
{
static void Main(string[] args)
{
MyContextBoundClass myBound = new MyContextBoundClass();
MyAgileClass myAgile = new MyAgileClass();
// Are they in or out of context?
Console.WriteLine("\nIs myBound out of context? {0}",
RemotingServices.IsObjectOutOfContext(myBound));
Console.WriteLine("Is myAgile out of context? {0}",
RemotingServices.IsObjectOutOfContext(myAgile));
// Direct reference or proxy?
Console.WriteLine("\nIs myBound a proxy? {0}",
RemotingServices.IsTransparentProxy(myBound));
Console.WriteLine("Is myAgile a proxy? {0}",
RemotingServices.IsTransparentProxy(myAgile));
Console.ReadLine();
}
}
} // namespace SimpleContext
Rezultatul este:
myBound este in afara contextului si este un proxy;
myAgile nu este in afara contextului si nu este un proxy.
Regasirea informatiei despre context
Metoda folosita este Thread.CurrentContext. Aceasta metoda returneaza un obiect
Context, pe care-l putem folosi pentru a gasi informatii despre context.
Exemplu
public class Diagnostics
{
// Displays the context id and properties for the given context.
public static void DisplayContextInfo()
{
Context ctx = Thread.CurrentContext;
Console.WriteLine(" Properties for context id: {0}", ctx.ContextID);
foreach(IContextProperty ctxProp in ctx.ContextProperties)
{
Console.WriteLine(" {0}", ctxProp.Name);
}
}
}
“Pasarea” obiectelor (Marshaling Objects)
Exista doua posibilitati:
pasarea prin valoare (MBV) ;
pasarea prin referinta (MBR).
Conceptual aceste tehnici de marshaling sunt similare notiunii de pasarea parametrilor unei
metode prin valoare sau referinta.
De exemplu, avem posibilitatea de a invoca urmatoarea metoda pe un obiect ce ruleaza intr-un appdomain separat:
public SomeClass GetAnObject()
{
return new SomeClass();
}
Daca SomeClass a fost definita ca tip MBV, atunci metoda returneaza o copie a obiectului, in caz contrar, apelul metodei de mai sus returneaza “un pointer” la obiect, cunoscut si sub numele de proxy. Fiecare tehnica este valida.
« Marshal By Value Objects »
Cand folosim MBV, runtime creaza o copie a obiectului remote in appdomain-ul clientului prin
mecanisme de serializare (serializare pe partea serverului si deserializare pe partea clientului).
Runtime va pasa obiectul prin MBV daca clasa are atributul Serializable.
[Serializable()]
public class MyMBVClass
{
// Implementare clasa
}
Marshal By Reference Objects
Obiectele MBR raman in appdomain unde au fost create. Clientii invoca metode pe obiectele
MBR printr-un proxy ce redirecteaza apelurile (forward).
Obiectele MBR trebuiesc sa fie derivate direct sau indirect din MarshalByRefObject.
public class MyMBRClass : MarshalByRefObject
{
// Implementare clasa
}
In fapt toate tipurile deriveaza din ContextBoundObject care la randul lor sunt derivate din
MarshalByRefObject.
Toate tipurile “context bound” sunt tipuri MBR.
Tipurile MBR ne permit sa distribuim procesarea.
Exemplu
// Un tip MBV (nu e derivat din MarshalByRefObject)
[Serializable]
public class CustomerData
{
private string mFirstName;
private string mLastName;
private string mEmail;
// …
}
// Un tip MBR ce contine o metoda ce returneaza CustomerData
public class CustomerService : MarshalByRefObject
{
public CustomerData GetCustomerByEmail(string email)
{
CustomerData custData = new CustomerData();
// cod …
// retur prin valoare
return custData;
}
}
Exemplu: cum se foloseste acest tip
class ClientMain
{
static void Main(string[] args)
{
// Deoarece CustomerService este MBR, se returneaza
// un proxy la obiectul remote.
CustomerService custService = new CustomerService();
// CustomerData este MBV, deci se returneaza
// o copie a obiectului remote
CustomerData custData =
custService.GetCustomerByEmail("[anonimizat]");
// cod …
}
}
Metode statice si alte detalii despre remoting
In cele mai multe cazuri, metodele unui obiect MBR se executa in interiorul “remote
appdomain”.
Urmatoarele exceptii trebuiesc luate in considerare:
Membrii statici. Metodele statice se executa totdeauna in appdomain-ul apelantului.
Campurile statice sunt accesate direct din memorie (nu prin proprietati) si nu pot fi
accesate direct din afara appdomain original. Campurile statice pot fi accesate de
metoade ale instantei deoarece acestea se executa in “remote appdomain”.
Campuri ale instantei. Daca obiectul MBR expune campuri publice ale instantei, atunci
proxy generat in mod automat de runtime defineste proprietatile (se genereaza set si get)
pentru accesul campurilor pe obiectul remote. In general nu este recomandat sa se expuna
campuri publice ale instantei pentru ca violeaza principiul de incapsulare al obiectului.
Metodele System.Object. Pentru a creste performanta, apelurile la metodele mostenite
din System.Object sunt executate appdomain-ul apelantului. Daca obiectul MBR
suprascrie metoda Equals sau ToString, atunci acestea vor fi executate in appdomain al
obiectului remote.
.NET Remote Framework. Generalitati.
Infrastructura remoting consta din:
proxy ;
canale de comunicatie ;
mesaje.
Proxy sunt obiecte locale ce impersoneaza obiectul remote. Proxy expune exact aceleasi metode si proprietati ca si obiectul remote. Oricum, implementarea unui proxy pentru o metoda data face apel la obiectul channel. Proxy creaza impresia ca obiectul remote este in acelasi proces cu clientul.
Obiectul channel reprezinta o conexiune la aplicatia remote. Fiecare obiect channel contine un
obiect formatter care converteste apelul metodei intr-un mesaj cu un format cunoscut.
Mesajul este trimis la server ce asculta pe un anumit canal de comunicatie. Folosind obiectul
formatter al canalului se deserializeaza mesajul si se trimite la un obiect intern numit
StackBuilder. Acest obiect converteste mesajul intr-un apel de metoda si apeleaza metoda pe
obiectul remote.
Obiecte Well-Known vs. Obiecte Client-Activated
Un appdomain poate expune tipuri MBR ca fiind obiecte well-known (server activated) sau obiecte client-activated.
Principala diferenta intre aceste obiecte o constituie modul cum sunt create si modul cum e
gestionat timpul de viata al acestora.
Obiecte well-known
Pentru obiectele well-known, atribuim un nume unic si cunoscut pe care clientul il paseaza runtime-ului pentru a se conecta la server. Serverul raspunde prin instantierea obiectului folosind constructorul implicit. In ceea ce priveste timpul de viata, un obiect well-known poate fi partajat de toti clientii si persista intre cererile clientilor (numite Singleton mode), sau pot exista in cadrul unui singur apel (numit SingleCall mode).
Obiectele wel-known sunt adesea cunoscute si sub numele de obiecte activate de server.
Obiecte client-activated
Un obiect client-activated permite clientului de a-l activa folosind orice ctor, nu numai ctor
implicit. Timpul de viata al unui obiect client-activated este dictat de Leasing Distributed
Garbage Collector, ce atribuie fiecarui asemenea obiect o anumita cuanta de timp (lease).
.NET runtime foloseste doua tipuri de proxy: proxy transparent si proxy real.
Proxy transparent – nu poate fi extins
Cand un client foloseste apeluri API runtime cum ar fi Activator.GetObject pentru a se conecta
la un obiect remote, runtime returneaza clientului un proxy transparent. Acest proxy furnizeaza
un nivel de interceptare pe partea clientului pentru runtime, permitand astfel verificarea
numarului corect de parametri pentru o metoda precum si tipurile acestora. De asemenea acest
proxy permite runtime-ului sa determine daca obiectul este rulat local sau la distanta.
In cazul cand obiectul este rulat local runtime va invoca direct metoda. Un proxy transparent impacheteaza apelul metodei si toti parametri intr-un obiect IMessage si il paseaza cu ajutorul metodei Invoke proxy-ului real (RealProxy).
Proxy transparent este creat in mod dinamic de runtime si nu poate fi extins pentru a crea proxy
personalizate.
Proxy transparent este continut intr-un real proxy.
Proxy real – poate fi extins
Proxy real este creat in mod dinamic de RT. Proxy real poate fi extins si personalizat.
In fapt, proxy real furnizeaza un punct de interceptie pentru dezvoltator pentru a insera cod
pentru procesare in timpul unui apel remote.
Proxy transparent apeleaza metoda Invoke a proxy-ului real.
Implementarea implicita a metodei Invoke face ca aceasta sa paseze obiectul IMessage
obiectului channel.
Generarea dinamica a proxy-ului
Generarea dinamica a proxy-ului are la baza reflection si clasa ObjRef.
ObjRef memoreaza informatiile necesare pentru a genera un proxy, folosit in comunicarea cu
un obiect remote.
In MSDN ObjRef este definita astfel:
[SerializableAttribute]
[ComVisibleAttribute(true)]
[SecurityPermissionAttribute(SecurityAction.LinkDemand,
Flags = SecurityPermissionFlag.Infrastructure)]
[SecurityPermissionAttribute(SecurityAction.InheritanceDemand,
Flags = SecurityPermissionFlag.Infrastructure)]
public class ObjRef : IObjectReference, ISerializable
Un ObjRef este o reprezentare serializabila a unui obiect ce extinde MarshalByRefObject.
Un ObjRef este folosit pentru a transfera o referinta a obiectului intre frontierele AppDomain. Crearea unui ObjRef pentru un obiect este cunoscuta ca marshaling.
ObjRef contine informatii ce descriu Type si clasa obiectului ce va fi transmis, locatia sa
exacta, informatii despre comunicare.
Dupa ce o clasa – ce a implementat MarshalByRefObject – este transmisa (marshaled),
obiectul ObjRef ce o reprezinta este transferat prin canalul de comunicatie in alt AppDomain,
posibil in alt proces sau alt calculator.
Cand ObjRef este deserializat (vezi serializarea XML si SOAP) in AppDomain destinatie, se va crea un proxy transparent pentru obiectul remote MBR. Operatia este cunoscuta sub numele de « unmarshaling ».
Sa consideram urmatorul exemplu
public class Customer : MarshalByRefObject
{
// Implementare …
}
public class CustomerService : MarshalByRefObject
{
public Customer CreateCustomer()
Universitatea “Al. I. Cuza” Iasi 18/77 14.12.2011
.NET Remoting. Servicii Web
Ioan Asiminoaei
{
return new Customer();
}
}
Avem doua obiecte MBR.
Clasa CustomerService expune o metoda ce creaza si retureaza un obiect Customer.
Presupunand ca aplicatia server expune tipul CustomerService ca un obiect well-known,
urmatorul cod din client poate fi folosit pentru a crea un proxy la obiectul remote:
CustomerService custSvc = (CustomerService) Activator.GetObject(…);
Metoda GetObject accepta argumente ce specifica tipul si locatia obiectului remote dat.
Cu aceasta informatie, runtime din client va folosi reflection pe obiectul remote pentru a obtine
metodele publice si semnatura acestora in vederea crearii unui proxy transparent.
Name Description
Activator.GetObject (Type,
String)
Creaza un proxy pentru obiectul well-known indicat de
tipul specificat si URL.
Activator.GetObject (Type,
String, Object)
Creaza un proxy pentru obiectul well-known indicat de tipul specificat, URL si canalul de date.
Generare proxy si ObjRef
Fie urmatorul cod
Customer cust = custService.CreateCustomer();
Aceasta metoda returneaza o referinta la un obiect Customer. Deci RT de pe partea clientului
trebuie sa genereze un proxy pentru acest obiect dar fara a apela Activator.GetObject.
Aici intervine serverul care nu va returna o referinta la obiectul Customer, ci va returna un
ObjRef.
ObjRef este un obiect CLR ce contine informatii privitoare la tipul remoting:
numele tipului obiectului remote, calificat complet, incluzand informatia despre
assembly;
numele tipurilor tuturor obiectelor remote ale clasei de baza;
numele tipurilor tuturor interfetelor implementate de obiectul remote;
obiectul URI si informatii privitoare la canalul inregistrat pe server.
ObjRef este transmis prin valoare, deci acesta este serializat si returnat clientului in locul
obiectului Customer. Rt din client foloseste aceasta informatie continuta in ObjRef pentru a
genera proxy.
Un ObjRef este creat si serializat ori de cate ori un obiect MBR este pasat intr-o metoda remote
sau returnat dintr-o metoda remote, fie ca valoare de retur sau un parametru out.
// undeva in cod …
Customer cust = new Customer();
remoteObject.SomeMethod(cust);
Daca remoteObject este un alt obiect remote, atunci apelul SomeMethod trimite un obiect
Customer in obiectul remote. Deoarece Customer este de tip MBR se creaza un ObjRef se
serializeaza si se trimite appdomain remote unde este utilizat pentru a genera un proxy.
Obiectul Customer folosit mai sus nu se incadreaza nici in well-known nici in client-activated (nu este creat nici de client, nici de server ci de o metoda). Un asemenea obiect se comporta ca un obiect client-activated.
Channels si Formatters
Channels reprezinta o abstractizare pentru remoting framework, abstractizare ce ascunde
complexitatile protocolului utilizat pentru comunicare intre client si server. Obiectul channel este
responsabil pentru transportul fiecarui apel de metoda de la client la server si a valorilor returnate
de server catre client.
CLR furnizeaza clase de baza si interfete ce pot fi utilizate pentru a dezvolta channel si formatter
personalizati.
HTTP Channel vs. TCP Channel
TCP channel (reprezentat de clasa TcpChannel) furnizeaza conectivitate folosind protocolul
TCP/IP. Implicit acest channel foloseste BinaryFormatter pentru a converti apelurile intr-un
format binar proprietar. Acest TCP channel necesita stabilirea unui port unic pe masina server.
Are probleme cu firewall-ul.
HTTP channel (reprezentat de clasa HttpChannel) foloseste protocolul HTTP. Acest channel
foloseste SoapFormatter pentru a converti apelurile de metoda intr-un format SOAP.
Cantitatea de informatii de transferat pe retea este mare in acest caz.
Deoarece HTTP lucreaza cu portul 80, de obicei firewall-ul nu blocheaza acest port pentru a
avea conexiune la internet. In concluzie lucreaza bine cu firewall-ul.
Inregistrarea canalelor
Atat serverul cat si clientul trebuie sa aleaga un canal cu care sa se inregistreze la runtime.
Aceasta inregistrare poate fi facuta folosind clasa ChannelServices.
ChannelServices : furnizeaza metode statice folosite in inregistrarea canalului, rezolutie si
desoperirea URL.
Inregistrarea unui canal implica doua lucruri:
1. se stabileste un punct final (endpoint). Un endpoint descrie locatia aplicatiei in cadrul
unei retele. Endpoint consta din IP masinii si un numar de port (10.77.1.12:13000).
2. inregistrarea unui channel in server face ca RT sa stabileasca un fir “listener” ce se
executa in acelasi appdomain. Scopul acestui fir este de a asculta pe endpoint pentru
apeluri la metode remote si a trimite rezultate inapoi la client.
RT permite numai un channel pentru un tip de data sa fie inregistrat la nivel de appdomain.
Intr-un appdomain putem avea HTTP channel cat si TCP channel.
2.2. Standarde e -business
Limbajele si protocoalele devin critice pentru interoperabilitate si integrare. Alte organizatii dezvolta afaceri pentru a extinde circulatia informatiei între sisteme interne si externe printr-un standard de dezvoltare.
Un numar de tehnologii care conduc integrarea afacerilor sunt discutate în continuare:
XML este un limbaj extensibil care descrie alte limbaje, da libertate afacerii de a-si organiza propriul limbaj de marcaje personalizat.
eXtensible Markup Language(XML) este un meta-limbaj de marcare recomandat de Consorțiul Web pentru crearea de alte limbaje de marcare, cum ar fi XHTML, RDF, RSS, MathML, SVG, OWL etc. Aceste limbaje formează familia de limbaje XML.
Meta-limbajul XML este o simplificare a limbajului SGML (din care se trage și HTML) și a fost proiectat în scopul transferului de date între aplicații pe internet, descriere structură date.
XML este acum și un model de stocare a datelor nestructurate și semi-structurate în cadrul bazelor de date native XML.
Datele XML pot fi utilizate în limbajul HTML, permit o identificare rapidă a documentelor cu ajutorul motoarelor de căutare. Cu ajutorul codurilor javascript, php etc. fișierele XML pot fi înglobate în paginile de internet, cel mai elocvent exemplu este sitemul RSS care folosește un fișier XML pentru a transporta informațiile dintr-o pagină web către mai multe pagini web.
Avantaje:
extensibilitate (se pot defini noi indicatori dacă este nevoie)
validitate (se verifică corectitudinea structurală a datelor )
oferă utilizatorilor posibilitatea de a-și reprezenta datele într-un mod independent de aplicație
XML este simplu și accesibil (sunt fișiere text create pentru a structura, stoca și a transporta informația)
poate fi editat, modificat foarte ușor (necesită doar un editor text simplu precum notepad, wordpad etc.)
XML da posibilitatea aplicatiilor si bazelor de date sa schimbe informatii între ele si poate fi folosit pentru a stoca orice tip de informative structurata. Are abilitatea de a transfera informatii între diferite sisteme informatice de aplicatii, care fara acesta, n-ar fi în stare sa comunice între ele. XML este cu mult mai flexibil si extensibil decât comunicatiile traditionale prin mesaje sau comunicatiile middleware. Cu XML, aplicatiile pot trimite informatii pe Internet folosind HTTP.
SOAP defineste un protocol pentru RPC (executia procedurilor la distanta – o comunicatie de tip aplicatie -catre-aplicatie care ascunde complexitatile retelei), folosind HTTP si XML. Este o cale relativ simpla de schimb de informatie între aplicatii, într-un mediu descentralizat si distribuit, deoarece permite conexiuni ale punctelor de conectare catre Web si beneficiaza de folosirea serviciilor.
SOAP – Simple Object Access Protocol – este un protocol de comunicare intre computere prin intermediul unei retele bazat pe XML.
Acesta este alcatuit din trei parti:
un ambalaj, care defineste ce se afla in mesaj si cum trebuie procesat;
un set de reguli de codare;
o conventie pentru procedurile de trimitere – primire.
Exemplu de modalitate de utilizare a procedurilor SOAP: un mesaj este trimis catre un site web cum ar fi un site de preturi pentru proprietati imobiliare cu parametrii necesari unei cautari. Site-ul va returna un document in format XML cu rezultatul cautarii (preturi, locatie, functionalitati, etc.). Avand datele astfel formatate, acestea pot fi integrate direct intr-o alta aplicatie sau website. SOAP este un protocol de mesaje bazat pe XML si este acum parte a arhitecturii ebXML.
UDDI (Universal Description Discovery and Integration) este un standard care asigura
o fundatie pentru un registru de companii si un mediu de stocare pentru serviciile lor Web. Este construit în vârful standardelor Internet actuale. Registrul de afaceri UDDI este un director cu servicii Web universale.
jUDDI este o implementare deschisa bazata pe Java a registrului UDDI si da posibilitatea
clientilor de a accesa registre UDDI din aplicatiile lor.
WSDL (limbaj de descriere a serviciilor Web) devine un standard de facto pentru descrierea serviciilor Web într-un format XML.
WSDL este extensibil sa poata permite descrierea punctelor de conectare si a mesajelor lor, indiferent de ce tip de formate de mesaje sau protocoale de retea sunt folosite pentru a
comunica.
EbXML (XML tip business electronic) este o infrastructura XML pentru afacerile electronice globale care le permite sa se descopera între ele si sa-si conduca afacerile
bazându-se pe mesaje XML. ebXML permite afacerilor sa implementeze protocoale de
servicii Web (precum WSDL, SOAP, UDDI).
BizTalk este un standard care defineste cum e structurata informatia si mecanismele
care sunt necesare pentru a procesa aceasta informatie. Fundatia BizTalk si serverul Biz-
Talk sunt platforme Microsoft pentru comunicare intercompanii si integrarea aplicatiilor
„enterprise”.
RosettaNet este un standard e-business care include: dictionarul de afaceri, dictionarul
tehnic, fundatia de implementare RosettaNet (RNIF) si procesele de interfata cu partenerii.
Fundatia RosettaNet include procese de afaceri bazate pe XML cunoscute ca „procese de interfata cu partenerii” (PIP) si dictionare de definitii comune pentru partile de computer si termenii de afaceri. RosettaNet PIP descrie pasii specifici implicati în completarea unui proces afacere-spre-afacere (ca de exemplu procesarea unui ordin de cumparare pe Inte rnet).
XAML (limbaj de marcaje pentru tranzactii) ofera coordonarea si procesarea tranzactiilor
on-line în servicii Web XML. XAML defineste un set de mesaje în format XML si modele interactive pe care serviciile Web le pot folosi pentru tranzactiile de afaceri între parteneri din Internet.
Exemplu: tehnologia Glue
Firma Glue Technology livreaza o solutie deschisa, bazata pe Java si XML pentru integrarea
usoara a aplicatiilor distribuite si a serviciilor Web. Serviciile Web sunt parti de software reutilizabile accesibile prin Internet, care permit conectarea dinamic a a aplicatiilor si a proceselor automate de afaceri peste sisteme disparate. Software-ul de integrare Glue si solutia de servicii conecteaza membrii unui lant de valori, incluzând operatii interne, afaceri si parteneri de comert, canale de client si da posibilitatea automatizarii proceselor de afaceri prin Internet si integrarea aplicatilor disparate si a sistemelor folosite în schimbul informational de afaceri.
Arhitectura Glue este conceputa sa fie „plugand- play”, sa integreze usor infrastructurile
existente compuse din diferite componente, servere de aplicatii, baze de date, pachete de software si alte aplicatii. Glue coexista cu celelalte tehnologii ale informatiei pentru a permite intra si interprocesele si desfasurarea de eveniment e prin integrarea atât a datelor cât si a etapelor proceselor de afaceri – sau permitând datelor si proceselor de afaceri sa comunice unele cu altele peste aplicatii variate si între organizatii conectate, folosind resurse limita.
Beneficii tehnice ale folosirii Glueware
Glueware duce e-business-ul catre urmatorul nivel, dând posibilitatea celor care-l folosesc sa foloseasca interfete multiple pentru a se conecta unui context de afaceri cu partenerii
de comert si sa participe în procesele de afaceri fara sa fie nevoie de introducerea datelor manual.
Dintre avantajele folosirii Glueware, amintim:
Client inteligent – folosind Glueware API, toate configurarile de server sunt abstractizate
si configurabile din afara de catre aplicatii care folosesc setul de API. Aplicatiile care folosesc API pot fi servicii Web, pachete software (de exemplu SAP), site-uri Web, JAVA, COM si aplicatii .NET. Agentii (clientii) sunt controlati, monitorizati si configurati în mod dinamic prin consola de administrare Glueware. API este simplu de utilizat, dar puternic, complet si suporta LDAP si SNMP.
Administrare globala si control – Glueware pune la dispozitie infrastructura necesara pentru urmarirea mesajelor, monitorizarea si controlul aplicatiilor client si administrarea serviciilor Glueware.
Abstractizarea tehnologiei – Nu exista dependenta de un singur software de server.
Glueware suporta JMS, Vitria, IBM MQ sau TIBCO si servere de aplicatii precum Weblogic si protocoale (TCP/IP, HTTP(S), SOAP). Serviciile sunt configurabile si devin plug-and-play.
SOAP and .NET – Glueware foloseste SOAP pentru formatul mesajelor. Mesajele
pot fi configurate sa suporte BizTalk, UDDI, RosettaNet si standarde OASIS.
Calitatea serviciului – Glueware asigura diferite niveluri de calitate pentru transportul
mesajelor peste Internet. Mesajele pot fi configurate sa fie integre, garantate si tranzactionabile.
Avantaje ale afacerilor electronice
Utilizând tehnologia Glue se evidentiaza o serie de avantaje ale afacerilor electronice:
Colaborare e-business – Arhitectura peerto- peer (P2P) si serviciile Web lucreaza
strâns legate sa salveze problemele actuale ale IT, precum distributia aplicatiilor si utilizarea
resurselor pe desktop-uri. Platforma Glueware permite organizatiilor sa obtina beneficii productive dintr-un set complet de procese de afaceri si membri din lantul de valori
Distributia aplicatiilor si utilizarea resurselor – P2P este folositor companiilor cu retele
mari, atâta timp cât foloseste CPU MIPS si hard-diskuri puternice, care distribuie munca
peste multiple sisteme. Rezultatele afacerii sunt împartite între membrii participanti.
Agenti inteligenti – În mediul P2P, agentii inteligenti colaboreaza pentru a facilita
schimbul de informatie si activitati între sistemele participante.
Costuri de infrastructura reduse – Glueware integreaza sistemele proprietare cu noi aplicatii rulând prin nodurile lantului de valori.
Aplicativitate în lantul de valori global –
Integrare B2B – Glueware pune la dispozitie infrastructura necesara pentru unitati de afaceri sa colaboreze în timp real si securizat.
2.3. Aplicații ASP.NET
ASP.NET este o tehnologie Microsoft pentru crearea de aplicații web și servicii web. ASP.NET este succesorul lui ASP (Active Server Pages) și beneficiază de puterea platformei de dezvoltare .NET, și de setul de instrumente oferite de mediul de dezvoltarea al aplicației „Visual Studio .NET”.
Cateva dintre avantajele ASP .NET sunt:
ASP .NET are un set larg de componente, bazate pe XML, oferind astfel un model de programare orientat obiect (OOP).
ASP .NET ruleaza cod compilat, ceea ce crește performanțele aplictiei web. Codul sursa poate fi separat în două fișiere, unul pentru codul executabil, iar un altul pentru continutul paginii (codul HTML și textul din pagină) .
.NET este compatibil cu peste 20 de limbaje diferite, cele mai utilizate fiind C# si Visual Basic.
Pentru construcția aplicațiile ASP.NET .NET Framework oferă foarte multe API-uri și instrumente de dezvoltare.
ASP.NET oferă un model de programare și o infrastructură prin cu ajutorul cărora se pot dezvolta atât aplicații Web cât și servicii Web XML.
Principalele caracteristici ale tehnologiei ASP.NET sunt următoarele:
Aplicațiile ASP.NET sunt compilate.
ASP.NET este multi-limbaj. Se poate alege orice limbaj CLI pentru a dezvolta o aplicație Web. Aceasta deoarece rezultatul compilării va fi cod IL adică un cod scris pentru .NET și poate rula în interiorul unui mediului protejat oferit de CLR.
aplicație ASP.NET folosește mediul de execuție oferit ce CLR.
Acest lucru implică:
Managementul automat al memoriei;
Type Safety;
Multithreading: o aplicație Web poate utiliza la un moment dat mai multe fire de execuție pentru a: executa operații asincrone (citirea unui fișier, apelul unui serviciu Web) sau pentru a executa o operație în mod continuu pe durata de viață a aplicației Web (de exemplu un fir cu prioritate scăzută care la intervale regulate trebuie să salveze într-o bază de date niște informații );
ASP.NET este orientat obiect. Cel mai bun exemplu este acela al controalelor server-side: controalele ce pot fi create și modificate programatic astfel încât să răspundă într-un anumit fel la evenimente sau să aibă un anumit aspect.
Aplicațiile ASP.NET sunt ușor de instalat și configurat.
Directoare din rădăcina aplicației recunoscute automat de ASP.NET 2.0
Bin
Conține toate assembly-urile precompilate (de obicei Dll) pe care aplicația ASP.NET le folosește: clasele compilate ale paginilor Web și/sau serviciilor Web precum și assemblyurile
referențiate.
App_Code
Conține codul sursă pentru compilarea dinamică. De obicei sunt componente separate de logica aplicației: clase pentru logica de login sau acces la baza de date folosite în DAL (Data Access Layer). Assembly-urile rezultate în urma compilării nu sunt depuse în Bin ci în directoare temporare utilizate pentru compilarea dinamică.
App_GlobalResources
În acest director sunt păstrate resursele globale ce sunt accesate de orice pagină din aplicație. Aici pot fi păstrate și fișierele necesare pentru globalizare.
App_LocalResources Are aceeași semnificație cu App_GlobalResources numai că
aceste resurse sunt dedicate numai unei singure pagini.
App_Data
Acest director este folosit pentru păstrarea datelor fie că sunt fișiere de baze de date (de exemplu *.mdf) fie fișiere XML ce conțin date. Tot aici se păstrează și baza de date pentru ce
furnizează informații despre roluri și autentificare.
App_WebReferences Conține referințe către servicii Web folosite de aplicație:
fișiere *.wsdl și *.disco.
App_Browsers
Acest director conține definiții pentru tipurile de browser-e pentru care este destinată aplicația. Sunt fișiere XML ce descriu capabilitățile pentru mai multe tipuri de browser-e.
Deși ASP.NET realizează acest lucru global prin intermediul acestor definiții se pot obține comportamente diferite ale aplicației în funcție de browser.
App_Themes Aici sunt păstrate temele și skin-urile folosite în paginile aplicației.
2.4. SharePoint Designer 2010
SharePoint Designer 2010 este un program de proiectare pagini Web și de aplicații, utilizat pentru a construi și a particulariza site-urile și aplicațiile SharePoint.
Cu SharePoint Designer 2010, se poate crea pagini bogate în date, construe soluții puternice care permit fluxul de lucru și să proiecta aspectul și stilul site-ului dvs. Site-urile pe care le creați pot varia de la site-uri mici pentru gestionarea proiectelor la soluții de tip portal pe bază de tablouri de bord, pentru întreprindere.
Existăi posibilitatea să efectuați toate acestea fără să scrieți nicio linie de cod.
Microsoft SharePoint Designer 2010. Introducere
Site-urile SharePoint își sporesc rapid complexitatea, pe măsură ce se dezvoltă pentru a face față cerințelor firmelor de toate tipurile și mărimile. Site-urile se bazează pe procese, mult mai dinamice și mai bogate în date.
SharePoint Designer 2010 asigură un mediu unic în care există posibilitatea de a lucra la site, în listele și bibliotecile sale, în pagini, surse de date, fluxurile de lucru, permisiuni etc. Este posibilitatea de a vedea aceste componente cheie ale site-ului într-un singur loc, precum și relațiile dintre aceste obiecte.
Este la dispoziție cadrul pentru a începe proiectarea si construirea site-uri de soluții pentru firme foarte particularizate. Începeți prin a vă conecta la sursele de date, atât în interiorul, cât și în exteriorul SharePoint. Prezentați-le utilizatorilor aceste informații și permiteți-le să remită informații utilizând un site SharePoint sau o aplicație client Office. Creați fluxuri de lucru foarte particularizate care automatizează procesele de afaceri. În sfârșit, particularizați stilul și aspectul site-ului, astfel încât să corespundă cu marca organizației dvs.
Deschiderea SharePoint Designer 2010
SharePoint Designer 2010 este un program client care se instalează pe computerul local. De asemenea, este foarte bine integrat cu SharePoint. Ca urmare, poate fi lansat direct de pe computer, utilizând meniul Windows Start și locații diverse în SharePoint, cum ar fi meniul Acțiuni site,
Există mai multe locuri de unde se poate deschide SharePoint Designer 2010, de exemplu, atunci când particularizați liste, vizualizări, fluxuri de lucru și pagini coordonatoare. Dacă nu ați instalat încă SharePoint Designer 2010, prima dată când îl lansați din SharePoint vi se solicită să îl descărcați și să îl instalați de pe Web. Următoarea dată când deschideți SharePoint Designer 2010, se deschide imediat. De asemenea, este disponibil și în meniul Start Windows
SharePoint Designer 2010 și caracteristicile sale individuale pot fi restricționate sau dezactivate utilizând pagina Setări SharePoint Designer.
Fila Fișier din SharePoint Designer 2010
Când deschideți SharePoint Designer 2010 din meniul Windows Start, primul lucru pe care îl vedeți este fila Fișier. Pe acest ecran, aveți opțiunea de a particulariza un site existent sau a crea un site nou.
Pentru a particulariza un site existent, răsfoiți la un site existent, particularizați Site-ul meu sau selectați unul dintre site-urile recente pe care le-ați deschis în SharePoint Designer 2010.
Pentru a crea un site nou, aveți posibilitatea să utilizați un șablon nou, să alegeți dintr-o listă de șabloane sau să alegeți un șablon dintre șabloanele deosebite. ă, apoi se deschide în SharePoint Designer 2010.
Interfața SharePoint Designer 2010
SharePoint Designer 2010 asigură un mediu în care aveți posibilitatea să creați, să particularizați și să implementați site-uri și soluții SharePoint. Acest lucru este posibil datorită interfeței de utilizator, care arată toate componentele care alcătuiesc site-ul și relațiile dintre componentele respective.
Interfața din trei părți: Navigare, Rezumat, Panglică
Există trei zone principale în interfața SharePoint Designer 2010 în care lucrați pentru a proiecta și a construi site-uri:
Panoul Navigare se utilizează pentru a naviga la părțile sau componentele majore ale site-ului
Paginile Galerie și Rezumat se utilizează pentru a vedea liste cu fiecare tip de componentă și rezumate ale unei anumite componente.
Panglica se utilizează pentru a efectua anumite acțiuni în componenta selectată.
Panoul de navigare afișează componentele care alcătuiesc site-ul: liste, biblioteci, tipuri de conținut, surse de date, fluxuri de lucru etc. Pentru a edita una dintre aceste componente, de exemplu o listă Anunțuri, deschideți Liste și biblioteci, iar aceasta vă va duce la o pagină galerie în care se afișează toate listele și bibliotecile.
De aici, aveți posibilitatea să deschideți lista Anunțuri, iar aceasta vă duce la o pagină de rezumat pentru lista respectivă. Pe pagina de rezumat, vedeți vizualizările, formularele, fluxurile de lucru asociate și altele. Pentru a edita una dintre vizualizări, deschideți-o direct din această pagină.
Interfața SharePoint Designer 2010 facilitează identificarea diverselor componente ale unui site, detalierea și editarea uneia dintre componente și întoarcerea la vizualizarea principală a site-ului.
Deschiderea filei Fișier
Pe lângă lucrul cu diverse obiecte din site în SharePoint Designer 2010, este util să vizualizați și să accesați setări de site sau de aplicație de dimensiuni mai mari. Aceasta include deschiderea unui alt site, adăugarea de pagini, importul de fișiere și modificarea setărilor aplicației SharePoint Designer 2010. Efectuați aceste acțiuni pe fila Fișier, care este primul ecran pe care îl vedeți când deschideți SharePoint Designer 2010 din meniul Windows Start sau dintr-o comandă rapidă de pe desktop.
Faceți clic pe fila Fișier din colțul din stânga sus pentru a accesa această vizualizare. Faceți clic pe Înapoi pentru a vă întoarce la interfața SharePoint Designer 2010.
Pilonii particularizării în SharePoint Designer 2010
SharePoint Designer 2010 poate fi utilizat pentru a crea și a particulariza site-uri și soluții care conțin o logică a aplicațiilor, dar care nu necesită scrierea unui cod. Aveți posibilitatea să îl utilizați pentru a adăuga sau a modifica surse de date, pentru a particulariza vizualizări de liste și de date, pentru a construi și a implementa fluxuri de lucru de afaceri, pentru a proiecta o marcă de corporație și multe altele. Însă, începeți să beneficiați cu adevărat de puterea și de funcționalitățile SharePoint Designer 2010 atunci când transformați un site predefinit într-o soluție de afaceri de succes pentru organizația dvs.
Conectarea la date în interiorul și în exteriorul SharePoint
Cu SharePoint Designer 2010, aveți posibilitatea să vă conectați la numeroase surse de date, apoi să integrați datele respective în site și în aplicațiile client Office. În consecință, utilizatorii dvs. pot vedea și interacționa cu datele de afaceri de pe site și din cadrul programelor pe care le alegeți, în loc să se conecteze separat la respectivele surse de date.
Direct de pe Panglică, aveți posibilitatea să vă conectați la o bază de date externă, serviciul SOAP Service, serviciul REST etc.
Conectarea la sursele de date este o caracteristică puternică din SharePoint Designer 2010, deoarece există foarte multe opțiuni acceptate care se pot utiliza pentru a pune datele la dispoziția utilizatorilor. Cu ajutorul conexiunilor de date, aveți posibilitatea să reuniți liste și biblioteci, baze de date și surse de date externe, servicii Web etc.
Iată o examinare a surselor de date la care aveți posibilitatea să vă conectați utilizând SharePoint Designer 2010.
Liste și biblioteci
Listele și bibliotecile reprezintă o sursă de date uzuală pe care o veți utiliza în site. Sunt unice în comparație cu alte surse de date, datorită faptului că fac parte deja din SharePoint și utilizează aceeași bază de date ca SharePoint. Nu trebuie să efectuați niciun pas suplimentar pentru a crea o conexiune la aceste surse de date, pur și simplu adăugați-le utilizând galeria Liste și biblioteci din SharePoint Designer 2010 sau adăugați-le în browser. După ce ați creat o listă sau o bibliotecă, aveți posibilitatea să particularizați coloanele, tipurile de conținut sau alte atribute de schemă asociate acesteia.
Date de afaceri externe
Serviciile de conectivitate cu aplicații de business (BCS) este un cadru bazat pe SharePoint care furnizează interfețe standardizate pentru datele și procesele de afaceri existente. Cu BCS, aveți posibilitatea să conectați surse de date de afaceri externe – SQL Server, SAP și Siebel, servicii Web și aplicații particularizate – la site-uri SharePoint și la aplicații Office.
În SharePoint Designer 2010, aveți posibilitatea să vă conectați la datele externe, dacă creați tipuri externe de conținut. Acestea reprezintă datele din sursa de date externă, prin stocarea detaliilor conexiunii, ale obiectelor utilizate în aplicația de bussiness, ale metodelor de a crea, a citi, a actualiza sau a șterge și ale acțiunilor pe care utilizatorii le pot întreprinde asupra obiectelor.
Tipul de date extern se stochează în Catalog date de lucru. După ce ați creat tipul de date extern, dvs. și ceilalți membri ai organizației aveți posibilitatea să creați cu ușurință liste, vizualizări, formulare, fluxuri de lucru SharePoint și chiar integrarea clientului Office, pe baza acestuia. Tipul de date extern devine o parte din SharePoint, ca orice altă componentă, ceea ce vă permite să creați interfețe de utilizator complet particularizate în aceste surse de date externe.
Baze de date externe
Adăugarea unei baze de date ca sursă de date vă permite să integrați date dintr-o altă bază de date în site. Aveți posibilitatea să vă conectați la Microsoft SQL Server, la Oracle și la orice bază de date care acceptă protocoalele OLE DB și ODBC. Trebuie să știți doar numele serverului pe care se află baza de date, furnizorul de date și tipul de autentificare de utilizat. După ce adăugați și configurați baza de date ca sursă de date, creați vizualizări și formulare care le permit utilizatorilor dvs. să citească și să scrie date în sursa de date fără să părăsească din site-ul SharePoint.
Servicii Web XML prin SOAP
SOAP (Simple Object Access Protocol) este un protocol pentru schimbul de mesaje XML, care face posibilă conectare al diverse surse de date cu ajutorul unui serviciu XML. În SharePoint Designer 2010, aveți posibilitatea să îl utilizați pentru a vă conecta la o sursă de date sau la alt site din organizație sau la un site de pe Internet, indiferent de tehnologia acestuia, limbajul de programare sau platformă. Aveți posibilitatea să utilizați un serviciu XML pentru a afișa un convertor de monede, o cotație bursieră, un calculator sau serviciul meteo pe site-ul dvs.
Scripturi la nivel de server prin REST
REST (Representational state transfer) este un stil arhitectural de software în rețea care utilizează tehnologiile și protocoalele de pe Web, nu este doar o metodă pentru construirea serviciilor Web. Aveți posibilitatea să utilizați acest tip pentru a obține date de la un site prin citirea unui script desemnat de pe server care descrie conținutul. Asemănător cu SOAP, aveți posibilitatea să utilizați acest stil în SharePoint Designer 2010 pentru a vă conecta la o sursă de date de pe alt site pentru a afișa, de exemplu, un convertor de monede, o cotație bursieră, un calculator sau serviciul meteo. Acest tip de conexiune de date este mai simplu de implementat decât SOAP, dar este restricționat la HTTP.
Fișiere sursă XML
Dacă organizația dvs. stochează datele în fișiere XML, aveți posibilitatea să vă conectați la aceste fișiere ca sursă de date în SharePoint Designer 2010. Pentru a vă conecta la fișierele XML ca sursă de date, aveți posibilitatea să le creați direct în SharePoint Designer 2010, să le importați dintr-o locație de pe computer sau din rețea sau să vă conectați la ele într-o locație externă.
Încheierea ciclului soluției de afaceri în SharePoint
În SharePoint Designer 2010, se pot realiza mult mai multe decât particularizarea de bază a site-ului. Există posibilitatea să creați soluții de afaceri de impact care conțin conexiuni de date, interfețe de utilizator bogate în date, fluxuri de lucru particularizate și aplicarea completă a mărcii într-un site. Toate acestea se pot realiza în SharePoint și urmați ciclul de viață al implementării aplicației, care se termină cu o soluție care poate fi implementată.
CAPITOLUL 3 XML ca bază de date
3.1 Este XML-ul o bază de date?
Un document XML este o bază de date în sensul cel mai strict al cuvântului și anume este o colecție de date. Având formatul unei baze de date documentele XML prezintă anumite avantaje, dar si deavantaje. De exemplu este auto-descris (tag-urile descriu structura și numele tipurilor de date, dar nu și semantica), este portabil (Unicode), și poate descrie date în structuri de arbori sau grafuri. Dezavantaje – este prolixs(neclar) și accesul la date este greoi datorită analizării și conversiei textului.
Putem considera și că XML și tehnologiile asociate constituie o bază de date în sensul mai larg al cuvântului – adică, un sistem de gestiune a bazelor de date (SGBD). XML oferă multe din avantajele bazelor de date: stocare (documente XML), scheme (DTD-uri, scheme XML, RELAX NG, ș.a,), limbaje de interogare (XQuery, XPath, XQL, XML-QL, QUILT, etc.), interfețe de programare (SAX, DOM, JDOM). Totuși multe componente ale bazelor de date convenționale: stocare eficientă, indecși, securitate, tranzacții și integritatea datelor, accesul multi-user, triggere, interogări făcute pe mai multe documente ș.a.
Astfel, se pot folosi documente XML ca o bază de date într-un mediu cu cerințe modeste și date puține, dar această soluție nu este viabilă într-un mediu pentru producție în masă, unde există mulți utilizatori, cerințe stricte de integritate a datelor și nevoia de o performanță bună.
3.2 Date și documente
Cel mai important factor în alegerea unei baze de date este ce va stoca aceasta: date sau documente. XML-ul poate fi folosit doar pentru a transporta date între baza de date și o aplicație sau poate fi folosit integral ca în cazul documentelor XHTML și DocBook. Finalitatea utilizării XML este importantă deoarece toate documentele centrate pe date au anumite caracteristici comune, la fel se întâmpla și în cazul informațiilor centrate pe documente.
3.2.1 Documente centrate pe date
Documentele centrate pe date sunt documente care folosesc XML-ul pentru transportul datelor. Aceste documente sunt folosite de către aplicații și nu are nici o importanță faptul că informațiile folosite au fost reținute pentru o perioadă de timp în documente XML. Exemple de documente centrate pe date sunt ordine de plată, programarea zborurilor, date științifice, ….
Documente centrate pe date au o structură regulată, datele sunt atomice (cea mai mică unitate independenta de date este un element sau un atribut). Ordinea elementelor care apar în document nu este importantă, decât în momentul validării documentului.
Informațiile care există în documentele centrate pe date pot proveni din baza de date (caz în care se dorește extragerea lor în fișiere XML), dar și din afara bazei de date (caz în care se dorește stocarea acestora în baza de date). Un exemplu de informații care provin dintr-o bază de date sunt cantitățile de date stocare în bazele de date relaționale, iar un exemplu de informații care se doresc a fi introduse într-o bază de date pot fi considerate datele științifice obținute de un sistem de măsurători și convertite în XML. De exemplu următorul ordin de vânzare este un document centrat pe date:
<OrdinVanzari NumarOV="12345">
<Client NumarClient="543">
<NumeClient>ABC Industries</NumeClient>
<Strada>123 Main St.</Strada>
<Oras>Chicago</Oras>
<Stat>IL</Stat>
<CodPostal>60609</CodPostal>
</Client>
<DataOrdin>981215</DataOrdin>
<Item NumarItem="1">
<Parte NumarParte="123">
<Descriere>
<p><b>Cheie reglabila:</b><br />
Hotel inoxidabil,
Garantie pe viata.</p>
</Descriere>
<Pret>9.95</Pret>
</Parte>
<Cantitate>10</Cantitate>
</Item>
<Item NumarItem="2">
<Parte NumarParte="456">
<Descriere>
<p><b>Separator:<b><br />
Aluminiu, un an garantie.</p>
</Descriere>
<Pret>13.27</Pret>
</Parte>
<Cantitate>5</Cantitate>
</Item>
</OrdinVanzari>
. În general orice site web care construiește documente HTML dinamic prin completarea unui template cu informații dintr-o bază de date poate fi înlocuit cu mai multe documente XML centrate pe date și unul sau mai multe stylesheet-uri XSL.
De exemplu, să considerăm următorul document care descrie un zbor:
<InfoZbor>
<LinieAeriana>ABC Airways</LinieAeriana> ofera <Numar>trei</Numar>
zboruri zilnice non-stop din <Origine>Dallas</Origine> spre
<Destinatie>Fort Worth</Destinatie>. Orele de plecare sunt
<Plecare>09:15</Plecare>, <Plecare>11:15</Plecare>,
and <Plecare>13:15</Plecare>. Sosirile sunt cateva minute mai tarziu.
</InfoZbor>
Acesta ar putea fi construit dintr-un fișier XML și un stylesheet simplu:
<Zboruri>
<LinieAeriana>ABC Airways</LinieAeriana>
<Origine>Dallas</Origine>
<Destinatie>Fort Worth</Destinatie>
<Zbor>
<Plecare>09:15</Plecare>
<Sosire>09:16</Sosire>
</Zbor>
<Zbor>
<Plecare>11:15</Plecare>
<Sosire>11:16</Sosire>
</Zbor>
<Zbor>
<Plecare>13:15</Plecare>
<Sosire>13:16</Sosire>
</Zbor>
</Zboruri>
3.2.2 Informații centrate pe documente
Documentele care folosesc viziunea centrată pe documente sunt, de obicei, acele documente care sunt destinate folosirii de către utilizatori. Exemple de astfel de documente sunt cărțile, email, anunțuri publicitare și aproape orice document XHTML scris de mână. Acestea sunt caracterizate de o structură mai puțin regulată, datele nu sunt atomice (cea mai mică unitate independentă de informație poate fi formată dintr-un element îmbinat cu alte informații din document). Ordinea elementelor care apar în document este aproape întotdeauna importantă.
Aceste tipuri de documente sunt de obicei scrise manual în XML sau în alte formate cum ar fi RTF, PDF sau SGML și apoi sunt transformate în XML. Spre deosebire de documentele centrate pe date aceste documente nu pot proveni din baze de date.
Spre exemplu următorul document ce conține descrierea unui produs este centrat pe documente:
<Produs>
<Intro>
<NumeProdus>Cheie reglabila</NumeProdus> de la <Producator>Full
Fabrication Labs,Inc.</Producator>este<Sumar>ca o cheie universala,
dar mai mica.</Sumar>
</Intro>
<Descriere>
<Paragraf>Cheia universala, care are <i> doua versiuni stanga si dreapta </i>, este confectionata din <b>cel mai fin hotel inoxidabil
</b>. Manerul cauciucat se adapteaza la mainile dumneavoastra
chiar si in cele mai aluneacoase situatii. Se poate regla
prin mai multe discuri.</Paragraf>
<Paragraf>Puteti:</Paragraf>
<Lista>
<Item><Link URL="Comanda.html">comanda propria dumneavoastra
cheie reglabila </Link></Item>
<Item><Link URL="Wrenches.htm">Cititi mai multe despre chei</Link></Item>
<Item><Link URL="Catalog.zip">Descarcati catalogul</Link></Item>
</Lista>
<Paragraf>Cheia reglabila costa <b>doar 44.90 RON</b> si, daca veti
comanda acum, veti primi un <b>ciocan</b>
cadou.</Para>
</Descriere>
</Produs>
3.3 Stocarea și recuperarea datelor
Pentru transferarea datelor între documente XML și o bază de date, este necesară maparea schemei documentului XML (DTD, Scheme XML, RELAX NG, etc.) pe schema bazei de date. Software-ul pentru transferul de date este construit peste această mapare. Software-ul poate folosi un limbaj de interogare XML (cum ar fi XPath, XQuery) sau poate transfera direct date conform cu maparea (echivalentul în XML al interogării SELECT * FROM Tabelă).
3.3.1 Maparea schemelor documentelor pe schemele bazelor de date
Mapările între schemele documentelor și schemele bazelor de date sunt efectuate pe tipurile elementelor, atribute, și text. Aproape întotdeauna se omit structurile fizice (cum ar fi entitățile și informația codificată) și unele structuri logice (cum ar fi instrucțiunile de procesare, comentariile). Aceste omiteri nu au o influență prea mare, deoarece baza de date și aplicația sunt interesate numai de datele din documentul XML.
O consecință a acestor transformări – adică stocarea datelor dintr-un document într-o bază de date și apoi reconstruirea documentului din datele existente în baza de date – este obținerea unui document diferit. Dacă acest lucru este acceptabil depinde de cerințele fiecărui proiect și poate influența alegerea softului.
De obicei sunt folosite două metode pentru a mapa schema unui document XML pe schema unei baze de date: maparea bazată pe tabele și maparea obiectual-relațională.
3.3.1.1 Maparea bazată pe tabele
Maparea bazată pe tabele este folosită de multe produse care efectuează transferul de date între un document XML și o bază de date relațională. Aceasta modelează un document XML ca o singură tabelă sau ca un set de tabele.
În funcție de software datele din coloane pot fi stocate ca elemente descendente sau ca atribute. În plus, produsele care folosesc mapări bazate pe tabele de multe ori includ metadate fie la începutul documentului fie ca atribute asociate fiecărui element din tabelă sau coloană.
Maparea bazată pe tabele este utilizată pentru serializarea datelor relaționale, ca în cazul transferării datelor între două baze de date relaționale. Dezavantajul acestei mapări este că nu poate fi folosită pentru un document XML care nu respectă formatul din exemplu.
3.3.1.2 Maparea obiectual-relațională
Maparea obiectual-relațională este folosită de către toate bazele de date relaționale care suportă XML și anumite produse middleware. Aceasta modelează datele din documentul XML ca un arbore de obiecte care sunt specifice datelor din document. În acest model, tipurile de elemente cu atribute sunt în general modelate în clase. Tipurile de elemente simple, atributele, și PCDATA sunt modelate ca proprietăți scalare. Modelul este apoi mapat pe bazele de date relaționale folosind tehnici de mapare obiectual-relaționale tradiționale. Astfel clasele sunt mapate pe tabele, proprietățile scalare pe coloane, și proprietățile cu valori obiect sunt mapate pe perechi de chei primare/chei străine.
Denumirea de „mapare obiectual-relațională” este de fapt un termen impropriu, deoarece arborele de obiecte poate fi mapat direct pe baze de date orientate obiect și ierarhizate. Totuși este folosit pentru că majoritatea produselor care folosesc această mapare folosesc baze de date relaționale și acest termen este bine cunoscut.
3.3.2 Limbaje de interogare
Multe produse transferă date direct conform cu modelul pe care sunt construite. Deoarece structura documentului XML este de obicei diferită de structura bazei de date, aceste produse deseori conțin sau sunt folosite cu XSLT. Acesta dă posibilitatea utilizatorilor să transforme documente la structura modelului înaintea transferării datelor în baza de date, și invers. Deoarece procesarea XSLT poate fi scumpă, unele produse conțin un număr limitat de transformări în mapările lor.
Soluția pe termen lung la această problemă este implementarea unor limbaje de interogare care returnează XML. În prezent cele mai multe asemenea limbaje se bazează pe fraze SELECT integrate în șabloane. Se presupune că această situație se va schimba atunci când XQuery și SQL/XML vor fi finalizate, acestea aflându-se în lucru. Aproape toate limbajele de interogare XML sunt deocamdată read-only, deci vor fi necesare metode diferite pentru inserarea, actualizarea și ștergerea datelor (în viitor aceste facilitați vor fi adăugate).
3.3.2.1 Limbaje de interogare bazate pe șabloane
Cele mai des întâlnite limbaje de interogare care returnează XML din baze de date relaționale sunt cele bazate pe șabloane. În aceste limbaje, nu există o mapare predefinită între document și baza de date. Frazele SELECT sunt integrate într-un șablon și rezultatele sunt procesate de către software-ul care transfera date. De exemplu, următorul template folosește elementele <SelectStmt> pentru a include fraze SELECT și numele coloanelor pentru a determina unde trebuiesc plasate rezultatele:
<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<SelectStmt>SELECT Airline, FltNumber,
Depart, Arrive FROM Flights</SelectStmt>
<Zbor>
<LinieAeriana>$Airline</LinieAeriana>
<NumarFlt>$FltNumber</NumarFlt>
<Plecare>$Depart</Plecare>
<Sosire>$Arrive</Sosire>
</Zbor>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Rezultatul procesării unui asemenea șablon ar putea fi:
<?xml version="1.0"?>
<InfoZbor>
<Introducere> Urmatoarele zboruri sunt diponibile:</Introduction>
<Zboruri>
<Zbor>
<LinieAeriana>ACME</LinieAeriana>
<NumarFlt>123</NumarFlt>
<Plecare>Dec 12, 1998 13:43</Plecare>
<Sosire>Dec 13, 1998 01:21</Sosire>
</Zbor>
</Zboruri>
<Concluzie>Speram ca unul dintre ele va este de folos</Concluzie>
</InfoZbor>
Limbajele de interogare bazate pe șabloane pot fi foarte flexibile. Deși setul de caracteristici variază de la un produs la altul, există unele caracteristici comune:
Abilitatea de a plasa seturi de rezultate oriunde în documentul de ieșire, incluzând ca parametrii și frazele SELECT .
3.3.2.2 Limbaje de interogare bazate pe SQL
Limbajele de interogare bazate pe SQL folosesc fraze SELECT modificate, iar rezultatele sunt transformate în XML. Există câteva limbaje particulare de acest tip și cel mai simplu dintre acestea folosește fraze SQL imbricate (nested), care sunt transformate direct în XML imbricat (nested) conform cu maparea relațional-obiectuală. Un alt limbaj de acest tip folosește obiecte SQL 3, de asemenea transformate direct în XML. Un alt limbaj folosește fraze OUTER UNION și marcaje speciale pentru a determina cum sunt transformate rezultatele în XML.
În plus fața de limbajele particulare, un număr de companii s-au reunit în 2000 pentru a standardiza extensiile XML la SQL. Rezultatele lor fac parte acum din specificația ISO SQL și este cunoscută ca SQL/XML. SQL/XML introduce un tip de date XML și adaugă un număr de funcții la SQL, așa că este posibilă construirea elementelor XML și a atributelor din date relaționale.
De exemplu, următoarea interogare:
SELECT Orders.SONumber,
XMLELEMENT(NAME "Order",
XMLATTRIBUTES(Orders.SONumber AS SONumber),
XMLELEMENT(NAME "Date", Orders.Date),
XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument FROM Orders
construiește un set de rezultate cu două coloane. Prima coloană conține numărul ordinului de vânzări și a doua coloană conține un document XML. Există un document XML pe fiecare linie, construit din datele din linia corespunzătoare în tabelul de comenzi. De exemplu documentul pentru linia pentru ordinul de vânzare 123 ar putea fi:
<Ordin NumarOV="123">
<Data>04/29/07</Data>
<Client>Gallagher Industries</Client>
</Ordin>
3.3.2.3 Limbaje de interogare XML
Spre deosebire de limbajele de interogare bazate pe șabloane sau bazate pe SQL, care pot fi folosite numai cu baze de date relaționale, limbajele de interogare XML pot fi folosite pentru orice document XML. Pentru a folosi acest tip de limbaje cu baze de date relaționale, datele din baza de date trebuie să fie modelate ca XML.
Cu XQuery, poate fi folosită fie maparea bazată pe tabele fie maparea obiectual relațională. Dacă este folosită o mapare bazată pe tabele, fiecare tabelă este tratată ca un document separat și în fiecare interogare sunt specificate uniri între tabele, ca în SQL. Dacă este folosită o mapare obiectual-relațională atunci ierarhiile de tabele sunt tratate ca un singur document și sunt specificate uniri în mapare. Se preconizează că mapările bazate pe tabele vor fi utilizate în majoritatea implementărilor, în detrimentul bazelor de date relaționale, deoarece se consideră că sunt mai ușor de implementat și mai bine cunoscute de utilizatorii SQL.
Cu XPath, o mapare obiectual-relațională trebuie să fie folosită pentru a executa interogări peste mai multe tabele. Aceasta se întâmplă deoarece XPath nu suportă unirile între documente. Astfel, dacă ar fi folosită o mapare bazată pe tabele, ar fi posibilă interogarea unei singure tabele la un moment dat.
3.4 Stocarea și recuperarea documentelor
Pentru stocarea documentelor XML există două strategii de bază: stocarea lor în sistemul de fișiere sau ca un BLOB într-o bază de date relațională și acceptarea funcționalităților XML limitate, sau stocarea lor într-o bază de date nativă XML.
3.4.1 Stocarea documentelor în sistemul de fișiere
Dacă se lucrează cu un set simplu de documente, cum ar fi un set mic de documentație, cea mai ușoara cale de stocare este în sistemul de fișiere. Se pot folosi instrumente cum ar fi „grep” pentru interogarea lor, și „sed” pentru modificarea lor. Căutările complete de text în documentele XML sunt inexacte, pentru că ele nu pot distinge marcajul de text și nu pot înțelege folosirea entităților. Totuși, într-un sistem mic, aceste inexactități ar putea fi acceptabile. Dacă se dorește un simplu control al tranzacțiilor, documentele pot fi întreținute cu o versiune de control a sistemului cum ar fi CVS sau RCS.
3.4.2 Stocarea documentelor în BLOB-uri
O opțiune puțin mai sofisticată este stocarea documentelor ca BLOB-uri într-o bază de date relațională. Această modalitate oferă un număr de avantaje a bazelor de date: controlul tranzacțiilor, securitate, acces multiuser. În plus, multe baze de date au instrumente pentru căutări de text și pot face căutări complete de text, căutări aproximative, căutări sinonime și căutări fuzzy. Unele dintre aceste instrumente sunt construite pentru a recunoaște XML, ceea ce va elimina problemele care apar la căutările documentelor XML ca simplu text.
Atunci când se stochează documente XML ca BLOB-uri, se pot implementa ușor indexări simple care recunosc XML, chiar dacă baza de date nu poate indexa XML. O modalitate de a face acest lucru este crearea a două tabele, o tabelă index și o tabelă document. Tabela document conține o cheie primară și o coloană BLOB în care este reținut documentul. Tabela index conține o coloană în care se găsește valoarea ce va fi indexată și o cheie străină care duce la cheia primară a tabelei document.
Atunci când documentul este stocat în baza de date, el este căutat pentru toate instanțele elementului sau atributului care este indexat. Fiecare instanța este stocată în tabela index, împreuna cu cheia primara a documentului. Coloana de valori este apoi indexată, și permite unei aplicații să efectueze o căutare rapidă a unei anumite valori a unui element sau atribut și să recupereze documentul corespunzător.
3.4.3 Baze de date native XML
Dacă sunt necesare mai multe caracteristici decât cele oferite de unul din sistemele de mai sus, trebuie luată în considerare o bază de date nativă XML. Bazele de date native XML sunt baze de date construite special pentru a stoca documente XML. Ca și alte baze de date, acestea suportă tranzacții, securitate, acces multiuser, API-uri programatice, limbaje de interogare. Singura diferență față de alte baze de date este aceea că modelul lor interior este bazat pe XML și nu pe altceva, ca în cazul modelului relațional.
Bazele de date native XML sunt de obicei folosite pentru a stoca documente centrate pe documente. Principalul motiv este că oferă suport pentru limbaje de interogare XML, care oferă posibilitatea adresării unor întrebări de forma: „Extrage toate documente în care al treilea paragraf de la începutul secțiunii conține un cuvânt îngroșat”, sau oferă posibilitatea limitării căutărilor complete de text la anumite porțiuni din document. Asemenea interogări sunt dificil de scris într-un limbaj ca SQL. Un alt motiv este acela că bazele de date native XML păstrează ordinea documentelor, instrucțiunile de procesare, și comentarii, și adesea păstrează secțiuni CDATA, folosirea entităților, și altele, pe când bazele de date ce permit folosirea XML nu posedă aceste caracteristici.
Bazele de date native XML sunt de obicei folosite pentru a integra date. Integrarea datelor a fost făcută cu baze de date relaționale federate, dar acestea necesitau ca toate resursele de date să fie mapate la modelul relațional. Această modalitate nu funcționează pentru mai multe tipuri de date și modelul de date XML oferă o flexibilitate mai mare. Bazele de date native XML tratează modificările schemelor mai ușor decât bazele de date relaționale și pot trata și date care nu au schemă. Ambele considerații sunt importante pentru integrarea datelor din surse care nu se află sub control direct.
Al treilea caz de utilizare major al bazelor de date native XML este pentru datele semistructurate, așa cum se găsesc în finanțe, în biologie, date care se schimbă atât de des încât nu este posibilă definirea unor scheme definitive. Datorită faptului că bazele de date native XML nu necesită scheme, ca bazele de date relaționale, ele pot să trateze acest tip de date, deși aplicațiile adesea necesită procesarea acestor date de către oameni.
Ultima utilizare majora a bazelor de date native XML este tratarea evoluției schemelor. Chiar dacă bazele de date native XML nu oferă soluții complete, ele oferă o flexibilitate mai mare decât bazele de date relaționale. De exemplu, bazele de date native XML nu necesită ca datele existente să fie mutate într-o altă schemă, ele pot trata modificări ale schemelor pentru care nu există nicio cale a migrației, și pot stoca date chiar dacă acestea aparțin unei versiuni necunoscute a unei scheme.
Alte utilizări ale bazelor de date native XML includ punerea la dispoziție de cache pentru date și metadate pentru tranzacții lungi, operarea cu documente mari și date ierarhice, și comportarea ca un intermediar între date și cache (mid-tier data cache).
Bibliografie
S. Buraga, Tehnologii XML, Polirom, Iași, 2006
L. Alboaie, S. Buraga, Servicii Web, Polirom, Iași, 2006
S. Buraga, Proiectarea siturilor Web (ediția a II-a), Polirom, Iași, 2005
BACIVAROV Angelica-Beatrice, CIUCHI C., PETRICĂ G. – Servicii Internet, Editura Matrix Rom, 2011
Ion Gh. Rosca , Bogdan Ghilic-Micu si Marian Stoica – « INFORMATICA , SOCIETATEA INFORMATIONALA , eSERVICIILE » – Editura Economica , Bucuresti 2006
Revista Informatica Economica, nr. 1(29)/2004
Site:
http://ro.wikipedia.org/wiki/XML
http://ro.saferpedia.eu/wiki/SOAP
http://office.microsoft.com/ro-ro/sharepoint-designer-help
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Servicii Web Xml. Aplicatii (ID: 150442)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.