mikä on SOA? 7 Soa Steps

tässä blogissa kerrotaan, mitä SOA-askelia organisaation on otettava, ennen kuin se voi todella onnistua toteuttamaan yrityksen palvelukeskeisen arkkitehtuurin tarjoamat kustannus-ja ketteryyshyödyt. Siinä käsitellään SOA: n merkitystä ja hyväksymisen eri vaiheita kuvaamalla teknologioita, prosesseja ja parhaita käytäntöjä, jotka auttavat yrityksiä menestymään palvelukeskeisissä arkkitehtuurihankkeissa.

mikä on SOA?

Service-oriented architecture (Soa) on ohjelmistosuunnittelussa käytetty palvelulähtöisyyttä tukeva arkkitehtuurityyppi, jossa palveluja tarjotaan muille komponenteille tietoliikenneprotokollan kautta verkon yli.

mitä SOA tarkoittaa?

Wikipedian antama määritelmä SOA: sta:

Service-oriented architecture (Soa) on ohjelmistosuunnittelun tyylisuunta, jossa palvelut tarjotaan muille komponenteille sovelluskomponenttien avulla verkon kautta kulkevan tietoliikenneprotokollan avulla. Palvelukeskeisen arkkitehtuurin perusperiaatteet ovat riippumattomia myyjistä, tuotteista ja teknologioista. Palvelu on erillinen yksikkö toimintoja, joita voidaan käyttää etänä ja toimia ja päivittää itsenäisesti, kuten hakea Luottokortin tiliote verkossa.

palvelulla on neljä ominaisuutta yhden SOA: n monista määritelmistä mukaan:

1. se edustaa loogisesti liiketoimintaa, jonka tulos on määritelty.
2. se on itsenäinen.
3. se on kuluttajille tarkoitettu musta laatikko.
4. se voi koostua muista taustalla olevista palveluista.

erilaisia palveluita voidaan käyttää yhdessä suuren ohjelmistosovelluksen toiminnallisuuden tarjoamiseen, minkä periaatteen SOA jakaa modulaarisen ohjelmoinnin kanssa. Palvelukeskeinen arkkitehtuuri integroi hajautettuja, erikseen ylläpidettäviä ja käyttöön otettuja ohjelmistokomponentteja. Sen mahdollistavat teknologiat ja standardit, jotka helpottavat komponenttien viestintää ja yhteistyötä verkossa, erityisesti IP-verkossa.

tämä antaa ytimekkään vastauksen siihen, mitä SOA tarkoittaa, mutta ei kuvaa syitä, miksi organisaatio haluaisi siirtyä kohti palvelukeskeistä arkkitehtuuria, tai SOA: n etuja.

myös Wikipediasta, mitä SOA tarkoittaa:

jotkut yritysarkkitehdit uskovat, että SOA voi auttaa yrityksiä reagoimaan nopeammin ja kustannustehokkaammin muuttuviin markkinaolosuhteisiin.Tämä arkkitehtuurin tyyli edistää uudelleenkäyttöä makro – (palvelu) tasolla mikro – (luokat) tasolla. Se voi myös yksinkertaistaa olemassa olevien tietoteknisten (vanhojen) omaisuuserien yhteenliittämistä ja käyttöä.

joiltakin osin SOA voidaan pitää pikemminkin arkkitehtuurin evoluutiona kuin vallankumouksena. Se tallentaa monia aiempien ohjelmistoarkkitehtuurien parhaita käytäntöjä. Esimerkiksi viestintäjärjestelmissä ei ole juurikaan kehitetty ratkaisuja, joissa todella staattisia siteitä käytetään verkon muiden laitteiden kanssa keskustelemiseen. Hyväksymällä tarkastuslausuman lähestymistavan tällaiset järjestelmät voivat asemoitua korostamaan hyvin määriteltyjen ja erittäin yhteentoimivien rajapintojen merkitystä.

poraamalla näitä käsitteitä voimme nähdä, että on olemassa joukko perusvalmiuksia, joita tarvitaan SOA: n mahdollisten hyötyjen saavuttamiseksi. Wikipedia käsittelee useita näistä ohjaavista periaatteista, joiden joukossa ovat:

• uudelleenkäyttö – kyky kapseloida ja paljastaa karkearakeiset yritystoiminnot palveluina
• Irtokytkentä-sen varmistaminen, että palvelun kuluttajat ovat riittävän abstrakteja palvelun fyysisestä toteutuksesta
• tunnistaminen ja luokittelu (löydettävyys) – sen varmistaminen, että potentiaaliset kuluttajat voivat löytää tarvitsemansa palvelut

