miten rakennetaan palvelukeskeinen arkkitehtuuri (SOA)

miten rakennetaan palvelukeskeinen arkkitehtuuri (SOA)

tässä artikkelissa käsitellään palvelukeskeistä arkkitehtuuria (Soa). Aloitamme syväsukelluksella 1) SOA: kuvaus ja sitten keskustellaan 2) palvelukeskeisen arkkitehtuurin rakentamisesta.

palvelukeskeinen arkkitehtuuri: kuvaus

mikä on SOA?

Soa eli palvelukeskeinen arkkitehtuuri on menetelmä, jonka avulla erityyppiset palvelut voivat olla keskenään vuorovaikutuksessa itsenäisesti. Palvelu on itsenäinen osa toiminnallisuutta, ja useita palveluita voidaan yhdistää tarjoamaan ohjelmistosovelluksen käyttöä ja toimivuutta laajassa mittakaavassa. Mitä SOA tekee on, että se tekee siitä yksinkertaisempaa ohjelmiston osia PC, jotka on kytketty verkkoon vuorovaikutuksessa ja yhteistyötä. SOA: n Suunnittelumalli on sellainen, että siinä olevat sovelluskomponentit voivat tarjota palveluja muille tällaisille komponenteille lähinnä verkon kautta. Jokainen tietokonejärjestelmä voi suorittaa mitä tahansa palveluita, joista jokainen on rakennettu vaihtamaan tietoja minkä tahansa muun eri palvelun kanssa verkossa ilman ihmisen apua.

Soa on liiketoimintaterminologiassa joukko liiketoiminnallisesti yhtenäistettyjä IT-palveluja, jotka yhdessä käsittelevät liiketoimintayhtiön tavoitteita ja prosesseja. Rakenteellinen suunnittelu SOA varmistaa, että on yhdenmukaistaminen vaatimukset liiketoiminnan sekä teknologisen ratkaisun saman.

SOA: n pääelementit

tässä ovat SOA: n pääelementit:

• SOA Drivers – SOA drivers tai enterprise business drivers sisältää asioita, kuten kilpailu, strategia, sääntelyvoimat ja markkinavoimat. Kaikki nämä seikat yhdessä ohjaavat liiketoimintarakennetta ja antavat muodon liiketoiminnan laajuiselle tulosjohtamiselle
• SOA mahdollistajat-viisi tärkeintä SOA mahdollistajaa ovat yrityksen liiketoimintamalli, liiketoiminnan suorituskyvyn optimointi, portfolion rationalisointi, yrityksen semantiikan määrittely ja Keskeiset suorituskykymittarit. Liiketoimintamalli on tärkeää, jotta palvelut voidaan sovittaa oikein liiketoiminnan tavoitteisiin ja tavoitteisiin. Semanttisen tiedon malli antaa tietyn yrityksen yhteisen ja yleisen liiketoimintaan liittyvän tiedon. Keskeiset suoritusindikaattorit tai Keskeiset suoritusindikaattorit mahdollistavat tarkastelujakson vaikutusten arvioinnin ja helpottavat liiketoimintaprosessien mittaamista. Toisaalta salkun rationalisointi mahdollistaa sovellusten, datan ja infrastruktuurin konsolidoinnin ja yksinkertaistamisen.
• SOA Implementation-mitä tulee toteutukseen, Yrityspalvelut ja prosessit ovat tärkeimmät näkökohdat. Liiketoimintaprosessit liittyvät useimmiten liiketoiminnan tavoitteisiin ja toiminnan tavoitteisiin, kun taas yrityspalveluiden tulee olla hyvin linjassa ja kriittisiä joustavan ja onnistuneen SOA-toteutuksen kannalta. Muita SOA: n toteutukseen liittyviä näkökohtia ovat yritysten sisältövarastot, semanttinen sanomanvälitys ja integraatiopalvelut. Tiedot edustavat yrityksen tietovarantoja, ja nämä tiedot välitetään dokumentteina, jotka tarjoavat eräänlaisia semanttisia viestejä palveluiden ja prosessien välillä.
• SOA – Tuki-kaikki olemassa olevien sovellusten ja järjestelmien toiminnot ja elementit ovat saatavilla ja käytettävissä palveluissa joidenkin integraatiopalvelujen tuella, jotka irrottavat suojat nykyisistä toiminnoista uusien palveluliittymien kautta.

