Uz pakalpojumu orientēta arhitektūra (SOA) parādījās šī gadsimta sākumā kā izplatītās skaitļošanas evolūcija. Pirms SOA, pakalpojumus tika saprasti kā lietojumprogrammas izstrādes procesa gala rezultāts. SOA lietojumprogramma sastāv no pakalpojumiem. Pakalpojumus var piegādāt atsevišķi vai apvienot kā komponentus lielākā, saliktā pakalpojumā.
Pakalpojumi mijiedarbojas pa vadu, izmantojot tādu protokolu kā REST vai SOAP (vienkāršs objekta piekļuves protokols). Pakalpojumi ir brīvi sapārotas, kas nozīmē, ka pakalpojumu saskarne ir neatkarīga no pamatā esošās ieviešanas. Izstrādātāji vai sistēmu integratori var apkopot vienu vai vairākus pakalpojumus lietojumprogrammā, nezinot, kā katrs pakalpojums tiek ieviests.
Šajā rakstā ir sniegts pārskats par Java SOA un uz pakalpojumiem orientētas arhitektūras galvenajiem raksturlielumiem, kas ieviesti, izmantojot uz SOAP balstītus tīmekļa pakalpojumus. Es arī īsi salīdzināšu SOA un mikropakalpojumus un apspriedīšu atšķirību starp RESTful un SOAP balstītajiem tīmekļa pakalpojumiem Java.
SOA un tīmekļa pakalpojumi
SOA un tīmekļa pakalpojumi bieži tiek sajaukti, taču tie nav viens un tas pats. SOA ir arhitektūra, kas ļauj izstrādātājiem apvienot vairākus lietojumprogrammu pakalpojumus lielākā, saliktajā pakalpojumā. SOA var ieviest, izmantojot uz SOAP balstītus tīmekļa pakalpojumus vai REST API, vai dažreiz to abu kombināciju. Ir svarīgi saprast, ka SOA a apkalpošana ir jebkurš attālināti pieejams resurss, kas var atbildēt uz pieprasījumiem. A tīmekļa pakalpojums tiek realizēts, izmantojot īpašus protokolus.
Kāpēc uz pakalpojumu orientēta arhitektūra?
SOA risina trīs kopīgas uzņēmuma problēmas:
- Ātri reaģējiet uz uzņēmējdarbības izmaiņām.
- Izmantojiet esošos ieguldījumus infrastruktūrā.
- Atbalstiet jaunus mijiedarbības kanālus ar klientiem, partneriem un piegādātājiem.
Uzņēmumu infrastruktūra ir neviendabīga visās operētājsistēmās, lietojumprogrammās, sistēmas programmatūrā un lietojumprogrammu infrastruktūrā. Tā rezultātā daudzas uzņēmuma sistēmas sastāv no sarežģītām un nekonsekventām lietojumprogrammām, kas nodrošina virkni savstarpēji atkarīgu pakalpojumu. Esošās lietojumprogrammas, kurās darbojas pašreizējie biznesa procesi, ir kritiskas, tāpēc sākt no nulles vai mainīt tās ir delikāts priekšlikums. Bet uzņēmumiem jāspēj pārveidot un paplašināt tehnisko infrastruktūru, lai tie atbilstu biznesa prasībām.
SOA un mikropakalpojumi
Microservices ir arhitektūras stils, kas izstrādāts no SOA. Abas ir sadalītas arhitektūras un abas piedāvā atsaistītu paradigmu. Kaut arī uz pakalpojumiem orientēta arhitektūra infrastruktūrai ir smagāka, mikropakalpojumi piedāvā elastīgāku, vieglu attīstības stilu. Abiem ir plusi un mīnusi, un abi tiek plaši izmantoti. Parasti SOA biežāk ievieš vai uztur izveidoti uzņēmumi, kuriem ir resursi, lai atbalstītu lielāku formalitāti. Mikroservisi bieži piesaista jaunas vai augošas organizācijas, kurām nepieciešama veiklība.
Salīdzinot ar monolītu arhitektūru, SOA brīvi saistītais raksturs padara to salīdzinoši nevainojamu, pievienojot jaunus pakalpojumus vai uzlabojot esošos pakalpojumus jaunām uzņēmējdarbības vajadzībām. Tas arī nodrošina iespēju padarīt pakalpojumus patērējamus dažādos kanālos un atklāt mantotās lietojumprogrammas kā pakalpojumus, tādējādi nodrošinot ieguldījumus infrastruktūrā.
Tā kā tie ir brīvi savienoti, SOA komponentus var mainīt ar minimālu ietekmi uz citiem komponentiem. Komponentus var arī pievienot arhitektūrai standartizētā veidā, un tos var pielāgot, lai risinātu slodzi.
Apsveriet, kā uzņēmums var izmantot esošo lietojumprogrammu kopu, lai izveidotu jaunu, saliktu piegādes ķēdes lietojumprogrammu. Lai gan esošās lietojumprogrammas ir neviendabīgas un izplatītas dažādās sistēmās, to funkcionalitāte tiek pakļauta un tām var piekļūt, izmantojot standarta saskarnes.
Metjū Taisons SOA galvenās īpašības
SOA var būt tikpat vienkārša kā atsevišķa sastāvdaļa, kas patērē cita komponenta sniegtos pakalpojumus, vai tikpat sarežģīta kā virkne sastāvdaļu, kas mijiedarbojas ar uzņēmuma pakalpojumu kopnes, piemēram, MuleSoft ESB, starpniecību. Neatkarīgi no mēroga, veiksmīgas SOA ieviešanas atslēga ir pēc iespējas mazāk sarežģīta, lai sasniegtu savus mērķus. Pirmajam un pēdējam jautājumam vienmēr jābūt: Vai šis dizains atbilst mūsu biznesa prasībām?
Neatkarīgi no mēroga vai sarežģītības, uz pakalpojumu orientētas arhitektūras modelis ir aptuveni vai vienāds:
- Pakalpojumu sniedzēji atklāj galapunktus un apraksta pieejamās darbības katrā galapunktā.
- Pakalpojumu patērētāji izsniedz pieprasījumus un patērē atbildes.
- Pakalpojumu sniedzēji ģenerē ziņojumus, lai apstrādātu pieprasījumus.
Uz pakalpojumu orientētas arhitektūras ieviešana
Lai ieviestu SOA, jāsāk ar pamata pakalpojuma arhitektūru, pēc tam nodrošiniet infrastruktūru, proti, protokolus un citus rīkus, kas nodrošina saziņu un savietojamību. 2. attēlā parādīta tipiskas pakalpojumu arhitektūras shēma.
Metjū Taisons Šajā diagrammā trīs klienti izsauc pakalpojumus, nosūtot ziņojumus uzņēmuma pakalpojumu kopnei, kas ziņojumus pārveido un novirza uz atbilstošu pakalpojumu ieviešanu. A biznesa noteikumu dzinējs iekļauj uzņēmējdarbības noteikumus pakalpojumā vai visos pakalpojumos. A pakalpojumu pārvaldības slānis pārvalda tādas darbības kā revīzija, rēķinu izrakstīšana un mežizstrāde.
Šīs arhitektūras komponenti ir brīvi savienoti, tāpēc tos var izslēgt vai atjaunināt, salīdzinoši minimāli ietekmējot lietojumprogrammu kopumā. Tas piešķir uzņēmumam elastību pēc vajadzības pievienot vai atjaunināt biznesa procesus. Pārsvarā atsevišķu pakalpojumu izmaiņām nevajadzētu būtiski ietekmēt citus pakalpojumus.
ZIEPES vs RESTful tīmekļa pakalpojumi
Ir iespējams pieņemt SOA stilu un ieviest to ar REST, piemēram, izmantojot JAX-RS API vai Spring Boot Actuator, taču šī diskusija ir ārpus šī raksta darbības jomas. Skatiet sadaļu “SOAP vs REST vs JSON”, lai iegūtu noderīgu SOAP un RESTful tīmekļa pakalpojumu salīdzinājumu. Ir arī zināma pārklāšanās starp RESTful tīmekļa pakalpojumiem un vieglāku stilu, kas saistīts ar mikropakalpojumiem.
SOAP balstīti tīmekļa pakalpojumi
Tīmekļa pakalpojumi, kas ieviesti, izmantojot SOAP, joprojām ir stingrāki nekā RESTful tīmekļa pakalpojumu vai mikropakalpojumu ieviešana, bet daudz elastīgāki nekā SOA sākuma laiki. Šeit mēs aplūkosim tikai augsta līmeņa protokolus, kas nepieciešami SOAP balstītajiem tīmekļa pakalpojumiem.
ZIEPES, WSDL un XSD
SOAP, WSDL un XSD ir SOAP balstītas tīmekļa pakalpojumu ieviešanas pamatinfrastruktūra. WSDL tiek izmantots, lai aprakstītu pakalpojumu, un SOAP ir transporta slānis ziņojumu sūtīšanai starp pakalpojumu patērētājiem un pakalpojumu sniedzējiem. Pakalpojumi sazinās ar formāli definētiem ziņojumiem, izmantojot XML shēmu (XSD). Jūs varat domāt par WSDL kā pakalpojuma saskarni (gandrīz līdzīgu Java saskarnei). Ieviešana tiek veikta Java klasēs, un komunikācija tīklā notiek, izmantojot SOAP. Funkcionāli patērētājs meklētu pakalpojumu, iegūtu WSDL šim pakalpojumam un pēc tam izsauktu pakalpojumu, izmantojot SOAP.
Tīmekļa pakalpojumu drošība
WS-I Basic Profile 2.0 specifikācija attiecas uz ziņojumu drošību. Šī specifikācija koncentrējas uz akreditācijas datu apmaiņu, ziņojumu integritāti un ziņojumu konfidencialitāti.
Tīmekļa pakalpojumu atklāšana
Kad tīmekļa pakalpojumu atklāšanas stūrakmens, UDDI (universālais apraksts, definīcija un integrācija) ir izbalējis vēsturē. Šodien parasti tiek parādīts uz SOAP balstīts tīmekļa pakalpojums, tāpat kā jebkuru citu pakalpojumu, izmantojot galapunkta URL. Kā piemēru varat izmantot JAX-WS pakalpojuma galapunkta saskarni un tās @WebService un @WebMethod anotācijas.
Tīmekļa pakalpojumu veidošana un ieviešana
Java izstrādātājiem ir vairākas iespējas uz SOAP balstītu tīmekļa pakalpojumu izveidei un izvietošanai, tostarp Apache Axis2 un Spring-WS; tomēr Java standarts ir JAX-WS, Java API XML Web Services. JAX-WS pamatideja ir izveidot Java klases un anotēt tās, lai izveidotu nepieciešamos artefaktus. Zem pārsega JAX-WS izmanto vairākas Java paketes, tostarp JAXB, vispārējas nozīmes bibliotēku, lai saistītu Java klases ar XML.
JAX-WS no izstrādātāja slēpj pamatā esošo sarežģītību un protokolus, tādējādi pilnveidojot Java balstītu SOAP pakalpojumu definēšanas un izvietošanas procesu. Mūsdienu Java IDE, piemēram, Eclipse, ietver pilnīgu atbalstu JAX-WS tīmekļa pakalpojumu izstrādei. JAX-WS specifikācija ir izvēlēta arī pastāvīgai izstrādei Džakartas EE.
Secinājums
Uz pakalpojumu orientēta arhitektūra, kas ieviesta ar SOAP balstītiem tīmekļa pakalpojumiem, prasa stingrākas un formālākas pakalpojumu definīcijas nekā RESTful tīmekļa pakalpojumi vai mikropakalpojumi. Tomēr dažas lielākas organizācijas turpina atbalstīt formālāku stilu, ko ievieš SOAP. Daudzas liela mēroga mantotās sistēmas ir veidotas arī uz SOAP, un dažas B2B un iekšējās sistēmas formālāk definētiem API līgumiem izvēlas uz SOAP balstītus tīmekļa pakalpojumus. Neatkarīgi no tā, vai izstrādājat vai uzturat plaša mēroga uzņēmuma sistēmu, SOA modeļa izpratne un spēja novērtēt iespējas to ieviest jums labi noderēs jūsu programmēšanas karjerā.
Šis stāsts "Kas ir uz pakalpojumu orientēta arhitektūra?" sākotnēji to publicēja JavaWorld.