riippumatta siitä, mitä SOA – määritelmää käytät, nämä perustavat rehtorit johtavat luonnolliseen toimintajärjestykseen, jonka organisaation on täytettävä, jotta se vähitellen ymmärtää palvelukeskeisen hyödyn arkkitehtuuri.

Katso, miksi Akana on vahva esiintyjä Forrester Wave™: API Management Solutions, Q3 2020-raportti.

Download Report

mitkä ovat seitsemän SOA-askelta?

SOA-askelia on seitsemän:

1. Create/Expose Services
2. Register Services
3. Secure Services
4. Manage (monitor) Services
5. Mediate and Virtualize Services
6. Governing the SOA
7. SOA Integration With ESB

tarkastuslausuman vaiheet 2-6 kuvaavat yritysten välisiä huolenaiheita, joihin olisi puututtava keskitetyllä tarkastuslausuman Infrastruktuurialustalla. Vaiheet 1 ja 7 käsittelevät erityistarpeita, ja ne toimitetaan usein osana olemassa olevaa yrityssovelluspinoa. Näiden vaiheiden seuraaminen johtaa organisaation oikealle tielle oivaltamaan SOA: n hyödyt. Jatka lukemista päästäksesi syvemmälle jokaiseen SOA-vaiheeseen.

Create/Expose Services

ensimmäinen askel organisaation siirtämisessä kohti SOA: ta on ilmeinen. SOA-sovellusta ei voi olla ilman palveluita, joten ensimmäinen askel on paljastaa tai luoda palveluja, joita verkkopalveluja käyttävät sovellukset voivat helposti kuluttaa.

on olemassa useita mielenkiintoisia päätöksiä, joita yritykset kohtaavat aloittaessaan tämän prosessin, eikä vähiten päätös siitä, pitäisikö olemassa olevat sovellukset rakentaa uudelleen palvelukeskeisen paradigman avulla vai paljastaa olemassa oleva sovelluslogiikka palvelukokonaisuutena. Tämä ei tietenkään ole binääripäätös, ja useimmat organisaatiot rakentavat uusia palveluita tyhjästä, usein käyttäen J2EE: tä ja / tai.net: tä, ja paljastavat myös olemassa olevien keskusyksikköjen ja muiden liiketoimintasovellusten palvelut.

on olemassa laaja valikoima erilaisia ratkaisuja yrityksille, jotka haluavat paljastaa olemassa olevat sovellukset palveluina, mukaan lukien Akanan markkinajohtaja SOLA, joka sallii keskuskoneiden CICS-sovellusten paljastaa ja kuluttaa luotettavia, turvallisia ja suorituskykyisiä palveluja.

jokaisen yrityksen, jolla on merkittävä (yli 1000 MIPS Gartnerin mukaan) investointi keskustietokoneeseen, tulisi tutkia tapoja hyödyntää paremmin tämän alustan etuja, ja niiden tulisi käyttää verkkopalveluja integroidakseen keskustietokoneensa sovellukset helposti nykyaikaisiin järjestelmiin. Akanan SOLA on tuotantotestattu asiakkailla, kuten Merrill Lynchillä, jossa se käsittelee yli 2 miljoonaa tapahtumaa päivässä yli 600 verkkopalvelusta. SOLA on ainoa tuote, joka tarjoaa keskusyksikön ohjelmoijille helppokäyttöisen, verkkopohjaisen käyttöliittymän CICS-sovellusten palvelujen paljastamiseen ja kuluttamiseen. Se sisältää sisäänrakennetun tuen edistyneille Web-palveluiden ominaisuuksille, kuten WS-Security, XML-salaus ja XML-allekirjoitus.

suurin osa perinteisistä yrityssovellusten integrointiyrityksistä (EAI) toimittaa myös versioita sovittimistaan, jotka paljastavat verkkopalvelut perinteisten patentoitujen protokolliensa sijaan. Itse asiassa monet näistä EAI alustoista ovat nousemassa uudelleen Yrityspalveluväylätuotteiksi. ESB käsittelee useita eri kysymyksiä, joista yksi on commodity data services-tyyppinen toiminto, jota käytetään Web services-rajapintojen paljastamiseen perinteisiltä sovittimilta.

mikä on verkkopalvelu?

Wikipediasta:

W3C määritteli verkkopalvelun seuraavasti: ”verkkopalvelu on ohjelmistojärjestelmä, joka on suunniteltu tukemaan yhteentoimivaa koneen ja koneen välistä vuorovaikutusta verkon yli. Siinä on käyttöliittymä, joka on kuvattu koneellisesti prosessoitavassa muodossa (erityisesti WSDL). Muut järjestelmät ovat vuorovaikutuksessa verkkopalvelun kanssa sen kuvauksen määräämällä tavalla käyttäen SOAP-viestejä, jotka tyypillisesti välitetään HTTP: llä XML-sarjan avulla yhdessä muiden verkkoon liittyvien standardien kanssa.”

tämä määritelmä on mielenkiintoinen teknisestä näkökulmasta, mutta se ei oikein pääse SOA: sta ja verkkopalveluista saatavan arvon ytimeen. Verkkopalvelujen keskeinen näkökohta on, että niiden pitäisi paljastaa liiketoimintalogiikka standardipohjaisen käyttöliittymän kautta. Yksi tärkeä näkökohta palvelun paljastamisessa tai luomisessa on sen rakeisuus. On olemassa monia eri koulukuntia siitä, mikä on palvelu (KS. edellä), mutta useimmat yritysarkkitehdit ovat samaa mieltä siitä, että jotta palvelu olisi hyödyllinen tarkastuslausumassa, sen on oltava riittävän karkearakeinen ollakseen hyödyllinen useissa eri sovelluksissa.

tämä tietenkin geelit, joissa on yksi SOA: n palvelujen perusperiaatteista – jotta palvelu voidaan käyttää uudelleen; sen on oltava yleisesti hyödyllinen ja käyttökelpoinen. Esimerkki yleisesti hyödyllisestä palvelusta voisi olla” getCustomerInfo ” – palvelu, joka palauttaa asiakkaan tiedot asiakastunnisteesta. Hienorakeisempi palvelu, joka ei välttämättä ole yleisesti hyödyllinen, voisi olla jotain tiettyä sovellusta, esimerkiksi ”setApplicationState”.

on tärkeää ottaa huomioon palvelujen rakeisuus sekä rakennettaessa uusia palveluja että paljastettaessa olemassa olevaa liiketoimintalogiikkaa palveluna. Olisi esimerkiksi helppoa ottaa CICS-liiketoimi ja altistaa useita eri palveluja erilaisten parametrien asettamiseksi ja saamiseksi, kun taas todellisuudessa karkeampi palvelu, joka paljastaa koko liiketoimen yhtenä palveluna, voisi olla paljon yleisemmin hyödyllinen ja siten arvokas.

Related Reading: selvitä, miten Akanan Sola Mainframe API tarjoaa asiakkaille nopean ja helpon prosessin mainframe-sovellusten paljastamiseksi turvallisiksi verkkopalveluiksi ja mahdollistaa mainframe-sovellusten kuluttamisen web-palveluihin.

Rekisteröidy

Ok, joten yrityksessäsi on yksi tai useampi palvelu käytettävissä. Mitä nyt?

jotta palvelua voidaan käyttää saati käyttää uudelleen, sovellusarkkitehteiden ja kehittäjien, jotka saattavat hyötyä tästä palvelusta, on tiedettävä, että se on olemassa. Tässä tulee Rekisteri. Yksinkertaisimmillaan rekisteri on pelkkä kirjastohakemisto, joka auttaa potentiaalisia palvelujen käyttäjiä löytämään palveluita, joista he voisivat olla kiinnostuneita. Rekisterin tulisi tarjota sekä haku-että selausrajapintoja, ja se tulisi järjestää loogisesti helpottamaan nopeaa ja tarkkaa palvelujen löytämistä.

nykyisessä Soa: ssa perusrekisteripalvelujen hyväksytty standardi on UDDI (Universal Discover, Description, and Integration). UDDI-spesifikaatio tarjoaa tietomallin ja joukon rajapintoja (kaikki verkkopalvelut itse) palveluiden julkaisemista ja löytämistä varten sekä lisäksi joukon rajapintoja itse rekisteripalvelimen hallintaan.

monet rekisteritoimittajat ovat vieneet rekisterin alkuperäistä käsitettä hieman pidemmälle ja käyttävät rekisteritekniikoita täydellisemmän arkiston pohjana. Rekisteritoimittajat lisäävät myös” politiikkaan ”perustuvia suodattimia julkaisutyökaluihinsa ja tarjoavat ”suunnitteluaikaisia hallintaratkaisuja”.

