Arhitectura sistemelor informatice distribuite si aplicatii Web. Managementul serviciilor de infrastructură. Standard de management al serviciilor web
Servicii web- un cuvânt nou în tehnologia sistemelor distribuite. Specificație Open Net Environment (ONE) Sun Microsystems Corporation și Inițiativa. Microsoft's Net oferă infrastructura pentru scrierea și implementarea serviciilor Web. ÎN în prezent Există mai multe definiții ale unui serviciu web. Un serviciu Web poate fi orice aplicație care are acces la Web, cum ar fi o pagină Web cu conținut dinamic. În mai mult în sens restrâns Un serviciu web este o aplicație care oferă interfață deschisă, potrivit pentru utilizare de către alte aplicații de pe Web. Specificația ONE Sun cere ca serviciile Web să fie accesibile prin HTTP și alte protocoale Web, pentru a permite schimbul de informații prin mesaje XML și pentru a putea fi căutate prin servicii speciale- servicii de căutare. A fost dezvoltat un protocol special pentru accesul la serviciile Web - Protocol simplu de acces la obiect (SOAP), care introduce interoperabilitatea bazată pe XML pentru multe servicii Web. Serviciile web sunt deosebit de atractive deoarece pot oferi un grad ridicat de compatibilitate între diferite sisteme.
Un serviciu Web ipotetic, conceput conform arhitecturii ONE a Sun, ar putea lua forma în care publică un registru de servicii. Descriere web-servirea sub formă de document .
Potențialul enorm al serviciilor Web nu este determinat de tehnologia folosită pentru a le crea. HTTP, XML și alte protocoale utilizate de serviciile Web nu sunt noi. Interoperabilitate iar scalabilitatea serviciilor Web înseamnă că dezvoltatorii pot construi rapid aplicații mai mari și servicii Web mai mari din servicii Web mai mici. Specificația Sun Open Net Environment descrie o arhitectură pentru creare servicii web inteligente.Serviciile Web inteligente folosesc un mediu de operare comun. Prin partajarea contextului, serviciile Web inteligente pot efectua autentificare standard pentru tranzacțiile financiare, pot oferi recomandări și îndrumări în funcție de locația geografică a companiilor implicate în tranzacție. e-business.
Pentru a crea o aplicație care este un serviciu Web, este necesar să se aplice o serie de tehnologii.
Relația dintre aceste tehnologii este prezentată în mod convențional în Fig. 10.1.
Orez. 10.1.
De fapt, serviciile Web sunt una dintre opțiunile de implementare arhitectura componentelor, în care aplicația este considerată ca o colecție de componente care interacționează între ele. După cum sa spus deja de multe ori, interacțiunea componentelor care rulează pe diferite platforme este destul de bună sarcină dificilă, în special, necesită dezvoltare protocol de comunicare, luând în considerare caracteristicile transferului de date între diferite platforme. Una dintre ideile principale care stau la baza tehnologiei serviciilor Web luate în considerare este respingerea binarului protocol de comunicare. Mesajele sunt schimbate între componentele sistemului prin transmiterea mesajelor XML. Deoarece mesajele XML sunt fișiere text, protocolul de transport de transmisie poate fi foarte diferit - mesajele XML pot fi transmise prin protocoale HTTP, SMTP, FTP, iar utilizarea diferitelor protocoale de transport este transparentă pentru aplicații. După cum sa menționat deja, se numește protocolul care permite interacțiunea serviciilor Web SĂPUN (Protocol simplu de acces la obiect). Este definit pe baza XML. SĂPUN asigură interacțiunea sistemelor distribuite, indiferent de modelul obiectului sau platforma utilizată. Date în interior SĂPUN transmise sub formă de documente XML de format special. SĂPUN nu impune niciun protocol de transport specific. Cu toate acestea, în aplicațiile reale transmisia este cel mai adesea implementată SĂPUN-mesaje de la Protocolul HTTP. De asemenea, este obișnuit să folosiți SMTP, FTP și chiar TCP „pur” ca protocol de transport. Asa de, SĂPUN definește un mecanism prin care serviciile Web își pot apela reciproc funcțiile. Într-un fel, funcționarea acestui protocol amintește de un apel de procedură la distanță - apelantul cunoaște numele serviciului Web, numele metodei sale, parametrii pe care metoda îi acceptă și formalizează apelul la această metodă sub forma SĂPUN-mesaj și îl trimite către serviciul Web.
Totuși, abordarea descrisă este potrivită numai dacă „semnăturile” metodelor pe care le implementează serviciul Web sunt cunoscute dinainte. Dar dacă nu este cazul? Pentru a rezolva această problemă, a fost introdus modelul serviciului Web strat suplimentar- strat pentru descrierea interfețelor de servicii. Acest strat este prezentat ca o descriere WSDL.
După cum este definit de W3C, " WSDL - format XML pentru descriere servicii de rețea ca un ansamblu de operații finite care funcționează folosind mesaje care conțin informații orientate pe documente sau pe proceduri.” Document WSDL descrie complet interfața serviciului Web cu lumea de afara. Oferă informații despre serviciile care pot fi obținute folosind metodele de servicii și despre cum să accesezi aceste metode. Astfel, dacă semnătura metodei unui serviciu Web nu este cunoscută exact (de exemplu, s-a schimbat în timp), serviciul Web țintă poate fi interogat WSDL-descriere - fisierul in care vor fi continute aceste informatii.
Următorul nivel de tehnologie este serviciul Descriere universală, descoperire și integrare (UDDI).Această tehnologie presupune menținerea unui registru al serviciilor Web. Conectându-se la acest registru, consumatorul poate găsi serviciile Web care se potrivesc cel mai bine nevoilor sale. Tehnologie UDDI permite căutarea și publicarea serviciul solicitat, iar aceste operațiuni pot fi efectuate fie de o persoană, fie de un alt serviciu Web sau de un program client special. UDDI, la rândul său, este și un serviciu Web.
Astfel, serviciile Web sunt o altă implementare a sistemului middleware. Trăsătură distinctivă această tehnologie este independenţa ei faţă de software-ul utilizat şi hardware, precum și utilizarea pe scară largă standarde deschise(cum ar fi XML) și protocoale de comunicare standard.
În prezent, serviciile Web sunt o tehnologie promovată foarte activ și sunt poziționate ca mijloc de rezolvare a unei serii de probleme.
Trebuie remarcat faptul că, folosindu-le, pot fi construite și așa-numitele aplicații „standard”, unde partea de server este proiectată ca un serviciu Web.
Protocol simplu de acces la obiect (SOAP)
Protocolul de bază care asigură interacțiunea într-un mediu de servicii Web este
„CERCETAREA ȘI DEZVOLTAREA METODELOR DE CONSTRUIRE DE SISTEME CAD-CAE DISTRIBUITE BAZATE PE TEHNOLOGIE...”
Ca manuscris
Anisimov Denis Andreevici
CERCETAREA SI DEZVOLTAREA METODELOR DE CONSTRUCTIE
SISTEME AUTOMATICE DISTRIBUITE
PROIECTARE BAZAT PE TEHNOLOGIA SERVICIILOR WEB
Specialitatea: 13.05.12 – Proiectare sisteme de automatizare
dizertații pentru o diplomă academică
candidat la științe tehnice
Sankt Petersburg 2013
Lucrarea a fost efectuată la instituția de învățământ bugetar de stat federal de învățământ profesional superior „Universitatea Electrotehnică de Stat din Sankt Petersburg „LETI” numită după. V. I. Ulyanova (Lenin), Departamentul de sisteme de proiectare asistată de calculator
Director stiintific– Doctor în științe tehnice, profesorul Dmitrevici Ghenadi Daniilovici
Adversari oficiali:
Doctor în științe tehnice, profesor, Universitatea Electrotehnică de Stat din Sankt Petersburg „LETI” numită după. IN SI.
Ulyanova (Lenin), Departamentul de prelucrare automată a informațiilor și sisteme de control Kutuzov Oleg Ivanovici Candidat la științe tehnice, Societatea pe acțiuni deschise „Concern”
„ASOCIAȚIA DE CERCETARE ȘI PRODUCTIE „AURORA”,
șef al laboratorului Pakhomenkov Iuri Mihailovici
Organizație lider: Instituția de învățământ de învățământ profesional superior bugetar de stat federal „Național St. Petersburg universitate de cercetare tehnologia informației, mecanică și optică"
Susținerea disertației va avea loc în data de 23 mai 2013 la ora 16.30 în cadrul unei ședințe a consiliului de disertație D212.238.02 al Universității Electrotehnice de Stat „LETI” din Sankt Petersburg, care poartă numele. IN SI.
Ulyanova (Lenin) la adresa: 197376, St. Petersburg, st. Profesora Popova, 5.
Teza poate fi găsită în biblioteca Universității Tehnice de Stat din Sankt Petersburg. Rezumatul a fost trimis „___”__________ 2013.
Secretar științific al Consiliului de disertație D212.238.02 N. M. Safyannikov
DESCRIEREA GENERALĂ A LUCRĂRII
Relevanţă cercetare Introducerea pe scară largă a sistemelor de proiectare asistată de calculator în practica problemelor de inginerie este limitată semnificativ de costul ridicat al software-ului licențiat. Împreună cu aceasta, crearea propriilor sisteme CAD este asociată cu o cheltuială uriașă de resurse și nu poate fi implementată într-un timp scurt, deoarece dezvoltarea sistemelor CAD moderne necesită sute de ani-om. Problema este complicată și de faptul că, în situații reale de operare, sistemele CAD integrate multifuncționale sunt utilizate, de regulă, extrem de ineficient, deoarece atunci când se rezolvă sarcini specifice Din compoziția principală a acestor sisteme, nu se utilizează adesea mai mult de 10-20% din software-ul cel mai specific fiecărui departament.Soluția la această problemă presantă poate fi descentralizarea arhitecturii CAD prin trecerea la sisteme de proiectare distribuite construite pe baza tehnologiilor Internet care implementează sarcini comunicare și schimb de informații între aplicații.
Așa, indiferent aplicații gestionate sunt autonomi și pot interacționa între ele în procesul de îndeplinire a unei sarcini comune.
Protocoalele tehnologice de internet oferă o bază fiabilă pentru conectarea subsistemelor și nu necesită utilizarea coordonată a resurselor situate în diferite noduri de rețea, ceea ce simplifică semnificativ procesul de construire și operare a unui sistem CAD distribuit. Principala cerință pentru posibilitatea implementării unor astfel de sistem distribuit este consistența interfețelor prin care sunt conectate subsistemele individuale. Dacă această cerință este îndeplinită, componentele CAD distribuite individuale pot fi create de diferiți dezvoltatori și menținute la diferite site-uri, de unde vor fi livrate (eventual pe bază comercială) clienților.
Cea mai eficientă metodă de combinare a subsistemelor într-o aplicație distribuită ar trebui considerată organizația apel de la distanță proceduri bazate pe arhitectură orientată spre servicii folosind servicii web. Integrarea bazată pe servicii web în dezvoltarea sistemelor CAD descentralizate vă permite să treceți la descrierea interfețelor și interacțiunilor bazate pe XML, oferind posibilitatea de a modifica și dezvolta software-ul construit menținând în același timp interfața selectată. Acest lucru permite, datorită cuplării slabe a subsistemelor individuale, să se asigure interacțiunea între servicii pe o platformă arbitrară și să se adapteze aplicațiile existente la condițiile de proiectare în schimbare.
Sarcina principală a efectuării operațiilor de calcul cu o astfel de arhitectură revine serviciilor web care rezolvă toate problemele de modelare a sistemelor proiectate; aplicațiilor client li se atribuie doar cele mai simple funcții de pregătire a datelor și afișare a rezultatelor modelării.
Când se dezvoltă software CAD folosind servicii web, acestea pot fi utilizate următoarele tipuri aplicații client:
aplicație tip consolă, aplicație tip fereastră și aplicație web.
O caracteristică a aplicațiilor de consolă este absența GUI, cu toate acestea, utilizarea lor poate fi utilă la implementarea sistemelor CAD simple pentru computere de buzunar cu o zonă mică de ecran.
Aplicațiile ferestre oferă cea mai bună implementare grafică posibilă și sunt cele mai potrivite pentru dezvoltarea sistemelor distribuite bazate pe servicii web. Pentru orice serviciu web, este posibil să construiți mai multe aplicații client cu moduri diferite de implementare a interacțiunii cu dialog.
Aplicațiile web oferă posibilitatea de a plasa întregul software CAD online. Avantajul aplicării acestei structuri este acces deschis la utilizarea CAD distribuită prin orice tip de browser, dezavantajul acestui tip de aplicație este creșterea timpului necesar descrierii componentelor sistemului proiectat datorită așteptării unui răspuns la pașii individuali de introducere a datelor.
Pentru orice tip de aplicație client, serviciile web sunt apelate în același mod, iar pentru fiecare serviciu web este posibil să se folosească orice modalitate de implementare a aplicațiilor client scrise în diferite limbi. Dacă este necesar, astfel de aplicații client pot fi ușor modificate pentru a se potrivi condițiilor de design în schimbare, iar serviciul web poate fi, de asemenea, extins pentru a include metode suplimentare.
Scopul lucrăriiși principalele obiective ale cercetării Această disertație este dedicată cercetării și dezvoltării metodelor de construire a sistemelor CAD distribuite independente de platformă folosind servicii web. Pentru o implementare specifică a fost aleasă sarcina dezvoltării unui sistem de automatizare distribuită pentru proiectarea circuitelor.
Pentru a atinge acest obiectiv, trebuie rezolvate următoarele sarcini:
1. Dezvoltați o metodologie generală pentru construirea, testarea offline și implementarea pe un server de servicii web Java selectat.
2. Efectuați cercetări metode comune construirea de software de servicii web Java pentru un sistem de automatizare a proiectării circuitelor distribuite.
3. Cercetarea și dezvoltarea unei metodologii pentru construirea de servicii web Java folosind tehnologia de compresie a datelor.
4. Realizarea cercetării și dezvoltării unei metodologii generale pentru construirea de șabloane pentru aplicații client de tip consolă și fereastră, precum și aplicații web client.
5. Dezvoltarea unei metodologii de implementare a funcționării serviciilor web și a aplicațiilor client în medii eterogene.
Metode de cercetare La îndeplinirea sarcinilor atribuite în teză s-au folosit elementele de bază teorie generală CAD, teoria sistemelor de modelare, teoria de bază a matricelor și graficelor.
Fiabilitatea rezultatelor științifice este confirmată de prevederile de bază ale teoriei generale a CAD, teoria modelării, corectitudinea aparaturii matematice utilizate și rezultatele obținute din testarea software-ului creat pentru servicii web și aplicații client.
Noi rezultate științifice
1. Se propune o arhitectură orientată spre servicii pentru CAD distribuit folosind servicii web.
2. A fost dezvoltată o metodologie generală pentru implementarea, testarea offline și implementarea serviciilor web Java pe un server CAD distribuit.
3. A cercetat și dezvoltat metode de construire a software-ului de servicii web Java pentru a rezolva probleme tipice de proiectare a circuitelor electronice.
5. A fost dezvoltată o metodologie generală pentru construirea aplicațiilor client consolă și fereastră, precum și aplicații web client.
6. A fost dezvoltată o metodologie pentru implementarea software-ului CAD distribuit pentru organizarea interacțiunii în medii eterogene de servicii web și aplicații client.
Dispoziții de bază depus spre apărare
1. Arhitectura CAD orientată către servicii distribuite bazată pe servicii web.
2. Metodologie generală pentru proiectarea de jos în sus a serviciilor web Java
3. Metodologie de implementare a software-ului de servicii web Java bazat pe compresia datelor.
Valoare practică
1. Structura CAD distribuită propusă oferă capacitatea de a organiza interacțiunea între diverse servicii web pe platforma selectată și de a adapta aplicațiile la condițiile de proiectare în schimbare.
2. Biblioteca construită de funcții auxiliare bazată pe comprimarea datelor crește eficiența creării software-ului de servicii web Java pentru sistemele de automatizare a designului de circuite
3. Metodologia de implementare dezvoltată interacțiunea client-server asigură funcţionarea sistemelor CAD distribuite în medii eterogene.
4. Software-ul sistemului de automatizare distribuit dezvoltat pentru proiectarea circuitelor conține un nucleu invariant pentru organizarea etapelor atât simbolice, cât și numerice ale programelor Java, care poate fi folosit ca bază pentru construirea sistemelor de proiectare pentru o gamă largă de obiecte.
Implementarea și implementarea rezultatelor Sistemul CAD distribuit dezvoltat în teză folosind servicii web a fost implementat în Java folosind platforma WTP (Web Tools Platform). Rezultatul practic este un sistem CAD de proiectare a circuitelor distribuite independent de platformă, care realizează modelarea multivariată a circuitelor neliniare în modul staționar, în modul dinamic, pentru a calcula caracteristicile frecvenței și oferă, de asemenea, calculul sensibilității funcțiilor de transfer și al sensibilității modului staționar. variabile la variațiile parametrilor.
Rezultatele lucrării de disertație au fost utilizate în cercetările bugetului de stat pe tema „Elaborarea de modele și metode de analiză și sinteză a sistemelor inteligente de sprijinire a deciziei pentru gestionarea obiectelor complexe distribuite” (cod CAD-47 plan de subiect al Universității Economice de Stat din Sankt Petersburg). 2011) și la tema „Bazele matematice și logice ale mediilor de construcție a instrumentelor virtuale” (cod CAD-49 plan tematic SPbGETU 2012) Rezultatele disertației sunt introduse în practica inginerească a companiei științifice-producție „Modem” și sunt utilizate în procesul educațional al departamentului CAD al Universității Tehnice de Stat din Sankt Petersburg pentru a studia metodologia de construire a software-ului pentru sistemele de automatizare a proiectării circuitelor în pregătirea diplomelor de licență și master în „Informatică și Informatică”.
Aprobarea lucrării Principalele prevederi ale disertației au fost raportate și discutate la următoarele conferințe:
1. A IX-a conferință a tinerilor oameni de știință „Navigație și controlul traficului” – Sankt Petersburg;
2. A 5-a conferință internațională „Fabricarea instrumentelor în ecologie și siguranță umană” – Sankt Petersburg, SUAI;
3. XIII, XIV, XVII conferințe internaționale « Educația modernă: conținut, tehnologie, calitate.” – Sankt Petersburg, Universitatea Electrotehnică de Stat din Sankt Petersburg;
4. 60, 61, 63-a conferințe științifice și tehnice ale personalului didactic al SETU.
Publicaţii Principalul conținut teoretic și practic al disertației a fost publicat în 16 lucrări științifice, inclusiv 4 articole în publicații de top peer-reviewed recomandate în lista actuală a Comisiei Superioare de Atestare, 1 certificat de înregistrare oficială a unui program de calculator înregistrat la Serviciul Federal. pentru proprietate intelectuală, brevete și mărci comerciale.
Structura și scopul disertației Disertația conține o introducere, patru capitole de conținut principal, o concluzie și o bibliografie care conține 69 de surse. Lucrarea este prezentată pe 154 de pagini de text și conține 21 de figuri și un tabel.
În introducere se dă o justificare a relevanței temei disertației, se formulează obiectivele cercetării și se oferă o listă de sarcini de rezolvat în lucrare.În primul capitol Sunt luate în considerare problemele construcției arhitecturii aplicațiilor distribuite, care determină structura generală, funcțiile îndeplinite și relația dintre componentele individuale ale sistemului.
Se arată că arhitectura unei aplicații distribuite acoperă atât aspectele sale structurale și comportamentale, cât și regulile de integrare și utilizare, funcționalitate, flexibilitate, fiabilitate, performanță, reutilizare, limitări tehnologice și probleme de interfață cu utilizatorul. Sarcina principală a integrării aplicațiilor autonome (subsisteme) într-o aplicație distribuită este de a furniza conexiuni functionale, oferind interacțiunile necesare cu o dependență minimă între subsisteme.
Lucrarea de disertație arată că un astfel de mecanism este furnizat cel mai eficient atunci când se utilizează o arhitectură bazată pe interacțiunea între subsisteme folosind apeluri de procedură la distanță, utilizată pentru schimbul de date și pentru efectuarea anumitor acțiuni. În cazul în care o aplicație trebuie să recupereze sau să modifice orice informație întreținută de o altă aplicație, o accesează printr-un apel de funcție.
Pentru a construi sisteme CAD distribuite, teza propune utilizarea unei arhitecturi orientate pe servicii (SOA) bazată pe o structură software modulară și interfețe standardizate. SOA folosește unificarea elementelor de bază procese operaționale, principii de utilizare repetată a elementelor funcționale, organizare bazată pe o platformă de integrare. Deși arhitectura SOA nu este asociată cu nicio tehnologie specifică de apel de procedură la distanță, subsistemele software proiectate în conformitate cu SOA sunt de obicei implementate ca o colecție de servicii web conectate folosind protocoale subiacente (SOAP, WSDL).
Sistemele bazate pe arhitectură orientată pe servicii aparțin clasei sistemelor multi-agent (MAS), care sunt formate din mai mulți agenți inteligenți care interacționează, care asigură autonomie, reprezentare limitată și descentralizare a subsistemelor individuale ale unui sistem informatic distribuit.
Serviciile web se bazează pe standardul XML și permit utilizatorilor să interacționeze cu instrumente de sistem externe prin Internet, fiind componente slab cuplate ale unui sistem software care sunt disponibile pentru utilizare prin protocoale Internet. Lucrarea de disertație arată că în implementarea practică a sistemelor CAD distribuite care utilizează servicii web, trebuie acordată o atenție semnificativă împărțirii corecte a responsabilităților funcționale atribuite aplicației client principal și serviciului web care interacționează cu această aplicație.
Metodologia specifică de implementare a serviciilor web depinde în mod semnificativ de limbajul de programare ales. Lucrarea arată că, atunci când se alege un limbaj de programare pentru construirea de servicii web, ar trebui să se acorde preferință limbajului Java, care asigură cel mai pe deplin independența platformei soluțiilor implementate. Un factor important în favoarea acestei alegeri este, de asemenea, disponibilitatea unui instrument puternic de suport pentru dezvoltarea de aplicații bazate pe web în Java, care este furnizat de mediul WTP (Web Tools Platform).
Lucrarea de disertație a efectuat o analiză comparativă a două metode principale de construire a serviciilor web Java - de jos în sus (de jos în sus), atunci când este creată mai întâi o clasă Java a unui serviciu web și apoi este generat un document WSDL pe baza acesteia, și de sus în jos (Sus în jos), când documentul WSDL necesar este creat pentru prima dată, iar apoi codul de implementare a serviciului web este generat pe baza acestuia. Pe baza unei evaluări comparative, se arată că proiectarea serviciilor web trebuie efectuată folosind o metodă de jos în sus, deoarece în acest caz documentul WSDL este format pe baza unei clase Java create în prealabil, care descrie toți parametrii trecuți către metoda serviciului web și valorile returnate prin această metodă. În acest caz, toate informațiile disponibile în clasa Java sunt convertite automat în documentul WSDL corespunzător, al cărui conținut corespunde exact structurii de bază a specificației WSDL și principalelor caracteristici ale metodei numite serviciu web, care asigură completarea fiabilitatea informațiilor conținute în documentul WSDL.
Pentru a face posibilă implementarea practică a proiectării serviciilor web folosind o metodă de jos în sus, disertația propune o metodologie pentru construirea unui proiect web dinamic și clasa Java pentru implementarea serviciului web conținut în acesta cu o descriere a metodelor numite, printre care, pe lângă principalele metode de lucru, trebuie să conțină neapărat o metodă auxiliară fără argumente, care returnează o variabilă șir care conține toate informațiile despre principalele metode care asigură funcționarea serviciului web și o descriere a formatelor parametrii trecuți, precum și datele returnate, ceea ce asigură auto-documentarea serviciului web și capacitatea de a crea și îmbunătăți continuu aplicații client indiferent de dezvoltatorul serviciului web.
Teza oferă o tehnică de organizare a unui apel către o metodă de informare a serviciului web direct dintr-un mediu integrat de dezvoltare a aplicațiilor Java, în care, utilizând adresa URL a serviciului web, puteți accesa răspunsul Soap al metodei de informare și conținutul returnării acesteia. valoare.
În al doilea capitol Sunt luate în considerare metode de construire a serviciilor web CAD distribuite, cu ajutorul cărora se calculează circuitele neliniare în mod staționar, se calculează funcțiile de circuit ale circuitelor liniare și liniarizate pentru domeniul frecvenței, iar circuitele neliniare sunt calculate în moduri dinamice. În plus, subsistemele incluse în sistemul distribuit includ un serviciu web pentru calcularea sensibilității funcțiilor de circuit în domeniul frecvenței și un serviciu web pentru calcularea sensibilității variabilelor în stare staționară ale circuitelor neliniare la variațiile parametrilor. Ca componente ale circuitelor proiectate pe baza serviciilor web dezvoltate, puteți utiliza dispozitive cu două terminale de tip R, C, L, surse controlate liniare dependente de frecvență, surse controlate neliniare, transformatoare, tranzistoare bipolare și unipolare, amplificatoare operaționale, precum și sursele master de curent și tensiune.
Baza pentru astfel de metode este structura generală a descrierii matematice a sistemelor de proiectare a circuitelor. Teza oferă o evaluare comparativă a posibilelor metode de alegere a unei baze de coordonate pentru a forma o descriere a circuitelor liniarizate, cu preferință acordată bazei extinse a potențialelor nodale. Se observă că, alături de avantajele neîndoielnice, o limitare semnificativă a acestei baze este imposibilitatea descrierii matematice a componentelor circuitului cu ecuații în formă implicită, ceea ce face adesea dificilă, și uneori imposibilă, uz practic. Pentru a realiza posibilitatea de a descrie componentele circuitului prin ecuații în formă implicită, lucrarea oferă o versiune modificată a bazei extinse de tensiuni nodale, care este luată ca bază pentru construirea software-ului pentru servicii web.
Atunci când se iau în considerare problemele legate de construcția de servicii web pentru probleme de calculare a proprietăților de frecvență ale circuitelor electronice, se observă că problemele de acest tip pot fi împărțite în două grupe. Prima grupă include probleme de calcul a circuitelor liniare, ai căror parametri componente au valori fixe care nu depind în procesul de rezolvare a problemei de valorile coordonatelor punctelor de operare ale componentelor. Al doilea grup este asociat cu calculul caracteristicilor de frecvență ale circuitelor liniarizate, ai căror parametri depind de coordonatele punctelor de operare ale componentelor și aceste coordonate, precum și valorile parametrilor liniarizați corespunzători. precalculat.
Pentru a rezolva primul grup de probleme de calcul a proprietăților de frecvență ale circuitelor electronice la efectuarea lucrărilor de disertație, a fost construit serviciul web ModService_Java. Pentru a putea lucra cu numere complexe la construirea acesteia, a fost creată o clasă personalizată Complex, deoarece la momentul acestei lucrări o astfel de clasă nu face parte din instrumentele standard. API-ul Java. Clasa Complex conține constructori și funcții de ajutor pentru procesarea datelor complexe și toate funcțiile necesare pentru efectuarea de operații aritmetice și logice pe numere complexe, deoarece Java nu are un operator de suprascriere pentru aceste operații. Serviciul web primește o descriere a componentelor circuitului și a directivelor de calcul ca argumente și returnează o matrice care descrie rezultatele calculării caracteristicilor frecvenței.
Pentru a calcula modul staționar al sistemelor neliniare, disertația propune o metodologie generală de construire a software-ului pentru serviciile web corespunzătoare, implementată la crearea serviciului web StaticService_Java. Serviciul web primește, de asemenea, ca argumente o descriere a componentelor circuitului și a directivelor de calcul și returnează o matrice care descrie rezultatele calculării variabilelor de bază și coordonatelor în stare staționară pentru toate componentele neliniare (diode, tranzistori bipolari, tranzistori unipolari, amplificatoare operaționale, neliniare). surse controlate). Elementul zero al matricei returnate este rezervat pentru transferul de informații către partea client în cazul unei lipse de convergență a procesului de calcul, care necesită modificarea directivelor de calcul și reapelarea metodei serviciului web.
Teza examinează posibile abordări pentru dezvoltarea unei metodologii pentru construirea de servicii web pentru calcularea caracteristicilor de frecvență ale circuitelor liniarizate, ai căror parametri depind de coordonatele punctelor de operare ale componentelor. Ca urmare a evaluării comparative, a fost aleasă o cale pentru construirea unui serviciu web bazat pe un sistem integrat, care include software pentru liniarizarea componentelor neliniare la punctele de operare calculate și pentru calculul ulterior al proprietăților de frecvență ale circuitului liniarizat. . Lucrarea oferă o metodologie generală pentru rezolvarea unei astfel de probleme, a cărei implementare a fost realizată în serviciul web StFrqService_Java. Serviciul web primește ca argumente o descriere a componentelor dependente de frecvență și neliniare ale circuitului, precum și directive de calcul și, ca urmare a activității sale, este returnată o matrice care descrie rezultatele calculării caracteristicilor frecvenței. În același mod ca și în calculul în stare de echilibru, elementul zero al matricei returnate este utilizat pentru a transfera informații către partea client în cazul în care procesul nu converge.
La dezvoltarea unei metodologii pentru construirea unui serviciu web pentru calcularea modurilor dinamice ale sistemelor neliniare, se folosește o descriere matematică a circuitului într-o bază extinsă modificată de potențiale nodale, care face posibilă obținerea unui sistem de ecuații de tip algebric-diferențial în forma cea mai generală. Eliminarea derivatelor din ecuațiile componente se realizează pe baza unor formule de corecție care decurg din metode implicite în mai multe etape de ordine superioară, în timp ce metoda Gear de ordinul doi este adoptată ca principală cu posibilitatea creșterii ordinii acesteia. Componentele din ecuațiile cărora derivatele sunt excluse sunt rețele cu două terminale de tip C și L, diode, transformatoare, tranzistoare bipolare și unipolare, amplificatoare operaționale, precum și surse controlate dependente de frecvență. Pentru a calcula valorile surselor autonome care păstrează valorile variabilelor corespunzătoare în pașii anteriori, sunt construite funcții de eșantionare auxiliare dis_cmp pentru toate componentele cmp enumerate cu proprietăți dependente de frecvență.
Metodologia dezvoltată a fost implementată în construcția serviciului web Dyn2Service_Java, care returnează la partea clientului o matrice care descrie rezultatele calculării caracteristicilor dinamice.
În al treilea capitol Sunt luate în considerare problemele construirii de servicii web folosind metode de compresie a datelor. Relevanța acestor probleme este determinată de faptul că structura sisteme reale caracterizată printr-o conexiune slabă între componente, ceea ce are ca rezultat descrierea lor matematică sub formă de matrici de tip rare, în care doar o mică parte din elemente au informații semnificative.
Această circumstanță pune sarcina de a schimba abordările general acceptate ale formării și soluționării ecuațiilor pentru a economisi memorie și a crește performanța, ceea ce este crucial pentru funcționarea sistemelor bazate pe web.
Lucrarea de disertație a analizat eficiența metodelor posibile de conversie a datelor în matrice compacte, pe baza cărora s-a făcut o concluzie despre oportunitatea alegerii unei metode bazate pe utilizarea compresiei Sherman și care necesită o procedură în două etape pentru efectuarea simbolică și prelucrarea datelor numerice. Un avantaj semnificativ al procedurii în două etape adoptate este împărțirea sa în două părți independente ale etapelor simbolice și numerice. Deoarece aproape toate problemele reale de proiectare a circuitelor sunt asociate cu calculul multivariat al unui circuit cu o structură neschimbată, etapa simbolică este efectuată pentru fiecare structură o singură dată, în timp ce etapa numerică este implementată de zeci, sute și uneori de mii de ori.
Cu toate acestea, procedura în două etape este caracterizată de o logică destul de complexă pentru construirea codului programului, iar atunci când treceți la o descriere bazată pe comprimarea datelor, este necesară o modificare semnificativă a descrierii complete a problemei create anterior.
Teza examinează o diagramă bloc a implementării procesării datelor în două etape la construirea aplicațiilor Java, conform căreia, în etapa de analiză simbolică, se formează o matrice de index de tip întreg, pentru care este o etapă simbolică de factorizare LU. efectuate, unde rândurile (coloanele) sunt ordonate pentru a minimiza numărul care apar din nou elemente cu valori diferite de zero. La etapa finală a etapei simbolice se construiesc matrice de coordonate, care conțin informații despre structura matricei index, în urma cărora această matrice poate fi ștearsă.
La etapa numerică, în conformitate cu formatul de descriere cunoscut, se formează matrice compacte și se realizează factorizarea lor numerică virtuală LU pe baza algoritmului construit în lucrare. După finalizarea etapei numerice de factorizare LU, toate variabilele de sistem sunt calculate și recodificate în funcție de permutările rândurilor (coloanelor) efectuate la etapa de procesare simbolică. Această sarcină, în conformitate cu tehnica generală de factorizare LU, este de obicei rezolvată utilizând mișcări înapoi și înainte prin rândurile matricei originale, dar deoarece nu există o matrice completă când se utilizează compresia datelor, atât mișcările înainte cât și înapoi sunt efectuate folosind algoritmi speciali, implementând aceste sarcini folosind compresia datelor.
Teza arată că sunt posibile două abordări diferite pentru dezvoltarea software-ului pentru servicii web bazate pe compresia datelor. Primul este asociat cu prelucrarea software-ului existent, bazat pe o descriere matematică completă sub formă de matrici inițiale cu o structură rară, pentru a construi metoda modificată, folosind matrice compacte. Deținerea unui prototip simplifică foarte mult procesul de creare a unei metode bazate pe compresia datelor, dar pentru a folosi cât mai eficient materialul disponibil, este necesar să ai la dispoziție o metodologie de dezvoltare. versiuni modificate servicii web. Această tehnică a fost construită în disertație și pe baza ei au fost modificate toate serviciile web discutate mai sus. Rezultatul este un cadru de servicii web care conține două metode principale de lucru, una bazată pe descrierea completă a circuitului modelat și a doua folosind tehnologia compactă de procesare a datelor.
A doua abordare este utilizată în cazurile în care nu există un prototip pentru a dezvolta o metodă bazată pe compresia datelor. În acest caz, atât etapele simbolice, cât și cele numerice sunt implementate în absența unei descrieri complete a circuitului simulat sub forma unei matrice rare, ceea ce complică semnificativ procesul de programare. În disertație, a doua abordare este utilizată pentru a construi servicii web care calculează sensibilitatea transmisiilor de circuit și a variabilelor de mod staționar ale circuitelor la variațiile parametrilor componentelor lor.
Pentru a calcula sensibilitatea caracteristicilor de frecvență ale funcțiilor de circuit, a fost construit serviciul web VaryService, care conține o metodă bazată pe diferențierea ecuațiilor și o metodă bazată pe circuite conectate.
Pe baza diferențierii ecuațiilor, metoda serviciului web VaryService vă permite să calculați valorile sensibilității vectoriale absolute și relative ale funcțiilor de circuit pentru domeniul frecvenței la parametrul variabil selectat pentru întregul set de variabile de bază. Parametrii variabili pot fi valorile rezistenței, capacității sau inductanței unui circuit arbitrar cu două terminale de tip R, C sau L și parametrii de transmisie ai surselor controlate dependente de frecvență, cum ar fi ITUN, INUN, ITUT sau INUT.
Metoda serviciului web VaryService, folosind circuite atașate, vă permite să calculați valorile sensibilității scalare absolute și relative ale funcțiilor de circuit pentru domeniul frecvenței în raport cu toți parametrii variabili posibili pentru valoarea selectată a variabilei analizate. Diagrama bloc software propusă în această lucrare vă permite să utilizați rezultatele formării de rețele compacte ale circuitului principal pentru a calcula circuitul atașat. Parametrii variabili din metoda bazată pe circuitul adjunct pot fi aceiași parametri ca și pentru metoda bazată pe diferențierea ecuațiilor.
Pentru a calcula sensibilitatea variabilelor care definesc modul staționar al circuitelor neliniare la variațiile parametrilor acestora, a fost dezvoltat serviciul web StVaryService, care conține, de asemenea, două metode, dintre care una se bazează pe diferențierea ecuațiilor, iar a doua pe un anexat. circuit. Parametrii variabili în ambele metode pot fi valorile rezistenței rezistenței și parametrii de transmisie ai surselor controlate precum ITUN, INUN, ITUT sau INUT.
Algoritmul de calcul al sensibilității absolute a variabilelor de bază ale modului staționar prin metoda diferențierii ecuațiilor prevede diferențierea ecuației neliniare a circuitului prin variabilele de bază și parametrii variabili, ceea ce face posibilă obținerea unei ecuații de sensibilitate , a cărui soluție determină sensibilitatea vectorială dorită a variabilelor modului staționar.
Implementarea practică a metodei se bazează pe diferențierea ecuațiilor componentelor variate folosind rezultatele calculării variabilelor de bază ale modului staționar al circuitului neliniar.
Algoritmul metodei care calculează sensibilitatea scalară a variabilelor de mod staționar folosind un circuit alăturat prevede calcularea variabilelor de bază ale modului staționar al circuitului principal și calculul variabilelor de bază ale circuitului conectat liniarizat, care se realizează pe baza matricelor compacte generate anterior pentru circuitul principal. Rezultatul celei de-a doua metode este o serie de valori absolute și relative ale sensibilității variabilei circuitului selectat pentru toți parametrii componentelor variabile.
Al patrulea capitol discută metode de construire a aplicațiilor client personalizate care oferă interacțiune cu serviciile web, care, după ce sunt construite într-un instrument de dezvoltare a aplicațiilor Java, trebuie să fie implementate pe un server CAD distribuit. Pentru a implementa un serviciu web, trebuie să cunoașteți principalele sale caracteristici, inclusiv numele serviciului, numele clasei, numele metodelor și tipul de document WSDL.
Informații relevante despre serviciile web dezvoltate și descrise mai sus pentru un sistem de proiectare a circuitelor distribuite sunt date în teză și în metodele de informare numite getInf, care sunt incluse în toate serviciile web dezvoltate. Lucrarea propune o tehnică simplă pentru implementarea directă a serviciilor web pe un server și discută moduri posibile importul fișierului WSDL pe partea client. Pe baza unei analize comparative, lucrarea arată că corectitudinea operațiunii de livrare a unui fișier WSDL de la un serviciu web la distanță către o aplicație client poate fi asigurată cel mai eficient prin utilizarea instrumentului Web Services Explorer și secvența cea mai optimă pentru importul unui Fișierul WSDL în cadrul inițial al aplicației client este stabilit.
Odată ce fișierul WSDL a fost livrat către proiectul aplicației client, se propune o transformare ulterioară a scheletului inițial al proiectului într-o aplicație client completă care să fie realizată în două etape. Prima etapă a acestei transformări este crearea unui obiect proxy în cadrul proiectului inițial, iar a doua etapă este formarea claselor care conțin metode care sprijină funcționarea obiectului proxy și interacțiunea serviciului de la distanță cu aplicația client. Implementarea primei etape se rezumă la completarea proiectului cu operatorii care creează un obiect proxy, a doua etapă se realizează cu ajutorul instrumentului Web Services al platformei WTP, cel mai moduri eficiente ale căror utilizări sunt date în teză.
Finalizarea scheletului inițial al proiectului într-o aplicație client finalizată se poate face în diverse moduri Pentru tipuri diferite aceasta aplicație. Cel mai simplu mod de a rula aplicații client este să le proiectezi pe baza aplicațiilor de consolă care nu au interfață grafică. Lucrarea propune o generalizare schema structurala implementarea unei aplicații de consolă CAD distribuită pentru calculul circuitelor electronice, care poate fi utilizată pentru orice serviciu web în ciuda varietății de soluții specifice posibile.
În timpul tezei, au fost implementate aplicații de consolă client pentru toate serviciile web CAD distribuite mai sus. Fișierele lor sursă pot fi livrate prin mijloace standard prin internet către client și utilizate atât pentru a construi cea mai simplă versiune a unei aplicații de consolă pentru interacțiunea cu serviciile CAD distribuite, cât și ca manual metodologic pentru a dezvolta aplicații mai bune cu ferestre.
Aplicațiile client ferestre oferă cele mai mari oportunități de funcționare în CAD distribuit, deoarece fac posibilă valorificarea la maximum a elementelor grafice. Pentru acest serviciu web, puteți construi diverse versiuni de aplicații client cu diferite moduri de organizare a dialogului cu utilizatorul și afișarea rezultatelor calculelor. Lucrarea a stabilit un set minim de instrumente de dialog care asigură interacțiunea completă cu serviciul. Un astfel de set conține un meniu fereastră și un set casete de dialog pentru introducerea datelor și afișarea rezultatelor calculelor, precum și gestionarea directivelor de calcul.
Teza propune o metodologie de construire a aplicațiilor web client, pe baza căreia s-au dezvoltat șabloane de pagină JSP care îndeplinesc funcțiile de selectare și deplasare în alte pagini, introducerea unui anumit set de variabile cu trecerea la pagina principala, introducând în mod ciclic un anumit set de variabile cu o tranziție la pagina următoare în funcție de valorile acestor variabile, apelând serviciul web necesar și afișând rezultatele muncii sale. Utilizarea aplicațiilor web client vă permite să plasați întregul cod de program al unui sistem distribuit în rețea și, în funcție de metoda adoptată de plasare a clientului și aplicații server, serviciul poate fi apelat fie de la una sau mai multe pagini web.
O caracteristică pozitivă a acestei arhitecturi este capacitatea de a organiza accesul la CAD distribuit printr-un browser web arbitrar, fără a fi nevoie să vă construiți propria aplicație client; dezavantajul acestei abordări de organizare a CAD distribuit este creșterea inevitabilă a intervalului de timp necesar descrierii. componentele sistemului în procesul de interacțiune interactivă.
Disertația construiește o metodologie de organizare a procesului de implementare a aplicațiilor client, al cărei scop este de a asigura capacitatea de a lansa o aplicație client folosind instrumente la nivel de sistem fără a utiliza un instrument de dezvoltare a aplicațiilor, în timp ce atât pentru aplicațiile client de tip consolă, cât și pentru aplicații client de tip fereastră, lansarea trebuie efectuată prin linia de comandă, iar pentru aplicațiile web - din browser. Informațiile despre locația serviciului web sunt transmise printr-un obiect de clasă proxy, care trebuie mai întâi configurat la adresa URL corespunzătoare.
Lucrarea notează că la implementarea unei aplicații de consolă, pagina de coduri a proiectului trebuie mai întâi schimbată, pentru care este necesar să treceți de la o pagină de coduri în care este afișat text chirilic în toate sistemele de instrumente integrate care lucrează cu cod Java, la o pagină de cod. în care textul chirilic va fi afișat în mod normal în fereastra liniei de comandă.
Disertația arată că atunci când se utilizează aplicații web client, în funcție de structura de comunicare aleasă între computerele client și server, informații despre locația serviciului web pot fi transmise atât printr-un obiect de clasă proxy, cât și printr-un URL introdus din browser. Metodele corespunzătoare de interacțiune a clientului cu serviciul atunci când își implementează sarcinile funcționale pentru structura de comunicare selectată sunt, de asemenea, discutate în lucrare.
Standardizarea SOAP oferă capacitatea de a interconecta aplicații slab cuplate, indiferent de platforma lor de implementare, ceea ce permite utilizare optimă o gamă largă de resurse eterogene, slab cuplate în aplicații distribuite. Teza oferă o metodologie generală pentru construirea de software pentru interacțiunea unui obiect de clasă proxy al unei aplicații în mediul .NET cu un serviciu în mediul Java/J2EE. Pe baza acestei metodologii a fost implementată organizarea interacțiunii dintre serviciile web Java dezvoltate și aplicațiile client Windows construite în mediul .NET bazate pe limbajul C#.
Abilitatea de a opera CAD distribuit în medii eterogene extinde în mod semnificativ domeniul de aplicare al acestuia.
In custodie se formulează principalele rezultate științifice și practice obținute pe baza cercetărilor efectuate în teză.
Principalele rezultate muncă
1. A fost dezvoltată o arhitectură pentru CAD orientat spre servicii distribuite, bazată pe servicii web, caracterizată printr-o structură descentralizată, independență de platformă și capacitatea de a realiza modernizarea continuă a subsistemelor individuale pentru a-și adapta proprietățile la condițiile de proiectare în schimbare.
2. A fost implementată o metodologie generală pentru construirea serviciilor web Java și a documentelor WSDL corespunzătoare folosind o metodă de jos în sus, precum și pentru livrarea lor către un server CAD distribuit după testarea offline în mediul de dezvoltare.
3. A fost dezvoltată o metodologie pentru construirea de software pentru servicii web Java pentru a rezolva probleme tipice de modelare sisteme continueîn proiectarea automată a circuitelor electronice.
4. A fost construită o bibliotecă de funcții auxiliare pentru a implementa software-ul de servicii web Java bazat pe compresia datelor.
5. A fost dezvoltată o metodologie generală de construire a șabloanelor pentru aplicații client consolă și fereastră pentru un sistem de automatizare a proiectării circuitelor distribuite și a fost implementată organizarea funcționării unui sistem CAD distribuit cu aplicații web client.
6. A fost dezvoltată o metodologie pentru construirea sistemelor CAD distribuite care asigură interacțiunea serviciilor web Java și aplicațiilor client de orice tip în medii eterogene.
1. Anisimov D.A. Construcția sistemelor de proiectare asistată de calculator bazate pe servicii Web [Text] / Anisimov D.A. Gridin V.N., Dmitrevich G.D. // Automatizarea în industrie – 2011. – Nr. 1 – p. 9-12.
2. Anisimov D.A. Construcția sistemelor de proiectare asistată de computer bazate pe tehnologii Web [Text] / Gridin V.N., Dmitrevich G.D., Anisimov D.A. // Tehnologii informaționale - 2011. - Nr. 5. – pp. 23-27.
3. Anisimov D.A. Construcție de servicii web pentru sisteme de automatizare pentru proiectarea circuitelor [Text] / Gridin V.N., Dmitrevich G.D., Anisimov D.A // Tehnologii informaționale și sisteme de calcul - 2012. - Nr. 4. – pp. 79-84.
4. Anisimov D.A. Metode de construcție a sistemelor de automatizare pentru proiectarea circuitelor bazate pe servicii web [Text] / Anisimov D.A // Știrile Universității Electrotehnice din Sankt Petersburg „LETI” - 2012. - Nr. 10. – Sankt Petersburg: Editura Universității Electrotehnice din Sankt Petersburg „LETI”, – p. 56-61.
5. Anisimov D.A. Acces la resurse Web în sistemele de navigare și control CAD [Text] / Laristov D.A., Anisimov D.A. // Giroscopie și navigație. 2007. Nr 2. –S. 106.
Arhitectura sistemelor informatice distribuite si aplicatii Web
Sistem distribuit este un set de independente calculatoare, care apare utilizatorilor lor ca un singur sistem unificat. În ciuda faptului că toate computerele sunt autonome, pentru utilizatori par să fie un singur sistem.
Principalele caracteristici ale sistemelor distribuite:
1. Diferențele dintre calculatoare și metodele de comunicare dintre acestea sunt ascunse utilizatorilor. Același lucru este valabil și pentru organizarea externă a sistemelor distribuite.
2. Utilizatorii și aplicațiile experimentează o experiență consecventă în sistemele distribuite, indiferent unde sau când interacționează.
De asemenea, sistemele distribuite ar trebui să fie relativ ușor de extins sau scalat. Această caracteristică este o consecință directă a avea calculatoare independente, dar în același timp nu indică modul în care aceste computere sunt de fapt combinate într-un singur sistem.
Pentru a menține o vedere unificată a sistemului, sistemele distribuite includ adesea un strat suplimentar de software care se află între ele nivel superior, unde locuiesc utilizatorii și aplicațiile, iar nivelul inferior, constând din sisteme de operare (Figura 1.11).
În consecință, un astfel de sistem distribuit este de obicei numit sistem de nivel mediu (middleware). Rețineți că stratul intermediar este distribuit între multe computere.
Caracteristicile funcționării sistemelor distribuite includ:
· Disponibilitate cantitate mare obiecte;
· întârzieri de execuție a cererii (de exemplu, dacă apelurile locale necesită aproximativ câteva sute de nanosecunde, atunci solicitările către un obiect din sistemele distribuite necesită de la 0,1 la 10 ms);
· unele obiecte pot să nu fie folosite o perioadă lungă de timp;
· componentele distribuite sunt executate în paralel, ceea ce duce la necesitatea coordonării execuției;
· cererile în sistemele distribuite au o mare probabilitate de eșec;
· cerințe sporite de siguranță.
Datorită prezenței unei latențe crescute, interfețele dintr-un sistem distribuit trebuie să fie proiectate pentru a reduce timpul de execuție a interogărilor. Acest lucru se poate realiza prin reducerea frecvenței de acces, precum și prin mărirea funcțiilor îndeplinite.
Pentru a combate eșecurile, clienții trebuie să verifice dacă cererile sunt executate de server. Securitatea în aplicațiile distribuite poate fi crescută prin monitorizarea sesiunilor de comunicare (autentificare, autorizare, criptare a datelor).
Arhitectura aplicațiilor Web (servicii web) este utilizată pe scară largă în zilele noastre. Serviciul web este o aplicație accesibilă prin Internet. Furnizează servicii, a căror formă nu depinde de furnizorul de servicii, deoarece utilizează o platformă de operare universală și format universal date (XML). Serviciile web se bazează pe standarde care definesc formatele și limba solicitărilor, precum și protocoalele de căutare a acestor servicii pe Internet. Schema de accesare a bazei de date prin Internet este prezentată în Fig. 1.12.
 |