SOA: n pääperiaatteet

Seuraavassa on luettelo SOA: n pääperiaatteista:

• palveluarkkitehtuuri – yksittäisten palvelujen fyysinen ulkoasu tai suunnittelu, joka ylittää kaikki palvelun käyttämät resurssit.
• Service composition architecture – kaikki palvelukeskeisiä suunnittelumenetelmiä käyttäen kehitetyt palvelut ovat koostumuskeskeisiä, ja tämä on niiden tärkein ominaisuus. Tämä arkkitehtuuri on siis eri palvelujen yksittäisten arkkitehtuureiden koostumus.
• Service inventory architecture – tämä arkkitehtuuri on muodostettu palveluvaraston piirustuksesta, jossa palveluvarasto koostuu palveluista, jotka automatisoivat yritysten menettelyjä.
• palvelukeskeinen kokonaisarkkitehtuuri-tämä tyyppi koostuu kokoonpano–, palvelu-ja varastoarkkitehtuureista.

Soa – käsitteen kehitys

• monoliittinen suunnittelu – tämä rakenne liittyi suhteellisen jäsentymättömään prosessikoodaukseen
• olio-ja rakennesuuntautunut suunnittelu-tämä on suunnittelu, johon kuuluu toiminnallisuuksiin perustuvia ohjelmayksiköitä.
• asiakas-palvelin-suunnittelu (kaksitasoinen suunnittelu) – tämä on hajautetun suunnittelun käsite ja liittyy toimintojen yhdistämiseen kahteen tasoon.
• Distributed object design (multiier design) – Tämä muotoilu sisältää objektien vuorovaikutuksia heterogeenisessa ympäristössä ja hajautetun objektin suunnittelua.
• Component object model architecture – tämä on muotoilu, jossa on aggregoitu kohteita logiikkaan perustuviin osiin, joilla on vahvasti tyypit, sekä hyvin määritelty käyttöliittymä.
• palvelukeskeinen arkkitehtuuri – tämä on suunnittelu, joka sisältää vuorovaikutusta ja viestintää karkearakeisten palvelujen kanssa, joilla on standardirajapinnat joustavaa vuorovaikutusta varten.

SOA ja JAVA

monet kehittäjät ajattelevat, että SOA sekä verkkopalvelut ovat synonyymejä toisilleen, mutta tämä ei pidä paikkaansa. He saattavat myös uskoa, että SOA: ta ei vain ole mahdollista rakentaa ilman verkkopalveluja, mutta todellisuudessa SOA on suunnitteluperiaate, mutta verkkopalvelut ovat eräänlainen toteutustekniikka. Tämä tarkoittaa, että SOA voidaan itse asiassa rakentaa hyödyntämättä tietynlaista toteutustekniikkaa. Mutta Java on toisenlainen perinteinen tekniikka, jonka avulla voidaan kehittää tai rakentaa palvelukeskeistä arkkitehtuuria.

SOA: n päätavoitteena on kehittää moduulien välille löyhä kytkentä, ja sovellus voidaan rakentaa, jos moduuleja ei ole kytketty toisiinsa liian tiukasti. Tällainen rakenne voidaan rakentaa tai muodostaa Javan avulla.

mitkä ovat SOA: n ominaisuudet?

• löyhä yhteys – SOA: n palvelut liittyvät löyhästi yhteen muodostaen yhden yhteyden. Tämä edellyttää kunkin palvelun keskinäisen riippuvuuden pienuutta. Pääajatuksena on vähentää keskinäisriippuvuutta tasolle, jolla Yhteensopivuus säilyy edelleen.
• standardized services interface – SOA: n yksi perusvaatimus on rajapintojen standardoinnin sekä yksityiskohtien tarve. Yksityiskohdista on käytävä ilmi, mitä tietoja tarvitaan, miten palvelua voidaan käyttää ja miten sääntöjä on sovellettava.
• uudelleenkäytettävyys – SOA: ssa palvelujen uudelleenkäytettävyys on mahdollista prosessiketjussa myös muiden osapuolten toimesta ja myös muunlaisiin tarkoituksiin.
• palvelun löydettävyys – toinen ominaisuus on, että palvelun on helposti löydyttävä, jotta sitä voi käyttää. Kaikkien kuluttajien saataville asetetaan palvelurekisterit, jotka koostuvat palvelun rajapinnasta ja toteutustavasta.
• palvelun itsenäisyys – jokaisen palvelun on kyettävä toimimaan ja toimimaan itsenäisesti. Tällä termillä viitataan niihin palveluihin, jotka ovat omavaraisia ja kykenevät yksin hallitsemaan resursseja, logiikkaa ja ympäristöä.
• Palveluorkestrointikapasiteetti – tämä on prosessi, jossa yksittäinen palvelu yhdistetään muihin vastaaviin palveluihin ja tuloksena on suurempia liiketoimintaprosesseja tai yksiköitä. Tämä on myös SOA: n ominaisuus tai vaatimus.
• palvelujen Statelessity – palvelujen suoritus perustuu käsitteeseen, että määritelty palvelu suoritetaan. Tässä otetaan huomioon tietojen säilyttäminen, mutta vain, jos vaatimus on erityisesti määritelty tai sitä pyydetään.

