Programare Orientată pe Servicii - Curs nr. 1 (recapitulativ) - Java RMI. CORBA - PDF

Programare Orientată pe Servicii Curs nr. 1 (recapitulativ): Java RMI. CORBA s, ef lucr. dr. ing. Alexandru Archip Universitatea Tehnică „Gheorghe Asachi” din Ias, i...

Programare Orientată pe Servicii Curs nr. 1 (recapitulativ): Java RMI. CORBA s, ef lucr. dr. ing. Alexandru Archip Universitatea Tehnică „Gheorghe Asachi” din Ias, i Facultatea de Automatică s, i Calculatoare Tehnologia informat, iei (licent, ă, an IV) – 2023 – 2024 E-mail: [email protected] POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 1/ 29 Pe scurt... 1 Sisteme s, i aplicat, ii distribuite 2 Java RMI Concepte fundamentale Registru RMI Server RMI Client RMI 3 CORBA Definit, ie s, i concepte generale Componente CORBA POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 2/ 29  Sisteme s, i aplicat, ii distribuite Cuprins 1 Sisteme s, i aplicat, ii distribuite 2 Java RMI Concepte fundamentale Registru RMI Server RMI Client RMI 3 CORBA Definit, ie s, i concepte generale Componente CORBA POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 3/ 29  Sisteme s, i aplicat, ii distribuite Definit, ii s, i not, iuni fundamentale Definit, ii: Arhitectura client-server Prin arhitectură client-server înt, elegem un model de calcul în cadrul căruia componenta server găzduies, te, livrează s, i gestionează un set de resurse s, i servicii de interes pentru una sau mai multe entităt, i interesate, denumite client, i. În mod uzual, server -ul este entitatea pasivă/reactivă: nu init, iază apeluri sau procesări de date; rutina principală este de a as, tepta cereri client, cereri care trebuie formulate, în mod uzual, în baza unui protocol; expune un punct de acces – uzual host:port. Client-ul este modulul activ – init, iază cereri, pentru care se as, teaptă un eventual răspuns adecvat. Modelul de interact, iune principal mai este numit model cerere-răspuns. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 4/ 29  Sisteme s, i aplicat, ii distribuite Definit, ii s, i not, iuni fundamentale Definit, ii: Sistem distribuit Un sistem distribuit este o colect, ie de calculatoare independente, interconectate care se prezintă utilizatorilor finali sub forma unui sistem unic. Un sistem de calcul distribuit este compus din componente software care sunt disponibile pe mai multe calculatoare s, i care rulează/operează similar unui singur sistem. Definit, ii: Aplicat, ii distribuite (sursă inspirat, ie definit, ie: ) O aplicat, ie distribuită este o aplicat, ie compusă dintr-un set de module specializate, module care pot fi distribuite în cadrul unui sistem distribuit. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 5/ 29  Sisteme s, i aplicat, ii distribuite Definit, ii s, i not, iuni fundamentale Figura 1: Sistem/aplicat, ie distribuit(ă)1 1 sursă imagine: https://www.ibm.com/docs/en/txseries/8.2?topic= computing-three-tiered-clientserver-architecture#erziaz01-gen4__threetieredfig POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 6/ 29  Sisteme s, i aplicat, ii distribuite Definit, ii s, i not, iuni fundamentale Sistemele s, i aplicat, iile distribuite sunt caracterizate, printre altele, în funct, ie de interdependent, a dintre modulele componente. Relativ la acest aspect, sunt agreate următoarele convent, ii: Sisteme s, i aplicat, ii puternic legate (eng.: strongly/tight coupled ) Un sistem (distribuit) este puternic legat (cuplat) dacă interact, iunile dintre componentele proprii este influent, ată/dependentă de structura/implementarea componentelor respective. Sisteme s, i aplicat, ii slab legate (eng.: loosely coupled ) Un sistem (distribuit) este slab legat (cuplat) dacă orice interact, iune dintre oricare dintre modulele sistemului nu este influent, ată de/nu se bazează pe structura/implementarea respectivelor module. În plus, orice astfel de interact, iune este realizată exclusiv prin intermediul unor interfet, e bine definite. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 7/ 29  Java RMI Cuprins 1 Sisteme s, i aplicat, ii distribuite 2 Java RMI Concepte fundamentale Registru RMI Server RMI Client RMI 3 CORBA Definit, ie s, i concepte generale Componente CORBA POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 8/ 29  Java RMI Introductiv Acronim: Remote Method Invocation Definit, ie Java RMI reprezintă un mecanism care facilitează comunicat, iile între două sau mai multe instant, e JVM a. a Java Virtual Machine În esent, ă, RMI ar trebui să simplifice dezvoltarea aplicat, iilor distribuite. (atunci când componentele distribuite sunt dezvoltate în Java) Este de la sine înt, eles faptul că RMI reprezintă un mecanism proprietar. Ca s, i consecint, ă directă, solut, iile distribuite dezvoltate pe bază de RMI vor fi strâns cuplate. Datele sunt reprezentate în format binar. Nu există – pentru că nu este necesar – un meta-limbaj care să descrie datele vehiculate. A fost init, ial conceput pentru a facilita procesarea la distant, ă (remote) a datelor între aplicat, ii distribuite Java. Versiunile recente oferă suport s, i pentru injectare de cod executabil între aceste aplicat, ii (i.e. între instant, ele JVM). POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 9/ 29  Java RMI Concepte fundamentale Aplicat, iile RMI includ cel put, in două componente distincte: o aplicat, ie de tip client, care va realiza interfat, a cu un eventual utilizator s, i va init, ializa apelurile (call -urile) distribuite; (cel put, in) o aplicat, ie de tip server (denumită s, i servant), care „răspunde” eventualelor apeluri client. Scenariul tipic de operare este (conform ): server creează instant, ele (obiectele) remote; publică referint, ele acestor instant, e în cadrul unui registru de nume; „răspunde” apelurilor client. client obt, ine referint, ele instant, elor remote necesare; invocă metodele corespunzătoarea. Conform , o aplicat, ie RMI poate fi caracterizată ca fiind o aplicat, ie de tip distributed object application. Astfel, funct, ionalităt, ile expuse de un obiect disponibil într-o instant, ă JVM pot fi propagate în alte instant, e JVM. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 10/ 29  Java RMI Concepte fundamentale Figura 2: Java RMI – schematic2 2 sursă imagine: http://www.sce.carleton.ca/netmanage/simulator/rmi/RMIExplanation.htm POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 11/ 29  Java RMI Concepte fundamentale Figura 3: Java RMI – interact, iunea client-server3 3 sursă imagine: http://www.sce.carleton.ca/netmanage/simulator/rmi/RMIExplanation.htm POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 12/ 29  Java RMI Dezvoltarea unei aplicat, ii Java RMI Etape definirea interfet, ei remote comun client/server rolul interfet, ei remote este, în principal, de a expune de metodele disponibile; o interfat, ă Java devine remote dacă: implementează interfat, a java.rmi.Remote toate metodele interfet, ei declară java.rmi.RemoteException în clauza throws; (put, in pretent, ios poate) mai poartă numele de contract remote. Notă Parametri formali s, i rezultatul furnizat ai metodelor interfet, elor remote trebuie să fie descris, i de tipuri de date serializabile (i.e. implements java.io.Serializable)a. a kinda common sense for Java programming, crede profu’ 0:-) POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 13/ 29  Java RMI Dezvoltarea unei aplicat, ii Java RMI Etape implementarea obiectelor remote doar server un obiect remote este un obiect Java care implementează o interfat, ă remote; poate expune local s, i alte metode, dar acestea din urmă NU vor putea fi invocate remote; va juca în final rolul elementului skeleton4 (Figura 3); implementarea client, ilor doar client interfat, a remote devine stub 5 -ul clientului (Figura 3); practic, toate call -urile către metodele stub-ului vor fi, în esent, ă, routate către punctul de acces corespunzător de pe server. 4 putem considera echivalent, a skeleton = gateway 5 putem considera echivalent, a stub = proxy POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 14/ 29  Java RMI Registrul RMI Caracteristici tip s, i rol aplicat, ie de tip server ; are rolul de a gestiona obiectele remote disponibile; asociază nume simbolice cu obiectele remote expuse (funct, ionalitate de tip căutare – eng. lookup); poate fi, în mod simplist, asociat unui server de nume (i.e. DNS simplist/specific Java RMI ); utilitar $JAVA_HOME/bin/rmiregistry; proprietăt, i ret, ea adresa IP/numele DNS a/al host-ului pe care rulează s, i port-ul; port implicit: 1099; argumente rmiregistry ; sintaxă : -J – argumentele corespunzătoare instant, ei JVM; ambele argumente sunt opt, ionale. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 15/ 29  Java RMI Server RMI Caracteristici tip s, i rol aplicat, ie de tip server ; implementează as, a-numitul contract remote; utilitar aplicat, ia Java dezvoltată pentru acest scop; particularităt, i la nivel de ret, ea este, de fapt, expus prin registrul RMI ; codebase-ul aplicat, iei trebuie să includă în CLASSPATH interfet, ele remote; trebuie setate corespunzător politicile de securitate care descriu permisiunile JVM atunci când sunt tratate efectiv cererile client, ilor. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 16/ 29  Java RMI Client RMI Caracteristici tip s, i rol aplicat, ie de tip client; realizează call -urile remote în mod transparent, atât pentru clientul aplicat, iei, cât s, i pentru dezvoltator ; interact, ionează via stub cu server -ul RMI; utilitar aplicat, ia Java dezvoltată pentru acest scop; particularităt, i la nivel de comunicat, ii în ret, ea, trebuie să poată accesa registrul RMI ; codebase-ul aplicat, iei trebuie să includă în CLASSPATH interfet, ele remote; trebuie setate corespunzător politicile de securitate care descriu permisiunile JVM atunci când sunt invocate componentele de tip server RMI s, i procesate răspunsurile primite. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 17/ 29  CORBA Cuprins 1 Sisteme s, i aplicat, ii distribuite 2 Java RMI Concepte fundamentale Registru RMI Server RMI Client RMI 3 CORBA Definit, ie s, i concepte generale Componente CORBA POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 18/ 29  CORBA Acronim s, i definit, ie Acronim Common Object Request Broker Architecture Definit, ie CORBA reprezintă atât un model arhitectural, cât s, i infrastructura corespunzătoare, dezvoltată de OMGa , pentru a permite interact, iuni între aplicat, ii (distribuite) eterogene. a Object Management Group Similar RMI : permite dezvoltarea aplicat, iilor de tip distributed object applications; vizează sisteme de calcul distribuit (i.e. aplicat, iile sunt găzduite în ret, ea); comunicat, iile efective sunt realizate prin elemente de tip stub (sau proxy, la nivel de client) s, i skeleton (sau gateway, la nivel de server ). POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 19/ 29  CORBA Acronim s, i definit, ie Acronim Common Object Request Broker Architecture Definit, ie CORBA reprezintă atât un model arhitectural, cât s, i infrastructura corespunzătoare, dezvoltată de OMGa , pentru a permite interact, iuni între aplicat, ii (distribuite) eterogene. a Object Management Group Spre deosebire de RMI : permite interact, iuni de tip „apel de metodă la distant, ă” (Remote Procedure Call/Remote Method Invocation) între sisteme de calcul s, i aplicat, ii software dezvoltate utilizând tehnologii diferite; reprezintă un prim pas în realizarea practică a conceptelor precum independent, ă de platformă s, i/sau reutilizare de cod. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 19/ 29  CORBA Acronim s, i definit, ie Figura 4: Modelul CORBA – schematic (preluare de la ) POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 20/ 29  CORBA Concepte generale Din punctul de vedere al similarităt, ilor cu Java RMI, punctăm: modelul fundamental utilizat este client-server ; interact, iunea este init, iată de client prin apelul unei metode disponibile pe/furnizate de obiectul servant; se bazează pe module de tip naming service pentru a identifica servant, ii corespunzători; (concret) dezvoltarea atât a aplicat, iilor cu rol de client, cât s, i a celor cu rol de servant (a server -elor) se bazează un set de informat, ii comune, cunoscute anterior stabilirii conexiunii efective. Principalele limitări derivă din lipsa suportului pentru tehnologiile implicate în dezvoltarea aplicat, iilor cu rol de client/servant. Trebuie t, inut cont de faptul că este un set de specificat, ii s, i protocoale proprietare! În plus, dacă limbajele de programare nu sust, in paradigma OOP, atunci interconectarea caracteristică poate fi deficitară. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 21/ 29  CORBA Object Request Broker Figura 5: Modelul de referint, ă OMG – arhitectura ORB (preluare din ) POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 22/ 29  CORBA Object Request Broker Object services interfet, e independente de domeniu, care sunt sau pot fi utilizate indiferent de natura obiectelor servante; de exemplu: servicii de nume, pentru gestiunea ciclului de viat, ă, a scurităt, ii, etc. Common facilities specificat, ii s, i module destinate prezentării s, i partajării obiectelor servante; adresează, în mod special, client, ii finali. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 23/ 29  CORBA Object Request Broker Domain interfaces specializări ale object facilities s, i common facilities care adresează diferite domenii specifice: industrial, financiar, medical, etc.. Application interfaces interfet, e dedicate, caracteristice fiecărei aplicat, ii CORBA; (cel mai probabil) este cea mai put, in standardizată componentă ORB. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 24/ 29  CORBA CORBA – modelul aplicat, iilor Figura 6: Modelul generic al aplicat, iilor CORBA (preluare din ) POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 25/ 29  CORBA CORBA – elemente cheie IDL Acronim: Interface Definition Language Este un limbaj independent de platformă, interpretat, cu sintaxă similară header -elor C/C++ s, i are rol pur descriptiv. Se pot defini module (grupuri/colect, ii de interfet, e), interfet, e, atribute s, i except, ii. Se compilează folosind instrumente specifice tehnologiilor în care sunt dezvoltat, i client, ii s, i servant, ii. OBJECT (SERVANT) Are rolul componentei server. Implementează efectiv logica de calcul remote. Se caracterizează prin identitate, interfat, ă s, i implementare. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 26/ 29  CORBA CORBA – elemente cheie ORB În contextul descris în Figura 6, este mecanismul care realizează efectiv legătura dintre client, i s, i servant, i. Are rolul de a decupla client, ii de servant, i s, i de a media schimbul efectiv de date. (similar RMI) Din perspectiva clientului, interact, iunea cu servantul remote se realizează prin apelul unei metode aparent locale. CORBA IDL stubs and skeletons Reprezintă, în esent, ă, punctele de acces dintre client, i s, i servant, i: client: este prezent stub-ul (cu rol de proxy de conectare); servant: este prezent skeleton-ul (cu rol de gateway de acces). (în mod static) Ambele elemente sunt, în esent, ă, rezultatul compilării descriptorului IDL. POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 27/ 29  Bibliografie recomandată Resurse utile – RMI 1 Mei Nagappan (assoc. prof.), CS 446: Software Design and Architecture (note de curs), Cheriton School of Computer Science, Univ. of Waterloo 2 Furbush J., Distributed systems: A quick and simple definition, 2018 3 IBM Corp., What is distributed computing, 2021 4 IBM Corp., What Are Distributed Applications?, 2022 5 Oracle, Java Tutorials – Trail: RMI, ultima accesare: oct. 2022 POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 28/ 29  Bibliografie recomandată Resurse utile – CORBA 6 ***, corba.org, ultima accesare: oct. 2022 7 Don Busch, Corba and Java, ultima accesare: oct. 2022 8 Oracle Corp., The CORBA Programming Model [tech article], ultima accesare: oct. 2022 9 O’Reilly learning platform, Java Enterprise in a Nutshell (second edition), ultima accesare: oct. 2022 10 Douglas C. Schmidt, Overview of CORBA, Vanderbilt University, ultima accesare: oct. 2022 11 Vidal J., CORBA (talk/lecture notes), University of South Carolina, ultima accesare: oct. 2022 POS | Aplicat,ii Distribuite. Java RMI TI IV 2023 – 2024 29/ 29  Programare Orientată pe Servicii Curs nr. 2: Fundamente. Servicii Web SOAP s, ef lucr. dr. ing. Alexandru Archip Universitatea Tehnică „Gheorghe Asachi” din Ias, i Facultatea de Automatică s, i Calculatoare Tehnologia informat, iei (licent, ă, an IV) – 2023 – 2024 E-mail: [email protected] POS | Fundamente TI IV 2023 – 2024 1/ 57 Pe scurt... 1 Servicii Web Definit, ii, scurt istoric Caracteristici s, i concepte fundamentale Avantaje s, i dezavantaje Modele arhitecturale 2 Servicii Web SOAP/XML Definit, ii Standarde fundamentale Ciclul de viat, ă WSDL SOAP POS | Fundamente TI IV 2023 – 2024 2/ 57  Servicii Web Cuprins 1 Servicii Web Definit, ii, scurt istoric Caracteristici s, i concepte fundamentale Avantaje s, i dezavantaje Modele arhitecturale 2 Servicii Web SOAP/XML Definit, ii Standarde fundamentale Ciclul de viat, ă WSDL SOAP POS | Fundamente TI IV 2023 – 2024 3/ 57  Servicii Web Concepte fundamentale Sisteme slab legate Un sistem (distribuit) se numes, te slab legat dacă orice interact, iune dintre oricare dintre modulele sistemului nu este influent, ată de/nu se bazează pe structura/implementarea respectivelor module. În plus, orice astfel de interact, iune este realizată prin intermediul unor interfet, e bine definite. Consecint, ă Orice schimbare internă în cadrul unui modul nu va afecta interact, iunea cu acel modul. SOA – Service Oriented Architecture SOA este un model de dezvoltare de aplicat, ii care presupune că funct, ionalitatea dorită poate fi obt, inută prin conectarea unor module software slab legate (denumite servicii). Altfel spus, o aplicat, ie dezvoltată utilizând SOA nu reprezintă altceva decât o colect, ie de servicii care implementează funct, ionalitatea dorită. POS | Fundamente TI IV 2023 – 2024 4/ 57  Servicii Web Concepte fundamentale Serviciu (software) Un serviciu (software) reprezintă o unitate de lucru bine definită, independentă s, i completă; serviciile (software) sunt oferite de către un furnizor de servicii pentru a livra prelucrări utile ale datelor pentru client, ii interesat, i (sau consumatori). Serviciu Web Un Serviciu Web este un serviciu software care este disponibil independent de platformă, prin intermediul unui protocol de comunicat, ie standard Web. Un serviciu Web poate fi considerat ca fiind o metodă standardizată de a integra aplicat, ii distibuite care paratajează date, procese s, i sau componente logice. POS | Fundamente TI IV 2023 – 2024 5/ 57  Servicii Web Scurt istoric – încercări similare DCOM DCOM reprezintă o extensie la nivel de ret, ea a COM (Component Object Model), introdusă în 1996. La nivel de implementare, această extensie oferă câteva componente bazate pe HTTP. Cu toate ca respectă specificat, iile DCE-RPC ale Open Software Foundation, extensia a fost inclusă mai mult pentru aplicat, ii Windows. RMI Revedem cursul nr. 1. A fost introdus în 1997, începând cu versiunea JDK 1.1. CORBA – Common Object Request Broker Architecture Revedem cursul nr. 1. POS | Fundamente TI IV 2023 – 2024 6/ 57  Servicii Web Serviciile WEB s, i SOA Thomas Earl, citat de Nowadays, SOA is... an application development model that promotes the use of services and is composed of... services that are mainly developed as... Web Services. Ceva slide-uri în urmă... Definit, ie: SOA reprezintă un model de dezvoltare de aplicat, ii ce se bazează pe module software slab cuplate/legate (denumite servicii) pentru a implementa o anumită funct, ionalitate. Cu alte cuvinte...... serviciile WEB reprezintă mecanismul de implementare al SOA! De ce? (Miss) Popularitate! POS | Fundamente TI IV 2023 – 2024 7/ 57  Servicii Web Definit, ii ale serviciilor Web Definit, ia 1 Sintagma servicii Web referă o colect, ie de standarde ce adresează interoperabilitatea. Aceste standarde definesc suita de protocoale s, i interfet, ele ce vor fi utilizate de oricare două entităt, i ce vor participa într-un schimb de mesaje. Definit, ia 2 Un serviciu Web reprezintă un sistem software construit astfel încât să asigure interoperabilitatea mas, ină-mas, ină în cadrul unei ret, ele de calculatoare. Adam Bosworth (Microsoft, citat de ) The term Web Services refers to an architecture that allows applications to talk to each other. Period. End of statement. Well, they aren’t super-efficient. POS | Fundamente TI IV 2023 – 2024 8/ 57  Servicii Web Caracteristici – SOA SOA se bazează pe servicii suport care sunt auto-descriptive s, i care utilizează în descriere tehnologii s, i limbaje independente de platformă. Standarde curente: WSDL/WADL/OpenAPI (s, i altele). Comunicat, iile dintre servicii s, i client, i se realizează, obligatoriu, prin intermediul standardelor deschise, precum documente XML sau documente JSON. Mesajele astfel vehiculate sunt cunoscute, ca tip s, i reprezentare, tuturor participant, ilor. Serviciile publice pot fi înregistrate în cadrul unor directoare de servicii. Standard (istoric, aparent abandonat): UDDI (Universal Description, Definition and Integration). Fiecare serviciu va oferi, obligatoriu, o componentă de tip QoS (Quality of Service). O astfel de componentă va include module legate de securitate, transfer de mesaje s, i politici generale de acces. POS | Fundamente TI IV 2023 – 2024 9/ 57  Servicii Web Caracteristici – Servicii Web Figura 1: Servicii Web – mecanismul de auto-descriere prin WSDL (exemplificare) POS | Fundamente TI IV 2023 – 2024 10/ 57  Servicii Web Caracteristici – Servicii Web Publicare s, i invocare 1 Un furnizor de servicii poate publica serviciile oferite în cadrul unui director de servicii (sau, eventual, direct „legat” de domeniul gazdă al serviciilor). Furnizorul de servicii va utiliza obligatoriu pentru publicare standarde deschise, independente de platformă (precum WSDL/WADL/OpenAPI, etc.). 2 Un consumator de servicii poate realiza una sau mai multe interogări pentru a descoperi serviciile necesare s, i mecanismele de interact, iune cu acele servicii. 3 Consumatorul de servicii poate solicita/primi documente descriptive complete sau part, iale, după cum acestea au fost publicate de către furnizorul de servicii. 4 Prin intermediul acestor documente, consumatorul de servicii va formula cererile adecvate, corespunzătoare fiecărui serviciu web dorit. 5 Serviciul Web va răspunde obligatoriu client, ilor [autorizat, i] conform specificat, iilor publicate. POS | Fundamente TI IV 2023 – 2024 11/ 57  Servicii Web Servicii Web De ce să folosim Servicii Web? Serviciile Web sunt independente de platformă: se bazează pe XML s, i/sau JSON în descrierea s, i transferul mesajelor; permit ca serviciile să fie dezvoltate în Java, dar client, ii să ruleze C/C++ nativ; independent, a de platformă este asigurată în mod transparent. (ideal ) Sunt auto-descriptive (în condit, iile în care se respectă, bineînt, eles, standardele!!) Mesajele sunt interschimbate prin intermediul unor protocoale de comunicat, ie deschise, bine cunoscute: avantajul este că aceste protocoale sunt, la ora actuală, suportate de [aproape] toate platformele hardware/software. POS | Fundamente TI IV 2023 – 2024 12/ 57  Servicii Web Servicii Web De ce să NU folosim Servicii Web Serviciile Web induc un trafic suplimentar considerabil: reprezentarea XML/JSON a datelor implică, obligatoriu, prezent, a meta-datelor (datele de descriere); portabilitatea este obt, inută în detrimentul performant, ei. Există autori care argumentează lipsa de versatilitate a serviciilor Web: majoritatea serviciilor Web se comportă similar tehnicilor RPC/RMI. (observat, ie derivată în fazele incipiente ale SOA, fără a considera componente RESTful s, i/sau cozi de mesaje) (tratarea incorectă a standardelor poate conduce, în mod uzual, către abordări similare RPC/RMI). Dacă o anumită resursă/o anumită funct, ionalitate nu este necesară a fi publicată/distribuită public, poate că nu ar fi necesară, în mod obligatoriu, utilizarea tehnologiilor deschise. POS | Fundamente TI IV 2023 – 2024 13/ 57  Servicii Web Modele arhitecturale – specificat, ii W3C Figura 2: Modelele arhitecturale ale serviciilor Web (preluare din ) POS | Fundamente TI IV 2023 – 2024 14/ 57  Servicii Web Modele arhitecturale – specificat, ii W3C Figura 3: Modelul orientat pe mesaj (preluare din ) POS | Fundamente TI IV 2023 – 2024 15/ 57  Servicii Web Modele arhitecturale – specificat, ii W3C Figura 4: Modelul orientat pe serviciu (preluare din ) POS | Fundamente TI IV 2023 – 2024 16/ 57  Servicii Web Modele arhitecturale – specificat, ii W3C Figura 5: Modelul orientat pe resursă (preluare din ) POS | Fundamente TI IV 2023 – 2024 17/ 57  Servicii Web Modele arhitecturale – specificat, ii W3C Figura 6: Modelul de politici (preluare din ) POS | Fundamente TI IV 2023 – 2024 18/ 57  Servicii Web Modele arhitecturale t, intă Servicii Web SOAP Un serviciu Web SOAP este un serviciu Web care utilizează în comunicat, ii modele de transfer bazate pe SOAP/XML. În mod uzual, comunicat, iile pot fi în continuare împărt, ite în comunicat, ii RPC s, i comunicat, ii de tip document. Acest tip de serviciu mai este referit ca s, i serviciu Web orientat pe act, iune sau pe operat, ie. Servicii Web RESTful Acronim: REpresentational State Transfer Acest tip de servicii Web sunt bazate pe arhitecturile orientate pe resurse. Implică o schimbare de perspectivă: entităt, ile cu rol de server devin colect, ii de resurse utile care sunt puse la dispozit, ia entităt, ilor cu rol de client care operează cu reprezentările necesare ale acestor resurse a. a Ce este, în esent, ă, un site sau o pagină web? POS | Fundamente TI IV 2023 – 2024 19/ 57  Servicii Web SOAP/XML Cuprins 1 Servicii Web Definit, ii, scurt istoric Caracteristici s, i concepte fundamentale Avantaje s, i dezavantaje Modele arhitecturale 2 Servicii Web SOAP/XML Definit, ii Standarde fundamentale Ciclul de viat, ă WSDL SOAP POS | Fundamente TI IV 2023 – 2024 20/ 57  Servicii Web SOAP/XML Definit, ii ale serviciilor Web Ne aducem aminte Definit, ia 1 Sintagma servicii Web referă o colect, ie de standarde ce adresează interoperabilitatea. Aceste standarde definesc suita de protocoale s, i interfet, ele ce vor fi utilizate de oricare două entităt, i ce vor participa într-un schimb de mesaje. Definit, ia 2 Un serviciu Web reprezintă un sistem software construit astfel încât să asigure interoperabilitatea mas, ină-mas, ină în cadrul unei ret, ele de calculatoare. POS | Fundamente TI IV 2023 – 2024 21/ 57  Servicii Web SOAP/XML Definit, ii ale serviciilor Web SOAP Figura 7: Servicii WEB – arhitectură (preluare din ) POS | Fundamente TI IV 2023 – 2024 22/ 57  Servicii Web SOAP/XML Standarde fundamentale XML Este considerat ca fiind limbajul fundamental al serviciilor Web SOAP. Este utilizat pentru a descrie modele, reprezentarea datelor, tipurile de date, mesajele permise, etc. HTTP Protocolul de transport preferat în cadrul serviciilor Web. (popularitate, remember, right?) POS | Fundamente TI IV 2023 – 2024 23/ 57  Servicii Web SOAP/XML Standarde fundamentale WSDL Limbaj bazat pe XML utilizat în descrierea/definirea serviciilor Web. SOAP Protocol bazat pe HTTP ce fundamentează schimbul de mesaje dintre serviciile Web s, i client, i. POS | Fundamente TI IV 2023 – 2024 24/ 57  Servicii Web SOAP/XML Servicii Web SOAP Figura 8: Ciclul de viat, ă al unui serviciu Web SOAP – abordarea clasică (preluare de la „Using SOAP Extension”) POS | Fundamente TI IV 2023 – 2024 25/ 57  Servicii Web SOAP/XML Servicii Web SOAP – Mecanismul de autodescriere Mecanismul de autodescriere WSDL Limbaj flexibil, bazat pe XML, al cărui scop este de a gestiona schimbul de date în cadrul sistemelor distribuite slab legate, descentralizate. Un document WSDL include în mod uzual următoarele date: interfat, a publică a Figura 9: WSDL v1.1 (stânga) vs. serviciului, tipurile de date v2.0 (dreapta) utilizate în cereri/răspunsuri, protocolul de transport utilizat, date de localizare. POS | Fundamente TI IV 2023 – 2024 26/ 57  Servicii Web SOAP/XML Definit, ie WSDL Documentul WSDL (Web Service Description Language) reprezintă un mecanism de descriere bazat pe XML ce furnizează instrumentele necesare reprezentării componentelor fundamentale ale serviciilor Web. O astfel de descriere trebuie să includă: interfat, a publică a serviciului Web descris; tipurile de date necesare compunerii cererilor/răspunsurilor; protocolul de transport ce va fi utilizat de către serviciul Web; adresa/le URI (s, i/sau setul complet de date de adresare) utilizată/e pentru a accesa serviciul Web. Versiuni majore WSDL 1.1 – martie 2001 – Ariba, IBM, Microsoft WSDL 1.2 – iunie 2003 (redenumit ca WSDL 2.0) WSDL 2.0 – iunie 2003 – recomandare W3C POS | Fundamente TI IV 2023 – 2024 27/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Structura unui document WSDL Elemente auxiliare POS | Fundamente TI IV 2023 – 2024 28/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) elementul root al documentului WSDL specifică numele serviciului Web prin intermediul atributului ”name” specifică spat, iile de nume XML utilizate în cadrul documentului curent (inclusiv spat, iul de nume t, intă!) elementele copil (standard): , , , , fiecare dintre elementele ment, ionate anterior poate avea propriul spat, iu de nume. POS | Fundamente TI IV 2023 – 2024 29/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Prin intermediul acestui element se definesc toate tipurile de date ce vor fi utilizate în cadrul mesajelor de tip cerere/răspuns. Conform standardelor curente, nu se impune o anumită tehnică de definire. Recomandările W3C indică utilizarea documentelor XSD. Acest element poate lipsi dacă mesajele sunt compuse din tipuri fundamentale de date sau dacă nu contravine unor convent, ii de reprezentare a cererilor/răspunsurilor (un exemplu în curând). OBSERVAT, IE Specificat, iile WSDL permit utilizarea de documente XSD externe pentru definirea tipurilor complexe de date. În astfel de cazuri, elementul poate lipsi. POS | Fundamente TI IV 2023 – 2024 30/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Prin intermediul acestui element se vor defini toate mesajele permise în interact, iunile dintre client s, i serviciu. Un serviciu Web va defini, în majoritatea cazurilor, două tipuri de mesaje: mesaje de intrare s, i mesaje de ies, ire. Element copil permis: Fiecare mesaj poate fi compus din zero sau mai multe părt, i. Elementele copil asociază fiecărui paramentru de intrare/ies, ire un tip de dată definit în. Exemplu: POS | Fundamente TI IV 2023 – 2024 31/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Prin intermediul acestui element se definesc complet toate operat, iile expuse de serviciu. Acest lucru implică, în mod uzual, combinarea unuia sau a mai mult elemente de tip. Sunt definite 4 primitive fundamentale de comunicare: One-way: clientul transmite un parametru/set de parametri către serviciu. Acest tip de operat, ie include un singur mesaj de intrare. Request-response: clientul transmite un parametru/set de parametri către serviciu s, i as, teaptă un răspuns din partea serviciului. Mesajele se vor specifica în ordinea intrare/ies, ire. Solicit-response: clientul as, teaptă un răspuns din partea serviciului. Mesajele se vor specifica în ordinea ies, ire/intrare. Notification: serviciul Web transmite un mesaj către client. Operat, ia este marcată doar prin mesaj de ies, ire. POS | Fundamente TI IV 2023 – 2024 32/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Element utilizat în definirea tipului de comunicat, ie ce va fi folosit s, i în definirea modului de reprezentare a mesajelor pentru fiecare element descris în cadrul. Fiecare comunicare dintre client s, i serviciu se va realiza prin intermediul protocoalelor incluse în cadrul acestui element. Aceste protocoale de comunicat, ie trebuie să fie cunoscute de ambele entităt, i participante. Pentru fiecare element se va include, obligatoriu, cel put, in un element corespunzător. OBSERVAT, IE Înainte de versiunea 1.1 a WSDL, elementul permitea numai metodele HTTP GET s, i HTTP POST! Suportul nativ pentru SOAP este oferit începând cu versiunea 1.1. POS | Fundamente TI IV 2023 – 2024 33/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Prin intermediul acestui element se vor defini efectiv interfet, ele de tip port ce vor fi utilizate în comunicat, iile cu serviciul Web. Pentru fiecare protocol de transport ce poate fi utilizat în comunicat, iile cu serviciul Web, elementul va cont, ine exact un element copil: Defines, te endpoint-urile individuale ce vor fi utilizate în comunicat, iile cu serviciul Web. Elementul trebuie să includă două atribute: name – nume unic în cadrul documentului WSDL ce defines, te serviciul Web curent; binding – informat, ie care trebuie să refere, obligatoriu, o entitate validă definită anterior. Elementul trebuie să specifice o singură adresă URL. POS | Fundamente TI IV 2023 – 2024 34/ 57  Servicii Web SOAP/XML Specificat, ii WSDL (1.0/1.1) Prin intermediul acestui element se pot oferi descrieri suplimentare ce pot fi utile diferit, ilor client, i. Datele incluse în cadrul acestui element nu au alt rol decât de a oferi o descriere utilizabilă de către un operator uman. Acest element poate fi copil pentru orice alt element standard. Oferă suport pentru dezvoltarea modulară a documentelor WSDL. Permite practic reutilizarea schemelor XSD sau a documentelor WSDL definite anterior. POS | Fundamente TI IV 2023 – 2024 35/ 57  Servicii Web SOAP/XML Specificat, iile WSDL Figura 10: WSDL 1.1 vs WSDL 2.0 POS | Fundamente TI IV 2023 – 2024 36/ 57  Servicii Web SOAP/XML SOAP – Definit, ii SOAP – Simple Object Access Protocol SOAP este un protocol de comunicat, ie bazat pe XML prin intermediul căruia se specifică mecanismele de reprezentare a datelor utilizate în cadrul unui schimb de mesaje, între una sau mai mult entităt, i în cadrul unui sistem distribuit. Observat, ii SOAP este privit, în prezent, ca aplicat, ie directă a standardelor XML. SOAP a fost dezvoltat, cel put, in la nivel de concept init, ial, ca extensie a HTTP. Scopul acestei extensii era de a oferi mecanisme bazate pe XML pentru comunicat, ii bazate pe HTTP. Avantajul real (s, i, cel mai probabil, singurul avantaj) este acela de a oferi independent, ă de platformă pentru aplicat, iile dezvoltate după modelul de invocare la distant, ă – Remote Procedure Call/Remote Method Invocation. POS | Fundamente TI IV 2023 – 2024 37/ 57  Servicii Web SOAP/XML SOAP – Definit, ii (2) Mesajul SOAP Un mesaj SOAP este un document XML compus din următoarele elemente XML: (element obligatoriu) defines, te începutul/finalul mesajului (elementul root al documentului; (element opt, ional) permite includerea unui set de parametri suplimentari ce pot influent, a procesarea mesajului; (element obligatoriu) cont, ine datele efective de lucru (cererea)/datele procesate (răspunsul); acestea sunt reprezentate sub forma unui document XML, construit conform unei scheme XSD agreată/cunoscută de ambele entităt, i; (element opt, ional) (dacă este cazul) poate include un set de informat, ii legate de eventualele erori ce au survenit în procesare. POS | Fundamente TI IV 2023 – 2024 38/ 57  Servicii Web SOAP/XML SOAP – Definit, ii (3) Observat, ii Spat, iul de nume XML pentru mesajul SOAP: http://www.w3.org/2001/12/soap-envelope Spat, iul de nume destinat reprezentării datelor dintr-un mesaj SOAP: http://www.w3.org/2001/12/soap-encoding POS | Fundamente TI IV 2023 – 2024 39/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP Structura generală a mesajului SOAP.................. POS | Fundamente TI IV 2023 – 2024 40/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (2) Elementul root al documentului XML ce reprezintă mesajul SOAP. Poate include elemente , obligatoriu înaintea elementului. Fiecare document va include exact un singur element. Formatul efectiv al acestui element depinde de versiunea protocolului SOAP utilizată. Rolul acestui element este de a marca începutul/finalul mesajului curent. POS | Fundamente TI IV 2023 – 2024 41/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (3) – exemplu de utilizare POST /relative/url HTTP/1.1 Host: www.domain.com Content-Type: application/soap; charset="utf-8" Content-Length: nnnn... Message information goes here... POS | Fundamente TI IV 2023 – 2024 42/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (4) Este un element opt, ional. Un mesaj SOAP valid poate include mai multe elemente. Dacă acest element este inclus (indiferent de câte ori este inclus), atunci acesta trebuie să preceadă elementul. Elementul are rolul de a oferi un plus de flexibilitate: prin intermediul unui element se pot transmite parametri care să condit, ioneze procesarea unui anumit mesaj. De exemplu, prin intermediul unui header se poate indica dacă elementul trebuie sau nu să includă semnătură digitală. Poate include următoarele atribute: Actor – este utilizat de client pentru a specifica explicit destinatarul final al mesajului curent. MustUnderstand – (atribut boolean) este utilizat pentru a specifica explicit dacă header-ul curent trebuie să fie procesat de destinatarul final al mesajului. POS | Fundamente TI IV 2023 – 2024 43/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (5) Element obligatoriu, ce are rolul de a include datele interschimbate prin intermediul mesajelor SOAP. Datele trebuie obligatoriu reprezentate prin documente XML, identificate de scheme XSD cunoscute de către participant, ii în schimbul de mesaje. În afara standardelor amintite (XML s, i XSD), SOAP nu impune alte restrict, ii cu privire la acest element. POS | Fundamente TI IV 2023 – 2024 44/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (6) – exemplu John POS | Fundamente TI IV 2023 – 2024 45/ 57  Servicii Web SOAP/XML Specificat, ii – mesajul SOAP (7) Este element opt, ional, cu rolul de a include eventuale mesaje de eroare. Informat, iile incluse trebuie să refere erorile în procesare mesajului SOAP. Dacă acest element este inclus, atunci trebuie inclus o singură dată, ca element copil al elementului. Include următoarele elemente copil: – codul specific de eroare: SOAP-ENV:VersionMismatch – spat, iul de nume al este invalid; SOAP-ENV:MustUnderstand – un element include un atribut MustUnderstand setat “true”, dar nu este cunoscut de către destinatarul mesajului; SOAP-ENV:Client – mesajul SOAP nu este bine format; SOAP-ENV:Server – eroare pe partea de server survenită în procesarea mesajului SOAP. – descrierea codului de eroare; – detalii despre entitatea care a cauzat eroarea; – informat, ii suplimentare, altele decât cele incluse în elementele anterioare. POS | Fundamente TI IV 2023 – 2024 46/ 57  Servicii Web SOAP/XML Specificat, ii – Codificarea SOAP Codificarea SOAP (eng. SOAP Encoding) SOAP include un set de reguli predefinite pentru reprezentarea/codificarea diferitelor tipuri de date. Tipurile de dată SOAP pot fi clasificate astfel: tipuri de date scalare tipuri de date utilizate pentru a mapa o singură valoare tipuri de date compuse tipuri de date utilizate pentru a mapa valori multiple. POS | Fundamente TI IV 2023 – 2024 47/ 57  Servicii Web SOAP/XML Specificat, ii – Codificarea SOAP (2) Codificarea SOAP (eng. SOAP Encoding) (2) Tipurile de date compuse pot fi clasificate după cum urmează: tablouri n-dimensionale (n cel put, in 1) – exemplu: un vector de 10 elemente de tip ”double” arrayType="xsd:double" un tablou de caractere de dimensiune 5x5 arrayType="xsd:string[5,5]" structuri de date – pot include tipuri de date diferite, fiecare dintre aceste fiind accesibile prin intermediul unui element unic. POS | Fundamente TI IV 2023 – 2024 48/ 57  Servicii Web SOAP/XML Specificat, ii – Codificarea SOAP (3) Codificarea SOAP – exemplu 3 4 12345 6.789 Of Mans First Disobedience, and the Fruit Of that Forbidden Tree, whose mortal taste Brought Death into the World, and all our woe, http://www.dartmouth.edu/~milton/reading_room/ POS | Fundamente TI IV 2023 – 2024 49/ 57  Servicii Web SOAP/XML Specificat, ii – Codificarea SOAP (4) Codificarea SOAP – exemplu (2) r1c1 r1c2 r1c3 r2c1 r2c2 POS | Fundamente TI IV 2023 – 2024 50/ 57  Servicii Web SOAP/XML Specificat, ii – mecanismele de transport SOAP Mecanismele de transport SOAP (eng. SOAP Transport) SOAP nu restrict, ionează utilizarea protocoalelor de transport! Mesajele SOAP pot fi interschimbate prin intermediul unei game variate de protocoale: SMTP, FTP, IBM’s MQSeries, sau Microsoft Message Queuing (MSMQ). Datorită popularităt, ii, implementările SOAP preferă HTTP pe post de protocol de transport implicit: Cererile SOAP sunt mapate peste cereri HTTP. Răspunsurile SOAP sunt mapate peste răspunsuri HTTP. Metoda HTTP preferată este HTTP POST. (recomandare) Cererile/răspunsurile HTTP includ header-ul Content-Type cu valoare application/xml sau application/xml+soap. Cererea HTTP poate include header-ul SOAPAction. Valoarea acestui header este, în continuare, strict dependentă de versiunea SOAP utilizată. În prezent poate fi migrată/corelată cu valoarea header-ului Content-Type POS | Fundamente TI IV 2023 – 2024 51/ 57  Servicii Web SOAP/XML Exemplu de mesaj SOAP SOAP Request POST /Quotation HTTP/1.0 Host: www.xyz.org Content-Type: text/xml; charset=utf-8 Content-Length: nnn SOAPAction: ”” Company POS | Fundamente TI IV 2023 – 2024 52/ 57  Servicii Web SOAP/XML Exemplu de mesaj SOAP (2) SOAP Response HTTP/1.0 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: nnn Here is the quotation POS | Fundamente TI IV 2023 – 2024 53/ 57  Servicii Web SOAP/XML Servicii Web SOAP SOAP SOAP specifică 2 modele de mesaje : RPC s, i mesaje document. Fiecare dintre aceste 2 modele poate fi reprezentat fie în format encoded, fie în format literal. Avem, deci, 4 modele clasice de reprezentare a mesajelor: RPC/encoded RPC/literal document/encoded (nu este utilizat ) document/literal Observat, ie Exemplele următoare presupun descrierea metodei: void myMethod(int x, float y) (pentru exemplul complet, studiat, i ). POS | Fundamente TI IV 2023 – 2024 54/ 57  Servicii Web SOAP/XML Servicii Web SOAP RPC/encoded RPC/literal 5 5 5.0 5.0 POS | Fundamente TI IV 2023 – 2024 55/ 57  Servicii Web SOAP/XML Servicii Web SOAP Document/literal Document/literal wrapped 5 5.0 5 5.0 POS | Fundamente TI IV 2023 – 2024 56/ 57  Bibliografie recomandată Resurse utile 1 http://www.xml.com/pub/a/ws/2003/09/30/soa.html 2 Service-oriented architecture (SOA) definition 3 Web Services explained 4 [W3C] Web Services Architecture 5 Nicolai M. Josuttis, SOA in Practice – The Art of Distributed System Design, O’REILLY (cap. 16) 6 Web Services Description Language 7 [W3C Note] Simple Object Access Protocol (SOAP) 1.1 8 [Russell Butek] Which style of WSDL should I use? 9 WSDL Essentials 10 http://www.tutorialspoint.com/wsdl/ 11 https://www.w3schools.com/xml/xml_wsdl.asp POS | Fundamente TI IV 2023 – 2024 57/ 57  Programare Orientată pe Servicii Curs nr. 3: Servicii Web RESTful (1) s, ef lucr. dr. ing. Alexandru Archip Universitatea Tehnică „Gheorghe Asachi” din Ias, i Facultatea de Automatică s, i Calculatoare Tehnologia informat, iei (licent, ă, an IV) – 2023 – 2024 E-mail: [email protected] POS | REST (1) TI IV 2023 – 2024 1/ 33 Cuprins 1 Definit, ie s, i concepte generale 2 Fundamente Principiile modelului REST Caracteristici REST peste HTTP Exemplificare: API RESTful pentru o bază de date SQL POS | REST (1) TI IV 2023 – 2024 2/ 33  Definit, ie s, i concepte generale Cuprins 1 Definit, ie s, i concepte generale 2 Fundamente Principiile modelului REST Caracteristici REST peste HTTP Exemplificare: API RESTful pentru o bază de date SQL POS | REST (1) TI IV 2023 – 2024 3/ 33  Definit, ie s, i concepte generale Acronim s, i definit, ie Acronim REpresentational State Transfer Acronimul a fost introdus de Roy Fielding∗ [UNIVERSITY OF CALIFORNIA, IRVINE] pentru a descrie un model arhitectural pentru aplicat, ii ce rulează în cadrul unei ret, ele de calculatoare [1, 2, 3]. Definit, ie REST reprezintă un model arhitectural care ar trebui utilizat/se recomandă a fi utilizat în dezvoltarea serviciilor Web care sunt axate pe resursele unui sistem s, i pe interact, iunile dintre resursele unui astfel de sistem. ∗ Observat, ie Este autorul/printre autorii specificat, iilor RFC care caracterizează protocolul HTTP! POS | REST (1) TI IV 2023 – 2024 4/ 33  Definit, ie s, i concepte generale Acronim s, i definit, ie Roy Fielding despre REST (citat din ) Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a vir- tual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (repre- senting the next state of the application) being transferred to the user and rendered for their use. POS | REST (1) TI IV 2023 – 2024 5/ 33  Definit, ie s, i concepte generale Definit, ie s, i concepte generale Modelul REST presupune că... WEB-ul este o colect, ie de resurse. orice client care accesează o resursă are nevoie de o reprezentare a respectivei resurse. o reprezentare a unei resurse are drept efect tranzit, ia clientului într-o nouă stare. o reprezentare a unei resurse poate include legături cu alte resurse; accesarea unei resurse implică o schimbare de stare sau o tranzit, ie între stări din partea aplicat, iei client. Standarde s, i protocoale fundamentale HTTP URI/URL JSON, XML, etc. POS | REST (1) TI IV 2023 – 2024 6/ 33  Fundamente Cuprins 1 Definit, ie s, i concepte generale 2 Fundamente Principiile modelului REST Caracteristici REST peste HTTP Exemplificare: API RESTful pentru o bază de date SQL POS | REST (1) TI IV 2023 – 2024 7/ 33  Fundamente Servicii WEB RESTful – caracteristici Principii arhitecturale [3, 6] 1 Informat, ia este abstractizată sub forma unei resurse, identificabilă prin intermediul unui mecanism uniform mecanismul principal la nivel WEB: URI/URL 2 Resursele sunt reprezentate prin date s, i metadate date – informat, iile proprii metadate – informat, ii descriptive 3 Toate interact, iunile sunt independente de context implică un comportament fără stare din partea componentei de tip serviciu, nu absent, a completă a stării POS | REST (1) TI IV 2023 – 2024 8/ 33  Fundamente Servicii WEB RESTful – caracteristici Principii arhitecturale [3, 6] 4 Pentru a opera cu o resursă/un set de resurse se utilizează un set fix de operat, ii/primitive aceste primitive au comportament identic, indiferent de resursa t, intă funct, ionalităt, ile acestor primitive trebuie corelate cu semantica resursei ar trebui implementate complet pentru tot setul de resurse expuse de o instant, ă a modelului REST (conform , consider totus, i discutabil) 5 Comportamentul idempotent al primitivelor, corelat cu metadatele asociate resurselor trebuie să ofere suport pentru implementarea tehnicilor de caching metadatele oferă informat, ii care pot caracteriza ciclul de viat, ă al reprezentărilor resurselor comportamentul idempotent al primitivelor facilitează reutilizarea reprezentărilor 6 Prezent, a entităt, ilor intermediare (i.e. sisteme/solut, ii cu rol de proxy ) este puternic recomandată/încurajată POS | REST (1) TI IV 2023 – 2024 9/ 33  Fundamente Servicii WEB RESTful – caracteristici Proprietăt, i ale Serviciilor WEB RESTful Model interact, iune client-server permite utilizarea tehnicilor de caching Tip serviciu fără stare fiecare cerere client trebuie să fie completă s, i trebuie procesată independent. Resurse trebuie să fie accesibile prin intermediul unei colect, ii de interfet, e uniforme. trebuie să fie identificate/identificabile prin intermediul unui nume/ID unic. sunt mapate în mod uzual prin scheme URL/URI. au reprezentări inter-conectate. POS | REST (1) TI IV 2023 – 2024 10/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Maparea standard (simplistă, primară) Modelul REST presupune existent, a unui set minimal standard de operat, ii ce sunt necesare în interact, iunea cu resursele unui sistem; acest set cuprinde exact 4 operat, ii fundamentale – create, read, update, delete: POST actualizarea unei resurse existente sau crearea unei resurse noi GET citirea unei resurse existente PUT crearea unei resurse noi sau înlocuirea uneia existente DELETE s, tergerea unei resurse existente Observat, ie O cerere HTTP este întotdeauna adresată unei resurse t, intă. Sintactic, o astfel de cerere include minim: METODA URL-absolut-tinta | URL-relativ-tinta HTTP/versiune Host: uri-host [:port] [corp cerere] POS | REST (1) TI IV 2023 – 2024 11/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Maparea standard (simplistă, primară) Modelul REST presupune existent, a unui set minimal standard de operat, ii ce sunt necesare în interact, iunea cu resursele unui sistem; acest set cuprinde exact 4 operat, ii fundamentale – create, read, update, delete: POST actualizarea unei resurse existente sau crearea unei resurse noi GET citirea unei resurse existente PUT crearea unei resurse noi sau înlocuirea uneia existente DELETE s, tergerea unei resurse existente Observat, ie Metodele HTTP TREBUIE, în mod OBLIGATORIU, utilizate în conformitate cu descrierea standard a acestora (RFC 9110 HTTP Semantics , versiunea 1.1 a HTTP descrisă în RFC 9112 ). De exemplu, metoda GET va fi utilizată tot timpul pentru a citi o reprezentare a unei resurse, s, i NU pentru a crea/ actualiza/ modifica o resursă existentă! POS | REST (1) TI IV 2023 – 2024 11/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Maparea standard (simplistă, primară) Modelul REST presupune existent, a unui set minimal standard de operat, ii ce sunt necesare în interact, iunea cu resursele unui sistem; acest set cuprinde exact 4 operat, ii fundamentale – create, read, update, delete: POST actualizarea unei resurse existente sau crearea unei resurse noi GET citirea unei resurse existente PUT crearea unei resurse noi sau înlocuirea uneia existente DELETE s, tergerea unei resurse existente Observat, ie Comportamentul metodelor HTTP principale [4, 5]: GET (metodă sigură/idempotentă) PUT (metodă ne-sigură/idempotentă) DELETE (metodă ne-sigură/idempotentă) vor avea efect asupra resursei t, intă; POST (metodă ne-sigură/non-idempotentă) va atas, a corpul cererii ca subordonat al t, intei. POS | REST (1) TI IV 2023 – 2024 11/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Metoda PUT The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation en- closed in the request message content. A successful PUT of a given representation would suggest that a subsequent GET on that same tar- get resource will result in an equivalent representation being sent in a 200 (OK) response. POS | REST (1) TI IV 2023 – 2024 12/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Metoda POST The POST method requests that the target resource process the re- presentation enclosed in the request according to the resource’s own specific semantics. For example, POST is used for the following func- tions (among others): - Providing a block of data, such as the fields entered into an HTML form, to a data-handling process; - Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles; - Creating a new resource that has yet to be identified by the origin server; and - Appending data to a resource’s existing representation(s). POS | REST (1) TI IV 2023 – 2024 13/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Utilizare gres, ită a metodei GET GET /adduser?name=Robert HTTP/1.1 Host: myserver Abordare corectă – utilizarea metodei POST POST /users HTTP/1.1 Host: myserver Content-Type: application/xml Robert POS | REST (1) TI IV 2023 – 2024 14/ 33  Fundamente Servicii WEB RESTful – Maparea metodelor HTTP Utilizare gres, ită a metodei GET (2) GET /updateuser?name=Robert&newname=Bob HTTP/1.1 Host: myserver Abordare corectă – utilizarea metodei PUT PUT /users/Robert HTTP/1.1 Host: myserver Content-Type: application/xml Bob POS | REST (1) TI IV 2023 – 2024 15/ 33  Fundamente Serviciile Web RESTful – fără stare! Modelul RESTful...... întăres, te necesitatea cererilor complete – acest tip de cerere cont, ine toate datele necesare unei procesări complete. Acest lucru implică faptul că, pe durata procesării, NU mai sunt necesare alte date legate de starea aplicat, iei sau alte date legate de aplicat, ie. Altfel spus, o cerere adresată unui serviciu Web RESTful va include complet toate datele necesare furnizorului de servicii pentru a oferi răspunsul angajat în baza contractului publicat. POS | REST (1) TI IV 2023 – 2024 16/ 33  Fundamente Serviciile Web RESTful – fără stare! Cu stare vs. fără stare Figura 1: Apel cu stare – preluare din Figura 2: Apel fără stare – preluare din POS | REST (1) TI IV 2023 – 2024 17/ 33  Fundamente Concepte de bază – servicii RESTful Servicii RESTful – sinteză Serviciile Web RESTful sunt acea clasă particulară de servicii axate pe resurse; clientul interact, ionează cu server-ul pentru a obt, ine reprezentări ale resurselor dorite. Specificat, iile RESTful reprezintă, în esent, ă, o colect, ie de recomandări bazate pe standarde existente. În esent, ă, acest model de dezvoltare poate fi implementat utilizând orice protocol de transport (la nivel de interact, iune client-server); în mod uzual, se preferă protocolul HTTP în baza faptului ca acesta a devenit un protocol sinonim not, iunii de Web. Notă Discut, iile din cadrul acestui curs sunt axate pe API-uri RESTful care furnizează resurse de tip înregistrări stocate într-o bază de date SQL. Modelul general de interact, iune urmărit este prezentat în Figura 3. Conceptele discutate se bazează, în principal, pe specificat, iile protocolului HTTP s, i pe recomandările HATEOAS (Hypermedia as the Engine of Application State). POS | REST (1) TI IV 2023 – 2024 18/ 33  Fundamente Scenariul de interact, iune propus Figura 3: API RESTful pentru DB SQL: componente Notat, ii: Cerere client/Răspuns server modelează intent, ia clientului, exprimată în termeni de tipul obt, ine resursa, actualizează resursa; se vor indica metodele HTTP corespunzătoare act, iunii solicitate de client, header -ele (cerere/răspuns) corespunzătoare s, i eventuale alte elemente particulare; POS | REST (1) TI IV 2023 – 2024 19/ 33  Fundamente Scenariul de interact, iune propus Figura 3: API RESTful pentru DB SQL: componente Notat, ii: REST API reprezintă codul care procesează diferitele cereri client pentru a furniza răspunsurile corespunzătoare; presupunem, pentru moment că acest modul este expus prin intermediul unui server Web Apache s, i conexiunea dintre acest modul s, i cel corespunzător bazei de date ca fiind operat, ională; POS | REST (1) TI IV 2023 – 2024 19/ 33  Fundamente Scenariul de interact, iune propus Figura 3: API RESTful pentru DB SQL: componente Notat, ii: Corespondent, ă comandă DB se va indica relat, ia dintre metoda HTTP recept, ionată din partea client-ului s, i echivalentul acestei comenzi la nivel de instruct, iune SQL; SQL DB server-ul de baze de date utilizat pentru exemplificare; pentru fiecare scenariu în parte se vor indica particularităt, ile tabelelor t, intă. POS | REST (1) TI IV 2023 – 2024 19/ 33  Fundamente Identificarea resurselor t, intă: ierarhie SQL DB Concept o bază de date este o colect, ie de tabele; un tabel reprezintă o colect, ie de înregistrări care respectă acelas, i format/tip de dată Abordare REST baza de date – resursă de tip container (resursă alcătuită din alte sub-resurse) tabelul – resursă de tip container (resursă alcătuită din alte sub-resurse) înregistrarea inclusă în tabel – resursă singulară (resursă pentru care stocăm valorile unui set predefinit de atribute) REST API: corelare resursă adresare URI (conform [8, 9]) URI local /api/identificator_db/identificator_tabel/{id} identificator_db: nume simbolic asociat bazei de date; poate expune o listă a tabelelor stocate în baza de date; POS | REST (1) TI IV 2023 – 2024 20/ 33  Fundamente Identificarea resurselor t, intă: ierarhie SQL DB Concept o bază de date este o colect, ie de tabele; un tabel reprezintă o colect, ie de înregistrări care respectă acelas, i format/tip de dată Abordare REST baza de date – resursă de tip container (resursă alcătuită din alte sub-resurse) tabelul – resursă de tip container (resursă alcătuită din alte sub-resurse) înregistrarea inclusă în tabel – resursă singulară (resursă pentru care stocăm valorile unui set predefinit de atribute) REST API: corelare resursă adresare URI (conform [8, 9]) URI local /api/identificator_db/identificator_tabel/{id} identificator_tabel: nume simbolic asociat unui tabel (în mod uzual, un substantiv la plural ); expune o listă a înregistrărilor stocate în tabel ; parametri de tip query: pot fi mecanismele de filtrare; POS | REST (1) TI IV 2023 – 2024 20/ 33  Fundamente Identificarea resurselor t, intă: ierarhie SQL DB Concept o bază de date este o colect, ie de tabele; un tabel reprezintă o colect, ie de înregistrări care respectă acelas, i format/tip de dată Abordare REST baza de date – resursă de tip container (resursă alcătuită din alte sub-resurse) tabelul – resursă de tip container (resursă alcătuită din alte sub-resurse) înregistrarea inclusă în tabel – resursă singulară (resursă pentru care stocăm valorile unui set predefinit de atribute) REST API: corelare resursă adresare URI (conform [8, 9]) URI local /api/identificator_db/identificator_tabel/{id} {id} identificatorul unic al înregistrării din tabel (Primary Key); expune o singură înregistrare; parametri de query: pot influent, a reprezentarea înregistrării. POS | REST (1) TI IV 2023 – 2024 20/ 33  Fundamente CRUD: Read Cerere client Obt, ine resursa identificată de URI REST API Verb HTTP s, i URI t, intă GET URI/local/resursa restrict, ii t, intă: nu există scop: oferă o reprezentare a resursei indicate o listă a resurselor de tip tabel, dacă t, inta este baza de date o listă a înregistrărilor stocate într-un tabel, dacă t, inta este un tabel o înregistrare inclusă în tabel, dacă t, inta indică un id inclus într-un tabel Corespondent, ă comandă DB Instruct, iunea SQL SELECT (în mod uzual) POS | REST (1) TI IV 2023 – 2024 21/ 33  Fundamente CRUD: Read Răspuns server Răspuns o reprezentare a resursei format: se recomandă JSON/XML/YAML (în general un format deschis) coduri s, i corp răspuns (exemple): COD: 200 OK; CORP: reprezentarea resursei (reprezentarea resursei trebuie să includă s, i relat, iile de navigare) COD: 304 Not Modified; CORP: nu există COD: 404 Not Found; CORP: o reprezentare a erorii de localizare POS | REST (1) TI IV 2023 – 2024 22/ 33  Fundamente CRUD: Delete Cerere client S, terge resursa identificată de URI REST API Verb HTTP s, i URI t, intă DELETE /api/db/tabel/{id} restrict, ii t, intă: nu se recomandă expunerea acestei metode pentru t, inte de tip DB sau tabel (ar implica s, tergerea completă a bazei de date/tabelului) scop: s, terge resursa indicată de URI-ul t, intă Corespondent, ă comandă DB Instruct, iunea SQL DELETE FROM table_name WHERE primary_key_column = {id} (în mod uzual) POS | REST (1) TI IV 2023 – 2024 23/ 33  Fundamente CRUD: Delete Răspuns server Răspuns o reprezentare a realizării act, iunii format: se recomandă JSON/XML/YAML (dacă este cazul) coduri s, i corp răspuns (exemple): COD: 200 OK; CORP: o reprezentare a rezultatului act, iunii sau ultima reprezentare a resursei, înainte de s, tergere (reprezentarea resursei trebuie să includă s, i relat, iile de navigare) COD: 202 Accepted; CORP: o reprezentare a rezultatului act, iunii (exemplu: cererea de s, tergere a fost acceptată) !!! la nivel de cod server, trebuie invalidat accesul pe resursă !!! COD: 204 No Content; CORP: nu există POS | REST (1) TI IV 2023 – 2024 24/ 33  Fundamente CRUD: Create Scenariu 1: clientul controlează identificatorul resursei (considerăm cazul în care resursa t, intă este o înregistrare într-un tabel) (identificatorul resursei: parametrul de cale {id}) Cerere client Adaugă o înregistrare nouă în tabel REST API Verb HTTP s, i URI t, intă PUT /api/db/tabel/{id} restrict, ii t, intă: nu se recomandă expunerea acestei metode peste baza de date sau peste tabele (ar implica re-crearea acestor resurse de tip container) scop: crearea unei noi înregistrări, identificată de URI-ul t, intă, în tabelul indicat Corespondent, ă comandă DB Instruct, iunea SQL INSERT INTO table(PK_column,...) VALUES (id,...) POS | REST (1) TI IV 2023 – 2024 25/ 33  Fundamente CRUD: Create Scenariu 1: clientul controlează identificatorul resursei (considerăm cazul în care resursa t, intă este o înregistrare într-un tabel) (identificatorul resursei: parametrul de cale {id}) Răspuns server Răspuns o reprezentare a resursei nou create format: se recomandă JSON/XML/YAML recomandări: reprezentarea răspunsului cuprinde cel put, in două informat, ii de tip legătură o adresă URI de tip self : se include calea absolută până la resursa nou creată (poate fi Header -ul HTTP Location:) o adresă URI de tip parent: include calea absolută a resursei părinte coduri s, i corp răspuns: COD: 201 Created; CORP: o reprezentare a resursei nou create COD: 406 Not Acceptable sau 409 Conflict; CORP: o reprezentare a eventualelor erori POS | REST (1) TI IV 2023 – 2024 26/ 33  Fundamente CRUD: Create Scenariu 2: server-ul SQL controlează identificatorul resursei (considerăm cazul în care resursa t, intă este o înregistrare într-un tabel) (de exemplu: PK_column de tip auto-increment) Cerere client Adaugă o înregistrare nouă în tabel REST API Verb HTTP s, i URI t, intă POST /api/db/tabel restrict, ii t, intă: nu se recomandă expunerea acestei metode peste baza de date (ar implica crearea unor resurse subordonate de tip container) scop: crearea unei noi înregistrări în tabelul indicat Corespondent, ă comandă DB Instruct, iunea SQL INSERT INTO table(lista coloane) VALUES (lista valori) POS | REST (1) TI IV 2023 – 2024 27/ 33  Fundamente CRUD: Create Scenariu 2: server-ul SQL controlează identificatorul resursei (considerăm cazul în care resursa t, intă este o înregistrare într-un tabel) (de exemplu: PK_column de tip auto-increment) Răspuns server Răspuns o reprezentare a resursei nou create format: se recomandă JSON/XML/YAML recomandări: reprezentarea răspunsului cuprinde cel put, in două informat, ii de tip legătură o adresă URI de tip self : se include calea absolută până la resursa nou creată (poate fi Header -ul HTTP Location:) o adresă URI de tip parent: include calea absolută a resursei părinte coduri s, i corp răspuns: COD: 201 Created; CORP: o reprezentare a resursei nou create COD: 406 Not Acceptable; CORP: o reprezentare a eventualelor erori POS | REST (1) TI IV 2023 – 2024 28/ 33  Fundamente CRUD: Update (înlocuire completă) Cerere client Înlocuies, te înregistrarea identificată de id REST API Verb HTTP s, i URI t, intă PUT /api/db/tabel/{id} restrict, ii t, intă: nu se recomandă expunerea acestei metode peste baza de date sau peste tabele (ar implica re-crearea acestor resurse de tip container) scop: actualizarea înregistrării identificate de URI-ul t, intă în tabelul indicat Corespondent, ă comandă DB Instruct, iunea SQL UPDATE tabel SET column1=val1,..., columnk=valk WHERE PK_column={id} (lista completă de coloane ale tabelului) POS | REST (1) TI IV 2023 – 2024 29/ 33  Fundamente CRUD: Update (înlocuire completă) Răspuns server Răspuns un indicator al realizării operat, iei cu succes format: se recomandă JSON/XML/YAML (dacă este cazul) recomandări: reprezentarea răspunsului cuprinde cel put, in informat, ia de identificare a înregistrării actualizate o adresă URI de tip self : se include calea absolută până la resursa nou creată (poate fi Header -ul HTTP Location:) coduri s, i corp răspuns: COD: 204 No Content; CORP: nu există COD: 409 Conflict; CORP: o reprezentare a eventualelor erori POS | REST (1) TI IV 2023 – 2024 30/ 33  Fundamente Considerente asupra tabelelor înlănt, uite Figura 4: Model generic pentru tabele înlănt, uite (presupunem PK_T1 s, i PK_T2 de tip AI ) REST API: adresele URI pot identifica rute/căi de navigare Metodă s, i URI (exemplu) GET /api/db/tabel1/{id1}/tabel2 rezultat resursa identificată de {id1}, pentru care se concatenează toate înregistrările pentru care FK _T 1 = {id1} în JoinT1T2 POS | REST (1) TI IV 2023 – 2024 31/ 33  Fundamente Considerente asupra tabelelor înlănt, uite Figura 4: Model generic pentru tabele înlănt, uite (presupunem PK_T1 s, i PK_T2 de tip AI ) REST API: adresele URI pot identifica rute/căi de navigare Metodă s, i URI (exemplu) GET /api/db/tabel1/{id1}/tabel2/{id2} rezultat resursa identificată de {id1}, pentru care se concatenează înregistrarea identificată de FK _T 2 = {id2} POS | REST (1) TI IV 2023 – 2024 31/ 33  Fundamente Considerente asupra tabelelor înlănt, uite Figura 4: Model generic pentru tabele înlănt, uite (presupunem PK_T1 s, i PK_T2 de tip AI ) REST API: adresele URI pot identifica rute/căi de navigare Metodă s, i URI (exemplu) POST /api/db/tabel1/{id1}/tabel2 corp cerere resursele care trebuie create în tabel2 s, i care trebuie „legate” de {id1} pas, i se crează, rând pe rând, fiecare înregistrare în tabel2, se obt, in identificatorii corespunzători s, i se actualizează JoinT 1T 2 Observat, ie înregistrarea identificată de {id1} trebuie să existe anterior cererii curente! POS | REST (1) TI IV 2023 – 2024 31/ 33  Bibliografie recomandată Resurse utile 1 Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, PhD Thesis 2 Roy Thomas Fielding, Architectural Styles and the Design of Network-based Software Architectures, PhD Thesis, Chapter 5 3 R.T. Fielding et. al., Reflections on the REST Architectural Style and ”Principled Design of the Modern Web Architecture” (Impact Paper Award), Proc. of the 2017 11th Joint Meeting on Foundations of Software Engineering, ACM 4 R. Fielding, M. Nottingham, J. Reschke. RFC 9110: HTTP Semantics (Iun. 2022) 5 R. Fielding, M. Nottingham, J. Reschke. RFC 9112: HTTP/1.1 (Iun. 2022) 6 A. Archip, C.M. Amarandei, P.C. Herghelegiu, C. Mironeanu and E. S, erban, RESTful Web Services – A Question of Standards, Proc. of ICSTCC 2018 7 [IBM] Introduction to RESTful Web services (Last update: 8 feb. 2015)1 1 cu mari rezerve la nivel de adoptare a standardelor! POS | REST (1) TI IV 2023 – 2024 32/ 33  Bibliografie recomandată Resurse utile 8 T. Berners-Lee, R. Fielding, L. Masinter. RFC 3986: Uniform Resource Identifier (URI): Generic Syntax (Ian. 2005) 9 M. Nottingham. RFC 8820: URI Design and Ownership (Iun. 2020) 10 L. Dusseault, J. Snell. RFC 5789: PATCH Method for HTTP (Mar. 2010) 11 Lokesh Gupta, HATEOAS Driven REST APIs (Last update: 10 Oct. 2021) POS | REST (1) TI IV 2023 – 2024 33/ 33  Programare Orientată pe Servicii Curs nr. 4: Servicii Web R