Akana pitää rekisteriä SOA: n keskeisenä rakennuspalikkana. Kaikki tuotteemme hyödyntävät UDDI: ta yhtenä keskusmyymälänä, joka tarjoaa arvovaltaista tietoa SOA: n palveluista. Tuotteet voivat toimia minkä tahansa UDDI-yhteensopivan rekisterin kanssa, ja Akana sisältää Oman UDDIv3-rekisteripalvelimen Palvelunhallintatuotteineen yrityksille, joilla ei vielä ole rekisteriä. Tässä suhteessa Rekisteri täyttää SOA: n roolin, jonka LDAP täytti henkilöllisyyden ja Pääsynhallintaratkaisujen osalta.

Akanan tuotteet keskittyvät ajonaikaiseen hallintoon ja hyödyntävät rekisteriä keskeisenä paikkana, jonka avulla voidaan löytää ajonaikaisia toimintatapoja, joita voidaan toteuttaa ja valvoa. Tietenkin, upotettu rekisteri on täysin toimiva UDDIv3 palvelin ja niin myös tekee ihanteellinen suunnittelu – aika palvelun arkisto.

Beyond registry on koko käytäntö-ja metatietopalvelujen käsite, joka tarjoaa SOA: n palveluihin kattavat arkistot kaikille suunnitteluajan ja suorituksen aikaisille artefakteille. Tätä konseptia käsitellään tarkemmin Akanan whitepaper the SOA Infrastructure Reference-mallissa.

varma

SOA: n ja verkkopalveluiden maailma ei ole pelkkää viiniä ja ruusuja. Olettaen, että olet nyt suorittanut vaiheet yksi ja askel, ota askel taaksepäin ja harkitse, mitä olet tehnyt. Olettaen, että olet menossa maksimaalisen liiketoiminnan arvo, olet todennäköisesti ottanut tehtävän kriittisiä sovelluksia, jaettu ne karkearakeinen palaset toiminnallisuutta, alttiina tämän toiminnallisuuden palveluina, ja sitten julkaistu nämä palvelut yleisesti saatavilla rekisteriin.

tämä kaikki voi tuntua hyvältä asialta, ja useimmissa tapauksissa se on hieno asia, mutta olet saattanut vahingossa luoda organisaatioosi ammottavia tietoturva-aukkoja ja paljastaa arkaluonteisia tietoja tai arvokkaita liiketoimia kenelle tahansa, jolla on alkeelliset Verkkopalvelutaidot. Palvelujen turvallisuuden varmistaminen tarkoittaa turvallisuuden täytäntöönpanokerroksen rakentamista palveluntarjoajille ja turvallisuuden toteutuskerroksen rakentamista palvelun kuluttajille.

hyvä tapa ymmärtää verkkopalveluiden tietoturvariskejä on muistella perinteisiä green screen-suurtietokonesovelluksia. Ainoa näiden sovellusten vaatima tietoturva oli sisäänkirjautuminen, jos pystyi käyttämään sovellusta, oli mukana. Nämä sovellukset sisälsivät samat peruskappaleet kuin nykyaikainen sovellus (käyttöliittymä, liiketoimintalogiikka, datapalvelut), mutta vain käyttöliittymä oli käytettävissä sovelluksen ulkopuolella. Verkkopalveluiden maailmassa on todennäköistä, että osa ydintietopalveluista paljastuu palveluiksi, osa bisneslogiikasta varmasti pitäisi paljastaa, eikä hakemusta ole kirjoitettu kumpaakaan näistä tukiasemista ajatellen. Tämä tarkoittaa, että on kriittistä turvata palvelut, jotka paljastat erikseen, et voi luottaa sovelluksen sisäisiin tietoihin sen oman turvallisuuden varmistamiseksi.

mitä verkkopalvelun turvaaminen siis tarkoittaa? Samat 5 tietoturvaperiaatetta, jotka pätevät muihinkin sovelluksiin, pätevät myös verkkopalveluissa:

• todennus-varmista, että tiedät palvelun pyytäjän henkilöllisyyden (ja varmista myös, että pyytäjä tietää yhteydenottamansa palvelun henkilöllisyyden). Pyyntöjen todentamiseen on olemassa useita erilaisia Verkkopalvelustandardeja, jotka vaihtelevat yksinkertaisista lähestymistavoista, kuten http-perustodentamisesta, monimutkaisempiin mekanismeihin, kuten SAML-tai X. 509-allekirjoitukseen. Hyvä Web services security työkalu pitäisi tukea kaikkia näitä eri vaihtoehtoja.
• valtuutus-varmista, että pyytäjällä on lupa käyttää pyytämäänsä palvelua tai toimintoa. Valtuutus on monimutkainen asia, ja saatavilla on useita erilaisia politiikkapäätöstuotteita. Useimmilla suuryrityksillä on olemassa oleva valtuutusratkaisu (CA SiteMinder, IBM TAM jne.), ja hyvä www-palveluiden tietoturvaratkaisu pitäisi pystyä integroimaan näihin sekä tarjoamaan omat valtuutusominaisuudet.
• Yksityisyys-varmista, että pyyntö-ja vastausviestejä ei voi lukea luvattomilla 3.osapuolilla. Tässä on XML-salauksen kaltaiset standardit, mutta XML-salauksen käyttämiseksi onnistuneesti Web services-tietoturvaratkaisun on tarjottava tehokkaat avain-ja varmennehallinta-ja jakeluominaisuudet sekä ihanteellisesti joitain asiakaspuolen työkaluja kuluttajien kehittäjien avuksi.
• kieltäytyminen-varmista, että pyynnön esittäjä ei voi kieltää pyynnön lähettämistä ja että palvelu ei voi kieltää vastauksensa lähettämistä. Tämä on XML-allekirjoituksen tehtävä, jossa on sama avainten hallinta-ja jakelumääräys kuin yksityisyydensuojassa.
• auditointi-varmistaa, että järjestelmä voi säilyttää tarpeen mukaan tarkat ja oikea-aikaiset tiedot pyynnöistä ja vastauksista.

yksi mielenkiintoinen kysymys ja keskustelun aihe, joka herää verkkopalvelujen turvallisuuden ympärillä, on se, missä tätä tietoturvaa pitäisi soveltaa. Jotkut myyjät väittävät, että turvallisuus olisi keskeinen toiminto valvotaan klusterin keskitetysti käyttöön välityspalveluja, kun taas toiset väittävät, että se olisi yksinomaan verkkotunnus palveluntarjoajan tai säiliö. Todellisuus on tietenkin jossain näiden kahden kannan välissä. Välityspalvelimella (tai valtakirjojen klusterilla) on varmasti tärkeä rooli todennus-ja uhkien havaitsemispalvelujen tarjoamisessa verkon reunalla ulkoisilta uhilta suojautumiseksi. Yhtä tärkeä rooli on myös palveluntarjoajalla tai konttipohjaisella vartioinnilla varmistaa palvelun turvallisuus viimeiseen kilometriin asti.

monilla yrityksillä on taipumus sivuuttaa tutkimus, joka osoittaa, että suurin osa tietoturvauhista on yrityksen sisäisiä, ei ulkoisia, ja siirtää siksi tietoturvan palomuurityyppiselle ratkaisulle. Akana tarjoaa korkean suorituskyvyn välityspalvelimen, joka suorittaa keskitettyjä tai verkon reunojen suojaustoimintoja, ja laajan valikoiman konttiagentteja, jotka varmistavat käyttöön otettujen palvelujen viimeisen mailin turvallisuuden.

verkkopalveluiden turvaaminen vaatii:

• Ota käyttöön täysin toimivat konteissa toimivat agentit viimeisen mailin turvallisuuden varmistamiseksi ja salaustoimintojen kuormituksen jakamiseksi
• Ota käyttöön tehokkaat verkon välittäjät reititystä ja verkon reunojen tietoturvan täytäntöönpanoa varten
• tarjoa kattava avain ja varmennehallinta ja jakelu sen varmistamiseksi, että palveluntarjoaja ja kuluttajien kehittäjät voivat menestyksekkäästi toteuttaa vaaditut turvapolitiikat
• tarjota kuluttajille kehittäjille työkaluja abstrakteihin kuluttajakehittäjiin yrityksen tietoturvan löytämisen ja toteuttamisen monimutkaisuudesta. käytännöt

aiheeseen liittyvä lukeminen: lue lisää API-tietoturvan parhaista käytännöistä.

Hallitse

kolme askelta SOA: n 7-portaiseen lähestymistapaan ja olemme alkaneet edistyä kohti todellista arvoa enterprise SOA: lta. Meillä on joitakin palveluita, ne julkaistaan rekisterissä ja potentiaaliset käyttäjät voivat löytää ne, ja olemme varmistaneet, että ne ovat turvallisia. Mitä muuta voisimme tarvita?