SOA: n edut ja hyödyt

• parempi sijoitetun pääoman tuotto – SOA: n suurimpia etuja on se, että se tarjoaa erinomaisen sijoitetun pääoman tuoton. Koska prosessi liittyy luomiseen vankka kerrokset, jokainen näistä palvelutasot tarjoavat paremman tuoton investoinnin, joka tehtiin luoda ohjelmisto.
• Code mobility-tämä on jälleen yksi SOA: n tärkeä etu, ja se on mahdollista, koska palvelukeskeisessä arkkitehtuurissa on sijaintien läpinäkyvyys. Suurin osa asiakkaista ei välitä, missä palvelut sijaitsevat, koska niissä on dynaaminen sitoumus sekä palvelujen haku. Tämä tarkoittaa, että SOA: ta käyttävät yritykset voivat siirtää palveluita eri koneille tai siirtää ne ulkopuolisille palveluntarjoajille.
• SOA: n uudelleenkäytettävyys – toinen etu on se, että eri koodeja ja palveluita voidaan käyttää yhä uudelleen. Ajonaikaisen palvelun uudelleenkäyttö on kätevää, ja se on yhtä helppoa kuin palvelun löytäminen hakemistosta ja sitominen siihen. Kehittäjien ei tarvitse huolehtia alustoista ja muista yhteensopimattomuuksista.
• tuki eri asiakastyypeille – mikä tahansa yritys voi käyttää useita asiakastyyppejä ja useita asiakkaita päästäkseen SOA: n palveluun. Tämä johtuu siitä, että tällaisessa rakenteessa tai konseptissa kerrokset on jaettu palveluun, ja asiakastasot ja erilaiset asiakastyypit ovat yksinkertaisempia toteuttaa.
• korkeampi saatavuustaso – useilla palvelimilla on useita tapauksia, joissa palveluja käytetään, koska SOA tukee sijainnin läpinäkyvyyttä. Tämä tarkoittaa, että yleinen saatavuus on erittäin korkea. Jos esimerkiksi kone tai verkon osa lakkaa toimimasta tai siinä on jokin ongelma, pyynnöt voidaan ohjata muihin palveluihin asiakkaan tietämättä tai sen häiritsemättä.
• vähemmän vikoja – tämä on SOA: n suuri etu. Vikojen todennäköisyys on paljon pienempi, ja yleinen testaus on paljon parempi, koska julkaistut rajapinnat palveluja, jotka voidaan testata helposti. Enemmän testausta tarkoittaa suurempaa tarkkuutta ja vähemmän vikoja.

SOA haastaa

