Arhitectura orientată spre servicii (SOA) a apărut la începutul acestui secol ca o evoluție a calculelor distribuite. Înainte de SOA, serviciile erau înțelese ca rezultatul final al procesului de dezvoltare a aplicațiilor. În SOA, aplicația în sine este compusă din servicii. Serviciile pot fi livrate individual sau combinate ca componente într-un serviciu compozit mai mare.
Serviciile interacționează prin cablu utilizând un protocol precum REST sau SOAP (Simple Object Access Protocol). Serviciile sunt cuplate slab, ceea ce înseamnă că interfața de serviciu este independentă de implementarea de bază. Dezvoltatorii sau integratorii de sistem pot compune unul sau mai multe servicii într-o aplicație fără să știe neapărat cum este implementat fiecare serviciu.
Acest articol este o prezentare generală a Java SOA și caracteristicile cheie ale unui arhitectură orientată spre servicii implementată utilizând servicii web bazate pe SOAP. De asemenea, voi compara pe scurt SOA și microservicii și voi discuta diferența dintre serviciile web RESTful și cele bazate pe SOAP în Java.
De ce arhitectura orientată spre servicii?
SOA abordează trei provocări comune ale întreprinderii :
- Răspundeți rapid la schimbările de afaceri.
- Profitați de investițiile existente în infrastructură.
- Sprijiniți noi canale de interacțiune cu clienții, partenerii și furnizorii.
Infrastructura întreprinderii este eterogenă între sistemele de operare, aplicații, software de sistem și infrastructura aplicațiilor. Ca urmare, multe sisteme de întreprindere sunt compuse din aplicații complexe și inconsistente care furnizează un gama de servicii interdependente. Aplicațiile existente care rulează procesele comerciale actuale sunt esențiale, așa că pornirea de la zero sau modificarea acestora este o propunere delicată. Dar întreprinderile trebuie să poată modifica și extinde infrastructura tehnică pentru a satisface cerințele afacerii.
comparativ cu un archi monolitic Tectura, natura slab asociată a SOA face relativ simplă conectarea la noi servicii sau actualizarea serviciilor existente pentru noi cerințe de afaceri. De asemenea, oferă opțiunea de a face consumabile serviciile pe diferite canale și de a expune aplicațiile vechi ca servicii, protejând astfel investițiile în infrastructură.
Deoarece sunt cuplate slab, componentele SOA pot fi schimbate cu impact minim asupra altor componente . Componentele pot fi, de asemenea, adăugate la arhitectură într-un mod standardizat și pot fi scalate pentru a aborda încărcarea.
De exemplu, luați în considerare modul în care o întreprindere ar putea utiliza un set de aplicații existente pentru a crea o nouă, aplicație pentru lanțul de aprovizionare compozit. În timp ce aplicațiile existente sunt eterogene și distribuite pe diferite sisteme, funcționalitatea lor este expusă și accesată utilizând interfețe standard.
Figura 1. Aplicația lanțului de aprovizionare într-o arhitectură orientată spre servicii
Caracteristicile cheie ale SOA
SOA poate fi la fel de simplu ca o singură componentă care consumă servicii furnizate de o altă componentă sau la fel de sofisticat ca o gamă de componente care interacționează printr-o magistrală de servicii de întreprindere, cum ar fi ESB-ul MuleSoft. Indiferent de scară, cheia unei implementări SOA de succes este să folosiți cât mai puțină complexitate posibil pentru a vă atinge obiectivele. Prima și ultima întrebare ar trebui să fie întotdeauna: Acest design satisface cerințele noastre de afaceri?
Indiferent de scară sau complexitate, modelul unei arhitecturi orientate spre servicii este mai mult sau mai puțin același:
- Furnizorii de servicii expun punctele finale și descriu acțiuni disponibile la fiecare punct final.
- Consumatorii de servicii emit cereri și consumă răspunsuri.
- Furnizorii de servicii generează mesaje pentru a gestiona solicitările.
Implementarea serviciului- arhitectură orientată
Pentru a implementa SOA începeți cu arhitectura de bază a serviciului, apoi furnizați infrastructura, adică protocoale și alte instrumente care permit comunicarea și interoperabilitatea. Figura 2 prezintă o diagramă a unei arhitecturi tipice de serviciu.
Figura 2. Un exemplu de arhitectură de servicii
În această diagramă, trei consumatori invocă servicii prin trimiterea de mesaje către o magistrală de servicii pentru întreprinderi, care transformă și direcționează mesajele către o implementare adecvată a serviciului . Un motor de reguli de afaceri încorporează reguli de afaceri într-un serviciu sau între servicii. Un strat de gestionare a serviciilor gestionează activități precum auditul, facturarea și înregistrarea în jurnal.
Componentele acestei arhitecturi sunt cuplate slab, deci pot fi schimbate sau actualizate cu un impact relativ minim asupra aplicației în ansamblu. Acest lucru oferă întreprinderii flexibilitate pentru a adăuga sau actualiza procesele de afaceri după cum este necesar. În cea mai mare parte, modificările aduse serviciilor individuale nu ar trebui să afecteze foarte mult alte servicii.
Serviciile web bazate pe SOAP
Serviciile web implementate utilizând SOAP sunt încă mai rigide decât o implementare RESTful de servicii web sau microservicii, dar mult mai flexibile decât în primele zile ale SOA. Aici vom analiza protocoalele la nivel înalt necesare pentru serviciile web bazate pe SOAP.
SOAP, WSDL și XSD
SOAP, WSDL și XSD sunt infrastructura fundamentală a unei implementări de servicii web bazate pe SOAP. WSDL este folosit pentru a descrie serviciul, iar SOAP este stratul de transport pentru trimiterea mesajelor între consumatori și furnizori de servicii. Serviciile comunică cu mesaje definite în mod oficial folosind XML Schema (XSD). Vă puteți gândi la WSDL ca interfață a serviciului (puțin analogă cu o interfață Java). Implementarea se face în clase Java, iar comunicarea prin rețea are loc prin SOAP. Funcțional, un consumator ar căuta un serviciu, ar primi WSDL pentru acel serviciu, apoi ar invoca serviciul utilizând SOAP.
Securitatea serviciului web
WS -Specificarea I Basic Profile 2.0 abordează securitatea mesajelor Această specificație se concentrează pe schimbul de acreditări, integritatea mesajelor și confidențialitatea mesajelor.
Descoperirea serviciului web
Odată ce piatra de temelie a descoperirii serviciului web, UDDI (Descriere universală, definiție și integrare) a dispărut în istorie. Astăzi este obișnuit să expunem un serviciu web bazat pe SOAP așa cum ați face orice alt serviciu, printr-o adresă URL finală. De exemplu, puteți utiliza interfața JAX-WS Service Endpoint Interface și @WebService și @WebMethod adnotări.
Construirea și implementarea serviciilor web
Dezvoltatorii Java au mai multe opțiuni pentru construirea și implementarea bazată pe SOAP servicii web, inclusiv Apache Axis2 și Spring-WS; totuși, standardul Java este JAX-WS, API-ul Java pentru serviciile web XML. Ideea de bază din spatele JAX-WS este de a crea clase Java și de a le adnota pentru a crea artefactele necesare. Sub capotă, JAX-WS folosește mai multe pachete Java, inclusiv JAXB, o bibliotecă de uz general pentru legarea claselor Java la XML.
JAX-WS ascunde complexitatea și protocoalele care stau la baza dezvoltatorului, astfel simplificând procesul de definire și implementare a serviciilor SOAP bazate pe Java. IDE-urile Java moderne precum Eclipse includ suport complet pentru dezvoltarea serviciilor web JAX-WS. Specificația WS a fost, de asemenea, selectată pentru dezvoltarea continuă în Jakarta EE.
Concluzie
Arhitectura orientată spre servicii implementată cu servicii web bazate pe SOAP necesită mai rigid și mai definiții de servicii formale decât serviciile web RESTful sau microserviciile. Cu toate acestea, unele organizații mai mari continuă să favorizeze stilul mai formal impus de SOAP. Multe sisteme vechi pe scară largă sunt, de asemenea, construite pe SOAP, iar unele sisteme B2B și interne aleg servicii web bazate pe SOAP pentru contractele lor API mai definite formal. Indiferent dacă dezvoltați sau mențineți un sistem de întreprindere la scară largă, înțelegerea modelului SOA și posibilitatea de a vă evalua opțiunile de implementare vă va servi bine în cariera dvs. de programare.