vastataksemme tähän kysymykseen meidän tulisi ensin tarkastella mahdollista katastrofiskenaariota. Mitä tapahtuu, kun palveluistani tulee oman menestyksensä uhreja? Ts. palvelu on tullut niin suosittu, että on olemassa useita (kymmeniä, tai satoja, tai tuhansia) erilaisia sovelluksia kuluttaa sitä ja se alkaa solki kuorman alle. Meillä on yhtäkkiä kymmeniä, satoja tai tuhansia sovelluksia, jotka epäonnistuvat tai toimivat huonosti, emmekä tiedä miksi, tai miten lopettaa se.

meidän on valvottava palvelujamme, jotta tiedämme, toimivatko ne normaalien toimintaparametrien mukaisesti, ja jotta näemme mahdolliset ongelmat ennen kuin ne ilmenevät ottamalla käyttöön kapasiteettisuunnittelumalleja.

käyttöönottamamme seurantaratkaisun pitäisi pystyä seuraamaan palvelujen perussaatavuutta, suorituskykyä (vasteaika), läpimenokykyä ja ulottumaan jopa sisältöön ja käyttäjälähtöiseen seurantaan. Sen olisi voitava seurata ja varoittaa erityisistä SLA-kynnysarvoista, ja sen olisi voitava soveltaa eri SLAs-palveluja saman palvelun tai toiminnon eri käyttäjiin.

monet myyjät määrittelevät tämän tuoteryhmän verkkopalvelujen Hallintaratkaisuksi, vaikka monet analyytikot ovat yhtä mieltä siitä, että hallinta on paljon laajempi kuin yksinkertainen seurantaratkaisu, ja sen tulisi sisältää suuri osa seuraavassa vaiheessa kuvatuista toiminnoista.

Ihannetapauksessa meidän ei tietenkään pitäisi joutua ottamaan käyttöön erillisiä turvallisuus-ja seurantaratkaisuja, koska joka kerta, kun sieppaamme viestejä välittäjän tai välittäjän kautta, lisäämme uuden suorituskyvyn pullonkaulan. Siksi Akanan palvelupäällikkö yhdistyy Verkkojohtajaan ja tarjoaa kattavan Soa-turvallisuus -, valvonta-ja hallintajärjestelmän yhdessä tehokkaassa ja helposti käyttöönotettavassa ratkaisussa.

jotkut Web services management (monitoring) myyjät sijoittavat ratkaisunsa Business Activity Monitoring (Bam) – alustoiksi, vaikka BAM on monimutkainen ratkaisu, joka vaatii integrointia moniin back-ja front-office-järjestelmiin ja tietokantoihin. Web-palvelujen vuorovaikutuksen seurantaa sisällön osalta ei tulisi pitää vaihtoehtona yrityksen BAM-ratkaisulle.

Aiheeseen Liittyvää: Lue lisää Akanan päästä päähän-API-Hallintaratkaisusta.

5. Sovittele ja virtualisoi

tässä vaiheessa näyttäisi siltä, että meidän SOA on valmis primetime. Ja niin se on, ainakin jonkin aikaa…

seuraava haasteiden sarja tapahtuu, kun SOA kypsyy. Sinun täytyy ottaa käyttöön uusia versioita palveluista, tai lisätä kapasiteettia palvelun ajamalla useita esiintymiä sitä, sinun täytyy tarjota sovelluksia käyttää tiettyjä esiintymiä palveluja, ja sinun täytyy tarjota palveluja, jotka paljastavat laajemman valikoiman erilaisia rajapintatyyppejä.

tässä kohtaa palveluvirtualisointi astuu kuvaan. Virtualisointi tuntuu monimutkaiselta, mutta todellisuus on melko yksinkertainen. Virtuaalinen palvelu on täysin uusi palvelu, jonka määrittelee oma WSDL, jolla on omat verkko-osoite-ja siirtoparametrit. Se ei toteuta mitään liiketoimintalogiikkaa; se toimii yksinkertaisesti välityspalveluna yhdelle tai useammalle fyysiselle palvelulle, reititykselle, kuormituksen tasapainottamiselle, muuntamiselle ja sovittelulle eri pyyntöviestityyppien ja standardien välillä.

vaikka virtualisoinnin käsite on pinnalta yksinkertainen, se on äärimmäisen voimakas. Se tarjoaa mahdollisuuden täysin abstrakti palvelun kuluttajille mitään suoraa tietoa fyysisen palvelun. Esimerkiksi virtuaalipalvelun kautta. Net-asiakas, joka käyttää Microsoft-toteutusta luotettavasta VIESTIPROTOKOLLASTA soap over http-ohjelmalla, voi kuluttaa tavallisen vanhan XML-palvelun, joka paljastuu IBM WebSphere MQ-sarjan kautta suurtietokonesovelluksesta. . Net-asiakas uskoisi, että se oli kommunikointia http-palvelun kanssa, joka tuki sen luotettavaa viestiprotokollaa, kun taas keskusyksikkö-sovellus uskoisi, että toinen natiivi mq-sarjan sovellus kyseli sitä.