• Testaustilan puute – yksi SOA: n suurimmista haasteista on testaustilan puute. Tyypillisessä arkkitehtuurissa ei ole hyvin muotoiltuja tai hienostuneita työkaluja tai menetelmiä päättömän palvelun, kuten viesti-tai tietokantapalvelun, testaamiseen. SOA: n päätavoitteena on tarjota ketteryyttä yrityksille ja yrityksille. Horisontaalisen luottamuksen puutteen vuoksi on kuitenkin investoitava testauskehykseen, joka helpottaisi haastetta.
• Manage Services Metadata – tämä on SOA: n yleinen ja hyvin ilmeinen haaste. Palveluiden metadatan hallinta ei ole vain vaikeaa, vaan usein hyvin monimutkaista. Palvelupohjaisessa arkkitehtuuritilassa palvelut vuorovaikuttavat keskenään viestiä vaihtamalla. Tällaisessa tilanteessa yksittäisissä palveluissa voi joskus syntyä miljoonia viestejä. Näiden monien palvelujen hallinta voi tulla hyvin vaikeaksi erityisesti silloin, kun palveluja toimittavat yrityksen eri yritykset ja osastot. Tämä luo monia luottamuskysymyksiä.
• oikean turvallisuustason tarjoaminen-toinen SOA: n haaste on asianmukaisen turvallisuustason tarjoaminen. Sovellusjohtoinen tietoturva ei ole oikea tapa tai malli palveluiden turvaamiseen, koska sovelluksiin suunnitellut tietoturvamallit eivät voi riittää, kun sovellus näyttäytyy muille.
• yhteentoimivuus – tästä tulee tärkeä osa tarkastuslausuman toteutusta. Usein tavoiteltaessa palvelujen keskinäisen riippuvuuden vähentämistä tai vähentämistä niiden yhteensopivuus voi vähentyä, mutta riippuvuus on vähennettävä sellaiselle tasolle, että yhteensopivuus voidaan edelleen säilyttää.
• Vendor hype – NIINAAN liittyy merkittävä toimittajan hype, joka luo tietyn tason kohtuuttomia odotuksia. Vaikka on olemassa monia etuja SOA, se voi olla useita haittoja samoin. Esimerkiksi SOA ei takaa IT-kustannusten vähenemistä eikä lupaa edes järjestelmien ketteryyden parantamista. Näin ollen olisi parempi, jos hypetyksen ja todellisuuden välillä olisi selvä ero.

palvelukeskeisen arkkitehtuurin rakentaminen

SOA Framework

ymmärtääksesi, miten SOA on rakennettu, sinun on ensin ymmärrettävä sen puitteet.

SOA katsotaan 5 erilaiseksi vaakatasoksi, jotka ovat:

1. Consumer interface layer – nämä ovat sovelluksia, jotka käyttävät palvelun tai sovelluksen rajapintoja.
2. Business process layer-tämä on taso, joka on palvelu, joka edustaa yrityskäyttötapauksia sovellusten osalta.
3. palvelut-monet palvelut nuijitaan yhteen kokonaisen yrityksen luomiseksi.
4. Palvelukomponentit – nämä ovat niitä komponentteja tai osia,joita käytetään palvelujen, kuten teknologisten rajapintojen ja teknisten kirjastojen, rakentamiseen.
5. Operational systems-tämä on taso, joka sisältää tekniset mallit, tietomallit ja tietovaraston jne.

Seuraavassa on SOA: n puitteiden pystykerrokset, joita vaakatasossa käytetään ja tuetaan:

1. Integraatiokerros – tämä taso koostuu protokollatuesta tai alustaintegraatiosta, tietojen integroinnista, sovellus-ja palveluintegraatiosta jne.
2. palvelun laatu-palvelun laatuun vaikuttavia tekijöitä ovat muun muassa saatavuus, turvallisuus ja suorituskyky.
3. Informational – tämä taso lähinnä tarjoaa liiketoimintaan liittyvää tietoa.
4. hallintotapa – tätä tasoa tai IT-strategiatasoa hallitaan horisontaalisilla kerroksilla, jotta saavutettaisiin valmius sekä toimintamalli tarpeen mukaan.

SOA Implementation Framework (SOAIF)

SOA implementation needs and requires run-time infrastructure software and tools. Tätä voidaan yhdessä kutsua palvelukeskeiseksi arkkitehtuurin toteutuskehykseksi tai SOAIF: ksi. Tämän konseptin tavoitteena on kattava kehys, joka tarjoaa kaikenlaista teknologiaa, jota yritys voi tarvita paitsi rakentaa myös pyörittää SOA. Soaif koostuu ja sisältää sekä ajonaikaisia että suunnitteluaikaisia ominaisuuksia. Se sisältää myös ohjelmistotoimintoja, joita yritys voi tarvita SOA: n suorittamiseen ja myös sen rakentamiseen, mukaan lukien palvelukeskeinen:

• mallintaminen
• integraatio
• Työkalut
• hallinta
• turvallisuus
• prosessit

lähestymistavat SOA

