Hva ER SOA? 7 SOA Steps

denne bloggen beskriver soa-trinnene en organisasjon må ta før den virkelig kan lykkes med å realisere kostnadene og smidighetsfordelene som tilbys av enterprise service-orientert arkitektur. Den diskuterer HVA SOA står for og de ulike stadiene AV SOA-adopsjon ved å beskrive teknologier, prosesser og beste praksis som er tilgjengelige for å hjelpe bedrifter med å lykkes i sine serviceorienterte arkitekturinitiativer.

Hva ER SOA?

TJENESTEORIENTERT arkitektur (SOA) Er en type arkitektur som brukes i programvaredesign som støtter tjenesteorientering, der tjenester leveres til andre komponenter gjennom en kommunikasjonsprotokoll over et nettverk.

Hva STÅR SOA for?

definisjonen AV SOA, som gitt Av Wikipedia:

TJENESTEORIENTERT arkitektur (SOA) Er en stil av programvaredesign der tjenester leveres til de andre komponentene av applikasjonskomponenter, gjennom en kommunikasjonsprotokoll over et nettverk. De grunnleggende prinsippene for serviceorientert arkitektur er uavhengige av leverandører, produkter og teknologier. En tjeneste er en diskret enhet av funksjonalitet som kan nås eksternt og handlet på og oppdatert uavhengig, for eksempel hente en kontoutskrift online.

en tjeneste har fire egenskaper i henhold TIL en av mange definisjoner AV SOA:

1. det representerer logisk en forretningsaktivitet med et spesifisert utfall.
2. Det er selvstendig.
3. det er en svart boks for sine forbrukere.
4. Det kan bestå av andre underliggende tjenester.

Ulike tjenester kan brukes sammen for å gi funksjonaliteten til et stort program, et prinsipp SOA deler med modulær programmering. Tjenesteorientert arkitektur integrerer distribuerte, separat vedlikeholdte og distribuerte programvarekomponenter. Det er aktivert av teknologier og standarder som letter komponentenes kommunikasjon og samarbeid over et nettverk, spesielt OVER ET IP-nettverk.

Dette gir et kortfattet svar på HVA SOA betyr, men det beskriver ikke årsakene til at en organisasjon ønsker å bevege seg mot serviceorientert arkitektur, eller fordelene MED SOA.

Også Fra Wikipedia om HVA SOA står for:

noen bedriftsarkitekter mener AT SOA kan hjelpe bedrifter å reagere raskere og mer kostnadseffektivt på endrede markedsforhold.Denne stilen av arkitektur fremmer gjenbruk på makro (tjeneste) nivå i stedet for mikro (klasser) nivå. Det kan også forenkle samtrafikk til—og bruk av—eksisterende IT (eldre) eiendeler.

I noen henseender KAN SOA betraktes som en arkitektonisk evolusjon snarere enn som en revolusjon. Den fanger opp mange av de beste praksisene fra tidligere programvarearkitekturer. I kommunikasjonssystemer har det for eksempel skjedd lite utvikling av løsninger som bruker virkelig statiske bindinger til å snakke med annet utstyr i nettverket. VED å omfavne EN SOA-tilnærming kan slike systemer posisjonere seg for å understreke betydningen av veldefinerte, svært interoperable grensesnitt.

Boring i disse konseptene kan vi se at det er et sett med grunnleggende evner som kreves for å oppnå de potensielle fordelene MED SOA. Wikipedia diskuterer en rekke av disse veiledende prinsippene, blant annet:

• Gjenbruk – evnen til å kapsle og avsløre grovkornede forretningsfunksjoner som tjenester
• Løs kobling-sikre at tjenesteforbrukerne er tilstrekkelig abstrahert fra den fysiske implementeringen av en tjeneste
• Identifikasjon og kategorisering (oppdagbarhet) – sørge for at potensielle forbrukere kan finne de tjenestene de trenger

uansett HVILKEN SOA – definisjon du bruker, vil disse grunnleggende prinsippene føre til en naturlig rekkefølge av aktiviteter en organisasjon må fullføre for å gradvis realisere Fordelene med serviceorientert arkitektur.

Se Hvorfor Akana Er En Sterk Utøver i Forrester Wave™: API Management Solutions, q3 2020 rapport.

Last Ned Rapport

