KNOW INTUIT, Prelegere, tehnologii componente și dezvoltare software distribuită
Comunicare sincronă și asincronă
Atunci când descrie interacțiunea dintre elementele sistemelor software, inițiatorul interacțiunii, i.e. componenta care trimite cererea de procesare se numește de obiceiclient, iar componenta care răspunde care procesează cererea se numeșteserver. „Client” și „server” în acest context denotă roluri în cadrul unei interacțiuni date. În cele mai multe cazuri, aceeași componentă poate acționa în roluri diferite - uneori ca client, apoi ca server - în diverse interacțiuni. Numai într-o clasă mică de sisteme, rolurile de client și server sunt atribuite componentelor pe durata existenței acestora.
Synchronouseste o interacțiune între componente în care clientul, după ce a trimis o solicitare, este blocat și poate continua să lucreze numai după primirea unui răspuns de la server. Din acest motiv, acest tip de interacțiune este uneori denumitblocare.
Simpla accesare a unei funcții sau a unei metode pe un obiect prin trecerea controlului în stiva de apeluri este un exemplu de comunicare sincronă.
Interacțiunea sincronă este destul de simplu de configurat și mult mai ușor de înțeles. Mintea umană are un singur „flux de control”, reprezentat ca un centru de atenție și, prin urmare, este mai ușor pentru o persoană să înțeleagă procesele care se desfășoară secvenţial, deoarece nu este nevoie să treci constant atenția asupra diferitelor evenimente care au loc simultan. Codul de program al componentei client care descrie interacțiunea sincronă este mai simplu - partea sa, care este responsabilă de procesarea răspunsului serverului, se află imediat după partea în care este formată cererea. Datorită simplității lor, sincroneinteracțiunile în majoritatea sistemelor sunt folosite mult mai des decât cele asincrone.
Cu toate acestea, interacțiunea sincronă duce la un timp semnificativ petrecut în așteptarea unui răspuns. Acest timp poate fi adesea folosit într-un mod mai util: în așteptarea unui răspuns la o solicitare, clientul ar putea face alte lucrări, efectua alte solicitări care nu depind de rezultatul care nu a ajuns încă. Deoarece toate sistemele distribuite constau dintr-un număr suficient de mare de straturi prin care trec aproape toate interacțiunile, scăderea totală a performanței asociată cu sincronismul interacțiunilor se dovedește a fi foarte mare.
Cel mai comun și din punct de vedere istoric primul mod destul de universal de a implementa interacțiunea sincronă în sistemele distribuite este un apel de procedură la distanță (Remote Procedure Call, RPC; de fapt, ar fi mai corect să spunem „apel de procedură la distanță”, dar din motive istorice, terminologia existentă a fost fixată). Modificarea sa pentru un mediu orientat pe obiect se numeșteRemote Method Invocation (RMI). RPC definește atât modul în care componentele comunică, cât și modul în care sunt dezvoltate acele componente.
Primul pas de dezvoltare este definirea interfeței procedurilor care vor fi utilizate pentru apelul la distanță. Acest lucru se realizează folosindInterface Definition Language (IDL)Interface Definition Language, care poate fi un limbaj specializat sau un limbaj obișnuit de programare, cu restricții determinate de capacitatea de a transfera apeluri către un mașină la distanță.
Definiția unei proceduri pentru apelurile la distanță este compilată de compilatorul IDL într-o descriere a acestei proceduri în limbaje de programare,pe care vor fi dezvoltate clientul și serverul (de exemplu, fișierele antet C/C++) și două componente suplimentare -clientșiserver stubs(client stubșiserver stub).
Client stubeste o componentă găzduită pe aceeași mașină ca și componenta client. Un apel de procedură de la distanță de către un client este implementat ca un apel local normal la o anumită funcție într-un stub client. Când procesează acest apel, stub-ul clientului face următoarele:
Ca rezultat, un apel de procedură la distanță arată ca un apel de funcție normal către client.