on olemassa kolme päätyyppiä tai-menetelmiä tai-lähestymistapoja, jotka ovat olleet kehittymässä kerhotiedon, erilaisuuden ja järjestelmien osalta yrityksessä. Eri palveluntarjoajien ja yritysten pyrkiessä tarjoamaan ratkaisuja asiakkaille ja kuluttajille nämä lähestymistavat auttavat täyttämään karkearakeisten, löyhästi nuijittujen ja asynkronisten palvelujen vaatimukset.

1. Enterprise Service Bus

ensimmäinen lähestymistapa, joka auttaa rakentamaan ja toteuttamaan optimaalisen SOA: n, on enterprise service bus tai ESB. Tämä lähestymistapa auttaa koordinoimaan ja järjestämään eri osatekijöitä, jotka ovat hajautettujen palvelujen muodossa verkossa. Tässä lähestymistavassa järjestelmät katsotaan erillisiksi ja hajautetuiksi palveluiksi, jotka kytkeytyvät toisiinsa asynkronisen viestipainotteisen infrastruktuurin kautta. Tällainen viestipainotteinen infrastruktuuri mahdollistaa löyhät yhteydet riippumattomien palvelujen tai moduulien välillä.

2. Liiketoimintaprosessien hallinta

monet yritykset ovat jo vuosien ajan yrittäneet ratkaista liiketoimintaprosessien ongelmia soveltamalla Liiketoimintaprosessien hallinnan lähestymistapaa. Tämä lähestymistapa ottaa huomioon tietotekniset varat ja järjestelmät toimintoina tai tehtävinä, jotka osallistuvat hyvin synkronoituihin ja hyvin organisoituihin liiketoimintaprosesseihin. BPM-työkaluja käytetään pääasiassa menetelmien mallintamisen ja suunnittelun yhteydessä sen sijaan, että niitä käytettäisiin integraatiotavoitteisiin pääsevien prosessien rakentamiseen. Tämä on BPM: n suurin haaste. By BPM-ratkaisut yksinään riittävät täyttämään SOA: n vaatimukset, koska ne eivät koostu ajonaikaisesta ympäristöstä, jota tarvitaan löyhästi kytkettyihin moduuleihin.

3. Palvelukeskeinen integraatio

kolmas ja viimeinen lähestymistapa SOA: n asianmukaiseen toteuttamiseen on palvelukeskeinen integraatio. Tämä erityinen lähestymistapa hyödyntää arkkitehtonisia ohjaavia sääntöjä tai periaatteita rakentaakseen ympäristön tai palveluekosysteemin, jota yritykset voivat yhdistää dynaamisesti ja luoda korkeatasoisia prosesseja, jotka voivat vastata alati muuttuviin ja muuttuviin vaatimuksiin. Tämä lähestymistapa ohittaa tiukasti kytketyt ja hauraat moduulit tekemällä eron kuluttajan ja palvelun tuottajan välille. Näin ollen se asettaa osa löysä kytkentä, joka on tarpeen toteuttaa Soa asianmukaisesti täyttää liiketoiminnan vaatimukset. Edes tämä lähestymistapa itsessään ei riitä takaamaan pitkäaikaista vuorovaikutusta palvelujen välillä.

SOA: n rakentamisen parhaat käytännöt

tarkastuslausumaa rakennettaessa on noudatettava joitakin parhaita ja hyödyllisimpiä käytäntöjä. Nämä käytännöt esitetään seuraavasti:

1. Toteutustekniikat ovat paljon hypetettyjä, ja niihin on muistettava olla hyppäämättä niiden suosion vuoksi. On mietittävä tarkkaan, onko verkkopalveluissa enemmän järkeä niiden vaatimukseen ja tarpeeseen. On tärkeää muistaa, että RMI: n kaltaista teknologiaa hyödyntävät talotekniikkalähtöiset sovellukset saattavat sopia yrityksen tapaukseen paremmin kuin verkkopalvelut.
2. on muistettava olla luomatta tai rakentamatta erittäin tiukasti toisiinsa kytkettyjä tai kytkettyjä moduuleja, Koska tämä johtaa hauraaseen kokoonpanoon tai infrastruktuuriin.
3. yhteentoimivuuden säilyttäminen on tärkeää, ja niiden osalta on noudatettava WS-I: n parhaita käytäntöjä.
4. jos et näe mitään järkeä verkkopalveluiden käytössä, on myös monia muita vaihtoehtoja, jotka voidaan valita.