Hva Er De Syv SOA-Trinnene?

det er syv SOA-trinn:

1. Opprett/Utsett Tjenester
2. Registrer Tjenester
3. Sikre Tjenester
4. Administrer (overvåk) Tjenester
5. Mediere Og Virtualisere Tjenester
6. Styr SOA
7. Soa-Integrasjon MED ESB

soa trinn 2 til 6 beskriver bekymringer på tvers av bedrifter som Bør Løses Med En Sentralisert Soa-Infrastrukturplattform. Trinn 1 og 7 adresserer spesifikke behov og leveres ofte som en del av en eksisterende enterprise application stack. Etter disse trinnene vil lede en organisasjon ned den rette veien til å realisere fordelene MED SOA. Fortsett å lese for å gå dypere inn I HVERT SOA-trinn.

Opprett / Utsett Tjenester

det første trinnet i å flytte en organisasjon mot SOA er åpenbart. DET kan ikke VÆRE NOE SOA-program uten tjenester, så det første trinnet må være å avsløre eller opprette tjenester som lett kan forbrukes av Webtjenesteaktiverte applikasjoner.

det er en rekke interessante beslutninger bedrifter står overfor når de begynner denne prosessen, ikke minst som er beslutningen om å gjenoppbygge eksisterende applikasjoner ved hjelp av et tjenesteorientert paradigme, eller å avsløre eksisterende applikasjonslogikk som et sett med tjenester. Dette er ikke en binær beslutning selvfølgelig, og de fleste organisasjoner vil bygge nye tjenester fra bunnen av, ofte ved HJELP AV J2EE OG / ELLER. NET, og vil også avsløre tjenester fra eksisterende stormaskin og andre forretningsapplikasjoner.

det finnes et bredt spekter av ulike løsninger for bedrifter som ønsker å avsløre eksisterende applikasjoner som tjenester, inkludert Akanas markedsledende SOLA, slik at mainframe CICS-applikasjoner kan avsløre og forbruke pålitelige, sikre tjenester med høy ytelse.

ethvert selskap med en betydelig (mer enn 1000 MIPS ifølge Gartner) investering i stormaskin bør undersøke måter å bedre utnytte fordelene med denne plattformen, og bør bruke Webtjenester for å enkelt integrere sine stormaskin applikasjoner med moderne systemer. AKANA ‘ S SOLA er produksjonsbevisst hos kunder som Merrill Lynch, hvor det behandler mer enn 2 millioner transaksjoner per dag fra mer enn 600 Webtjenester. SOLA ER det eneste produktet som tilbyr mainframe programmerere en enkel å bruke, Web – basert grensesnitt for å utsette og forbruker tjenester FRA CICS applikasjoner. Det inkluderer innebygd støtte for avanserte Webtjenester evner SOM WS-Security, XML-Kryptering, OG XML-Signatur.

de fleste av de tradisjonelle enterprise application integration (EAI) selskapene leverer også versjoner av sine adaptere som avslører Webtjenester i stedet for deres tradisjonelle proprietære protokoller. Faktisk mange AV DISSE eai plattformer er re-dukker Opp Som Enterprise Service Bus produkter. ESB adresserer flere forskjellige problemer, hvorav den ene er funksjonen commodity data services-typen som brukes til å vise Webtjenestegrensesnitt fra tradisjonelle adaptere.

Hva Er En Webtjeneste?

Fra Wikipedia:

i forhold TIL W3c Webtjenester definerte W3C en webtjeneste som: «en webtjeneste er et programvaresystem designet for å støtte interoperabel maskin-til-maskin-interaksjon over et nettverk. Den har et grensesnitt beskrevet i en maskin-processable format (spesielt WSDL). Andre systemer samhandler med webtjenesten på en måte som er foreskrevet av beskrivelsen ved HJELP AV SOAP-meldinger, vanligvis formidlet VED HJELP AV HTTP med EN XML-serialisering i forbindelse med andre web-relaterte standarder.»

