hvad er SOA? 7 SOA-trin

denne blog beskriver de SOA-trin, en organisation skal tage, før den virkelig kan få succes med at realisere de omkostnings-og smidighedsfordele, der tilbydes af enterprise serviceorienteret arkitektur. Den diskuterer, hvad SOA står for, og de forskellige faser af SOA-adoption ved at beskrive teknologierne, processer, og bedste praksis til rådighed for at hjælpe virksomheder med at få succes i deres serviceorienterede arkitekturinitiativer.

hvad er SOA?

serviceorienteret arkitektur (SOA) er en type arkitektur, der bruges i programdesign, der understøtter serviceorientering, hvorved tjenester leveres til andre komponenter gennem en kommunikationsprotokol over et netværk.

Hvad står SOA for?

definitionen af SOA, som leveres af SOA:

serviceorienteret arkitektur (SOA) er en stil af programdesign, hvor tjenester leveres til de andre komponenter af applikationskomponenter gennem en kommunikationsprotokol over et netværk. De grundlæggende principper for serviceorienteret arkitektur er uafhængige af leverandører, produkter og teknologier. En tjeneste er en diskret enhed af funktionalitet, der kan tilgås eksternt og handlet på og opdateret uafhængigt, såsom at hente et kreditkort erklæring online.

en tjeneste har fire egenskaber i henhold til en af mange definitioner af SOA:

1. det repræsenterer logisk en forretningsaktivitet med et bestemt resultat.
2. det er selvstændigt.
3. det er en sort boks til sine forbrugere.
4. det kan bestå af andre underliggende tjenester.

forskellige tjenester kan bruges sammen for at give funktionaliteten af et stort program, et princip SOA deler med modulær programmering. Serviceorienteret arkitektur integrerer distribuerede, separat vedligeholdte og implementerede programmelkomponenter. Det er aktiveret af teknologier og standarder, der letter komponenternes kommunikation og samarbejde over et netværk, især over et IP-netværk.

dette giver et kortfattet svar på, hvad SOA betyder, men det beskriver ikke grundene til, at en organisation ønsker at bevæge sig mod serviceorienteret arkitektur eller fordelene ved SOA.

om hvad SOA står for:

nogle virksomhedsarkitekter mener, at SOA kan hjælpe virksomheder med at reagere hurtigere og mere omkostningseffektivt på ændrede markedsforhold.Denne arkitekturstil fremmer genbrug på makro (service) niveau snarere end mikro (klasser) niveau. Det kan også forenkle sammenkobling til—og brug af-eksisterende it (ældre) aktiver.

i nogle henseender kunne SOA betragtes som en arkitektonisk udvikling snarere end som en revolution. Det indfanger mange af de bedste fremgangsmåder fra tidligere arkitekturer. I kommunikationssystemer har for eksempel lidt udvikling af løsninger, der bruger virkelig statiske bindinger til at tale med andet udstyr i netværket, fundet sted. Ved at omfavne en SOA-tilgang kan sådanne systemer positionere sig for at understrege vigtigheden af veldefinerede, meget interoperable grænseflader.

boring i disse begreber kan vi se, at der er et sæt grundlæggende funktioner, der kræves for at opnå de potentielle fordele ved SOA. Vi diskuterer en række af disse vejledende principper, blandt hvilke er:

• genbrug – evnen til at indkapsle og eksponere grovkornede forretningsfunktioner som tjenester
• løs kobling-sikring af, at serviceforbrugere er tilstrækkeligt abstraheret fra den fysiske implementering af en tjeneste
• identifikation og kategorisering (opdagelighed) – at sikre, at potentielle forbrugere kan finde de tjenester, de har brug for

uanset hvilken SOA – definition du bruger, er disse grundlæggende principper føre til en naturlig rækkefølge af aktiviteter, som en organisation skal gennemføre for trinvist at realisere fordelene ved serviceorienteret arkitektur.

se, hvorfor Akana er en stærk Performer i Forrester-bølgen, HR: API Management Solutions, 3.kvartal 2020-rapport.

Hent rapport

Hvad er de syv SOA trin?

der er syv SOA trin:

1. Opret/Udsæt tjenester
2. registrer tjenester
3. sikre tjenester
4. Administrer (monitor) tjenester
5. mægle og virtualisere tjenester
6. styr SOA
7. SOA Integration med ESB

soa trin 2 til 6 beskriver problemer på tværs af virksomheder, der skal løses med en centraliseret SOA-infrastrukturplatform. Trin 1 og 7 adresserer specifikke behov og leveres ofte som en del af en eksisterende enterprise application stack. Efter disse trin vil føre en organisation ned den rigtige vej til at realisere fordelene ved SOA. Fortsæt med at læse for at gå dybere ind i hvert SOA-trin.

Opret/Udsæt tjenester

det første skridt i at flytte en organisation mod SOA er indlysende. Der kan ikke være nogen SOA-applikation uden tjenester, så det første skridt skal være at afsløre eller oprette tjenester, der let kan forbruges af applikationer, der er aktiveret på internettet.

der er en række interessante beslutninger, som virksomheder står over for, når de begynder denne proces, ikke mindst beslutningen om at genopbygge eksisterende applikationer ved hjælp af et serviceorienteret paradigme eller at afsløre eksisterende applikationslogik som et sæt tjenester. Dette er naturligvis ikke en binær beslutning, og de fleste organisationer vil bygge nye tjenester fra bunden, ofte ved hjælp af J2EE og/eller.net, og vil også udsætte tjenester fra eksisterende mainframe og andre forretningsapplikationer.

der er en bred vifte af forskellige løsninger til virksomheder, der ønsker at eksponere eksisterende applikationer som tjenester, herunder Akanas markedsledende SOLA, der giver mainframe CICS-applikationer mulighed for at eksponere og forbruge pålidelige, sikre, højtydende tjenester.

enhver virksomhed med en betydelig (mere end 1000 MIP ‘ er ifølge Gartner) investering i mainframe bør undersøge måder til bedre at udnytte fordelene ved denne platform og bør bruge internettjenester til let at integrere deres mainframe-applikationer med moderne systemer. Akanas SOLA er produktionstestet hos kunder som Merrill Lynch, hvor den behandler mere end 2 millioner transaktioner om dagen fra mere end 600 internettjenester. SOLA er det eneste produkt, der tilbyder mainframe-programmører en brugervenlig, internetbaseret grænseflade til at udsætte og forbruge tjenester fra CICS-applikationer. Det omfatter indbygget understøttelse af avancerede funktioner til internettjenester som f.eks.

de fleste af de traditionelle Enterprise application integration (EAI) virksomheder leverer også versioner af deres adaptere, der udsætter internettjenester snarere end deres traditionelle proprietære protokoller. Faktisk er mange af disse EAI-platforme genopstået som Enterprise Service Bus-produkter. ESB adresserer flere forskellige problemer, hvoraf den ene er funktionen commodity data services type, der bruges til at afsløre grænseflader til internettjenester fra traditionelle adaptere.

Hvad er en hjemmeside?

:

i forbindelse med V3C-tjenester definerede V3C en internettjeneste som: “en internettjeneste er et system designet til at understøtte interoperabel maskine-til-maskine-interaktion over et netværk. Det har en grænseflade beskrevet i et maskinbehandlbart format (specifikt VSDL). Andre systemer interagerer med internettjenesten på en måde, der er foreskrevet i dens beskrivelse ved hjælp af SOAP-beskeder, typisk formidlet ved hjælp af HTTP med en serialisering i forbindelse med andre internetrelaterede standarder.”

denne definition er interessant fra et teknisk perspektiv, men det kommer ikke rigtig til hjertet af den værdi, der kan udledes af SOA og internettjenester. Et grundlæggende aspekt af internettjenester er, at de skal afsløre forretningslogik via en standardbaseret grænseflade. Et vigtigt aspekt ved at udsætte eller oprette en tjeneste er dens granularitet. Der er mange forskellige tankeskoler om, hvad der udgør en tjeneste (Se ovenfor), men de fleste virksomhedsarkitekter er enige om, at en tjeneste skal være tilstrækkelig grovkornet til at være nyttig til flere forskellige applikationer for at være nyttig i en SOA.

