Ohjelmointi

Mikä on palvelukeskeinen arkkitehtuuri?

Palvelukeskeinen arkkitehtuuri (SOA) syntyi tämän vuosisadan alkupuolella hajautetun laskennan evoluutiona. Ennen SOA: ta, palvelut ymmärrettiin sovelluskehitysprosessin lopputuloksena. SOA: ssa itse sovellus koostuu palveluista. Palvelut voidaan toimittaa yksittäin tai yhdistää komponentteina suuremmassa, yhdistetyssä palvelussa.

Palvelut ovat vuorovaikutuksessa langan yli käyttämällä protokollaa, kuten REST tai SOAP (yksinkertainen objektin käyttöprotokolla). Palvelut ovat löyhästi kytketty, mikä tarkoittaa, että palvelurajapinta on riippumaton taustalla olevasta toteutuksesta. Kehittäjät tai järjestelmäintegraattorit voivat laatia yhden tai useamman palvelun sovellukseksi tietämättä, miten kukin palvelu toteutetaan.

Tämä artikkeli on yleiskatsaus Java SOA: sta ja SOAP-pohjaisia ​​verkkopalveluja käyttämällä toteutetun palvelukeskeisen arkkitehtuurin pääominaisuuksista. Vertailen myös lyhyesti SOA: ta ja mikropalveluja ja keskustelen erosta Java-RESTful- ja SOAP-pohjaisten verkkopalveluiden välillä.

SOA ja verkkopalvelut

SOA ja verkkopalvelut sekoitetaan usein, mutta ne eivät ole sama asia. SOA on arkkitehtuuri, jonka avulla kehittäjät voivat yhdistää useita sovelluspalveluita suuremmaksi, yhdistetyksi palveluksi. SOA voidaan toteuttaa käyttämällä SOAP-pohjaisia ​​verkkopalveluja tai REST-sovellusliittymiä tai joskus molempien yhdistelmää. On tärkeää ymmärtää, että SOA: ssa a palvelu on mikä tahansa etänä käytettävissä oleva resurssi, joka voi vastata pyyntöihin. A verkkopalvelu toteutetaan käyttämällä erityisiä protokollia.

Miksi palvelukeskeinen arkkitehtuuri?

SOA vastaa kolmeen yleiseen yrityshaasteeseen:

  • Reagoi nopeasti liiketoiminnan muutoksiin.
  • Hyödynnä olemassa olevia infrastruktuuri-investointeja.
  • Tukea uusia vuorovaikutuskanavia asiakkaiden, kumppaneiden ja toimittajien kanssa.

Yritysinfrastruktuuri on heterogeeninen kaikissa käyttöjärjestelmissä, sovelluksissa, järjestelmäohjelmistoissa ja sovellusinfrastruktuureissa. Tämän seurauksena monet yritysjärjestelmät koostuvat monimutkaisista ja epäjohdonmukaisista sovelluksista, jotka tarjoavat erilaisia ​​keskinäisiä palveluita. Nykyiset liiketoimintaprosesseja käyttävät sovellukset ovat kriittisiä, joten alusta alkaen tai niiden muokkaaminen on herkkä ehdotus. Yritysten on kuitenkin voitava muokata ja laajentaa teknistä infrastruktuuria vastaamaan liiketoiminnan vaatimuksia.

SOA ja mikropalvelut

Mikroservices on SOA: sta kehittynyt arkkitehtoninen tyyli. Molemmat ovat hajautettuja arkkitehtuureja ja molemmat tarjoavat irrotetun paradigman. Vaikka palvelukeskeinen arkkitehtuuri on raskaampaa infrastruktuurissa, mikropalvelut tarjoavat joustavamman, kevyemmän kehitystavan. Molemmilla on etuja ja haittoja, ja molempia käytetään laajasti. Yleisesti ottaen SOA: ta toteuttavat tai ylläpitävät useammin vakiintuneet yritykset, joilla on resursseja tukea enemmän muodollisuuksia. Mikropalvelut vetoavat usein uusiin tai kasvaviin organisaatioihin, jotka vaativat ketteryyttä.