Virtuaalipalvelut tarjoavat laajan valikoiman toimintoja:

• he voivat käyttää XML-muunnostekniikoita, jotta kuluttajat voivat jatkaa vanhan version käyttöä palvelusta, jota ei enää ole, muuttamalla pyyntö-ja vastausviestejä vanhan version ja käyttöön otetun uuden version välillä.
• he voivat valita tiettyjä toimintoja useista eri palveluista ja yhdistää ne yhdeksi toimivaksi WSDL: ksi tietylle kuluttavan sovelluksen luokalle.
• ne voivat tarjota erilaisia toimintapoliittisia vaatimuksia eri käyttäjäluokille (ts. sisäiset käyttäjät, joilla on yksi käytäntökokonaisuus ja toinen palvelun toteutus, joka pakottaa erilaiset käytäntökokonaisuudet ulkoisille kuluttajille).
• ne voivat tarjota liikenteen siltoja palveluja ja kuluttajia varten yhteensopimattomissa kuljetuksissa (esim.http ja JMS). • Ne voivat toimia välittäjinä eri standardien täytäntöönpanon tai jopa standardien versioiden välillä.
• ne voivat toimia välittäjinä eri viestityylien välillä-RSS, SOAP, REST, POX (Plain Old XML).
• ne voivat tarjota tehokkaan sisällön – tai kontekstipohjaisen reitityksen, joka tarjoaa kehittyneitä kuormitustasapainoja ja korkean käytettävyyden ominaisuuksia.

virtuaalipalvelujen lähtökohtana on, että niitä tarvitaan kaikissa reitityksissä tai muissa kehittyneissä verkkopalveluissa, ja niistä tulee nopeasti olennainen osa mitä tahansa yritystä.

Government

kun 7 vaiheesta 5 on saatu päätökseen, yritys SOA on lähes valmis lähtemään. Sinulla on nyt Turvalliset, hallinnoidut palvelut, jotka ovat laajan yleisön saatavilla luotettavasti, kuormittavasti ja helposti löydettävissä.

seuraava askel on yhdistää kaikki ensimmäisten 5 vaiheen kautta saavutetut valmiudet hallintopuitteisiin. Hallintotapa on ylikäytettyä ja paljon väärin käytettyä työtä, joten Tarkastellaanpa lyhyesti hallintotavan määritelmää. Jälleen Wikipediasta:

termi hallinto käsittelee prosesseja ja järjestelmiä, joilla organisaatio tai yhteiskunta toimii. Usein perustetaan hallitus hallinnoimaan näitä prosesseja ja järjestelmiä.

tästä määritelmästä on olennaista, että hallinnossa on kyse prosesseista ja järjestelmistä. SOA: n hallintotavan tapauksessa keskustelemme organisaatioprosesseista, kuten arkkitehtuurin arviointilautakunnasta, ja tässä blogissa käsitellyistä järjestelmistä, kuten rekisteristä, tietoturvasta ja hallintateknologioista.

SOA: n hallinto jaetaan usein kahteen erilliseen osaan, suunnitteluajan hallintoon ja ajonaikaiseen hallintoon. Suunnitteluaikana organisaatiot haluavat valvoa (hallita), millaisia palveluja voidaan julkaista, kuka voi julkaista ne, millaisia skeemoja ja viestejä nämä palvelut voivat hyväksyä, ja monia muita sääntöjä palveluista. Suoritusaikana organisaatioiden on varmistettava palvelujensa turvallisuus, luotettavuus ja suorituskyky sekä varmistettava, että palvelut ovat määriteltyjen yrityspolitiikkojen mukaisia. Suunnittelu-aika hallinto on mielenkiintoinen ja auttaa varmistamaan järjestäytyneen, hyvin suunniteltu SOA, mutta se kalpenee merkityksettömäksi verrattuna aktiivinen valvonta SOA ajonaikaisena.