dette geler naturligvis med en af de grundlæggende principper for tjenester i SOA – for at en service kan genbruges; det skal generelt være nyttigt og brugbart. Et eksempel på en generelt nyttig tjeneste kan være en “getCustomerInfo” – tjeneste, der returnerer detaljer om en kunde fra en kundeidentifikator. En mere finkornet tjeneste, der måske ikke er generelt nyttig, kan være noget specifikt for en bestemt applikation, “setApplicationState” for eksempel.

det er vigtigt at overveje granularitet af tjenester både når man bygger nye tjenester, og når man udsætter eksisterende forretningslogik som en service. For eksempel ville det være let at tage en CICS-transaktion og udsætte flere forskellige tjenester for at indstille og få forskellige parametre, mens virkeligheden er, at en mere grovkornet tjeneste, der udsætter hele transaktionen som en enkelt tjeneste, kan være meget mere generelt nyttig og derfor værdifuld.

relateret læsning: Find ud af, hvordan Akanas sola Mainframe API giver kunderne en hurtig og nem proces til at eksponere mainframe-applikationer som sikre internettjenester, og giver mainframe-applikationer mulighed for at forbruge internettjenester.

registrer

Ok, så du har en eller flere tjenester tilgængelige i din virksomhed. Hvad nu?

for at en tjeneste kan bruges, endsige genbruges, skal applikationsarkitekter og udviklere, der kan drage fordel af denne service, vide, at den findes. Det er her et register kommer ind. På det enkleste niveau er et register intet andet end et biblioteksindeks, der hjælper potentielle brugere af tjenester med at finde tjenester, de måske er interesseret i. Registreringsdatabasen skal tilbyde både søge-og gennemse grænseflader og bør organiseres logisk for at lette hurtig og nøjagtig opdagelse af tjenester.

i dagens SOA er den accepterede standard for grundlæggende registreringstjenester UDDI (Universal Discover, Description og Integration). UDDI-specifikationen indeholder en datamodel og et sæt grænseflader (alle internettjenester selv) til udgivelse og opdagelse af tjenester samt et yderligere sæt grænseflader til styring af selve registerserveren.

mange registerleverandører har taget det oprindelige koncept med registreringsdatabasen ganske lidt længere og bruger registerteknologier som base for et mere komplet lager. Registreringsleverandører tilføjer også” politik “-baserede filtre til deres udgivelsesværktøjer og tilbyder”design-time governance solutions”.

Akana anser registry for at være en grundlæggende byggesten for SOA. Alle vores produkter udnytter UDDI som en enkelt central butik for autoritativ information om tjenesterne i en SOA. Produkterne kan fungere med ethvert UDDI-kompatibelt register, og Akana inkluderer sin egen UDDIv3-registerserver med sit Service Manager-produkt til virksomheder, der ikke allerede har et register. I denne henseende udfylder registry rollen for SOA, som LDAP udfyldte for identitets-og Adgangsstyringsløsninger.

Akanas produkter fokuserer på run-time governance og udnytter registreringsdatabasen som et centralt sted at finde run-time-politikker til implementering og håndhævelse. Selvfølgelig, den integrerede registreringsdatabasen er fuldt funktionel UDDIv3 server og så også gør en ideel design-tid Service repository.

Beyond registry er hele konceptet med politik-og metadatatjenester, der leverer omfattende arkiver til alle design-tid og kørselstid artefakter til tjenesterne i SOA. Dette koncept er dækket mere detaljeret i Akanas hvidbog the SOA Infrastructure Reference Model.

sikker

verden af SOA og internettjenester er ikke alle vin og roser. Forudsat at du nu har gennemført trin et og trin, skal du tage et skridt tilbage og overveje, hvad du har gjort. Forudsat at du går efter maksimal forretningsværdi, har du sandsynligvis taget missionskritiske applikationer, opdelt dem i grovkornede stykker funktionalitet, udsat denne funktionalitet som tjenester og derefter offentliggjort disse tjenester til et universelt tilgængeligt register.