Monoliittiseen arkkitehtuuriin verrattuna SOA: n löyhästi yhdistetty luonne tekee suhteellisen saumattomasta liittää uusia palveluja tai päivittää olemassa olevia palveluja vastaamaan uusia liiketoimintatarpeita. Se tarjoaa myös mahdollisuuden tehdä palveluista kuluttavia eri kanavilla ja paljastaa vanhat sovellukset palveluina turvaamalla siten infrastruktuuri-investoinnit.

Koska ne ovat löyhästi kytkettyinä, SOA-komponentteja voidaan muuttaa mahdollisimman vähän muihin komponentteihin. Komponentit voidaan myös lisätä arkkitehtuuriin standardoidulla tavalla, ja ne voidaan skaalata kuormituksen mukaan.

Mieti esimerkiksi, kuinka yritys voisi käyttää olemassa olevia sovelluksia uuden, yhdistetyn toimitusketjusovelluksen luomiseen. Vaikka nykyiset sovellukset ovat heterogeenisiä ja hajautettuja eri järjestelmiin, niiden toiminnallisuus paljastetaan ja niihin pääsee tavallisten rajapintojen avulla.

Matthew Tyson

SOA: n pääominaisuudet

SOA voi olla yhtä yksinkertainen kuin yksittäinen komponentti, joka kuluttaa toisen komponentin tarjoamia palveluita, tai yhtä hienostunut kuin joukko komponentteja, jotka ovat vuorovaikutuksessa yrityksen palveluväylän, kuten MuleSoftin ESB: n, kanssa. Mittakaavasta riippumatta, onnistuneen SOA-toteutuksen avain on käyttää mahdollisimman vähän monimutkaisuutta tavoitteidesi saavuttamiseksi. Ensimmäisen ja viimeisen kysymyksesi tulee aina olla: Täyttääkö tämä malli liiketoimintavaatimuksemme?

Mittakaavasta tai monimutkaisuudesta huolimatta palvelukeskeisen arkkitehtuurin malli on suunnilleen sama:

  • Palveluntarjoajat paljastavat päätepisteet ja kuvaavat käytettävissä olevat toiminnot jokaisessa päätepisteessä.
  • Palvelukuluttajat esittävät pyyntöjä ja kuluttavat vastauksia.
  • Palveluntarjoajat tuottavat viestejä pyyntöjen käsittelemiseksi.

Palvelukeskeisen arkkitehtuurin toteuttaminen

Voit ottaa SOA: n käyttöön aloittamalla peruspalveluarkkitehtuurin ja tarjoamalla sitten infrastruktuurin, eli protokollat ​​ja muut viestinnän ja yhteentoimivuuden mahdollistavat työkalut. Kuvassa 2 on kaavio tyypillisestä palveluarkkitehtuurista.

Matthew Tyson

Tässä kaaviossa kolme kuluttajaa vetoaa palveluihin lähettämällä viestejä yrityksen palveluväylälle, joka muuntaa ja reitittää viestit sopivaan palvelun toteutukseen. A liiketoimintasääntöjen moottori sisällyttää liiketoimintasäännöt palveluun tai palvelujen yli. A palvelunhallintataso hallinnoi toimintoja, kuten tilintarkastusta, laskutusta ja puunkorjuuta.

Tämän arkkitehtuurin komponentit on kytketty löyhästi, joten ne voidaan kytkeä pois päältä tai päivittää suhteellisen vähäisellä vaikutuksella koko sovellukseen. Tämä antaa yritykselle joustavuutta lisätä tai päivittää liiketoimintaprosesseja tarpeen mukaan. Suurimmaksi osaksi yksittäisten palvelujen muutosten ei pitäisi vaikuttaa suuresti muihin palveluihin.

SOAP vs. RESTful-verkkopalvelut

SOA-tyyli on mahdollista ottaa käyttöön ja toteuttaa se REST: n avulla, esimerkiksi käyttämällä JAX-RS API: ta tai Spring Boot Actuatoria, mutta tämä keskustelu ei kuulu tämän artikkelin piiriin. Katso "SOAP vs REST vs JSON" hyödyllinen vertailu SOAP vs RESTful -verkkopalveluista. RESTful-verkkopalvelujen ja mikropalveluihin liittyvän kevyemmän tyylin välillä on myös jonkin verran päällekkäisyyksiä.

SOAP-pohjaiset verkkopalvelut

