Palvelukeskeistä arkkitehtuuria tai SOA (Layer Englanti oriented palveluarkkitehtuurin , SOA ) on eräänlainen sovittelu arkkitehtuurin , joka on vuorovaikutuksen sovellus , joka toteuttaa palvelut (komponentit ohjelmistot ):
Tämä termi ilmestyi vuosina 2000-2001, ja se koski alun perin syntaktisen yhteentoimivuuden kysymyksiä suhteessa liiketoiminnassa käytettyihin tietotekniikoihin. Tämä malli on kehittynyt viittaamaan nyt sovittelurakenteen tiettyyn osajoukkoon käytettävissä olevan tekniikan mukaan.
Jokapäiväisessä elämässä toimittaja tarjoaa palvelua asiakkaalle, joka käyttää sitä osapuolten välisessä luottamussuhteessa. Yleensä asiakasta kiinnostaa vain palvelun tuotetulos ilman tarvetta tai huolta siitä, miten se saadaan. SOA noudattaa samaa periaatetta. Palvelu on toiminto, jonka "toimittaja" (tai "tuottaja") suorittaa "asiakkaalle" (tai "kuluttajalle"), mutta kuluttajan ja tuottajan välinen vuorovaikutus tapahtuu välittäjän (joka voi olla väylä) kautta, joka on vastuussa yhteyden muodostamisesta komponentit. Koska palvelu on suuri, se kattaa ja tarjoaa järjestelmän komponenttien toiminnot. Nämä järjestelmät voidaan määritellä myös sovelluskerroksiksi. Palvelukeskeinen arkkitehtuuri on erittäin tehokas ratkaisu yritysten kohtaamiin ongelmiin, jotka liittyvät uudelleenkäytettävyyteen, yhteentoimivuuteen ja tietojärjestelmiä toteuttavien eri järjestelmien välisen kytkennän vähentämiseen . SOA tai SOA olivat suosituksi kynnyksellä standardeja kuten Web Services on sähköisen kaupankäynnin (sähköinen kaupankäynti) ( B2B , yritysten välisen tai B2C , kuluttajakaupasta), joka perustuu alustoilla, kuten Java EE tai .NET . He soveltavat osaa kaupungistumisen periaatteista . Palvelukeskeisessä arkkitehtuurissa erotellaan hakemiston, väylän, sopimuksen ja palvelun käsitteet, joista jälkimmäiset ovat palvelukeskeisen arkkitehtuurin ydin ja keskipiste. SOA: n muunnosta tai tarkemmin toteutusta, joka perustuu täysin Internetiin, kutsutaan WOA: ksi ( Web-Oriented Architecture ).
Vuosikymmenellä 1980-1990 tietojärjestelmien yhteentoimivuusongelma, joka on erityisen monimutkainen yritysten sulautumisen tai yritysostojen aikana, synnytti tietojen yhteentoimivuuden tutkimusalueen ; Tuolloin syntaktinen yhteentoimivuus erotettiin semanttisesta tietojen yhteentoimivuudesta. Tämä tutkimus johti monipohjaisiin järjestelmiin , hajautettujen tietokantojen ja yhdistetyn arkkitehtuurin kehittämiseen . Monien ratkaisemattomien ongelmien vuoksi liittovaltion arkkitehtuuri käytännössä hylättiin.
Kaksi tärkeintä toiminnallista vaatimusta, jotka ilmaantuivat tänä aikana, ovat:
Nämä toiminnalliset vaatimukset kiteytetään keksintöä Gio Wiederhold sovittelun arkkitehtuurin vuonna 1990-1992:
Tietovälitystutkimuksessa keskityttiin sitten yleisen arkkitehtuurin luomiseen, kuten ARPA I3, jossa ilmestyi viisi suurta palveluperhettä (sopeutuminen, muunnos, laajennus, hallinta ja koordinointi), korkean semanttisen ilmeikkyyden omaavien kielten, kuten KQML ja semanttiset tiedonmuunnostyökalut, kuten ontologiat .
Samaan aikaan verkkotekniikan kehitys muutti vähitellen muita hajautettuja laskentatekniikoita vähemmän houkutteleviksi. XML: n saapuminen vuonna 1996 aiheutti villityksen tälle kielelle tutkimusyhteisössä ja tapauskohtaiset tai monimutkaisemmat kielet, kuten KQML, käytännössä hylättiin, ainakin tämän tyyppisen arkkitehtuurin kohdalla. Teollisuus kehittänyt monia tuotteita impulssi perustutkimusta, esimerkiksi, on enemmän kuin 150 FT suoran linjan Wiederhold, valtaosa on ollut aktiivisesti mukana kehittämässä tätä tekniikkaa IBM , Oracle , Sun , Microsoft , Cisco , Samsung , LG , Bell Laboratories , Silicon Graphics , Kodak , Google , Napster ja muut; kuten James Duncan Davidson, joka oli Tomcatin ( Java Servlet ja JavaServer Pages ) sekä Antin luoja . Vuosikymmenen 1990–2000 lopussa löydettiin huomattava määrä tämän tyyppisiä tekniikoita, joiden yhteentoimivuus oli toisinaan erittäin ongelmallista, ainakin ilman ohjelmistoreittejä sen saavuttamiseksi.
Palvelukeskeinen arkkitehtuuri noudattaa useita palvelunhallinnan periaatteita, jotka vaikuttavat suoraan ohjelmistoratkaisun sisäiseen käyttäytymiseen ja sen suunnittelutyyliin:
Palvelukeskeinen arkkitehtuuri edustaa teknistä tapaa integroida yrityksen eri tietojärjestelmät, kun kukin IT-resurssi on palvelu. Sen avulla voidaan rakentaa rakennuspalikat, joista muodostuu tietojärjestelmän kaupunkisuunnittelu.
Rajapinnan käsite on tärkeä palvelukeskeisessä lähestymistavassa. Itse asiassa se edustaa ainoaa pääsyä ohjelmistoratkaisun toimintoihin ja varmistaa viestinnän viestien vaihdon kautta. Jokainen viesti sisältää ohjelmistoratkaisulle ominaisen semantiikan. Lisäksi tämä viesti on kirjoitettu molemmille osapuolille ymmärrettävällä kielellä. Ketterän arkkitehtuurin tarjoamat palvelut kuvaavat asiakkaalta odotettavien viestien rakennetta.
Palvelukeskeinen arkkitehtuuri on hajautettu ohjelmistoratkaisu. Se tarjoaa mekanismin viestien turvalliseen vaihtoon taustalla olevien tietojärjestelmien välillä käyttämällä standardoituja tietoliikenneprotokollia. Tämä lähestymistapa tarjoaa arkkitehtuurille mahdollisuuden avautua monenlaisille olemassa oleville ohjelmistoratkaisuille.
Palvelu on keskeinen osa palvelukeskeistä arkkitehtuuria. Se koostuu hyvin määritellystä toiminnosta tai toiminnallisuudesta. Se on myös erillinen komponentti, joka ei riipu mistä tahansa kontekstista tai ulkoisesta palvelusta. Se on jaettu toimintoihin, jotka muodostavat niin monen erityisen toiminnon kuin palvelu voi suorittaa. Voimme vetää yhtäläisyyden toisaalta toimintojen ja palveluiden sekä toisaalta menetelmien ja luokkien välillä olio-tilassa.
Palvelukeskeinen arkkitehtuuri on pohjimmiltaan kokoelma palveluja, jotka ovat vuorovaikutuksessa ja kommunikoivat keskenään. Tämä viestintä voi koostua yksinkertaisesta tietojen palautuksesta tai toiminnasta (useiden palvelujen koordinointi).
Palvelu on käsittelyyksikkö, joka täyttää seuraavat ominaisuudet:
Palvelun muunnelma on esimerkiksi verkkopalvelu, joka käyttää kuvauskielenä WSDL: ää (XML-metakieli), UDDI-hakemisto sen lokalisoinnin sallimiseksi ja siirtoprotokolla, kuten HTTP REST- arkkitehtuurissa ja SOAP SOA-arkkitehtuurille.
Palvelujen hierarkia vastaa ratkaisun arkkitehtuurin eri teknisiä tasoja:
Palveluhakemisto viittaa kaikkiin IS: ssä käytettävissä oleviin palveluihin (ja niihin liittyviin sopimuksiin), joten se osallistuu aktiivisesti IS: n dynaamisen kartoituksen toteuttamiseen. Väylämallissa palvelu voidaan rekisteröidä itse (rekisteröinti). UDDI- hakemistot muodostavat tänään standardin viitepalveluille.
SOA: n yleisin toteutus on palveluväylään perustuva. Tällä väylällä on välittäjä (väliohjelmisto) kuluttajan ja palvelun tuottajan välillä, mikä mahdollistaa löysän kytkennän. Linja-auto tarjoaa myös erilaisia palveluja:
Puhumme yleensä ESB: stä ( Enterprise Service Bus ), uuden sukupolven työkalusta IAE: lle ( Enterprise Application Integration , EAI ), joka perustuu standardeihin, kuten XML, JMS ( Java Message Service ) tai verkkopalveluihin. Suurin ero IAE: n kanssa on, että ESB tarjoaa täysin hajautetun integraation palvelukonttien avulla. Nämä "minipalvelimet" sisältävät integrointilogiikan ja ne voidaan jättää pois mistä tahansa verkon kohdasta. ESB on pääasiassa asynkroninen vaihtotyökalu, jossa on standardoidut (SOAP, JMS ...) tai integroidut ( JBI ...) rajapinnat . Se voi myös tarjota tapahtumien aktivoimia lisäarvopalveluja (käännös, muunnos jne.).
Toinen mahdollisuus perustaa SOA IS: n sisällä on käyttää verkkoa ainoana palvelutukena (eikä väylänä). Tämän lähestymistavan tekee mahdolliseksi se, että verkko sisältää jo SOA: lle tarvittavat ominaisuudet (reititys, suojaus jne.).
Tällainen arkkitehtuuri edellyttää kuitenkin, että kaikki palvelut ovat näkyvissä verkossa (mikä tarkoittaa pääsyä URL-osoitteesta), mikä suosii verkkopalveluja (muista, että verkkopalvelut eivät ole ainoa tapa paljastaa palveluja verkossa.) Tämän suunnittelun etuna on, että tuki palvelujen kutsuviesteille (siis verkolle) on todella yleinen eikä vaadi mitään määrityksiä, ylläpitoa, kehitystä ... Mutta tämä ratkaisu on tällä hetkellä melko vanhentunut tilanteissa, joissa suorituskyky on ongelma. kriteeri (vrt . verkkopalvelujen haitat ).
Tämä ratkaisu näyttää puhtaalta arkkitehtuuriltaan (tekniset näkökohdat lukuun ottamatta) todella sopivan SOA: n periaatteiden kanssa.
Tämän kappaleen kirjoittamishetkellä (kesä 2008) WOA on edelleen nuori ja ilman todellista formalismia, se aiheuttaa edelleen monia keskusteluja. Siksi on välttämätöntä ottaa kaikki tarvittava etäisyys WOA: n nykyisen kuvauksen suhteen.
Qworum on esimerkki WOA-tekniikasta.
SOA-arkkitehtuurit perustuvat pääasiassa kutsurajapinnan ( SOAP , vanha lyhenne sanoista Simple Object Access Protocol ) ja tietojen kuvaussanastoon ( WSDL , Web Services Description Language ja XML , Extensible Markup Language ), joiden on oltava yhteisiä kaikille agenteille (palveluntarjoajat) palvelun käyttäjät).
Tämän laitteen avulla voidaan uudelleenkäyttää liiketoimintasovelluksia, tavoitteena yrityksen sopeutuminen nopeasti uuteen markkinatilanteeseen.
Yhteentoimivuuden kannalta SOA-arkkitehtuurit perustuvat osittain WS-I: ssä kuvattuihin standardeihin .
Erilaisten standardien ja protokollien kerrosten joukossa, jotka mahdollistavat tällaisten arkkitehtuurien rakentamisen, huomataan:
SOA-arkkitehtuuria voidaan täydentää seuraavasti:
OASIS (Organization for the Advancement of Structured Information Standards) on voittoa tavoittelematon yhteenliittymä, joka ohjaa tietojärjestelmäarkkitehtuurien "OPEN" -standardien kehittämistä, lähentämistä ja käyttöönottoa.
Noin 2013, monet yritykset, kuten Netflix , soveltivat SOA-malleja ottamalla huomioon tekniikan kehityksen (konttikuljetukset, kubernetit , kafka jne.). Aikaisempi palaute on mahdollistanut joidenkin periaatteiden, erityisesti palvelujen tarkkuuden, tarkentamisen , tästä johtuen nimi " Microservices ". Tästä näkökulmasta voimme pitää mikropalveluja SOA: n evoluutiona.
SNCF on ottanut käyttöön SOA-arkkitehtuuria sen varausjärjestelmän (haku aikataulutus, korko pyynnöstä, varaus ...), joka tukee sekä terminaalit portilla virastojen ja asemia, ja korostaa sen online-tilaus verkkosivuilla Voyages-sncf.com .
Myös Air France-KLM -ryhmä on päättänytheinäkuu 2008valita palvelukeskeinen arkkitehtuuri IS: lle (verkkopalveluihin perustuva arkkitehtuuri lopulta korvaa "koti" SOA-arkkitehtuurin, joka on ollut käytössä 1990-luvulta lähtien). Yhtiö valitsee tämän arkkitehtuurin, jotta "tehdä sen on sekä skaalautuva ja reagoiva".
Lopuksi Ranskan hallinto uudenaikaistaa myös uudistamalla teknisen infrastruktuurin tietyissä ministeriöissä, mukaan lukien puolustus ja entiset taistelijat. Esimerkiksi seuraavan osastohankintatietojärjestelmän projektiryhmä aikoo käyttää ESB: hen perustuvaa palveluarkkitehtuuria. Tämän ministeriön SI HA: n on todellakin vaihdettava muiden kanssa. Siten SOA antaa sen integroitua maisemaan, jota rajoittaa voimakas yhteentoimivuuden tarve.