dette kan alle synes som en god ting, og i de fleste tilfælde er det en stor ting, men du kan have uforvarende skabt nogle Gabende sikkerhedshuller i din organisation og udsat følsomme oplysninger, eller høj værdi transaktioner til alle med rudimentære tjenester færdigheder. Sikring af Tjenesternes sikkerhed betyder opbygning af et sikkerhedshåndhævelseslag hos tjenesteudbyderne og et sikkerhedsimplementeringslag hos serviceforbrugerne.

en god måde at forstå sikkerhedsrisiciene med internettjenester er at tænke tilbage på traditionelle mainframe-applikationer med grøn skærm. Den eneste sikkerhed, der kræves af disse programmer var login sikkerhed, hvis du kunne få adgang til programmet, du var i. Disse applikationer indeholdt de samme grundlæggende stykker som en moderne applikation (interface, forretningslogik, datatjenester), men kun grænsefladen var tilgængelig uden for applikationen. I en verden af internettjenester er det sandsynligt, at nogle af kernedatatjenesterne vil blive eksponeret som Tjenester, noget af forretningslogikken skal bestemt udsættes, og applikationen blev ikke skrevet med nogen af disse adgangspunkter i tankerne. Dette betyder, at det er afgørende at sikre de tjenester, du udsætter individuelt, du kan ikke stole på applikationens interne for at sikre sin egen sikkerhed.

så hvad betyder det at sikre en internettjeneste? De samme 5 principper for sikkerhed, der gælder for andre applikationer, gælder også for internettjenester:

• godkendelse-sørg for, at du kender identiteten af serviceanmoderen (og sørg også for, at anmoderen kender identiteten på den tjeneste, Den kontakter). Der er flere forskellige standarder for internettjenester til godkendelse af anmodninger, lige fra enkle tilgange som http basic authentication til mere komplekse mekanismer som SAML eller 509 signatur. Et godt sikkerhedsværktøj til internettjenester skal understøtte alle disse forskellige muligheder.
• autorisation – sørg for, at anmoderen er autoriseret til at få adgang til den tjeneste eller operation, den anmoder om. Autorisation er et komplekst problem, og der er mange forskellige politiske beslutningsprodukter tilgængelige. De fleste store virksomheder vil have en eksisterende løsning til godkendelse (CA SiteMinder, IBM TAM osv.), og en god sikkerhedsløsning til internettjenester skal være i stand til at integrere med disse samt give sine egne autorisationsfunktioner.
• privatliv – sørg for, at anmodnings-og svarmeddelelser ikke kan læses af uautoriserede 3.parter. Det er her standarder som kryptering kommer til deres ret, men for at kunne bruge kryptering, skal Sikkerhedsløsningen give effektiv nøgle-og certifikatstyring og distributionsfunktioner og ideelt set nogle klientsideværktøjer til at hjælpe forbrugerudviklere.
• ikke-afvisning – sørg for, at anmoderen ikke kan nægte at sende en anmodning, og sørg for, at tjenesten ikke kan nægte at sende sit svar. Dette er rollen som en signatur med den samme nøgleadministration og distributionsbestemmelse som for privatlivets fred.
• revision – sørg for, at systemet kan opretholde en nøjagtig og rettidig registrering af anmodning og svar efter behov.

et interessant spørgsmål og debatpunkt, der opstår omkring sikkerhed for internettjenester, er, hvor denne sikkerhed skal anvendes. Nogle leverandører vil hævde, at sikkerhed skal være en central funktion, der håndhæves gennem en klynge af centralt implementerede fuldmagter, mens andre vil hævde, at det udelukkende skal være tjenesteudbyderens eller containerens domæne. Virkeligheden er selvfølgelig et sted mellem disse to positioner. Der er bestemt en vigtig rolle for en fuldmagt (eller klynge af fuldmagter) i at levere autentificerings-og trusseldetekteringstjenester i kanten af netværket for at beskytte mod eksterne trusler. Der er også en lige så vigtig rolle for udbyder-eller containerbaseret sikkerhed for at sikre tjenestens sikkerhed til den sidste kilometer.