denne definisjonen er interessant fra et teknisk perspektiv, men det kommer egentlig ikke til hjertet av verdien SOM KAN utledes FRA SOA og Webtjenester. Et grunnleggende aspekt Ved Webtjenester er at de bør avsløre forretningslogikk via et standardbasert grensesnitt. Et viktig aspekt ved å utsette eller skape en tjeneste er dens granularitet. Det er mange forskjellige tankeskoler om hva som utgjør en tjeneste (se ovenfor), men de fleste bedriftsarkitekter vil være enige om at for å være nyttig I EN SOA, må en tjeneste være tilstrekkelig grovkornet til å være nyttig for flere forskjellige applikasjoner.

Dette, Selvfølgelig, gels med en av de grunnleggende prinsippene for tjenester I SOA – for at en tjeneste som skal gjenbrukes; det må være generelt nyttig og brukbar. Et eksempel på en generelt nyttig tjeneste kan være en» getCustomerInfo » – tjeneste som vil returnere detaljer om en kunde fra en kundeidentifikator. En mer finkornet tjeneste som kanskje ikke er generelt nyttig, kan være noe spesifikt for et bestemt program, «setApplicationState» for eksempel.

det er viktig å vurdere granularitet av tjenester både når man bygger nye tjenester, og når man eksponerer eksisterende forretningslogikk som en tjeneste. For eksempel vil det være enkelt å ta EN CICS-transaksjon og avsløre flere forskjellige tjenester for å sette og få ulike parametere, mens virkeligheten er at en mer grovkornet tjeneste som avslører hele transaksjonen som en enkelt tjeneste, kan være mye mer generelt nyttig og derfor verdifull.

Relatert Lesing: Finn ut hvordan AKANAS SOLA Mainframe API gir kundene en rask og enkel prosess for å eksponere stormaskinprogrammer som sikre webtjenester, og lar stormaskinprogrammer forbruke webtjenester.

Registrer

Ok, så du har en eller flere tjenester tilgjengelig i bedriften. Hva nå?

for at en tjeneste skal kunne brukes, enn si gjenbrukes, må applikasjonsarkitekter og utviklere som kan ha nytte av denne tjenesten, vite at den eksisterer. Det er her et register kommer inn. På sitt enkleste nivå er et register ikke noe mer enn en biblioteksindeks som hjelper potensielle brukere av tjenester med å finne tjenester de kan være interessert i. Registeret bør tilby både søk og bla grensesnitt, og bør organiseres logisk for å lette rask og nøyaktig oppdagelse av tjenester.

i DAGENS SOA er den aksepterte standarden FOR grunnleggende registertjenester UDDI(Universal Discover, Description and Integration). UDDI-spesifikasjonen gir en datamodell og et sett med grensesnitt (alle Webtjenester selv) for publisering og oppdagelse av tjenester, samt et ytterligere sett med grensesnitt for styring av selve registerserveren.

Mange registerleverandører har tatt det opprinnelige begrepet register ganske mye lenger og bruker registerteknologier som grunnlag for et mer komplett depot. Registerleverandører legger også til «policy» – baserte filtre til deres publiseringsverktøy, og tilbyr «design-time governance solutions».

Akana anser registret for å være en grunnleggende byggestein AV SOA. Alle våre produkter utnytte UDDI som en enkelt sentral butikk for autoritativ informasjon om tjenestene I EN SOA. Produktene kan fungere med ET HVILKET SOM helst UDDI-kompatibelt register, Og Akana inkluderer sin Egen UDDIv3-registerserver med Sitt Service Manager-produkt for selskaper som ikke allerede har et register. I denne forbindelse fyller registret rollen FOR SOA SOM LDAP fylte For Identitets-og Tilgangsstyringsløsninger.

Akanas produkter fokuserer på styring av kjøring og utnytter registeret som et sentralt sted for å finne retningslinjer for kjøring for å implementere og håndheve. Selvfølgelig er den innebygde registret fullt funksjonell UDDIv3 server og så gjør også en ideell design – time service repository.

Utover registry er hele konseptet med policy og metadata tjenester som gir omfattende repositories for alle design-tid og run-time artefakter for tjenestene I SOA. Dette konseptet er dekket mer detaljert I Akanas whitepaper SOA Infrastructure Reference Model.

Sikker

verden AV SOA Og Webtjenester er ikke bare vin og roser. Forutsatt at du nå har fullført trinn ett og trinn, ta et skritt tilbake og vurder hva du har gjort. Forutsatt at du går for maksimal forretningsverdi, vil du sannsynligvis ha tatt virksomhetskritiske applikasjoner, brutt dem ned i grovkornede stykker funksjonalitet, utsatt denne funksjonaliteten som tjenester, og deretter publisert disse tjenestene til et universelt tilgjengelig register.

