Į paslaugą orientuota architektūra (SOA) atsirado šio amžiaus pradžioje kaip paskirstytojo skaičiavimo evoliucija. Prieš SOA, paslaugos buvo suprantami kaip galutinis programos kūrimo proceso rezultatas. SOA, pati programa susideda iš paslaugų. Paslaugos gali būti teikiamos atskirai arba sujungiamos kaip sudėtinės didesnės, sudėtinės paslaugos sudėtinės dalys.
Tarnybos sąveikauja per laidą naudodamos tokį protokolą kaip REST arba SOAP (paprastas prieigos prie objektų protokolas). Paslaugos yra silpnai sujungta, tai reiškia, kad paslaugų sąsaja yra nepriklausoma nuo pagrindinio įgyvendinimo. Kūrėjai ar sistemų integratoriai gali sukomponuoti vieną ar daugiau paslaugų į programą, nebūtinai žinodami, kaip kiekviena paslauga yra įgyvendinama.
Šis straipsnis yra „Java SOA“ apžvalga ir pagrindinės į paslaugas orientuotos architektūros, įdiegtos naudojant SOAP pagrįstas žiniatinklio paslaugas, charakteristikos. Taip pat trumpai palyginsiu SOA ir mikroservisus bei aptarsiu skirtumą tarp „Java“ RESTful ir SOAP pagrįstų interneto paslaugų.
SOA ir interneto paslaugos
SOA ir žiniatinklio paslaugos dažnai maišomos, tačiau tai nėra tas pats dalykas. SOA yra architektūra, leidžianti kūrėjams sujungti kelias programų paslaugas į didesnę sudėtinę paslaugą. SOA gali būti įdiegta naudojant SOAP pagrįstas žiniatinklio paslaugas ar REST API arba kartais abiejų derinį. Svarbu suprasti, kad SOA, a paslaugą yra bet kuris nuotoliniu būdu prieinamas šaltinis, galintis atsakyti į užklausas. A interneto paslauga yra įgyvendinamas naudojant specialius protokolus.
Kodėl į paslaugas orientuota architektūra?
SOA sprendžia tris bendrus įmonės iššūkius:
- Greitai reaguokite į verslo pokyčius.
- Pasinaudokite esamomis infrastruktūros investicijomis.
- Palaikykite naujus sąveikos su klientais, partneriais ir tiekėjais kanalus.
Įmonių infrastruktūra nevienalytė visose operacinėse sistemose, programose, sistemos programinėje įrangoje ir programų infrastruktūroje. Todėl daugelį įmonės sistemų sudaro sudėtingos ir nenuoseklios programos, teikiančios įvairias tarpusavyje susijusias paslaugas. Esamos programos, kuriose vykdomi dabartiniai verslo procesai, yra labai svarbios, todėl pradėti nuo nulio ar jas modifikuoti yra subtilus pasiūlymas. Tačiau įmonės turi sugebėti modifikuoti ir išplėsti techninę infrastruktūrą, kad atitiktų verslo poreikius.
SOA ir mikro paslaugos
„Microservices“ yra architektūrinis stilius, išsivystęs iš SOA. Abi yra paskirstytos architektūros ir abi siūlo atsietą paradigmą. Nors į paslaugas orientuota architektūra yra sunkesnė infrastruktūros srityje, mikro paslaugos teikia lankstesnį, lengvą plėtros stilių. Abiem yra pliusų ir minusų, ir abu yra plačiai naudojami. Paprastai kalbant, SOA dažniau diegia ar prižiūri įsteigtos įmonės, turinčios išteklių palaikyti daugiau formalumų. Mikroservisai dažnai kreipiasi į naujas ar augančias organizacijas, reikalaujančias judrumo.
Palyginti su monolitine architektūra, dėl laisvai susietos SOA prigimties tampa gana sklandu prijungti naujas paslaugas arba atnaujinti esamas paslaugas atsižvelgiant į naujus verslo reikalavimus. Tai taip pat suteikia galimybę paversti paslaugas skirtingais kanalais ir atskleisti senas programas kaip paslaugas, taip apsaugant investicijas į infrastruktūrą.
Kadangi jie laisvai sujungiami, SOA komponentai gali būti pakeisti kuo mažiau paveikiant kitus komponentus. Komponentus taip pat galima pridėti prie architektūros standartizuotai ir juos galima keisti atsižvelgiant į apkrovą.
Pavyzdžiui, apsvarstykite, kaip įmonė gali naudoti esamų programų rinkinį kurdama naują sudėtinę tiekimo grandinės programą. Nors esamos programos yra nevienalytės ir paskirstytos įvairiose sistemose, jų funkcionalumas atskleidžiamas ir pasiekiamas naudojant standartines sąsajas.
Matthew Tysonas Pagrindinės SOA charakteristikos
SOA gali būti tokia paprasta, kaip vienas komponentas, vartojantis kito komponento teikiamas paslaugas, arba toks pat sudėtingas, kaip komponentų, sąveikaujančių per įmonės paslaugų magistralę, pvz., „MuleSoft“ ESB, spektras. Nesvarbu, kokia skalė, raktas į sėkmingą SOA diegimą yra kuo mažesnis sudėtingumas, kad pasiektumėte savo tikslus. Pirmasis ir paskutinis klausimas visada turėtų būti: Ar šis dizainas atitinka mūsų verslo reikalavimus?
Nepaisant masto ar sudėtingumo, į paslaugas orientuotos architektūros modelis yra daugmaž toks pats:
- Paslaugų teikėjai pateikia galinius taškus ir apibūdina galimus veiksmus kiekviename taške.
- Paslaugų vartotojai pateikia prašymus ir vartoja atsakymus.
- Paslaugų teikėjai generuoja pranešimus, kad tvarkytų užklausas.
Į paslaugą orientuotos architektūros diegimas
Norėdami įdiegti SOA, pradėkite nuo pagrindinės paslaugos architektūros, tada pateikite infrastruktūrą, ty protokolus ir kitus įrankius, kurie įgalina ryšį ir sąveiką. 2 paveiksle parodyta tipinės paslaugos architektūros schema.
Matthew Tysonas Šioje diagramoje trys vartotojai naudojasi paslaugomis siųsdami pranešimus įmonės paslaugų magistralei, kuri pranešimus transformuoja ir nukreipia į tinkamą paslaugų įgyvendinimą. A verslo taisyklių variklis įtraukia verslo taisykles į paslaugą arba į visas paslaugas. A paslaugų valdymo sluoksnis valdo tokias veiklas kaip auditas, sąskaitų išrašymas ir registravimas.
Šios architektūros komponentai yra laisvai susieti, todėl juos galima išjungti arba atnaujinti, turint palyginti nedidelį poveikį visai programai. Tai suteikia įmonei lankstumo pridėti ar atnaujinti verslo procesus, jei reikia. Dažniausiai atskirų paslaugų pakeitimai neturėtų labai paveikti kitų paslaugų.
SOAP vs RESTful interneto paslaugos
Galima pritaikyti SOA stilių ir įdiegti jį naudojant REST, pvz., Naudojant JAX-RS API arba „Spring Boot Actuator“, tačiau šiai diskusijai šis straipsnis netaikomas. Žr. „SOAP vs REST vs JSON“, kad būtų naudingas SOAP ir RESTful žiniatinklio paslaugų palyginimas. Taip pat yra tam tikrų sutapimų tarp „RESTful“ žiniatinklio paslaugų ir lengvesnio stiliaus, susijusio su mikro paslaugomis.
SOAP pagrįstos žiniatinklio paslaugos
Žiniatinklio paslaugos, įdiegtos naudojant SOAP, vis dar yra griežtesnės nei „RESTful“ žiniatinklio paslaugų ar mikropaslaugų diegimas, tačiau kur kas lankstesnės nei ankstyvosios SOA dienos. Čia mes tiesiog pažvelgsime į aukšto lygio protokolus, reikalingus SOAP pagrįstoms žiniatinklio paslaugoms.
Muilas, WSDL ir XSD
SOAP, WSDL ir XSD yra pagrindinė SOAP pagrįstos žiniatinklio paslaugos diegimo infrastruktūra. WSDL naudojamas paslaugai apibūdinti, o SOAP yra transporto sluoksnis, skirtas siųsti pranešimus tarp paslaugų vartotojų ir teikėjų. Tarnybos bendrauja su pranešimais, formaliai apibrėžtais naudojant XML schemą (XSD). Galite galvoti apie WSDL kaip paslaugos sąsają (beveik analogišką „Java“ sąsajai). Diegimas atliekamas „Java“ klasėse, o ryšys tinkle vyksta per SOAP. Funkciškai vartotojas ieškotų paslaugos, gautų tos paslaugos WSDL, tada pasinaudotų paslauga naudodamas SOAP.
Žiniatinklio paslaugų sauga
WS-I Basic Profile 2.0 specifikacija skirta pranešimų saugumui. Ši specifikacija orientuota į keitimąsi duomenimis, pranešimų vientisumą ir pranešimų konfidencialumą.
Interneto paslaugų atradimas
Kai žiniatinklio paslaugų atradimo kertinis akmuo, UDDI (universalus aprašymas, apibrėžimas ir integracija) išnyko istorijoje. Šiandien įprasta SOAP pagrindu veikiančią žiniatinklio paslaugą atskleisti taip, kaip tai darytumėte bet kurią kitą paslaugą, naudodama galutinį URL. Kaip pavyzdį galite naudoti JAX-WS tarnybos pabaigos taško sąsają ir ją @WebService ir @WebMethod anotacijos.
Interneto paslaugų kūrimas ir diegimas
„Java“ kūrėjai turi keletą galimybių kurti ir diegti SOAP pagrįstas žiniatinklio paslaugas, įskaitant „Apache Axis2“ ir „Spring-WS“; tačiau „Java“ standartas yra JAX-WS, „Java“ API, skirta „XML Web Services“. Pagrindinė JAX-WS idėja yra sukurti „Java“ klases ir jas komentuoti, kad būtų sukurti reikalingi artefaktai. Po gaubtu JAX-WS naudoja keletą „Java“ paketų, įskaitant JAXB, bendrosios paskirties biblioteką, kad susietų „Java“ klases su XML.
JAX-WS slepia pagrindinį sudėtingumą ir protokolus nuo kūrėjo, tokiu būdu supaprastindamas Java pagrįstų SOAP paslaugų apibrėžimo ir diegimo procesą. Šiuolaikiniai „Java IDE“, pvz., „Eclipse“, apima visišką JAX-WS žiniatinklio paslaugų kūrimo palaikymą. Taip pat buvo pasirinkta JAX-WS specifikacija, skirta nuolat tobulinti Džakarta EE.
Išvada
Į paslaugas orientuota architektūra, įdiegta naudojant SOAP pagrįstas žiniatinklio paslaugas, reikalauja griežtesnių ir oficialesnių paslaugų apibrėžimų nei RESTful žiniatinklio paslaugos ar mikro paslaugos. Tačiau kai kurios didesnės organizacijos ir toliau palaiko oficialesnį stilių, kurį taiko SOAP. Daugelis didelio masto senų sistemų taip pat yra pagrįstos SOAP, o kai kurios B2B ir vidinės sistemos savo oficialiau apibrėžtoms API sutartims pasirenka SOAP pagrįstas žiniatinklio paslaugas. Nesvarbu, ar kuriate, ar palaikote didelio masto įmonės sistemą, suprantate SOA modelį ir sugebate įvertinti savo diegimo galimybes, jums bus naudinga jūsų programavimo karjeroje.
Ši istorija „Kas yra į paslaugas orientuota architektūra?“ iš pradžių buvo išleista „JavaWorld“.