mange virksomheder har en tendens til at overse den forskning, der viser, at størstedelen af sikkerhedstrusler er interne for virksomheden, ikke eksterne, og derfor delegerer sikkerhed til en brandvægs type løsning. Akana tilbyder en højtydende fuldmagt, der udfører centraliserede sikkerhedsfunktioner eller netværkskant, og en bred vifte af containeragenter for at sikre den sidste kilometer sikkerhed for implementerede tjenester.

sikring af internettjenester kræver:

• Implementer fuldt funktionelle containeragenter for at sikre sidste kilometer sikkerhed og distribuere belastningen af kryptografiske operationer
• Implementer højtydende netværksmæglere til routing og netværkskantsikkerhedshåndhævelse
• Giv omfattende nøgle-og certifikatstyring og distribution for at sikre, at tjenesteudbyder og forbrugerudviklere med succes kan implementere de krævede sikkerhedspolitikker
• Giv værktøjssæt til forbrugerudviklere til abstrakte forbrugerudviklere fra kompleksiteten ved at opdage og implementere virksomhedens sikkerhed politikker

relateret læsning: få mere at vide om API Security best practices.

Administrer

tre trin i 7-trins tilgangen til SOA, og vi begynder at gøre nogle fremskridt hen imod at opnå reel værdi fra enterprise SOA. Vi har nogle tjenester, de offentliggøres i et register og kan opdages af potentielle brugere, og vi har sikret, at de er sikre. Hvad kunne vi ellers have brug for?

for at besvare dette spørgsmål skal vi først se på et potentielt katastrofescenarie. Hvad sker der, når mine tjenester bliver ofre for deres egen succes? Dvs. en tjeneste er blevet så populær, at der er flere (tiere eller hundreder eller tusinder) forskellige applikationer, der bruger den, og den begynder at spænde under belastningen. Vi har pludselig tiere eller hundreder eller tusinder af applikationer, der fejler eller fungerer dårligt, og vi ved ikke hvorfor, eller hvordan vi stopper det.

vi er nødt til at overvåge vores tjenester, så vi ved, om de fungerer inden for normale driftsparametre, og så vi ser potentielle problemer, før de opstår ved at implementere kapacitetsplanlægningsmodeller.

den overvågningsløsning, vi implementerer, skal være i stand til at overvåge tjenester for grundlæggende tilgængelighed, ydeevne (responstid), gennemstrømning og endda udvide til indhold og brugerbaseret overvågning. Det bør være i stand til at overvåge og advare om specifikke SLA-tærskler og bør være i stand til at anvende forskellige SLA ‘ er på forskellige brugere af den samme tjeneste eller operation.

mange leverandører definerer denne produktkategori som en løsning til administration af internettjenester, selvom mange analytikere er enige om, at ledelsen er meget bredere end en simpel overvågningsløsning og bør omfatte meget af den funktionalitet, der er beskrevet i næste trin.

ideelt set skal vi naturligvis ikke være nødt til at implementere separate løsninger til sikkerhed og overvågning, fordi hver gang vi opfanger meddelelser gennem og agent eller formidler, tilføjer vi en anden ydelsesflaskehals. Dette er grunden til, at Akanas servicechef kombinerer med Netværksdirektør for at levere en omfattende SOA-sikkerheds -, overvågnings-og styringsplatform i en enkelt, højtydende, let at implementere løsning.

nogle leverandører af internettjenester (overvågning) placerer deres løsninger som platforme til overvågning af forretningsaktiviteter (BAM), selvom BAM er en kompleks løsning, der kræver integration med mange back – og front-office-systemer og databaser. Overvågning af interaktioner mellem internettjenester for indhold bør ikke betragtes som et alternativ til en Enterprise BAM-løsning.

Relateret Læsning: Få mere at vide om Akanas end-to-End API-styringsløsning.

5. Mægle og virtualisere

på dette tidspunkt ser det ud til, at vores SOA er klar til primetime. Og sådan er det i hvert fald i et stykke tid…