Dette kan alle virke som en god ting, og i de fleste tilfeller er det en stor ting, men du kan ha utilsiktet opprettet noen gapende sikkerhetshull i organisasjonen og utsatt sensitiv informasjon, eller høy verdi transaksjoner til alle med rudimentære Webtjenester ferdigheter. Å sikre sikkerheten til tjenestene betyr å bygge et sikkerhetshåndhevelseslag hos tjenesteleverandørene, og et sikkerhetsimplementeringslag hos tjenesteforbrukerne.

en god måte å forstå sikkerhetsrisikoen med Webtjenester er å tenke tilbake til tradisjonelle grønne skjerm mainframe-applikasjoner. Den eneste sikkerheten som kreves av disse programmene var påloggingssikkerhet, hvis du kunne få tilgang til programmet, du var i. Disse programmene inneholdt de samme grunnleggende delene som en moderne applikasjon (grensesnitt, forretningslogikk, datatjenester), men bare grensesnittet var tilgjengelig utenfor applikasjonen. I Verden Av Webtjenester er det sannsynlig at noen av kjernedatatjenestene vil bli utsatt som tjenester, noe av forretningslogikken bør absolutt bli utsatt, og søknaden ble ikke skrevet med noen av disse tilgangspunktene i tankene. Dette betyr at det er viktig å sikre tjenestene du utsetter individuelt, du kan ikke stole på internals av programmet for å sikre sin egen sikkerhet.

så hva betyr det å sikre En Webtjeneste? De samme 5 sikkerhetsprinsippene som gjelder for andre applikasjoner, gjelder Også For Webtjenester:

• Autentisering-sørg for at du kjenner identiteten til den som ber om tjenesten(og sørg også for at den som ber vet identiteten til tjenesten den kontakter). Det finnes flere Forskjellige webtjenester standarder for godkjenning av forespørsler, alt fra enkle tilnærminger som http enkel godkjenning, til mer komplekse mekanismer som SAML eller X. 509 signatur. Et godt sikkerhetsverktøy For Webtjenester bør støtte alle disse ulike alternativene.
• Autorisasjon-kontroller at forespørgeren er autorisert til å få tilgang til tjenesten eller operasjonen den ber om. Autorisasjon er et komplekst problem, og det er mange ulike politiske beslutningsprodukter tilgjengelig. De fleste store bedrifter vil ha en eksisterende løsning for autorisasjon (CA SiteMinder, IBM TAM, ETC), og en god Sikkerhetsløsning For Webtjenester skal kunne integreres med disse, samt gi egne autorisasjonsfunksjoner.
• Personvern-sørg for at forespørsler og svarmeldinger ikke kan leses av uautoriserte 3. parter. Det er her standarder som XML-Kryptering kommer til sin rett, men For å kunne bruke XML-Kryptering, Må Sikkerhetsløsningen For Webtjenester gi effektiv nøkkel – og sertifikatadministrasjon og distribusjon, og ideelt sett noen klientverktøy for å hjelpe forbrukerutviklere.
• Ikke-Avvisning-sørg for at forespørgeren ikke kan nekte å sende en forespørsel og sikre at tjenesten ikke kan nekte å sende svaret. DETTE er ROLLEN SOM XML-Signatur, med samme nøkkelbehandling og distribusjon som for personvern.
• Revisjon-sikre at systemet kan opprettholde en nøyaktig og rettidig registrering av forespørsel og svar etter behov.

et interessant spørsmål, og poenget med debatt, som oppstår rundt Webtjenester sikkerhet er der denne sikkerheten skal brukes. Noen leverandører vil hevde at sikkerhet skal være en sentral funksjon håndhevet gjennom en klynge av sentralt distribuerte proxyer, mens andre vil hevde at det skal være utelukkende domenet til tjenesteleverandøren eller beholderen. Virkeligheten er selvfølgelig et sted mellom disse to stillingene. Det er absolutt en viktig rolle for en proxy (eller klynge av proxyer) i å tilby autentiserings-og trusseldeteksjonstjenester på kanten av nettverket for å beskytte mot eksterne trusler. Det er også en like viktig rolle for leverandør eller containerbasert sikkerhet for å sikre sikkerheten til tjenesten til den siste milen.