Akanan palvelupäällikkö on toimialojen johtava ajonaikaisen hallinnon alusta, joka tarjoaa kattavan ratkaisun turvallisuuteen, seurantaan, hallintaan, välitykseen ja rekisteriin. Run-time governance tarjoaa olennaisilta osiltaan yhtenäisen kehyksen tässä asiakirjassa kuvattujen tarkastuslausuman eri vaiheiden soveltamisen valvomiselle ja seurannalle. Se tarjoaa yhden kokonaisvaltaisen ratkaisun, joka tarjoaa valvonnan palvelurekisteriin, turvallisuuteen, hallintaan ja sovitteluun. Hyvä ajankäytön hallintoratkaisu ilmenee eräänlaisena työpöytänä, joka tarjoaa työkaluja kaikille tarkastuslausuman aktiivisille osallistujille.

• Palvelunkehittäjä: työkalut julkaista, luokitella, määritellä metatiedot, ladata ”agentti”, virtualisoida, versio, valitse käytäntö, valitse näkyvyys/käyttöoikeudet, osallistua kapasiteetin suunnitteluun ja käyttää työnkulkua
• Service Consumer: Työkalut helpottaa palvelun löytämistä, valintaa ja pääsyä työnkulkuun
• Operations Staff: työkalut seurata palvelun suorituskykyä, vianmääritys, seurata riippuvuuksia, versiopalvelut, virtualisointi, välityspalvelun hallinta
• Security Staff: Työkalut politiikan hallinta, politiikan raportointi, vaatimustenmukaisuuden tarkistaminen, turvallisuuden valvonta
• yritysarkkitehti: Työkalut sovellusten seurantaan, suhteiden hallintaan, suunnittelupolitiikan validointiin ja määrittelyyn, palveluversion hallintaan, palvelun välityspalvelimen antamiseen, palveluvirtualisointiin
• yrityksen IT-hallinta: Reuse metric management, service reuse metrics, soa statistics

SOA-integraatio ESB: n kanssa

kun tarkastellaan viimeisten 6 askeleen tuloksia kohti SOA: ta, jäämme miettimään, mitä muuta voisi olla. Nyt meillä on joukko palveluita, jotka on julkaistu rekisterissä, turvallinen, hallittu, luotettava ja löyhästi kytketty, kaikki käärittynä vankkaan suunnitteluun ja ajonaikaiseen hallintaratkaisuun.

joidenkin yritysten viimeinen vaihe on ottaa käyttöön yksi tai useampi Yrityspalveluväylä (Enterprise Services Bus, ESB) palvelujen integroimiseksi korkeamman tason yhdistettyihin tai organisoituihin palveluihin. Nämä ESBs toimitetaan usein osana laajempaa sovelluskokonaisuutta, kuten Oracle eBusiness applications tai SAP. Joitakin erikoistuneita ESBs: iä voidaan käyttää monimutkaisten komposiittipalvelujen luomiseen, ja ne ulottuvat Liiketoimintaprosessien hallinnan (BPM) piiriin.

aiheeseen liittyvää lukemista:Lue lisää Akanan Integraatioratkaisuista.

Yrityspalveluväylä (ESB) on yhä suositumpi käsite. ESB on alun perin tarkoitettu sekä viestipohjaisten väliohjelmistojen että EAI: n (enterprise application integration) ratkaisujen kehittäjäksi, ja se tarkoittaa hyvin erilaisia asioita eri organisaatioille. Kun analyytikot, toimittajat ja asiakkaat tulevat toimeen ESB: n idean kanssa, näyttää siltä, että ESB kiteyttää 3 toiminnallista konseptia; sovittimet, jotka on otettu EAI-työkalusta varmistaakseen yhteyden vanhoihin sovelluksiin, viestipalvelut, jotka on otettu sanomalähtöisestä väliohjelmistoalustasta luotettavan toimituksen varmistamiseksi, ja prosessiorkestrointi ketterien sovellusten rakentamiseksi.

analyytikot ovat yksimielisiä siitä, että useimmat organisaatiot päätyvät useisiin ESB-alustoihin useilta toimittajilta, jotka tarjoavat palveluja omassa kontekstissaan. Tässä ympäristössä on erittäin tärkeää, että ESBs käyttää SOA: n keskitettyä infrastruktuuria varmistaakseen, että niiden paljastamissa ja kuluttamissa palveluissa noudatetaan johdonmukaisesti turvallisuus-ja sanomanvälityskäytäntöjä.

Akanan Service Manager-ja Network Director-tuotteet yhdessä tarjoavat täydellisen ratkaisun yrityksen useiden ESB-instanssien hallinnointiin ja sovitteluun.

nyt kun tiedät enemmän siitä, mitä SOA tarkoittaa ja Keskeiset SOA-askeleet, tsekkaa Akana toiminnassa!

Aloituskoe