det næste sæt udfordringer opstår, når din SOA modnes. Du skal introducere nye versioner af tjenester eller øge kapaciteten af en tjeneste ved at køre flere forekomster af den, du skal levere applikationer til at bruge specifikke forekomster af tjenester, og du skal tilbyde tjenester, der afslører en bredere vifte af forskellige grænsefladetyper.

det er her service virtualisering kommer ind. Virtualisering virker kompleks, men virkeligheden er ret simpel. En virtuel tjeneste er en helt ny tjeneste, defineret af sin egen VSDL, med sin egen netværksadresse og transportparametre. Det implementerer ikke nogen forretningslogik; det fungerer simpelthen som en fuldmagt til en eller flere fysiske tjenester, routing, belastningsbalancering, transformation og formidling mellem forskellige anmodningsmeddelelsestyper og standarder.

mens det er enkelt på overfladen, er begrebet virtualisering ekstremt kraftfuldt. Det giver mulighed for fuldt ud at abstrakte serviceforbrugere fra enhver direkte viden om den fysiske service. For eksempel kan en.NET-klient, der bruger en Microsoft-implementering af en pålidelig meddelelsesprotokol med SOAP via http, forbruge en almindelig gammel tjeneste, der er eksponeret via IBM-serien fra en mainframe-applikation. Net-klienten ville tro, at det var kommunikation med en http-tjeneste, der understøttede dens pålidelige meddelelsesprotokol, mens mainframe-applikationen ville tro, at den blev forespurgt af en anden indbygget MK-serie-applikation.

virtuelle tjenester tilbyder en bred vifte af funktionalitet:

• de kan bruge transformationsteknologier til at give forbrugerne mulighed for at fortsætte med at bruge en gammel version af en tjeneste, der ikke længere findes, ved at omdanne anmodnings-og svarmeddelelser mellem den gamle version og den nye version, der er implementeret.
• de kan vælge specifikke operationer fra flere forskellige tjenester og kombinere dem til en enkelt funktionel VSDL til en bestemt klasse af forbrugende applikation.
• de kan give forskellige politiske krav til forskellige klasser af bruger (dvs. interne brugere med et politiksæt og en anden implementering af tjenesten, der håndhæver et andet politiksæt for eksterne forbrugere).
• de kan levere transport bro for tjenester og forbrugere på uforenelige transporter (f.eks http og JMS). * De kan mægle mellem forskellige standarder implementering eller endda versioner af standarder.
• de kan mægle mellem forskellige messaging stilarter – RSS, sæbe, hvile, kopper (almindelig gammel).
• de kan levere kraftfuld indhold – eller kontekstbaseret routing til at levere avancerede load-balancing og høj tilgængelighed kapaciteter.

den nederste linje med virtuelle tjenester er, at de er nødvendige for enhver routing eller andre avancerede internettjenester, og vil hurtigt blive en væsentlig del af enhver virksomhed SOA.

regere

med 5 ud af 7 trin afsluttet, er enterprise SOA stort set klar til at gå. Du har nu sikre, administrerede tjenester, der er tilgængelige for et bredt publikum på en pålidelig, belastningsbalanceret måde og let kan opdages.

det næste trin er at binde alle de kapaciteter, der leveres gennem de første 5 trin, sammen med en styringsramme. Governance er et overbrugt og meget misbrugt arbejde, så lad os kort se på en definition af regeringsførelse.

begrebet governance omhandler de processer og systemer, som en organisation eller et samfund opererer med. Ofte oprettes en regering til at administrere disse processer og systemer.

det centrale punkt at tage fra denne definition er, at styring handler om processer og systemer. I tilfælde af SOA-styring, vi diskuterer organisatoriske processer som et arkitekturanmeldelseskort, og systemer som registreringsdatabasen, sikkerhed, og styringsteknologier diskuteret i denne blog.

Governance for SOA er ofte opdelt i to separate dele, design-time governance og run-time governance. På design-time ønsker organisationer at kontrollere (styre) de typer tjenester, der kan offentliggøres, hvem der kan offentliggøre dem, hvilke typer skemaer og meddelelser disse tjenester kan acceptere og en række andre regler om tjenester. I driftstid skal organisationer sikre sikkerheden, pålideligheden og udførelsen af deres tjenester og skal sikre, at tjenester overholder definerede virksomhedspolitikker. Design – time governance er interessant og hjælper med at sikre en organiseret, veldesignet SOA, men det blegner i ubetydelighed sammenlignet med aktiv kontrol af SOA på run-time.

