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.