mange bedrifter har en tendens til å overse forskningen som viser at flertallet av sikkerhetstrusler er interne for bedriften, ikke eksterne, og derfor delegerer sikkerhet til en brannmur type løsning. Akana tilbyr en høy ytelse proxy som utfører sentraliserte eller nettverk kanten sikkerhetsfunksjoner, og et bredt spekter av i container agenter for å sikre den siste mil sikkerhet for distribuerte tjenester.

Sikring Av Webtjenester krever:

• Distribuer fullt funksjonelle beholderagenter for å sikre siste mils sikkerhet og distribuere belastningen av kryptografiske operasjoner
• Distribuer nettverksformidlere med høy ytelse for ruting og sikkerhetshåndhevelse for nettverkskanter
• Gi omfattende nøkkel-og sertifikatadministrasjon og distribusjon For å sikre at tjenesteleverandør-og forbrukerutviklere kan implementere nødvendige sikkerhetspolicyer
• Gi forbrukerutviklerverktøysett til abstrakte forbrukerutviklere fra kompleksiteten ved å oppdage og implementere bedriftssikkerhet policyer

Relatert Lesing: Finn ut mer om ANBEFALTE FREMGANGSMÅTER FOR API-Sikkerhet.

Administrer

Tre trinn i 7-trinns tilnærming TIL SOA, og vi begynner å gjøre noen fremskritt mot å oppnå reell verdi fra enterprise SOA. Vi har noen tjenester, de er publisert i et register og kan oppdages av potensielle brukere, og vi har sørget for at de er sikre. Hva annet kan vi muligens trenger?

for å svare på dette spørsmålet bør vi først se på et potensielt katastrofescenario. Hva skjer når mine tjenester blir ofre for sin egen suksess? Dvs. en tjeneste har blitt så populær at det er flere (tiere eller hundrevis eller tusenvis) forskjellige applikasjoner som bruker det, og det begynner å spenne under lasten. Vi har plutselig tiere, eller hundrevis eller tusenvis av applikasjoner som feiler eller utfører dårlig, og vi vet ikke hvorfor, eller hvordan vi skal stoppe det.

vi må overvåke våre tjenester slik at vi vet om de utfører innenfor normale driftsparametere, og slik at vi ser potensielle problemer før de oppstår ved å implementere kapasitetsplanleggingsmodeller.

overvåkingsløsningen vi distribuerer, skal kunne overvåke tjenester for grunnleggende tilgjengelighet, ytelse (responstid), gjennomstrømning og til og med utvide til innhold og brukerbasert overvåking. Den skal kunne overvåke og varsle om bestemte SLA-terskler, og skal kunne bruke forskjellige Sla-Er til forskjellige brukere av samme tjeneste eller operasjon.

mange leverandører definerer denne produktkategorien som En Administrasjonsløsning For Webtjenester, selv om mange analytikere er enige om at ledelsen er mye bredere enn en enkel overvåkingsløsning, og bør inkludere mye av funksjonaliteten beskrevet i neste trinn.

Ideelt sett bør vi selvfølgelig ikke distribuere separate løsninger for sikkerhet og overvåking fordi hver gang vi avskjærer meldinger gjennom og agent eller mellommann, legger vi til en annen flaskehals for ytelse. Dette er grunnen Til At Akana Service Manager kombinerer Med Network Director for å gi en omfattende SOA sikkerhet, overvåking og administrasjonsplattform i en enkelt, høy ytelse, enkel å distribuere løsning.

noen Web services management (monitoring) leverandører posisjonerer sine løsninger Som Business Activity Monitoring (Bam) plattformer, SELV OM BAM er en kompleks løsning som krever integrasjon med mange back-og front-office systemer og databaser. Overvåking av Interaksjoner På Nettjenester for innhold bør ikke betraktes som et alternativ til en BAM-løsning for bedrifter.

Relatert Lesing: Finn ut mer Om Akanas Ende-TIL-Ende API Management-Løsning.

5. Mediere Og Virtualisere

På dette punktet ser det ut til at VÅR SOA er klar for primetime. Og så er det, for en stund i det minste…