Akana ‘ s Service Manager er branchens førende run-time governance platform, der tilbyder en omfattende løsning til sikkerhed, overvågning, ledelse, mægling og register. Run-time governance giver i det væsentlige en enkelt ramme for kontrol og overvågning af anvendelsen af de forskellige trin til SOA, der er beskrevet i dette dokument. Det giver en enkelt overordnet løsning, der giver tilsyn med serviceregister, sikkerhed, ledelse og mægling. En god run-time governance-løsning vil manifestere sig som en form for arbejdsbord, der giver værktøjer til alle de aktive deltagere i en SOA.

• Serviceudvikler: værktøjer til at offentliggøre, kategorisere, definere metadata, hente “agent”, virtualisere, version, vælge politik, vælge synlighed/adgangsrettigheder, deltage i kapacitetsplanlægning og få adgang til arbejdsgang
• Service forbruger: værktøjer til at lette opdagelse, udvælgelse og adgang til arbejdsgang
• driftspersonale: værktøjer til at overvåge tjenestens ydeevne, fejlfinding af problemer, overvåge afhængigheder, versionstjenester, virtualisering, fuldmægtigstyring
• sikkerhedspersonale: værktøjer til politikstyring, politikrapportering, kontrol af overholdelse, sikkerhed revision
• enterprise arkitekt: Værktøjer til applikationsovervågning, relationsstyring, designpolitisk validering og definition, serviceversionsstyring, service til fuldmægtig opgave, service virtualisering
• Enterprise IT Management: genbrug metrisk styring, service genbrug metrics, SOA statistik

SOA Integration med ESB

når vi ser tilbage på resultaterne af de sidste 6 trin mod en SOA, undrer vi os over, hvad der ellers kan være. På nuværende tidspunkt har vi et sæt tjenester, der offentliggøres i et register, sikkert, administreret, pålideligt og løst koblet, alt sammen pakket ind i en solid design-og run-time governance-løsning.

det sidste trin for nogle virksomheder er at implementere en eller flere Enterprise Services Bus (ESB) implementeringer for at integrere tjenester i sammensatte eller orkestrerede tjenester på højere niveau. Disse ESB ‘ er leveres ofte som en del af en bredere applikationspakke, såsom Oracle eBusiness applications eller SAP. Nogle specialiserede ESB ‘ er kan bruges til at oprette komplekse sammensatte tjenester og vil strække sig ind i området Business Process Management (BPM).

relateret læsning:Find ud af mere om Akanas integrationsløsninger.

Enterprise Service Bus (ESB) er et stadig mere populært koncept. Oprindeligt udtænkt som udviklingen af både meddelelsesorienterede mellemvare-og EAI-løsninger (enterprise application integration) betyder ESB meget forskellige ting for forskellige organisationer. Som analytikere, leverandører og kunder kommer overens med ideen om en ESB, ser det ud til, at en ESB indkapsler 3 funktionelle koncepter; adaptere hentet fra et EAI-værktøj for at sikre forbindelse med ældre applikationer, messaging-tjenester hentet fra en meddelelsesorienteret mellemvareplatform for at sikre pålidelig levering og procesorkestrering for at opbygge smidige applikationer.

konsensus blandt analytikere er, at de fleste organisationer vil ende med flere ESB-platforme fra flere leverandører, der leverer tjenester i deres egen sammenhæng. I dette miljø er det afgørende, at ESBs bruger en central SOA-infrastruktur for at sikre konsekvent overholdelse af sikkerheds-og messaging-politikker for de tjenester, de udsætter og forbruger.

Akanas Service Manager-og Netværksdirektørprodukter giver tilsammen en komplet løsning til styring af og mægling mellem flere ESB-tilfælde i en virksomhed.

nu hvor du ved mere om, hvad SOA står for og de vigtigste SOA-trin, så tjek Akana i aktion!

Start Forsøg