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 protokollan, kuten REST tai SOAP (yksinkertainen objektin käyttöprotokolla), avulla. Palvelut on kytketty löyhästi, mikä tarkoittaa, että palvelurajapinta on riippumaton taustalla olevasta toteutuksesta. Kehittäjät tai järjestelmäintegraattorit voivat laatia yhden tai useamman palvelun sovellukseen tietämättä, miten kukin palvelu toteutetaan.
Tämä artikkeli on yleiskatsaus Java SOA: sta ja palvelukeskeinen arkkitehtuuri, joka on toteutettu SOAP-pohjaisten verkkopalvelujen avulla. Vertailen myös lyhyesti SOA: ta ja mikropalveluja ja keskustelen RESTful- ja SOAP-pohjaisten verkkopalvelujen eroista Java-käyttöjärjestelmässä.
Miksi palvelukeskeinen arkkitehtuuri?
SOA vastaa kolmeen yleiseen yrityshaasteeseen :
- Reagoi nopeasti liiketoiminnan muutoksiin.
- Hyödynnä olemassa olevia infrastruktuuri-investointeja.
- Tuetaan 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 toimittavat valikoima keskenään riippuvia palveluita. Nykyiset liiketoimintaprosesseja käyttävät olemassa olevat sovellukset ovat kriittisiä, joten alusta alkaen tai niiden muokkaaminen on herkkä ehdotus. Yritysten on kuitenkin voitava muokata ja laajentaa teknistä infrastruktuuria vastaamaan liiketoiminnan vaatimuksia.
Kuten verrattuna monoliittiseen archiin 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 kulutettavia eri kanavilla ja paljastaa vanhat sovellukset palveluina, mikä turvaa infrastruktuuri-investoinnit.
Koska ne ovat löyhästi kytkettyinä, SOA-komponentit voidaan vaihtaa mahdollisimman vähän muihin komponentteihin . Komponentit voidaan myös lisätä arkkitehtuuriin standardoidulla tavalla ja ne voidaan skaalata kuormituksen osoittamiseksi.
Mieti esimerkiksi, miten yritys voisi käyttää olemassa olevia sovelluksia uuden, yhdistetty toimitusketjun käyttö. Vaikka nykyiset sovellukset ovat heterogeenisiä ja hajautettuja eri järjestelmiin, niiden toiminnot paljastetaan ja niihin pääsee tavallisilla rajapinnoilla.
Kuva 1. Toimitusketjusovellus palvelukeskeisessä arkkitehtuurissa
SOA: n tärkeimmät ominaisuudet
SOA voi olla yhtä yksinkertainen kuin yksittäinen komponentti, joka kuluttaa toisen komponentin tarjoamia palveluja, tai yhtä hienostunut kuin joukko komponentteja, jotka ovat vuorovaikutuksessa yrityksen palveluväylän, kuten MuleSoftin ESB: n, kanssa. Huolimatta laajuudesta, avain onnistuneeseen SOA-käyttöönottoon 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?
Palvelulähtöisen arkkitehtuurin malli huolimatta mittakaavasta tai monimutkaisuudesta on suunnilleen sama:
- Palveluntarjoajat paljastavat päätepisteet ja kuvaavat käytettävissä olevat toimet kussakin päätepisteessä.
- Palvelun kuluttajat lähettävät pyyntöjä ja kuluttavat vastauksia.
- Palveluntarjoajat luovat viestejä pyyntöjen käsittelemiseksi.
Palvelun toteuttaminen- suuntautunut arkkitehtuuri
SOA: n toteuttamiseksi aloitat peruspalveluarkkitehtuurista ja tarjoat sitten infrastruktuurin, eli protokollat ja muut viestinnän ja yhteentoimivuuden mahdollistavat työkalut. Kuvassa 2 on kaavio tyypillisestä palveluarkkitehtuurista.
Kuva 2. Palveluarkkitehtuuri
Tässä kaaviossa kolme kuluttajaa vetoaa palveluihin lähettämällä viestejä yrityksen palveluväylälle, joka muuntaa ja reitittää viestit sopivaan palvelun toteutukseen . Liiketoimintasääntöjen moottori sisältää liiketoimintasäännöt palvelussa tai palvelujen yli. Palvelunhallintataso hallinnoi toimintoja, kuten tilintarkastusta, laskutusta ja lokien kirjaamista.
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-pohjaiset verkkopalvelut
SOAP: lla toteutetut verkkopalvelut ovat edelleen jäykempiä kuin RESTful-verkkopalvelujen tai mikropalvelujen toteutus, mutta huomattavasti joustavampia kuin SOA: n alkuvaiheet. Tässä tarkastellaan vain SOAP-pohjaisten verkkopalvelujen edellyttämiä korkean tason protokollia.
SOAP, WSDL ja XSD
SOAP, WSDL ja XSD ovat perusinfrastruktuuri SOAP-pohjaisen verkkopalvelun toteutuksesta. WSDL: ää käytetään palvelun kuvaamiseen, ja SOAP on siirtokerros viestien lähettämiseen palvelun kuluttajien ja palveluntarjoajien välillä. Palvelut kommunikoivat XML-skeeman (XSD) avulla muodollisesti 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, hankkii palvelulle WSDL: n ja kutsui sitten palvelun SOAP: n avulla.
Verkkopalvelun suojaus
WS -I Basic Profile 2.0 -määritys käsittelee viestien suojauksen. Tämä määrittely keskittyy tunnistetietojen vaihtoon, viestien eheyteen ja viestien luottamuksellisuuteen.
Verkkopalvelujen löytäminen
Kun verkkopalvelujen löytämisen kulmakivi on UDDI (Universal Description, Definition and Integration) haalistunut historiaan. Tänään on yleistä paljastaa SOAP-pohjainen verkkopalvelu samalla tavalla kuin minkä tahansa muun palvelun päätelaitteen URL-osoitteen kautta. Voit esimerkiksi 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-pohjaisen rakentamiseen ja käyttöönottoon verkkopalvelut, 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, yleiskirjasto Java-luokkien sitomiseksi XML: ään.
JAX-WS piilottaa taustalla olevan monimutkaisuuden ja protokollat kehittäjältä, virtaviivaistaa prosessia Java-pohjaisten SOAP-palveluiden määritteleminen ja käyttöönotto: Nykyaikaiset Java IDE: t, kuten Eclipse, sisältävät täyden tuen JAX-WS-verkkopalvelujen kehittämiselle. WS-määrittely on myös valittu jatkuvaan kehittämiseen Jakarta EE: ssä.
Johtopäätös
SOAP-pohjaisten verkkopalveluiden kanssa toteutettu palvelukeskeinen arkkitehtuuri vaatii jäykempää ja muodolliset palvelumääritelmät kuin RESTful-verkkopalvelut tai mikropalvelut. Jotkut suuremmat organisaatiot suosivat kuitenkin edelleen SOAP: n noudattamaa muodollisempaa tyyliä. Monet laajamittaiset vanhat järjestelmät ovat myös rakennettu 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ää, ymmärrät SOA-mallin ja pystyt arvioimaan vaihtoehtoja sen toteuttamiseksi palvelee sinua hyvin ohjelmoijaurallasi.