det neste settet med utfordringer oppstår når SOA modnes. Du må introdusere nye versjoner av tjenester, eller øke kapasiteten til en tjeneste ved å kjøre flere forekomster av den, du må klargjøre programmer for å bruke bestemte forekomster av tjenester, og du må tilby tjenester som viser et bredere spekter av forskjellige grensesnittyper.

det er her tjenestevirtualisering kommer inn. Virtualisering virker komplisert, men virkeligheten er ganske enkel. En virtuell tjeneste er en helt ny tjeneste, definert AV sin EGEN WSDL, med egen nettverksadresse og transportparametere. Det implementerer ikke noen forretningslogikk; det fungerer bare som en proxy til en eller flere fysiske tjenester, ruting, lastbalansering, transformering og formidling mellom ulike forespørselsmeldingstyper og standarder.

mens det er enkelt på overflaten, er begrepet virtualisering ekstremt kraftig. Det gir muligheten til å fullt abstrakt service forbrukere fra enhver direkte kunnskap om den fysiske tjenesten. FOR eksempel, gjennom en virtuell tjeneste, KAN EN. NET-klient som bruker En microsoft-implementering av en pålitelig meldingsprotokoll MED SOAP over http, forbruke en vanlig GAMMEL XML-tjeneste eksponert via IBM WebSphere MQ-serien fra et stormaskinprogram. NET-klienten ville tro at det var kommunikasjon med en http-tjeneste som støttet sin pålitelige meldingsprotokoll, mens mainframe-applikasjonen ville tro at den ble spurt av en annen innfødt MQ-serieapplikasjon.

Virtuelle tjenester tilbyr et bredt spekter av funksjonalitet:

• DE kan bruke XML-transformasjonsteknologier for å la forbrukerne fortsette å bruke en gammel versjon av en tjeneste som ikke lenger eksisterer, ved å transformere forespørsler og svarmeldinger mellom den gamle versjonen og den nye versjonen som er distribuert.
• De kan velge spesifikke operasjoner fra flere forskjellige tjenester og kombinere dem til en enkelt funksjonell WSDL for en bestemt klasse av forbrukerprogram.
• De kan gi ulike policykrav for ulike klasser av brukere (dvs. interne brukere med ett policysett og en annen implementering av tjenesten som håndhever et annet policysett for eksterne forbrukere).
• De kan tilby transport bro for tjenester og forbrukere på inkompatible transporter(f. eks http og JMS). * De kan formidle mellom ulike standarder implementering eller versjoner av standarder.
• De kan formidle mellom ulike meldingsstiler-RSS, SOAP, REST, POX (Vanlig GAMMEL XML).
• De kan tilby kraftig innhold – eller kontekstbasert ruting for å levere avansert lastbalansering og funksjoner med høy tilgjengelighet.

bunnlinjen med virtuelle tjenester er at de kreves for ruting eller andre avanserte Webtjenester, og vil raskt bli en viktig del AV enhver bedrift SOA.

Styr

med 5 av 7 trinn fullført, er enterprise SOA ganske klar til å gå. Du har nå sikre, administrerte tjenester som er tilgjengelige for et bredt publikum på en pålitelig, belastningsbalansert måte og er lett å oppdage.

det neste trinnet er å knytte sammen alle evner som leveres gjennom de første 5 trinnene med et styringsrammeverk. Styring er et overused og mye misbrukt arbeid, så la oss kort se på en definisjon av styring. Igjen fra Wikipedia:

begrepet styring omhandler prosessene og systemene som en organisasjon eller samfunn opererer med. Ofte etableres en regjering for å administrere disse prosessene og systemene.

hovedpoenget å ta fra denne definisjonen er at styring handler om prosesser og systemer. NÅR DET gjelder SOA-styring, diskuterer vi organisatoriske prosesser som et arkitekturvurderingsbord, og systemer som registret, sikkerhet og ledelsesteknologier diskutert i denne bloggen.

Styring for SOA er ofte delt inn i to separate deler, design-time governance og run-time governance. På designtidspunktet vil organisasjoner kontrollere (styre) hvilke typer tjenester som kan publiseres, hvem som kan publisere dem, hvilke typer skjemaer og meldinger disse tjenestene kan godta, og en rekke andre regler om tjenester. Ved kjøring må organisasjoner sørge for sikkerheten, påliteligheten og ytelsen til tjenestene sine, og må sørge for at tjenestene overholder definerte bedriftspolicyer. Design – time governance er interessant og bidrar til å sikre en organisert, godt utformet SOA, men det blekner til ubetydelighet i forhold til aktiv kontroll AV SOA på kjøretid.

