1. Proceduri de mecanism RPC
comunicații sincrone între module de aplicație (client și server) sprijină specificația procedurii de apel de la distanță (remote procedure apel - RPC). Pentru a comunica, transmite apelul și a reveni rezultatul proceselor de client și server se aplică componentelor specifice - adaptoare sau cotoare client și server (de ciot engleză -. Adaptor Stub). Aceste proceduri-stub nu implementează nici o logică de aplicare și sunt destinate numai pentru organizarea de interacțiune a modulelor aplicațiilor la distanță (în general). Fiecare funcție pe server, care poate fi cauzată de un client la distanță, ar trebui să aibă un astfel de proces.
În cazul în care clientul apel de procedură la distanță se execută mai întâi un apel de procedură locală, care este parte a adaptorului client. apel local împreună cu parametrii trecut la adaptorul de client. Astfel, prin utilizarea unui limbaj special definiție interfață (Interface Definition Language - IDL) interfață, o procedură de determinare, adică descrierea parametrilor de procedură transmise acestuia înainte de RPC RPC și a revenit după finalizarea. Apoi, această descriere este tradus și a produs pachetul de date în formatul mesajului - marshaling (marshaling). Adaptorul client este sistemul de operare gazdă, care transmite mesajul către sistemul de operare server de la distanță. Sistemul de operare de la distanță trimite un mesaj la adaptorul de server care implementeaza partea de server a apelului și constând din programe care primesc o cerere de la un client, formatul de date (unmarshaling), apelează procedura reală (implementată în server), și a reveni rezultatele la client. Clientul este blocat și așteaptă un răspuns, dar serverul ruleaza adaptor de server, care transformă mesajul în parametrii procedurii locale. Serverul vede provocarea ca un apel direct procedurii sale locale cu parametrii necesari, un apel și trimite rezultatele la adaptorul de server. Adaptor Server formatează rezultatele procedurii în mesajul către client și server este sistemul de operare gazdă. Sistemul de operare pentru servere transmite mesajul către sistemul de operare al clientului. Clientul este derivat din așteptările statului, sistemul său de operare primește mesajul și trimite-l la adaptor client care preia rezultatele din mesaj, le trimite la client și managementul se întoarce client.
2. Abordarea orientată spre obiect la procesarea informației distribuite
Abordarea orientată spre obiect contribuie la o prelucrare distribuită semnificativă organizarea mecanismelor de îmbunătățire. Cea mai importantă proprietate a obiectelor (obiect) este faptul că acestea vă permit să ascundă structura lor internă prin care au o interfață bine definită. Prin urmare, atunci când înlocuirea sau modificarea obiectelor de interfață pot rămâne neschimbate. Din cauza acestei posibile principii relative de distribuție a luminii și utilizarea RPC de obiecte la distanță.
Obiectele incapsuleaza date numite de stat (de stat) și operațiuni pe aceste date, numite metode (metoda). Pentru a accesa sau de a manipula starea obiectului pe care doriți să utilizați metode care sunt accesate prin interfețe. Un obiect poate implementa mai multe interfețe, și mai multe obiecte care asigură punerea sa în aplicare pot exista pentru această descriere interfață.
Forma de existență a obiectelor în sisteme distribuite corespunde adesea obiectele selectate de limbaj de programare orientat pe obiect. Aceste obiecte sunt așa-numitele obiecte de compilare-timp. Utilizarea acestor obiecte în sistemele distribuite, de obicei, simplifică foarte mult crearea de aplicații distribuite. Dezavantajul utilizării unor astfel de obiecte este dependența lor pe un anumit limbaj de programare. Alternativa este de a crea un obiect distribuit în mod direct în timpul rulării. În această abordare, aplicațiile distribuite sunt independente de limbajul de programare specială și pot fi create din obiecte scrise în limbi diferite. Atunci când se lucrează cu timpul de execuție astfel de obiecte pentru a converti o anumită implementare software a unui obiect, care metode vor fi disponibile pentru sistemul de computer la distanță, adaptorul utilizează obiecte împachetări acest exemplu de realizare, pentru a da o vizibilitate de implementare obiect.
Client pentru a face contactul cu un obiect, prin deputat poate opune pentru a accesa metodele obiect. Astfel, mecanismul de așa-numitele apeluri la distanță la metode (- RMI la distanță invocare a metodei) este implementată cu o abordare orientată spre obiect de prelucrare a informațiilor distribuite.
Contactarea metalul poate fi statice (interfețe cunoscute în proiectarea) sau dinamice (parametrii colectate inainte de metoda accesare).
Pe baza mecanismului RMI dezvoltat mai multe standarde și implementări de software ale platformelor middleware orientate obiect de sprijin eficient de informații distribuite de procesare.
3 interacțiuni tranzacționale de prelucrare a datelor distribuite pe bază
Pentru a implementa interacțiuni tranzacționale aplică TPM Monitor de procesare a tranzacțiilor (Transaction Processing Monitor), sau monitoare de tranzacții, destinate să asigure accesul fiabil la multiplex un număr mare de resurse pentru un număr mare de utilizatori simultani. Mecanismul TPM - cea mai veche tehnologie de implementare a sistemelor distribuite, care a apărut în 1970 într-un mediu de mare de calculatoare mainframe pentru a efectua servicii bancare, asigurări și alte calcule vysokokritichnyh.
Monitoarele tranzactionale sunt una dintre cele mai complexe și multi-tehnologie în middleware mondială. Acestea sunt concepute pentru a sprijini aplicarea automatizată, conceput sub forma unei secvențe de tranzacții. Fiecare tranzacție este finalizată bloc circulația la resurse (mai ales - la baza de date) și o acțiune pe ea. executarea corectă a tranzacției trebuie să garanteze îndeplinirea a patru condiții - proprietățile așa-numita acid (atomicitate, coerență, izolare, durabilitate):
* Atomicitate (Atomicitate) - forma de tranzacție operațiune indivizibilă, unitatea atomică ( «unitate de lucru» - «unitate de operare"), cu începere și de terminare definit. Acest bloc este fie executat de la început până la sfârșit, sau nu efectuat deloc. Dacă în timpul executării unei defecțiuni de tranzacție a avut loc este derulată înapoi la starea inițială;
* Coerența (coerență) - la finalizarea tranzacției toate resursele implicate într-o stare consistentă;
* Izolarea (izolare) - simultane de acces pentru tranzacții diferite aplicații la resurse partajate este coordonată în așa fel încât aceste tranzacții nu afectează reciproc;
* Durabilitate (pe termen lung) - toate actualizările resurselor în tranzacția va fi de lungă durată.
Funcționalitatea monitorului tranzactional este suficient pentru dezvoltarea, punerea în aplicare, gestionarea și întreținerea sistemelor informatice distribuite tranzacționale. Această funcționalitate include limba IDL, denumirea, securitatea și autentificarea, compilatoare, adaptoare, suport pentru lucrul cu tranzacția apeluri (tranzacție paranteze callback), păstrarea intrări de jurnal, de restaurare, de blocare, de gestionare a proceselor și a priorităților, de echilibrare a sarcinii, replicare, managementul resurselor .
Arhitectura include o componentă de interfață monitor de tranzacții client și suport pentru acces direct prin intermediul terminalului. flux Programul efectuează procedura scrisă în monitor care conține operația logică pe resursa numită. Router-ul compară operațiunile și provocările cu care se poate referi la resurse (de exemplu, baza de date) sau serviciile locale ale monitorului. Structura router-ului include o bază de date care conține definiții specializate corespondențelor între nume de resurse logice și dispozitive fizice. Dacă schimbați administratorul de sistem corectează această corespondență: aplicația client nu este necesar să se modifice - clientul știe doar numele logice. interacțiunea resurselor are loc prin managerul de interacțiune (de exemplu, sistemul de comunicații care asigură livrarea garantată și derulare înapoi). Eterogenitatea resurselor asociate cu monitorul ascunde plicul. Efectuează un manager de tranzacții tranzacție efectuarea de protocol 2PC și garantează proprietățile tranzacționale ale procedurilor efectuate de monitor tranzacțional.
Astfel, consorțiul a fost dezvoltat de către OMG Server specificație obiect OTS tranzacție (Object Transaction Server), al cărui scop - să unifice monitorizează tranzacțiile de funcționalitate combinate și cerere obiect brokerii. Această extindere a CORBA este reflectată în caietul de sarcini pentru Java STC (Java Transaction Service - Java Transaction Service).
4. distribuite de procesare, pe baza informațiilor tehnologiei de mesagerie
1) mesaje-trecere,
2) cozile de mesaje c,
Sistemul de mesaje (Message Passing - MP) oferă o interacțiune directă cu fiecare alte aplicații prin trimiterea și primirea de mesaje. Pentru această conexiune logică este stabilită între modulele software. Rezultă că această soluție nu este potrivit pentru programele cuplate slab rulează în modul de timp definit, de exemplu, aplicații, anumite componente care să sprijine utilizatorii mobili. Schimb de mesaje poate fi modul sincron sau asincron. Pe lângă mijloacele de comunicare directă, acest tip de sistem poate furniza servicii suplimentare ale stratului intermediar, de exemplu, serviciul de director.
cozi de mesaje poate fi de lungă durată (persistentă), sau nu. În acest din urmă caz, dacă există o defecțiune a managerului de coadă, mesajul în coada de așteptare vor fi pierdute. Dacă este acceptat de coada pe termen lung, mesajele vor fi restaurate după managerul de repornire. Această opțiune este cu siguranță preferabilă pentru aplicațiile cele mai solicitante. O altă caracteristică a sistemelor intermediare pe baza de cozi de mesaje este de a oferi una dintre cele trei „calitatea serviciului“ niveluri:
* Livrare de încredere de mesaje (livrare mesaj de încredere) - sistemul asigură faptul că nici un singur pachet de rețea se pierde în procesul de mesagerie;
* Mesaje de livrare asigurat (de livrare a mesajului asigurat) - fiecare mesaj este livrat doar o singură dată.
based Sistem intermediar coadă de mesaje poate sprijini de procesare a tranzacțiilor, dezmembrare tranzacții sincrone mari care modifica mai multe baze de date distribuite, eterogene în tranzacții asincrone mai mici, care interacționează unele cu altele prin cozi. Astfel, sistemul OIM poate fi folosit ca un strat mai eficient de comunicare asincronă pentru monitor de procesare a tranzacțiilor TRM. Mesajul eșalonare este un puternic, flexibil și, în același timp, un mecanism simplu de interacțiune între programe. În esență, acest mecanism este similar cu alte paradigme de dezvoltare a aplicațiilor - crearea de programe și conduse de evenimente. Eveniment de o cerere (reprezentant legături) determină o acțiune specifică în cealaltă. Și acest model este cel mai apropiat de procesele de interacțiune reale în activitatea companiilor reale.
Reprezentanții software-ului, construit pe baza mesajului de așteptare sunt sistemul IBM mqseries, MSMQ (Microsoft Message Queuing Server) al Microsoft, compania MessageQ BEA, compania dbQ Sybase.
Procese, prin abonarea la un anumit subiect, transferă apartenența lor la demonul locale. Demon creează tabelul de abur (proces subiect), iar mesajul este livrat la un anumit subiect doar vizualizarea acestui tabel pentru abonații locali, trimițându-l la fiecare dintre procesele. Dacă în acest subiect la acest site nimeni nu a semnat, mesajul este distrus imediat.
Baza tehnologică pentru toate schimburile de tipuri de mesagerie nouă generație devin specificație JMS (Java Message Service - Serviciul de mesagerie Java), definește în detaliu modul de a interacționa cu clienții și serverele în mediul de mesaje asincrone. Printre JMS avantaje includ faptul că acesta corespunde ideilor moderne despre interacțiunea dintre aplicații și nu necesită abilități speciale și este disponibil pentru orice programator care lucrează în Java. Aceste calități este semnificativ diferit de mqseries unelte, care necesită o pregătire specială. Un alt stimulent pentru nașterea unei noi generații de MOM - apariția de date XML Extensible Markup Language (Extensible Markup Language - «eXtensible Markup Language") pentru Internet-aplicații, care permite o singură cerere de a «înțelege» cealaltă.
5. Prelucrarea informațiilor distribuite pe baza modelelor potrivite
Abordarea de bază utilizată în sistemele distribuite bazate pe armonizarea modelelor este separarea proprietății asupra proceselor de calcul a mecanismelor de coordonare a acestora. Dacă luăm în considerare un sistem distribuit ca un set de procese (eventual multithreaded), partea de calcul a sistemului distribuit format dintr-un grup de procese, fiecare dintre care efectuează o operațiuni de calcul specifice, iar aceste operații pot fi efectuate, în principiu, independent de alte procese. În acest model, partea de potrivire a unui sistem distribuit suportă toate comunicațiile între procesele și organizează cooperarea lor reciprocă. Se formeaza „adezivul“ care unește activitățile desfășurate prin diferite procese. În sistemele distribuite, de coordonare se concentrează asupra procesului de reconciliere.
În acest caz, în cazul în care procesele au legături de conectare și de timp, alinierea se realizează în mod direct, și are numele de potrivire directă (coordonare directă). referințe de conectivitate are, în general, identificarea explicită forma interlocutorului în timpul interacțiunii. De exemplu, procesul poate interacționa cu un alt proces numai dacă știe ID-ul de proces, care vrea să facă schimb de informații. conexiune temporară înseamnă că ambele interacționează cu fiecare alte procese sunt active simultan. O astfel de conexiune are loc la nerezidentului pe baza mesajelor de comunicare.
Un exemplu al unui sistem de potrivire este un sistem de Jini ( «vârcolac") de la Sun Microsystems. Atribuirea unui sistem de armonizare Jini se bazează în principal pe faptul că acest sistem este capabil de a susține comunicațiile folosind serviciul generativ Linda-cum ar fi numit JavaSpace. Cu toate acestea, există multe servicii și facilități care fac Jini este mai mult decât sistemul doar de potrivire.
Jini - un sistem distribuit alcătuit din elemente separate, dar interdependente. Acesta este legat de limbajul de programare Java, deși multe dintre principiile sale pot fi puse în aplicare prin utilizarea altor limbi. O parte importantă a sistemului este un model de comunicare de coordonare generativ. Jini oferă atât calendarul și procesele referențiale folosind sistemul incoerență JavaSpace de potrivire. JavaSpace - împărtășește spațiul de date în care să stocheze tuplele. Perechile sunt seturi tipizovannye de referințe la obiecte Java. Într-un sistem Jini pot coexista mai multe spații JavaSpace.
Arhitectura sistemului Jini poate fi reprezentat în trei nivele. Cel mai scăzut nivel de infrastructură constituie. La acest nivel, există mecanismele de bază ale Jini, inclusiv cele care sprijină interacțiunea prin apeluri de limbă RMI Java. Serviciile sunt furnizate atât procedee convenționale și dispozitive pe care software-ul Jini (inclusiv Java Virtual Machine) nu este disponibilă. Prin urmare, serviciile de înregistrare și de căutare, de asemenea, fac parte din infrastructura Jini. Al doilea nivel este format dintr-un mijloc de uz general, care completează infrastructura de bază și pot fi folosite pentru a pune în aplicare mai eficientă a serviciilor. Unele dintre aceste instrumente includ subsistem de notificare eveniment și, chirie bani și resurse care descriu interfețele standard pentru tranzacții. Nivelul superior este format din clienți și servicii. Spre deosebire de celelalte două niveluri Jini nu determină compoziția acestui nivel fără ambiguitate. Stadiul actual al implementării sistemului suportă o serie de servicii de nivel superior, inclusiv serverul JavaSpace și manager de tranzacții care implementează interfețele de tranzacție Jini. programe de nivel înalt, în plus, sunt de multe ori permisiunea de a utiliza în mod direct mecanisme de infrastructură Jini.
Notificare eveniment este implementat de la distanță obiecte ascultător de apel obiect care sunt înregistrate pentru acest eveniment. Data viitoare are loc un eveniment, obiectul ascultător este invocat din nou. Deoarece sistemul Jini în sine nu oferă nici o garanție că notificarea evenimentului este livrat la obiecte ascultător, notificările sunt, de obicei numere de serie la un ascultător obiect are o idee despre succesiunea de evenimente.