SOAP: lla toteutetut verkkopalvelut ovat edelleen jäykempiä kuin RESTful-verkkopalvelujen tai mikropalvelujen toteutus, mutta paljon joustavampia kuin SOA: n alkuaikoina. Tässä tarkastellaan vain SOAP-pohjaisiin verkkopalveluihin tarvittavia korkean tason protokollia.

SOAP, WSDL ja XSD

SOAP, WSDL ja XSD ovat SOAP-pohjaisen verkkopalvelutoteutuksen perusinfrastruktuuri. WSDL: ää käytetään palvelun kuvaamiseen, ja SOAP on siirtokerros viestien lähettämiseen palvelun kuluttajien ja palveluntarjoajien välillä. Palvelut kommunikoivat virallisesti XML-skeeman (XSD) avulla määriteltyjen viestien kanssa. Voit ajatella WSDL: ää palvelun käyttöliittymänä (löysästi analoginen Java-käyttöliittymän kanssa). Toteutus tapahtuu Java-luokissa, ja verkon kautta viestintä tapahtuu SOAP: n kautta. Toiminnallisesti kuluttaja etsii palvelua, hankki WSDL: n palvelulle ja kutsui sitten palvelua SOAP: lla.

Verkkopalvelun suojaus

WS-I Basic Profile 2.0 -määritys koskee viestien suojausta. Tämä määrittely keskittyy tunnistetietojen vaihtoon, viestien eheyteen ja viestien luottamuksellisuuteen.

Verkkopalvelujen löytäminen

Kun verkkopalvelujen löytämisen kulmakivi, UDDI (Universal Description, Definition and Integration) on haalistunut historiaan. Tänään on yleistä paljastaa SOAP-pohjainen verkkopalvelu samalla tavalla kuin minkä tahansa muun palvelun päätelaitteen URL-osoitteen kautta. Esimerkiksi voit käyttää JAX-WS-palvelun päätepistettä ja sen @WebService ja @WebMethod merkinnät.

Verkkopalvelujen rakentaminen ja käyttöönotto

Java-kehittäjillä on useita vaihtoehtoja SOAP-pohjaisten verkkopalvelujen rakentamiseen ja käyttöönottoon, mukaan lukien Apache Axis2 ja Spring-WS; Java-standardi on kuitenkin JAX-WS, Java-sovellusliittymä XML-verkkopalveluille. JAX-WS: n ydinajatuksena on luoda Java-luokkia ja merkitä ne tarvittavien artefaktien luomiseksi. Konepellin alla JAX-WS käyttää useita Java-paketteja, mukaan lukien JAXB, yleiskäyttöinen kirjasto Java-luokkien sitomiseksi XML: ään.

JAX-WS piilottaa taustalla olevan monimutkaisuuden ja protokollat ​​kehittäjältä, mikä virtaviivaistaa Java-pohjaisten SOAP-palveluiden määrittelyä ja käyttöönottoa. Nykyaikaiset Java IDE: t, kuten Eclipse, sisältävät täyden tuen JAX-WS-verkkopalvelujen kehittämiselle. JAX-WS -määrittely on myös valittu jatkuvaan kehittämiseen Jakarta EE: ssä.

Johtopäätös

SOAP-pohjaisilla verkkopalveluilla toteutettu palvelukeskeinen arkkitehtuuri vaatii jäykempiä ja muodollisempia palvelumääritelmiä kuin RESTful-verkkopalvelut tai mikropalvelut. Jotkut suuremmat organisaatiot suosivat kuitenkin edelleen SOAP: n noudattamaa muodollisempaa tyyliä. Monet laajamittaiset vanhat järjestelmät rakennetaan myös SOAP: lle, ja jotkut B2B- ja sisäiset järjestelmät valitsevat SOAP-pohjaiset verkkopalvelut muodollisemmin määritetyille API-sopimuksilleen. Olitpa kehittämässä tai ylläpitämässä laajamittaista yritysjärjestelmää, SOA-mallin ymmärtäminen ja mahdollisuus arvioida vaihtoehtoja sen toteuttamiseksi palvelee sinua hyvin ohjelmoijaurallasi.

Tämä tarina "Mikä on palvelukeskeinen arkkitehtuuri?" julkaisi alun perin JavaWorld.