Akana Service Manager Er industriens ledende run-time governance plattform, og tilbyr en omfattende løsning for sikkerhet, overvåking, ledelse, mekling og register. Run-time governance gir i hovedsak et enkelt rammeverk for å kontrollere og overvåke anvendelsen AV DE ulike trinnene TIL SOA beskrevet i dette dokumentet. Det gir en enkelt overordnet løsning som gir tilsyn i tjenesten register, sikkerhet, ledelse og mekling. En god løsning for styring av kjøring vil manifestere seg som en form for arbeidsbenk som gir verktøy for alle de aktive deltakerne i EN SOA.

• Tjenesteutvikler: verktøy for å publisere, kategorisere, definere metadata, laste ned «agent», virtualisere, versjon, velge policy, velge synlighet/tilgangsrettigheter, delta i kapasitetsplanlegging og tilgangsflyt
• Tjenestekonsument: Verktøy for å lette tjenesteoppdagelse, utvalg og tilgangsflyt
• Driftspersonell: Verktøy for å overvåke tjenesteytelse, feilsøke problemer, overvåke avhengigheter, versjonstjenester, virtualisering, proxyadministrasjon
• Sikkerhetspersonell: Verktøy for policyadministrasjon, policyrapportering, samsvarskontroll, sikkerhetsrevisjon
• bedriftsarkitekt: Verktøy for applikasjonsovervåking, relasjonsstyring, validering av designpolicy og definisjon, service version management, service to proxy assignment, service virtualization
• Enterprise IT Management: Gjenbruk metric management, service reuse metrics, SOA statistics

SOA Integrasjon med ESB

Ser tilbake på resultatene fra de siste 6 trinnene mot EN SOA, er vi igjen lurer på hva annet kan det muligens være. Nå har vi et sett av tjenester som er publisert i et register, sikker, administrert, pålitelig og løst koblet, alt pakket inn i en solid design og run-time governance løsning.

det siste trinnet for noen bedrifter er å distribuere En Eller FLERE Enterprise Services Bus (ESB) implementeringer for å integrere tjenester i kompositt-eller orkestrerte tjenester på høyere nivå. Disse Esb-ene vil ofte bli levert som en del av en bredere applikasjonspakke, for Eksempel Oracle eBusiness applications eller SAP. Noen spesialiserte ESBs kan brukes til å lage komplekse sammensatte tjenester, og vil strekke Seg inn i riket Av Business Process Management (Bpm).

Relatert Lesing:Finn ut mer Om Akanas Integrasjonsløsninger.

Enterprise Service Bus (ESB) er et stadig mer populært konsept. OPPRINNELIG tenkt som utviklingen av både meldingsorientert mellomvare og eai (enterprise application integration) løsninger, BETYR ESB svært forskjellige ting for ulike organisasjoner. Som analytikere, leverandører og kunder kommer til uttrykk med ideen OM EN ESB, ser DET ut TIL at EN ESB innkapsler 3 funksjonelle konsepter; adaptere tatt fra ET eai-verktøy for å sikre tilkobling med eldre applikasjoner, meldingstjenester hentet fra en meldingsorientert mellomvareplattform for å sikre pålitelig levering, og prosessorganisering for å bygge smidige applikasjoner.

konsensus blant analytikere er at de fleste organisasjoner vil ende opp med flere ESB-plattformer fra flere leverandører, og tilby tjenester i sin egen sammenheng. I dette miljøet er Det avgjørende at Esb-ene bruker en sentral soa-infrastruktur for å sikre konsekvent overholdelse av sikkerhets-og meldingspolicyer for tjenestene de eksponerer og forbruker.

Akanas Service Manager Og Network Director-Produkter kombineres for å gi en komplett løsning for styring av og mekling mellom FLERE ESB-forekomster i et foretak.

Nå som Du vet mer om HVA SOA står for og nøkkelen SOA trinn, sjekk Ut Akana i aksjon!

Start Prøve