| Figura 1.12 – Schema de acces la serverul SGBD prin Internet |
În prezent sunt trei diverse tehnologii, susținând conceptul de sisteme de obiecte distribuite: EJB, DCOM CORBA.
Ideea principală din spatele dezvoltării tehnologiei EJB ( Enterprise Java Beans) - creează o infrastructură pentru componente, astfel încât acestea să poată fi introduse și îndepărtate cu ușurință de pe servere, crescând sau scăzând astfel funcționalitatea serverului. Componentele EJB sunt clase Java și pot rula pe orice server compatibil EJB, chiar și fără recompilare. Principalele obiective ale tehnologiei EJB sunt:
1. Ușurează crearea de aplicații pentru dezvoltatori, scutindu-i de nevoia de a implementa de la zero servicii precum tranzacții, fire de execuție, încărcări etc.. Dezvoltatorii își pot concentra atenția asupra descrierii logicii aplicațiilor lor, schimbând sarcinile de stocare , transferul și securitatea datelor către sistemul EJB .
2. Descrieți principalele structuri ale sistemului EJB și interfețele pentru interacțiunea dintre componentele sale.
3. Eliberați dezvoltatorul de implementarea obiectelor EJB datorită prezenței unui generator de cod special.
Datorită modelului Java folosit, EJB este o modalitate relativ simplă și rapidă de a crea sisteme distribuite.
Tehnologia DCOM ( Model de obiecte componente distribuite) este o arhitectură software dezvoltată de Microsoft pentru distribuirea aplicațiilor pe mai multe computere dintr-o rețea. Componenta software un computer poate folosi DCOM pentru a transmite mesaje către o componentă a altui computer. DCOM stabilește automat o conexiune, transmite un mesaj și returnează un răspuns de la componenta de la distanță. Capacitatea DCOM de a interconecta componentele a permis Microsoft să ofere Windows o serie de capabilități suplimentare, în special, implementarea Microsoft Transaction Server, care este responsabil pentru executarea tranzacțiilor cu baze de date pe Internet.
Hai sa sunăm serviciu o resursă care implementează o funcție de afaceri și are următoarele proprietăți:
este reutilizabil;
definit de una sau mai multe interfețe explicite independente de tehnologie;
este slab cuplat cu alte resurse similare și poate fi invocat prin protocoale de comunicare care permit resurselor să interacționeze între ele.
serviciu web numit sistem software identificat prin șir URI, ale căror interfețe și legături sunt definite și descrise de XML. Descrierea acestui sistem software poate fi găsită de alte sisteme software care pot interacționa cu acesta conform acestei descrieri prin mesaje bazate pe XML transmise folosind protocoale Internet.
1.1 Elemente de bază ale serviciilor web
Servicii web este o nouă arhitectură promițătoare care oferă un nou nivel de distribuție. În loc să dezvolte sau să achiziționeze componente și să le încorporeze într-un IS, se propune să le cumpere timpul de funcționare și să formeze un sistem software care să efectueze apeluri de metodă de la componente care sunt deținute și susținute de furnizori independenți. Mulțumită Servicii web funcțiile oricărui program din rețea pot fi puse la dispoziție prin Internet. Cel mai simplu exemplu serviciu web- sistem Pașaport pe Hotmail, care vă permite să creați autentificarea utilizatorului pe propriul site.
Serviciile web se bazează pe următoarele tehnologii universale:
TCP/IP – protocol universal, înțeles de toate dispozitivele din rețea, de la mainframe la telefoane mobile și PDA-uri;
HTML – limbă universală marcaj utilizat pentru a afișa informații pe dispozitivele utilizatorului;
XML(Extensible Markup Language) – un limbaj universal pentru lucrul cu orice tip de date.
Versatilitatea acestor tehnologii este baza pentru înțelegerea serviciilor web. Acestea se bazează doar pe tehnologii general acceptate, deschise și oficial neutre din punct de vedere al furnizorilor. Numai prin aceasta poate fi atins principalul avantaj al serviciilor web ca concept de construire a SI distribuit - universalitatea lor, adică capacitatea de a fi utilizat pentru orice sisteme de operare, limbaje de programare, servere de aplicații etc.
Astfel, serviciile web rezolvă problema inițială - problema integrării aplicațiilor de diferite naturi și construirii SI distribuite. Aceasta este principala diferență fundamentală dintre serviciile web și predecesorii lor.
Servicii web - Acest aplicații XML, conectarea datelor cu programe, obiecte, baze de date sau tranzacții comerciale întregi. Documentele XML formatate ca mesaje sunt schimbate între serviciul web și program. Standardele de servicii web definesc formatul unor astfel de mesaje, interfața către care este trimis mesajul, regulile de legare a conținutului mesajului de aplicația care implementează serviciul și invers, precum și mecanismele de publicare și căutare a interfețelor.
XML(EnglezăeX tensionabile M arkup L limbaj- extensibil limbaj de marcare; pronuntat [ x-em-el]). Recomandat Consorțiul World Wide Web(W3C). Specificația XML descrie documentele XML și descrie parțial comportamentul procesoarelor XML (programe care citesc documente XML și oferă acces la conținutul acestora). XML a fost conceput ca un limbaj cu un simplu formal sintaxă, convenabil pentru creareși programe de procesare a documentelor și, în același timp, convenabile pentru oameni să citească și să creeze documente, punând accent pe utilizarea pe Internet. Limbajul se numește extensibil deoarece nu fixează marcajul folosit în documente: dezvoltatorul este liber să creeze markup în funcție de nevoile unui anumit domeniu, limitat doar de regulile sintactice ale limbajului. Combinație de sintaxă formală simplă, prietenie umană, extensibilitate și codare bazată Unicode să prezinte conținutul documentelor la care a condus utilizare pe scară largă atât XML în sine, cât și multe limbaje specializate derivate bazate pe XML într-o mare varietate de software.
Aplicații XML standard
XML poate fi folosit pentru mai mult decât pentru a descrie un singur document. Un individ, o companie sau un comitet de standarde poate defini setul necesar de elemente XML și structura documentului pentru a fi utilizate pentru o anumită clasă de documente. Se numește un set similar de elemente și descrierea structurii documentului aplicație XML sau Dicționar XML. De exemplu, o organizație poate defini o aplicație XML pentru a crea documente care descriu structuri moleculare, prezentări multimedia sau care conțin grafică vectorială.
Servicii web poate fi folosit în multe aplicații. Indiferent dacă serviciile web rulează de pe desktop-urile sau laptopurile clienților, acestea pot fi folosite pentru a accesa aplicații de internet, cum ar fi precomandă sau urmărirea comenzilor.
Servicii web potrivit pentru Integrare B2B (afaceri la afaceri),închiderea aplicaţiilor efectuate de diferite organizaţii într-un singur proces de producţie. Servicii web poate aborda, de asemenea, problema mai largă a integrării aplicațiilor pentru întreprinderi (Integrarea aplicațiilor pentru întreprinderi, EAI), conectând mai multe aplicații de la o întreprindere la mai multe alte aplicații. În toate aceste cazuri, tehnologiile de servicii web sunt „cleiul” care conectează diferitele bucăți de software.
După cum se poate observa din fig. 1, serviciile web sunt un înveliș care oferă o modalitate standard de interacțiune cu mediile software de aplicație, cum ar fi sisteme de gestionare a bazelor de date (DBMS), .NET, J2EE (Java2 Platform, Enterprise Edition), CORBA (Common Object Request Broker Architecture), revânzători de pachete de planificare a resurselor întreprinderii ( Planificarea resurselor întreprinderii, ERP), brokeri de integrare etc.
Fig.1. Serviciile web interacționează cu sistemele de aplicații
Interfețele pentru servicii web sunt obținute din mediul de rețea mesaje XML standard, transforma date XMLîntr-un format „înțeles” de o anumită aplicație sistem softwareși trimiteți un mesaj de răspuns (cel din urmă este opțional). Implementarea software a serviciilor web (software de bază, Nivel inferior) poate fi creat în orice limbaj de programare folosind orice sistem de operare și orice middleware ( middleware).
Un exemplu simplu: căutarea de informații
În prezent, majoritatea serviciilor sunt apelate prin internet prin introducerea datelor în Formulare HTMLși trimiterea acestor date către serviciu prin adăugarea lor la șirul Uniform Resource Locator ( Localizator uniform de resurse, URL):
http://www.google.com/search?q=Skate+boots&btnG=Google+Search
Acest exemplu ilustrează simplitatea interacțiunilor web (cum ar fi căutarea, cumpărarea de acțiuni sau solicitarea de indicații rutiere) în care parametrii și cuvintele cheie sunt încorporate direct în adresa URL. ÎN în acest caz, o cerere simplă de căutare pentru cizme de skate (ghete cu patine) este prezentată în șirul de interogare motorului de căutare Google. Cuvântul cheie de căutare reprezintă serviciul care va fi accesat, iar parametrul Skate+boots este șirul de căutare care a fost introdus în formularul HTML de pe pagina site-ului Google. Căutarea Google va transmite această solicitare către diferite motoare de căutare, care vor returna o listă de adrese URL pentru paginile care se potrivesc cu parametrul de căutare Skate+boots. Această metodă ineficientă de căutare pe Internet se bazează în întregime pe potrivirea șirului de text specificat cu indexat Pagini HTML.
XML - Cel mai bun mod trimiterea datelor. XML oferă avantaje semnificative la transmiterea datelor prin Internet. Acum interogarea anterioară poate fi reprezentată ca document XML:
xmlns:s="www.xmlbus.com/SearchService"> Trimiterea unei cereri în formular document XML are următoarele avantaje: capacitatea de a defini tipuri și structuri de date, flexibilitate și extensibilitate mai mari. XML poate reprezenta date structurate sau date de un anumit tip (de exemplu, este acceptabil să specificați valoarea câmpului de dimensiune ca șir de numere sau ca număr în virgulă mobilă) și să conțină mai multe informații decât permite o adresă URL. Acest exemplu este prezentat sub forma unui mesaj SOAP (Simple Object Access Protocol), o formă standard de schimb de mesaje XML, care este una dintre tehnologiile care stau la baza serviciilor web. Într-un mesaj SOAP, numele serviciului solicitat și parametrii de intrare sunt reprezentați ca elemente XML separate. Acest exemplu ilustrează și utilizarea spațiilor de nume XML (xmlns:), un alt element important al serviciilor web. Deoarece documentele XML acceptă mai multe tipuri de date, structuri complexe și agregarea schemelor, tehnologiile moderne de servicii web oferă avantaje semnificative față de capabilitățile existente pentru accesarea aplicațiilor software prin HTML și URL-uri. Software-ul open source a devenit un element de bază în crearea unora dintre cele mai mari site-uri web din lume. Odată cu creșterea acestor site-uri web, au apărut cele mai bune practici și linii directoare pentru arhitectura lor. Acest capitol își propune să acopere câteva dintre aspectele cheie de luat în considerare atunci când proiectați site-uri web mari, precum și câteva dintre componentele de bază utilizate pentru atingerea acestor obiective. Accentul acestui capitol este pe analiza sistemelor bazate pe web, deși o parte din material poate fi extrapolată la alte sisteme distribuite. Ce înseamnă exact să creezi și să gestionezi un site web sau o aplicație scalabilă? La un nivel primitiv, aceasta este pur și simplu conectarea utilizatorilor la resurse de la distanță prin intermediul internetului. Și resurse sau acces la aceste resurse, care sunt distribuite pe mai multe servere și sunt linkul care asigură scalabilitatea site-ului. La fel ca majoritatea lucrurilor din viață, timpul petrecut în avans pentru planificarea construirii unui serviciu web poate ajuta mai târziu; Înțelegerea unora dintre considerentele și compromisurile din spatele site-urilor web mari poate aduce decizii mai inteligente atunci când construiți site-uri web mai mici. Mai jos sunt câteva principii cheie care influențează proiectarea sistemelor web la scară largă: Fiecare dintre aceste principii oferă o bază pentru luarea deciziilor în proiectarea unei arhitecturi web distribuite. Cu toate acestea, ele pot fi, de asemenea, în conflict între ele, deoarece atingerea obiectivelor unuia vine în detrimentul neglijării celuilalt. Un exemplu simplu: alegerea de a adăuga pur și simplu mai multe servere ca soluție de performanță (scalabilitate) poate crește costul de gestionare (trebuie să rulați un server suplimentar) și achizițiile de servere. Atunci când dezvoltați orice fel de aplicație web, este important să luați în considerare aceste principii cheie, chiar dacă este pentru a confirma că proiectul poate sacrifica unul sau mai multe dintre ele. Când luăm în considerare arhitectura sistemului, există mai multe probleme care trebuie abordate, cum ar fi ce componente merită folosite, cum se potrivesc împreună și ce compromisuri pot fi făcute. Investirea banilor în extindere fără o nevoie clară de aceasta nu este o decizie de afaceri inteligentă. Cu toate acestea, o anumită gândire în planificare poate economisi timp și resurse semnificative în viitor. Această secțiune se concentrează pe câțiva factori de bază care sunt critici pentru aproape toate aplicațiile web mari: Servicii, Probabil ați mai postat imagini online. Pentru site-urile mari care stochează și livrează multe imagini, există provocări în crearea unei arhitecturi rentabile, extrem de fiabile, care are latențe scăzute de răspuns (recuperare rapidă). Imaginați-vă un sistem în care utilizatorii au posibilitatea de a-și încărca imaginile pe un server central și în care imaginile pot fi solicitate printr-un link de site sau API, similar cu Flickr sau Picasa. Pentru a simplifica descrierea, să presupunem că această aplicație are două sarcini principale: capacitatea de a încărca (scrie) imagini pe server și de a solicita imagini. Desigur, încărcarea eficientă este criteriu important, cu toate acestea, se va acorda prioritate livrării prompte conform solicitării utilizatorilor (de exemplu, imaginile pot fi solicitate pentru afișare pe o pagină web sau de către o altă aplicație). Această funcționalitate este similară cu ceea ce poate oferi un server web sau un server edge Content Delivery Network (CDN). Un server CDN stochează, de obicei, obiectele de date în mai multe locații, aducându-le astfel mai aproape geografic/fizic de utilizatori, rezultând performanțe îmbunătățite. Alte aspecte importante ale sistemului: O altă problemă potențială a acestui design este că un server web precum Apache sau lighttpd are, de obicei, o limită superioară a numărului de conexiuni simultane pe care le poate deservi (valoarea implicită este de aproximativ 500, dar poate fi mult mai mare) și cu trafic ridicat. , înregistrările pot utiliza rapid această limită. Deoarece citirile pot fi asincrone sau pot profita de alte optimizări de performanță, cum ar fi compresia gzip sau fragmentarea, serverul web poate comuta mai repede citirile de feed și poate comuta între clienți în timp ce deservește mult mai multe solicitări decât numărul maxim de conexiuni (cu Apache și număr maxim conexiuni setate la 500, este foarte posibil să se servească câteva mii de solicitări de citire pe secundă). Înregistrările, pe de altă parte, tind să mențină conexiunea deschisă pe toată durata descărcării. Astfel, transferul unui fișier de 1 MB pe server ar putea dura mai mult de 1 secundă pe majoritatea rețelelor de acasă, ceea ce înseamnă că serverul web poate procesa doar 500 dintre aceste intrări simultane. Anticiparea acestei probleme potențiale sugerează necesitatea de a separa citirea și scrierea imaginilor în servicii independente, prezentate în . Acest lucru ne va permite nu numai să le extindem pe fiecare dintre ele individual (din moment ce este probabil să facem întotdeauna mai multe citiri decât scrieri), ci și să fim conștienți de ceea ce se întâmplă în fiecare serviciu. În cele din urmă, va diferenția problemele care pot apărea în viitor, facilitând diagnosticarea și evaluarea problemei accesului lent la citire. Avantajul acestei abordări este că suntem capabili să rezolvăm probleme independent unul de celălalt - fără a fi nevoie să ne facem griji cu privire la înregistrarea și preluarea de noi imagini în același context. Ambele servicii încă folosesc corpus global de imagini, dar prin utilizarea tehnicilor specifice serviciului, ele sunt capabile să-și optimizeze propria performanță (de exemplu, cererile de așteptare sau memorarea în cache). imagini populare- acest lucru va fi discutat mai detaliat mai târziu). Atât din perspectiva serviciilor, cât și a costurilor, fiecare serviciu poate fi scalat independent, după cum este necesar. Și acesta este un lucru pozitiv, deoarece combinarea și amestecarea acestora le-ar putea afecta din neatenție performanța, ca în scenariul descris mai sus. Desigur, modelul de mai sus va funcționa optim dacă există două puncte finale diferite (de fapt, acesta este foarte asemănător cu mai multe implementări ale furnizorilor de stocare în cloud și ale rețelelor de livrare de conținut). Există multe modalități de a rezolva astfel de probleme și în fiecare caz se poate găsi un compromis. De exemplu, Flickr rezolvă această problemă de citire-scriere prin distribuirea utilizatorilor între diferite module, astfel încât fiecare modul să poată servi doar un număr limitat de utilizatori. anumiți utilizatori, iar pe măsură ce numărul de utilizatori crește, mai multe poduri sunt adăugate la cluster (consultați prezentarea de scalare Flickr, În ceea ce privește aceste sisteme, nu există panaceu, dar ar trebui să porniți întotdeauna de la principiile descrise la începutul acestui capitol: determinați nevoile sistemului (sarcină de citire sau scriere sau ambele, nivel de paralelism, interogări pe seturi de date, intervale, sortare, etc.), să efectueze teste comparative de referință ale diferitelor alternative, să înțeleagă condițiile potențiale de defecțiune a sistemului și să elaboreze un plan cuprinzător în cazul în care apare o defecțiune. Pentru a gestiona cu grație eșecul, arhitectura web trebuie să aibă redundanță în serviciile și datele sale. De exemplu, dacă există o singură copie a unui fișier stocată pe un singur server, pierderea acelui server va însemna pierderea fișierului. Cu greu situație similară poate fi descris pozitiv și, de obicei, poate fi evitat prin crearea mai multor copii sau copii de rezervă. Același principiu se aplică serviciilor. Vă puteți proteja împotriva defecțiunii unui singur nod oferind o parte integrantă a funcționalității aplicației, pentru a vă asigura că mai multe copii sau versiuni ale acesteia pot rula simultan. Crearea redundanței în sistem vă permite să scăpați de puncte slabeși oferă funcționalitate de rezervă sau redundantă în caz de urgență. De exemplu, dacă există două instanțe ale aceluiași serviciu care rulează în producție și una dintre ele eșuează complet sau parțial, sistemul poate depăși eșecul prin trecerea la o copie de lucru. Alte Rol cheie redundanță serviciu – creare arhitectură care nu prevede partajarea resurselor. Cu această arhitectură, fiecare nod este capabil să opereze independent și, mai mult, în absența unui „creier” central care să gestioneze stările sau să coordoneze acțiunile altor noduri. Promovează scalabilitatea, deoarece adăugarea de noi noduri nu necesită conditii speciale sau cunoștințe. Cel mai important, aceste sisteme nu au un punct critic de defecțiune, ceea ce le face mult mai rezistente la defecțiuni. De exemplu, în aplicația noastră de server de imagini, toate imaginile ar avea copii redundante undeva într-o altă piesă hardware (în mod ideal, într-o locație geografică diferită în cazul unui dezastru, cum ar fi un cutremur sau un incendiu în centrul de date), iar serviciile ar accesa imaginile vor fi redundante, având în vedere că toate vor putea servi cererile. (Cm. .) Seturile de date pot fi atât de mari încât nu pot fi găzduite pe un singur server. De asemenea, se poate întâmpla ca operațiunile de calcul să necesite prea mari resurse informatice, reducând productivitatea și producția crestere necesara putere. În orice caz, aveți două opțiuni: scalare verticală sau orizontală. Scalare verticală implică adăugarea mai multor resurse la un singur server. Deci, pentru un set de date foarte mare, aceasta ar însemna adăugarea mai multor (sau mai multe) hard disk-uri, și astfel întregul set de date ar putea fi găzduit pe un singur server. În cazul operațiunilor de calcul, aceasta ar însemna mutarea calculului pe un server mai mare, cu un procesor mai rapid sau mai multă memorie. În orice caz, scalarea verticală se face pentru a face o singură resursă de sistem de calcul capabilă de procesare suplimentară a datelor. Scalare orizontală, pe de altă parte, implică adăugarea mai multor noduri. În cazul unui set mare de date, aceasta ar însemna adăugarea unui al doilea server pentru a stoca o parte din volumul total de date, iar pentru o resursă de calcul, aceasta ar însemna împărțirea muncii sau a încărcăturii pe câteva noduri suplimentare. Pentru a profita din plin de potențial scalare orizontală, trebuie implementat ca principiu intern al dezvoltării arhitecturii sistemului. În caz contrar, schimbarea și izolarea contextului necesar pentru scalarea orizontală poate fi problematică. Cea mai comună metodă de scalare orizontală este împărțirea serviciilor în segmente sau module. Ele pot fi distribuite în așa fel încât fiecare set logic funcționalitatea va funcționa separat. Acest lucru se poate face în funcție de limitele geografice sau de alte criterii, cum ar fi utilizatorii plătitori și neplătitori. Avantajul acestor scheme este că oferă un serviciu sau un depozit de date cu funcționalitate îmbunătățită. În exemplul nostru de server de imagini, este posibil ca un singur server de fișiere folosit pentru a stoca imaginea să fie înlocuit cu mai multe servere de fișiere, fiecare conținând propriul set unic de imagini. (Vezi.) Această arhitectură ar permite sistemului să umple fiecare server de fișiere cu imagini, adăugând servere suplimentare pe măsură ce devine plin. spatiu pe disc. Designul va necesita o schemă de denumire care asociază numele fișierului imagine cu serverul care îl conține. Numele imaginii poate fi generat dintr-o schemă de hashing consecventă legată de servere. Sau, alternativ, fiecare imagine ar putea avea un ID incremental, care ar permite serviciului de livrare, atunci când solicită o imagine, să proceseze doar gama de ID-uri asociate fiecărui server (ca index). Desigur, există dificultăți în distribuirea datelor sau a funcționalității pe mai multe servere. Unul dintre probleme fundamentale - locația datelor; în sistemele distribuite, cu cât datele sunt mai aproape de punctul de operare sau de calcul performanță mai bună sisteme. În consecință, distribuirea datelor pe mai multe servere este potențial problematică, deoarece în orice moment datele pot fi necesare, există riscul ca acestea să nu fie disponibile în locația dorită, serverul va trebui să efectueze o recuperare costisitoare a informațiilor necesare peste rețeaua. O altă problemă potențială apare în formă Există, desigur, unele obstacole asociate cu segmentarea datelor, dar segmentarea vă permite să izolați fiecare problemă de celelalte: după date, după încărcare, după modele de utilizare etc. în blocuri gestionate. Acest lucru poate ajuta la scalabilitate și gestionabilitate, dar există totuși riscuri. Există multe modalități de a reduce riscul și de a gestiona eșecurile; cu toate acestea, din motive de concizie, acestea nu sunt tratate în acest capitol. Dacă doriți mai multe informații despre acest subiect, ar trebui să aruncați o privire la postarea de blog despre toleranța la erori și monitorizarea. După ce am analizat câteva principii de bază în dezvoltarea sistemelor distribuite, să trecem acum la o problemă mai complexă - scalarea accesului la date. Cele mai simple aplicații web, cum ar fi aplicațiile LAMP stack, sunt similare cu imaginea din . Pe măsură ce o aplicație crește, apar două provocări principale: scalarea accesului la serverul de aplicații și la baza de date. Într-un design de aplicație extrem de scalabil, serverul web sau de aplicații este de obicei minimizat și adesea implementează o arhitectură de partajare a resurselor. Acest lucru face ca stratul de server de aplicații al sistemului să fie scalabil pe orizontală. Ca rezultat al acestui design, munca grea se va muta în jos pe stiva către serverul bazei de date și servicii suport; Acest strat este locul în care intră în joc problemele reale de scalare și performanță. Restul acestui capitol acoperă unele dintre cele mai comune strategii și tehnici pentru îmbunătățirea performanței și scalabilității acestor tipuri de servicii prin furnizarea de acces rapid la date. Majoritatea sistemelor pot fi simplificate la un circuit în În scopul acestei secțiuni, să presupunem că aveți mulți teraocteți (TB) de date și le permiteți utilizatorilor să acceseze porțiuni mici din acele date în ordine aleatorie. (Cm. .) Acest lucru este deosebit de dificil deoarece încărcarea terabytelor de date în memorie poate fi foarte costisitoare și are un impact direct asupra I/O-ului pe disc. Viteza de citire de pe un disc este de câteva ori mai mică decât viteza de citire de pe RAM - putem spune că accesarea memoriei este la fel de rapidă ca Chuck Norris, în timp ce accesarea unui disc este mai lentă decât coada de la clinică. Această diferență de viteză este vizibilă în special pentru seturi mari date; În numere brute, accesul la memorie este de 6 ori mai rapid decât citirile pe disc pentru citirile secvențiale și de 100.000 de ori mai rapid pentru citirile aleatorii (vezi Pathologies of Big Data, http://queue.acm.org/detail. cfm?id=1563874). ). Mai mult, chiar și cu identificatori unici, rezolvarea problemei de a găsi locația unei mici bucăți de date poate fi la fel de dificilă ca și încercarea de a alege ultima bomboană umplută cu ciocolată dintr-o cutie cu sute de alte bomboane fără a căuta. Din fericire, există multe abordări care pot fi luate pentru a simplifica lucrurile, cele mai importante patru abordări fiind utilizarea cache-urilor, proxy-urilor, indexurilor și echilibratorilor de încărcare. Restul acestei secțiuni discută modul în care fiecare dintre aceste concepte poate fi utilizat pentru a face accesul la date mult mai rapid. Memorarea în cache beneficiază de o caracteristică a principiului de bază: datele solicitate recent este probabil să fie din nou necesare. Cache-urile sunt folosite la aproape toate nivelurile de calcul: hardware, OS, browsere web, aplicații web și multe altele. Un cache este ca memoria pe termen scurt: limitat ca dimensiune, dar mai rapid decât sursa de date originală și conține elemente care au fost accesate recent. Cache-urile pot exista la toate nivelurile din arhitectură, dar sunt adesea găsite la nivelul cel mai apropiat de front end, unde sunt implementate pentru a returna datele rapid, fără încărcare semnificativă a backend-ului. Deci, cum poate fi folosit un cache pentru a accelera accesul la date în exemplul nostru de API? În acest caz, există mai multe locații cache adecvate. O posibilă opțiune de plasare este selectarea nodurilor la nivel de interogare, așa cum se arată în Plasarea cache-ului direct pe nodul la nivel de cerere permite stocarea locală a datelor de răspuns. De fiecare dată când se face o solicitare de serviciu, nodul va returna rapid date locale, stocate în cache, dacă există. Dacă nu este în cache, nodul de solicitare va solicita datele de pe disc. Cache-ul de pe un nod la nivel de interogare ar putea fi, de asemenea, localizat atât în memorie (care este foarte rapidă), cât și pe disc local nod (mai rapid decât încercarea de a accesa stocarea în rețea). Ce se întâmplă când distribuiți memoria cache pe mai multe noduri? După cum puteți vedea, dacă nivelul de solicitare include multe noduri, atunci este probabil ca fiecare nod să aibă propriul cache. Cu toate acestea, dacă echilibratorul dvs. de încărcare distribuie aleatoriu solicitările între noduri, atunci aceeași solicitare va merge la diferite noduri, crescând astfel ratele de cache. Două moduri de a depăși acest obstacol sunt cache-urile globale și distribuite. Semnificația unui cache global este clar din nume: toate nodurile împărtășesc un singur spațiu cache. În acest caz, adăugați un server sau stocare de fișiere de un fel care este mai rapid decât spațiul de stocare original și care va fi disponibil pentru toate nodurile la nivel de solicitare. Fiecare dintre nodurile de solicitare interogează memoria cache în același mod ca și cum ar fi local. Acest tip de schemă de stocare în cache poate cauza unele probleme, deoarece un singur cache poate fi foarte ușor supraîncărcat dacă numărul de clienți și cereri crește. În același timp, această schemă este foarte eficientă pe anumite arhitecturi (în special cele asociate cu hardware specializat care face ca acest cache global să fie foarte rapid, sau care are un set fix de date care trebuie să fie stocat în cache). Există două forme standard de cache globale prezentate în diagrame. Situația arătată este că atunci când răspunsul din cache nu este găsit în cache, memoria cache în sine devine responsabilă pentru recuperarea părții lipsă a datelor din stocarea de bază. Ilustrat este responsabilitatea nodurilor de solicitare de a prelua orice date care nu se găsesc în cache. Majoritatea aplicațiilor care folosesc cache-urile globale tind să folosească primul tip, unde memoria cache în sine gestionează înlocuirea și preluarea datelor pentru a preveni clienții să inunde cererile pentru aceleași date. Cu toate acestea, există unele cazuri în care a doua implementare are mai mult sens. De exemplu, dacă memoria cache este folosită pentru foarte fișiere mari, un procent scăzut de acces reușit la cache va duce la supraîncărcarea memoriei cache-tampon cu accesări nereușite la cache; in aceasta situatie ajuta sa ai procent mare set de date partajat (sau set de date fierbinte) în cache. Un alt exemplu este o arhitectură în care fișierele stocate în cache sunt statice și nu trebuie șterse. (Acest lucru se poate întâmpla din cauza caracteristicilor de performanță subiacente referitoare la o astfel de latență a datelor - poate că anumite părți ale datelor trebuie să fie foarte rapide pentru seturi mari de date - în care logica aplicației înțelege strategia de înlocuire sau hotspot-urile mai bine decât memoria cache.) Acești indecși sunt adesea stocați în memorie sau undeva foarte local la cererea clientului primit. Berkeley DB (BDB) și structurile de date arborescente, care sunt utilizate de obicei pentru a stoca date în liste ordonate, sunt ideale pentru accesul indexat. Există adesea multe straturi de indici care acționează ca o hartă, deplasându-vă dintr-o locație în alta și așa mai departe, până când aveți datele de care aveți nevoie. (Cm. ) Indecșii pot fi, de asemenea, utilizați pentru a crea mai multe alte vizualizări ale acelorași date. Pentru seturi mari de date, aceasta este o modalitate excelentă de a defini filtre și vizualizări diferite fără a fi nevoie să creați multe copii suplimentare ale datelor. De exemplu, să presupunem că sistemul de găzduire a imaginilor menționat mai sus găzduiește de fapt imagini ale paginilor cărților, iar serviciul permite clienților să interogheze textul din acele imagini, căutând tot conținutul text pe un anumit subiect în același mod în care îți permit motoarele de căutare. pentru a căuta HTML.conținut. În acest caz, toate aceste imagini de cărți folosesc atât de multe servere pentru a stoca fișiere, iar găsirea unei singure pagini pe care să o prezinte utilizatorului poate fi destul de dificilă. Inițial, indexurile inverse pentru interogarea cuvintelor arbitrare și seturi de cuvinte ar trebui să fie ușor disponibile; apoi există sarcina de a naviga la pagina și locația exactă din acea carte și de a prelua imaginea corectă pentru rezultatele căutării. Deci, în acest caz, indexul inversat s-ar mapa la locație (cum ar fi cartea B), iar apoi B ar putea conține indexul cu toate cuvintele, locațiile și numărul de apariții din fiecare parte. Un index inversat, pe care Index1 l-ar putea afișa în diagrama de mai sus, ar arăta cam așa: Fiecare cuvânt sau set de cuvinte servește ca index pentru acele cărți care le conțin. Indexul intermediar va arăta similar, dar va conține doar cuvintele, locația și informațiile pentru cartea B. Această arhitectură stratificată permite fiecărui index să ocupe mai puțin spațiu decât dacă toate aceste informații ar fi stocate într-un index mare inversat. Și asta moment cheieîn sistemele la scară mare, deoarece chiar și atunci când sunt comprimați, acești indici pot fi destul de mari și costisitoare de stocat. Să presupunem că avem multe cărți din toată lumea în acest sistem - 100.000.000 (vezi postarea de blog „În interiorul cărților Google”) - și că fiecare carte are doar 10 pagini (pentru a simplifica calculele) cu 250 de cuvinte pe pagină: Aceasta oferă ne un total de 250 de miliarde de cuvinte. Dacă luăm că numărul mediu de caractere dintr-un cuvânt este 5 și codificăm fiecare caracter cu 8 biți (sau 1 octet, chiar dacă unele caractere ocupă de fapt 2 octeți), cheltuind astfel 5 octeți pe cuvânt, atunci indexul care îi conține pe fiecare cuvântul o singură dată ar necesita o stocare mai mare de 1 teraoctet. Așadar, puteți vedea că indexurile care conțin și alte informații, cum ar fi seturile de cuvinte, locațiile de date și numărul de utilizare, pot crește în dimensiune foarte rapid. Crearea unor astfel de indici intermediari și prezentarea datelor în bucăți mai mici face ca problema datelor mari să fie mai ușor de rezolvat. Datele pot fi distribuite pe mai multe servere și, în același timp, pot fi accesibile rapid. Indexurile sunt piatra de temelie a regăsării informațiilor și baza modernului de astăzi motoare de căutare. Desigur, această secțiune doar zgârie suprafața subiectului de indexare și au existat o mulțime de cercetări despre cum să faci indici mai mici, mai rapid, să conțină mai multe informații (cum ar fi relevanța) și să fie ușor de actualizat. (Există unele probleme legate de gestionarea condițiilor concurente, precum și de numărul de actualizări necesare pentru a adăuga date noi sau a modifica datele existente, mai ales atunci când este vorba de relevanță sau punctaj). Este important să vă găsiți datele rapid și ușor, iar indexurile sunt cel mai simplu și mai eficient instrument pentru atingerea acestui obiectiv. În sfârșit, un alt critic o parte importantă a oricărui sistem distribuit - echilibrator de încărcare. Echilibratoarele de încărcare sunt o parte esențială a oricărei arhitecturi, deoarece rolul lor este de a distribui sarcina între nodurile responsabile cu deservirea cererilor. Acest lucru permite ca mai multe noduri să servească în mod transparent aceeași funcție în sistem. (Vezi.) Scopul lor principal este să gestioneze multe conexiuni simultane și să direcționeze acele conexiuni către unul dintre nodurile solicitate, permițând sistemului să se scaleze prin simpla adăugare de noduri pentru a servi mai multe solicitări. Există mulți algoritmi diferiți pentru solicitările de service, inclusiv selecția aleatorie a nodurilor, algoritm ciclic sau chiar selectarea unui nod pe baza anumitor criterii, cum ar fi utilizarea procesor central sau RAM. Echilibratoarele de sarcină pot fi implementate ca dispozitive hardware sau software. Printre echilibratoarele de sarcină pe software Cel mai utilizat software open source este HAProxy. Într-un sistem distribuit, echilibratoarele de încărcare sunt adesea amplasate la „marginea din față” a sistemului, astfel încât toate cererile primite trec direct prin ele. Este foarte probabil ca într-un sistem complex distribuit o solicitare să treacă prin mai multe balansoare, așa cum se arată în La fel ca proxy-urile, unii echilibratori de încărcare pot, de asemenea, direcționa cererile diferit, în funcție de tipul de solicitare. Ele sunt cunoscute și sub numele de proxy inverse. Gestionarea datelor specifice unei anumite sesiuni de utilizator este una dintre provocările atunci când se utilizează echilibratori de încărcare. Pe un site de comerț electronic, atunci când aveți un singur client, este foarte ușor să permiteți utilizatorilor să plaseze articole în coșul lor și să salveze conținutul între vizite (acest lucru este important deoarece probabilitatea de a vinde un articol crește semnificativ dacă, atunci când utilizatorul revine pe site, produsul este încă în coș). Cu toate acestea, dacă un utilizator este direcționat către un nod pentru prima sesiune și apoi către un alt nod la următoarea sa vizită, pot apărea inconsecvențe deoarece noul nod este posibil să nu cunoască conținutul coșului de cumpărături al utilizatorului respectiv. (Nu te-ai supăra dacă ai pune un pachet de Mountain Dew în cărucior și nu era acolo când te-ai întors?) O soluție ar putea fi să faci sesiunile „lipioase”, astfel încât utilizatorul să fie întotdeauna direcționat către același nodul. Cu toate acestea, profitarea unor caracteristici de fiabilitate, cum ar fi failover-ul automat, va fi semnificativ dificilă. În acest caz, coșul utilizatorului va avea întotdeauna conținut, dar dacă nodul lor lipicios devine inaccesibil, atunci va fi necesară o abordare specială și presupunerea despre conținutul coșului nu va mai fi adevărată (deși sperăm că această presupunere nu va fi inclusă în aplicația). Desigur, această problemă poate fi rezolvată folosind alte strategii și instrumente, cum ar fi cele descrise în acest capitol, cum ar fi serviciile și multe altele (cum ar fi cache-urile browserului, cookie-urile și rescrierea URL-urilor). Dacă sistemul are doar câteva noduri, atunci tehnici precum caruselul DNS vor fi probabil mai practice decât echilibratoarele de încărcare, care pot fi costisitoare și pot adăuga un strat inutil de complexitate sistemului. Desigur, în sistemele mari există tot felul de algoritmi diferiți de programare și echilibrare a sarcinii, inclusiv ceva la fel de simplu precum randomizarea sau caruselul, până la mecanisme mai complexe care țin cont de caracteristicile de performanță ale modelului de utilizare a sistemului. Toți acești algoritmi vă permit să distribuiți traficul și cererile și vă pot oferi instrumente utile fiabilitate, cum ar fi failover-ul automat sau eliminarea automată a unui nod deteriorat (de exemplu, atunci când nu mai răspunde). Cu toate acestea, aceste caracteristici avansate pot face diagnosticarea problemelor greoaie. De exemplu, în situații de încărcare mare, echilibratoarele de încărcare vor elimina nodurile care pot rula lent sau pot expira (din cauza unui val de solicitări), ceea ce va înrăutăți lucrurile pentru alte noduri. Monitorizarea extinsă este importantă în aceste cazuri, deoarece, deși traficul și încărcarea generală a sistemului par să scadă (deoarece nodurile deservesc mai puține solicitări), nodurile individuale pot fi extinse la limitele lor. Echilibratoarele de sarcină sunt o modalitate ușoară de a crește capacitatea sistemului. Ca și celelalte metode descrise în acest articol, joacă un rol esențial în arhitectura sistemului distribuit. Echilibratoarele de sarcină oferă, de asemenea, funcția critică de verificare a stării de sănătate a nodurilor. Dacă, în urma unei astfel de verificări, un nod nu răspunde sau este supraîncărcat, atunci acesta poate fi eliminat din pool-ul de procesare a cererilor și, datorită redundanței sistemului dvs., sarcina va fi redistribuită între nodurile de lucru rămase. . Până acum am analizat multe moduri de a citi rapid datele. În același timp, o altă parte importantă a scalării stratului de date este gestionarea eficientă a înregistrărilor. Când sistemele sunt simple și au sarcini minime de procesare și baze de date mici, scrierea poate fi rapid rapid. Cu toate acestea, în mai mult sisteme complexe Acest proces poate dura un timp nedefinit. De exemplu, este posibil ca datele să fie scrise în mai multe locuri pe servere sau indici diferiți, sau sistemul poate fi pur și simplu sub încărcare mare. În cazurile în care scrierile, sau chiar orice sarcină, durează mult timp, obținerea performanței și a disponibilității necesită construirea asincroniei în sistem. O modalitate obișnuită de a face acest lucru este de a organiza o coadă de solicitări. Imaginați-vă un sistem în care fiecare client solicită o sarcină de service la distanță. Fiecare dintre acești clienți își trimite cererea către server, care efectuează sarcinile cât mai repede posibil și returnează rezultatele acestora clienților corespunzători. În sistemele mici în care un singur server (sau serviciu logic) poate servi clienții care sosesc imediat ce ajung, situațiile de această natură ar trebui să funcționeze bine. Cu toate acestea, atunci când serverul primește mai multe solicitări decât poate gestiona, atunci fiecare client este forțat să aștepte ca cererile altor clienți să finalizeze procesarea înainte de a răspunde la cererea proprie va fi generat. Acesta este un exemplu de solicitare sincronă, prezentată în . Acest tip de comportament sincron poate degrada semnificativ performanța clientului; de fapt, fiind inactiv, clientul este forțat să aștepte până primește un răspuns la cerere. Adăugarea de servere suplimentare pentru a face față încărcării sistemului nu rezolvă de fapt problema; Chiar și cu echilibrarea eficientă a sarcinii, este extrem de dificil să se ofere distribuția uniformă și echitabilă a sarcinii necesară pentru a maximiza productivitatea clientului. Mai mult, dacă serverul de procesare a acestei solicitări nu este disponibil (sau s-a prăbușit), atunci și clientul conectat la acesta nu va mai funcționa. O soluție eficientă la această problemă necesită o abstractizare între cererea clientului și munca efectivă efectuată pentru a o servi. Cozi de intrare. Modul în care funcționează coada este foarte simplu: o sarcină sosește, intră în coadă, iar apoi „lucrătorii” acceptă următoarea sarcină de îndată ce au posibilitatea de a o procesa. (Vezi.) Aceste sarcini pot fi note simple la o bază de date sau ceva la fel de complex precum generarea unei imagini previzualizare pentru document. Când un client trimite cereri de sarcini la o coadă, nu mai trebuie să aștepte rezultatele execuției; în schimb, cererile au nevoie doar de confirmarea faptului că au fost primite corect. Această confirmare poate servi ulterior ca referință la rezultatele muncii atunci când clientul le solicită. Cozile permit clienților să lucreze într-un mod asincron, oferind o abstractizare strategică a cererii și răspunsului clientului. Pe de altă parte, în sistem sincron, nu există nicio diferențiere între cerere și răspuns și, prin urmare, acestea nu pot fi gestionate separat. Într-un sistem asincron, clientul trimite o sarcină, serviciul răspunde cu un mesaj care confirmă că sarcina a fost primită, iar clientul poate verifica apoi periodic starea sarcinii, solicitând rezultatul doar odată ce aceasta a fost finalizată. În timp ce clientul face o solicitare asincronă, este liber să facă alte lucrări și chiar să facă cereri asincrone de la alte servicii. Acesta din urmă este un exemplu al modului în care cozile și mesajele funcționează în sistemele distribuite. Cozile oferă, de asemenea, o anumită protecție împotriva întreruperilor și defecțiunilor serviciului. De exemplu, este destul de ușor să creați o coadă foarte rezistentă care poate reîncerca solicitările de servicii care eșuează din cauza defecțiunilor momentane ale serverului. Este de preferat să folosiți o coadă pentru a impune garanțiile de calitate a serviciului, mai degrabă decât să expuneți clienții la întreruperi temporare ale serviciului, necesitând o gestionare complexă și adesea inconsecventă a erorilor din partea clientului. Cozile sunt principiul de bază în gestionarea transmisiei distribuite între diverse părți orice sistem distribuit pe scară largă și există multe modalități de a le implementa. Există destul de multe implementări open source, cum ar fi RabbitMQ. 1.1 Principii de construire a sistemelor web distribuite
1.2 Elemente de bază
redundanţă, segmentare, Și tratarea eșecului. Fiecare dintre acești factori implică alegeri și compromisuri, mai ales în contextul principiilor descrise în secțiunea anterioară. Pentru a clarifica, hai sa dam un exemplu.Exemplu: Aplicație de găzduire a imaginilor
Figura 1.2: Separarea citire/scriere
http://mysqldba.blogspot.com/2008/04/mysql-uc-2007-presentation-file.html). În primul exemplu, este mai ușor să scalați hardware-ul în funcție de sarcina reală de utilizare (numărul de citiri și scrieri din întregul sistem), în timp ce Flickr se scalează pe baza bazei de utilizatori (cu toate acestea, aceasta folosește ipoteza unei utilizări uniforme în întregul sistem). utilizatori diferiți, deci capacitatea trebuie planificată în funcție de stoc). În trecut, o indisponibilitate sau o problemă cu unul dintre servicii ar sparge funcționalitatea întregului sistem (de exemplu, nimeni nu putea scrie fișiere), apoi indisponibilitatea unuia dintre modulele Flickr ar afecta doar utilizatorii asociați acestuia. În primul exemplu, este mai ușor să efectuați operațiuni pe întregul set de date - de exemplu, actualizarea serviciului de înregistrare pentru a include metadate noi sau căutarea tuturor metadatelor imaginii - în timp ce cu arhitectura Flickr, fiecare modul trebuia actualizat sau căutat ( sau a trebuit creat serviciul de căutare pentru a sorta metadatele care sunt de fapt destinate acestui scop).Redundanţă
Comutarea poate avea loc automat sau poate necesita intervenție manuală.
Privind în viitor, balansoarele de încărcare sunt o modalitate excelentă de a face acest lucru posibil, dar mai multe despre asta mai jos.
Figura 1.3: Aplicație redundantă de găzduire a imaginilorSegmentarea
Figura 1.4: Aplicație de găzduire a imaginilor cu redundanță și segmentare
inconsecvență (incoerență).Când diverse servicii citește și scrie într-o resursă partajată, eventual un alt serviciu sau un depozit de date, este posibil să apară condiții de cursă - unde unele date sunt considerate a fi actualizate la cea mai recentă stare, dar sunt de fapt citite înainte de a fi actualizate - caz în care datele sunt inconsecvente. De exemplu, într-un scenariu de găzduire a imaginilor, poate apărea o condiție de cursă dacă un client a trimis o solicitare de actualizare a unei imagini a unui câine, schimbând titlul „Câine” în „Gizmo” în timp ce un alt client citea imaginea. Într-o astfel de situație, nu este clar ce titlu, „Câine” sau „Gizmo”, ar fi primit al doilea client.1.3. Elemente de bază pentru acces rapid și scalabil la date
Figura 1.5: Aplicații web simple
Figura 1.6: Aplicație web simplificată
care este un loc bun pentru a începe să cauți. Dacă aveți multe date, se poate presupune că doriți să aveți același acces ușor și acces rapid ca cutia de bomboane din sertarul de sus al biroului tău. Deși această comparație este prea simplificată, ea indică două probleme complexe: scalabilitate de stocare a datelor și acces rapid la date.
O sarcină similară este de a determina locația unui fișier imagine undeva pe un server de fișiere într-un exemplu de aplicație de găzduire a imaginilor.
Figura 1.7: Acces la date specificeCache-urile
.
Figura 1.8: Plasarea în cache pe un nod la nivel de interogare
Figura 1.9: Sisteme de cacheCache global
Figura 1.10: Cache-ul global, unde memoria cache este responsabilă pentru recuperare
Figura 1.11: Cache global, unde nodurile de solicitare sunt responsabile pentru extragereCache distribuită
Figura 1.17: Indici multinivelEchilibratoare de sarcină
Figura 1.18: Load Balancer
.
Figura 1.19: Echilibratoare de sarcină multipleCozile
Figura 1.20: Cerere sincronă
Figura 1.21: Utilizarea cozilor pentru a gestiona cererile
ActiveMQ
BeanstalkD, dar unii folosesc și servicii precum
