Vad är SOA? 7 SOA-steg

den här bloggen beskriver SOA-stegen som en organisation måste ta innan den verkligen kan lyckas med att realisera de kostnads-och agilityfördelar som erbjuds av enterprise service-oriented architecture. Den diskuterar vad SOA står för och de olika stadierna av SOA-adoption genom att beskriva de tekniker, processer och bästa praxis som finns tillgängliga för att hjälpa företag att lyckas med sina serviceorienterade arkitekturinitiativ.

Vad är SOA?

Service-oriented architecture (SOA) är en typ av arkitektur som används i mjukvarudesign som stöder serviceorientering, varigenom tjänster tillhandahålls till andra komponenter via ett kommunikationsprotokoll över ett nätverk.

Vad står SOA för?

definitionen av SOA, som tillhandahålls av Wikipedia:

Service-oriented architecture (SOA) är en typ av mjukvarudesign där tjänster tillhandahålls till de andra komponenterna av applikationskomponenter, via ett kommunikationsprotokoll över ett nätverk. De grundläggande principerna för serviceorienterad arkitektur är oberoende av leverantörer, produkter och tekniker. En tjänst är en diskret funktionsenhet som kan nås på distans och åtgärdas och uppdateras oberoende, till exempel att hämta ett kreditkortsutdrag online.

en tjänst har fyra egenskaper enligt en av många definitioner av SOA:

1. det representerar logiskt en affärsverksamhet med ett visst resultat.
2. det är fristående.
3. det är en svart låda för sina konsumenter.
4. det kan bestå av andra underliggande tjänster.

olika tjänster kan användas tillsammans för att tillhandahålla funktionaliteten hos en stor programvara, en princip SOA delar med modulär programmering. Serviceorienterad arkitektur integrerar distribuerade, separat underhållna och distribuerade programvarukomponenter. Det möjliggörs av tekniker och standarder som underlättar komponenternas kommunikation och samarbete över ett nätverk, särskilt över ett IP-nätverk.

detta ger ett kortfattat svar på vad SOA betyder, men det beskriver inte orsakerna till att en organisation vill gå mot serviceorienterad arkitektur eller fördelarna med SOA.

även från Wikipedia om vad SOA står för:

vissa företagsarkitekter tror att SOA kan hjälpa företag att reagera snabbare och mer kostnadseffektivt på förändrade marknadsförhållanden.Denna typ av arkitektur främjar återanvändning på Makro (service) nivå snarare än mikro (klasser) nivå. Det kan också förenkla samtrafik till—och användning av-befintliga IT-tillgångar (äldre).

i vissa avseenden kan SOA betraktas som en arkitektonisk utveckling snarare än som en revolution. Den fångar många av de bästa metoderna från tidigare programvaruarkitekturer. I kommunikationssystem har till exempel liten utveckling av lösningar som använder verkligt statiska bindningar för att prata med annan utrustning i nätverket ägt rum. Genom att anta ett SOA-tillvägagångssätt kan sådana system positionera sig för att betona vikten av väldefinierade, mycket interoperabla gränssnitt.

borrning i dessa begrepp kan vi se att det finns en uppsättning grundläggande funktioner som krävs för att uppnå de potentiella fördelarna med SOA. Wikipedia diskuterar ett antal av dessa vägledande huvudmän, bland vilka är:

• återanvändning – förmågan att inkapsla och exponera grovkorniga affärsfunktioner som tjänster
• lös koppling-se till att tjänstekonsumenterna är tillräckligt abstraherade från den fysiska implementeringen av en tjänst
• identifiering och kategorisering (upptäckbarhet) – se till att potentiella konsumenter kan hitta de tjänster de behöver

oavsett vilken SOA – definition du använder, dessa grundläggande principer leda till en naturlig ordning av aktiviteter som en organisation måste slutföra för att stegvis inse fördelarna med serviceorienterad arkitektur.

se varför Akana är en stark aktör i Forrester Wave Brasilien: API Management Solutions, Q3 2020-rapporten.

ladda ner rapport

vilka är de sju soa-stegen?

det finns sju SOA-steg:

1. skapa/exponera tjänster
2. registrera tjänster
3. säkra tjänster
4. hantera (övervaka) tjänster
5. medla och virtualisera tjänster
6. styr soa
7. soa-Integration med ESB

soa steg 2 till 6 beskriver tvärföretagsproblem som bör hanteras med en centraliserad soa-Infrastrukturplattform. Steg 1 och 7 tillgodoser specifika behov och levereras ofta som en del av en befintlig företagsapplikationsstack. Att följa dessa steg leder en organisation på rätt väg för att förverkliga fördelarna med SOA. Fortsätt läsa för att gå djupare in i varje SOA-steg.

skapa/exponera tjänster

det första steget i att flytta en organisation mot SOA är uppenbart. Det kan inte finnas någon SOA-applikation utan tjänster, så det första steget måste vara att exponera eller skapa tjänster som lätt kan konsumeras av Webbtjänstaktiverade applikationer.

det finns ett antal intressanta beslut som företag står inför när de börjar denna process, inte minst är beslutet om att bygga om befintliga applikationer med ett serviceorienterat paradigm eller att exponera befintlig applikationslogik som en uppsättning tjänster. Detta är naturligtvis inte ett binärt beslut, och de flesta organisationer kommer att bygga nya tjänster från grunden, ofta med J2EE och/eller.Net, och kommer också att avslöja tjänster från befintliga stordator och andra affärsapplikationer.

det finns ett brett utbud av olika lösningar för företag som vill exponera befintliga applikationer som tjänster, inklusive Akanas marknadsledande SOLA som gör det möjligt för mainframe CICS-applikationer att exponera och konsumera pålitliga, säkra, högpresterande tjänster.

alla företag med en betydande (mer än 1000 MIPS enligt Gartner) investering i mainframe bör undersöka sätt att bättre utnyttja fördelarna med denna plattform och bör använda webbtjänster för att enkelt integrera sina mainframe-applikationer med moderna system. AKANAS SOLA är produktionsbevisad hos kunder som Merrill Lynch där den bearbetar mer än 2 miljoner transaktioner per dag från mer än 600 webbtjänster. SOLA är den enda produkten som erbjuder mainframe-programmerare ett lättanvänt, webbaserat gränssnitt för att exponera och konsumera tjänster från CICS-applikationer. Den innehåller inbyggt stöd för avancerade webbtjänster funktioner som WS-säkerhet, XML-kryptering och XML-signatur.

de flesta av de traditionella EAI-företagen (Enterprise application integration) levererar också versioner av sina adaptrar som exponerar webbtjänster snarare än deras traditionella proprietära protokoll. Faktum är att många av dessa EAI-plattformar återuppstår som Enterprise Service Bus-produkter. ESB tar upp flera olika problem, varav en är commodity data services-funktionen som används för att exponera Webbtjänstgränssnitt från traditionella Adaptrar.

Vad är en webbtjänst?

Från Wikipedia:

i förhållande till W3C-webbtjänster definierade W3C en webbtjänst som: ”en webbtjänst är ett mjukvarusystem som är utformat för att stödja interoperabel maskin-till-maskin-interaktion över ett nätverk. Den har ett gränssnitt som beskrivs i ett maskinbehandlingsbart format (specifikt WSDL). Andra system interagerar med webbtjänsten på ett sätt som föreskrivs av dess beskrivning med SOAP-meddelanden, vanligtvis förmedlas med HTTP med en XML-serialisering i samband med andra webbrelaterade standarder.”

denna definition är intressant ur ett tekniskt perspektiv, men det kommer inte riktigt till hjärtat av det värde som kan härledas från SOA och webbtjänster. En grundläggande aspekt av webbtjänster är att de ska exponera affärslogik via ett standardbaserat gränssnitt. En viktig aspekt av att exponera eller skapa en tjänst är dess granularitet. Det finns många olika tankeskolor om vad som utgör en tjänst (se ovan), men de flesta företagsarkitekter håller med om att för att vara användbara i en SOA måste en tjänst vara tillräckligt grovkornig för att vara användbar för flera olika applikationer.

detta, naturligtvis, geler med en av de grundläggande principerna för tjänster i SOA – för att en tjänst ska kunna återanvändas; det måste vara allmänt användbart och användbart. Ett exempel på en allmänt användbar tjänst kan vara en” getCustomerInfo ” – tjänst som returnerar information om en kund från en kundidentifierare. En mer finkornig tjänst som kanske inte är allmänt användbar kan vara något specifikt för en viss applikation, till exempel ”setApplicationState”.

det är viktigt att överväga granularitet av tjänster både när man bygger nya tjänster och när man exponerar befintlig affärslogik som en tjänst. Till exempel skulle det vara lätt att ta en CICS-transaktion och exponera flera olika tjänster för att ställa in och få olika parametrar, medan verkligheten är att en mer grovkornig tjänst som exponerar hela transaktionen som en enda tjänst kan vara mycket mer allmänt användbar och därför värdefull.

relaterad läsning: ta reda på hur Akanas SOLA Mainframe API ger kunderna en snabb och enkel process för att exponera mainframe-applikationer som säkra webbtjänster och tillåter mainframe-applikationer att konsumera webbtjänster.

registrera

Ok, så att du har en eller flera tjänster tillgängliga i ditt företag. Vad händer nu?

för att en tjänst ska kunna användas, än mindre återanvändas, måste applikationsarkitekter och utvecklare som kan dra nytta av denna tjänst veta att den finns. Det är här ett register kommer in. På sin enklaste nivå är ett register inget annat än ett biblioteksindex som hjälper potentiella användare av tjänster att hitta tjänster de kan vara intresserade av. Registret bör erbjuda både sök-och bläddringsgränssnitt och bör organiseras logiskt för att underlätta snabb och korrekt upptäckt av tjänster.

i dagens SOA är den accepterade standarden för grundläggande registertjänster UDDI (Universal Discover, Description, and Integration). UDDI-specifikationen tillhandahåller en datamodell och en uppsättning gränssnitt (alla webbtjänster själva) för publicering och upptäckt av tjänster, samt en ytterligare uppsättning gränssnitt för hantering av registerservern själv.

många registerleverantörer har tagit det ursprungliga konceptet register ganska lite längre och använder registerteknik som bas för ett mer komplett arkiv. Registerleverantörer lägger också till” policy ” – baserade filter i sina publiceringsverktyg och erbjuder ”design-time governance solutions”.

Akana anser att registret är en grundläggande byggsten för SOA. Alla våra produkter utnyttjar UDDI som en enda central butik för auktoritativ information om tjänsterna i en SOA. Produkterna kan fungera med alla UDDI-kompatibla register, och Akana innehåller sin egen uddiv3-registerserver med sin Service Manager-produkt för företag som inte redan har ett register. I detta avseende fyller registret rollen för SOA som LDAP fyllde för identitets-och Åtkomsthanteringslösningar.

Akanas produkter fokuserar på styrning av körtid och utnyttjar registret som en central plats för att hitta körtidspolicyer för att implementera och genomdriva. Naturligtvis är den inbäddade registret fullt fungerande uddiv3 server och så gör också en idealisk design-time service repository.

Beyond registry är hela konceptet med policy-och metadatatjänster som tillhandahåller omfattande repositories för alla design-Tid och run-time artefakter för tjänsterna i SOA. Detta koncept behandlas mer detaljerat i Akanas whitepaper the SOA Infrastructure Reference Model.

säkra

SOA-och Webbtjänsternas värld är inte allt vin och rosor. Förutsatt att du nu har slutfört steg ett och steg, ta ett steg tillbaka och överväga vad du har gjort. Om du antar att du går för maximalt affärsvärde, kommer du sannolikt att ha tagit uppdragskritiska applikationer, brutit ner dem i grovkorniga funktioner, exponerat denna funktionalitet som tjänster och sedan publicerat dessa tjänster till ett universellt tillgängligt register.

det här kan alla verka som en bra sak, och i de flesta fall är det en bra sak, men du kan oavsiktligt ha skapat några gapande säkerhetshål i din organisation och utsatt känslig information eller transaktioner med högt värde för alla med rudimentära webbtjänster. Att säkerställa säkerheten för tjänster innebär att man bygger ett säkerhetsskyddslager hos tjänsteleverantörerna och ett säkerhetsimplementeringslager hos tjänstekonsumenterna.

ett bra sätt att förstå säkerhetsriskerna med webbtjänster är att tänka tillbaka på traditionella grönskärmsapplikationer. Den enda säkerhet som krävs av dessa program var inloggning säkerhet, om du kunde komma åt programmet, du var i. Dessa applikationer innehöll samma grundläggande delar som en modern applikation (gränssnitt, affärslogik, datatjänster), men endast gränssnittet var tillgängligt utanför applikationen. I världen av webbtjänster är det troligt att några av de centrala datatjänsterna kommer att exponeras som tjänster, en del av affärslogiken borde verkligen exponeras och applikationen skrevs inte med någon av dessa åtkomstpunkter i åtanke. Det betyder att det är viktigt att säkra de tjänster du exponerar individuellt, du kan inte lita på applikationens interna för att säkerställa sin egen säkerhet.

så vad betyder det att säkra en webbtjänst? Samma 5 principer för säkerhet som gäller för andra applikationer gäller även för webbtjänster:

• autentisering-se till att du känner till tjänsteförfrågarens identitet (och se också till att den som begär tjänsten känner till identiteten på den tjänst Den kontaktar). Det finns flera olika webbtjänster standarder för autentisering förfrågningar, allt från enkla metoder som http grundläggande autentisering, till mer komplexa mekanismer som SAML eller X. 509 signatur. Ett bra säkerhetsverktyg för webbtjänster bör stödja alla dessa olika alternativ.
• auktorisering-se till att begäraren har behörighet att få tillgång till den tjänst eller operation den begär. Auktorisation är en komplex fråga och det finns många olika politiska beslutsprodukter tillgängliga. De flesta stora företag kommer att ha en befintlig lösning för godkännande (CA SiteMinder, IBM TAM, etc), och en bra Webbtjänstsäkerhetslösning ska kunna integreras med dessa samt ge sina egna auktoriseringsfunktioner.
• Sekretess-se till att begäran och svarsmeddelanden inte kan läsas av obehöriga 3: e parter. Det är här standarder som XML-kryptering kommer till sin rätt, men för att framgångsrikt kunna använda XML-kryptering måste webbtjänstens säkerhetslösning tillhandahålla effektiva nyckel-och certifikathanterings-och distributionsfunktioner, och helst några klientverktyg för att hjälpa konsumentutvecklare.
• Non-Repudiation-se till att begäraren inte kan neka att skicka en begäran och se till att tjänsten inte kan neka att skicka sitt svar. Detta är rollen som XML-signatur, med samma nyckelhantering och distribution som för integritet.
• revision-se till att systemet kan upprätthålla en korrekt och snabb registrering av begäran och svar efter behov.

en intressant fråga och debattpunkt som uppstår kring Webbtjänstsäkerhet är var denna säkerhet ska tillämpas. Vissa leverantörer kommer att hävda att säkerhet bör vara en central funktion som verkställs genom ett kluster av centralt distribuerade proxyservrar, medan andra kommer att hävda att det endast bör vara tjänsteleverantörens eller behållarens domän. Verkligheten är naturligtvis någonstans mellan dessa två positioner. Det finns verkligen en viktig roll för en proxy (eller ett kluster av proxyservrar) för att tillhandahålla autentiserings-och hotdetekteringstjänster i utkanten av nätverket för att skydda mot externa hot. Det finns också en lika viktig roll för leverantör eller containerbaserad säkerhet för att säkerställa säkerheten för tjänsten till den sista milen.

många företag tenderar att förbise forskningen som visar att majoriteten av säkerhetshot är interna för företaget, inte externa, och därför delegerar säkerhet till en brandväggslösning. Akana erbjuder en högpresterande proxy som utför centraliserade eller nätverkskant säkerhetsfunktioner, och ett brett utbud av i containeragenter för att säkerställa den sista milen säkerhet utplacerade tjänster.

säkra webbtjänster kräver:

• distribuera fullt fungerande in-container agenter för att säkerställa sista mil säkerhet och fördela belastningen av kryptografiska operationer
• distribuera högpresterande nätverksförmedlare för routing och network edge security enforcement
• ge omfattande nyckel-och certifikathantering och distribution för att säkerställa att tjänsteleverantören och konsumentutvecklare framgångsrikt kan genomföra nödvändiga säkerhetspolicyer
• ge consumer developer toolkits till abstract consumer developers från komplexiteten att upptäcka och implementera enterprise security policyer

relaterad läsning: Läs mer om bästa praxis för API-säkerhet.

hantera

tre steg i 7-stegsmetoden till SOA och vi börjar göra några framsteg mot att uppnå verkligt värde från företagets SOA. Vi har vissa tjänster, de publiceras i ett register och kan upptäckas av potentiella användare, och vi har sett till att de är säkra. Vad mer kan vi behöva?

för att svara på denna fråga bör vi först titta på ett potentiellt katastrofscenario. Vad händer när mina tjänster blir offer för sin egen framgång? Dvs. en tjänst har blivit så populär att det finns flera (tiotals eller hundratals eller tusentals) olika applikationer som konsumerar det och det börjar spänna under belastningen. Vi har plötsligt tiotals eller hundratals eller tusentals applikationer som misslyckas eller fungerar dåligt och vi vet inte varför eller hur man stoppar det.

vi måste övervaka våra tjänster så att vi vet om de fungerar inom normala driftsparametrar och så att vi ser potentiella problem innan de uppstår genom att implementera kapacitetsplaneringsmodeller.

övervakningslösningen vi distribuerar ska kunna övervaka tjänster för grundläggande tillgänglighet, prestanda (svarstid), genomströmning och till och med utvidga till innehåll och användarbaserad övervakning. Det bör kunna övervaka och varna om specifika SLA-tröskelvärden och bör kunna tillämpa olika SLA: er på olika användare av samma tjänst eller operation.

många leverantörer definierar denna produktkategori som en Webbtjänsthanteringslösning, även om många analytiker är överens om att ledningen är mycket bredare än en enkel övervakningslösning och bör innehålla mycket av den funktionalitet som beskrivs i nästa steg.

helst bör vi naturligtvis inte behöva distribuera separata lösningar för säkerhet och övervakning eftersom varje gång vi avlyssnar meddelanden genom och agent eller mellanhand lägger vi till en annan prestandaflaskhals. Det är därför Akanas Service Manager kombinerar med Network Director för att tillhandahålla en omfattande SOA-säkerhets -, övervaknings-och hanteringsplattform i en enda, högpresterande, lätt att distribuera lösning.

vissa leverantörer av webbtjänster (övervakning) placerar sina lösningar som Bam – plattformar (Business Activity Monitoring), även om BAM är en komplex lösning som kräver integration med många back-och front office-system och databaser. Övervakning av webbtjänstinteraktioner för innehåll bör inte betraktas som ett alternativ till en Bam-lösning för företag.

Relaterad Läsning: Ta reda på mer om Akanas End-to-End API-hanteringslösning.

5. Förmedla och virtualisera

vid denna tidpunkt verkar det som om vår SOA är redo för primetime. Och så är det, åtminstone ett tag…

nästa uppsättning utmaningar uppstår när din SOA mognar. Du måste införa nya versioner av tjänster eller öka kapaciteten för en tjänst genom att köra flera instanser av den, du måste tillhandahålla applikationer för att använda specifika instanser av tjänster och du måste erbjuda tjänster som avslöjar ett bredare utbud av olika gränssnittstyper.

det är här servicevirtualisering kommer in. Virtualisering verkar komplex, men verkligheten är ganska enkel. En virtuell tjänst är en helt ny tjänst, definierad av sin egen WSDL, med egen nätverksadress och transportparametrar. Det implementerar inte någon affärslogik; det fungerar helt enkelt som en proxy till en eller flera fysiska tjänster, routing, lastbalansering, transformering och förmedling mellan olika typer av begäran och standarder.

även om det är enkelt på ytan är begreppet virtualisering extremt kraftfullt. Det ger möjlighet att helt abstrakt service konsumenter från någon direkt kunskap om den fysiska tjänsten. Till exempel, genom en virtuell tjänst, kan en.NET-klient som använder en Microsoft-implementering av ett pålitligt meddelandeprotokoll med SOAP över http konsumera en vanlig gammal XML-tjänst som exponeras via IBM WebSphere MQ-serien från en mainframe-applikation. Net-klienten skulle tro att det var kommunikation med en http-tjänst som stödde dess tillförlitliga meddelandeprotokoll, medan mainframe-applikationen skulle tro att den frågades av en annan inbyggd mq-serieapplikation.

virtuella tjänster erbjuder ett brett utbud av funktioner:

• de kan använda XML-omvandlingstekniker för att tillåta konsumenter att fortsätta använda en gammal version av en tjänst som inte längre finns genom att omvandla begäran och svarsmeddelanden mellan den gamla versionen och den nya versionen som har distribuerats.
• de kan välja specifika operationer från flera olika tjänster och kombinera dem till en enda funktionell WSDL för en specifik klass av konsumerande applikation.
• de kan tillhandahålla olika policykrav för olika användarklasser (dvs. interna användare med en policyuppsättning och en annan implementering av Tjänsten som upprätthåller en annan policyuppsättning för externa konsumenter).
• de kan tillhandahålla transportbryggning för tjänster och konsumenter på inkompatibla transporter (t.ex. http och JMS). * De kan medla mellan olika standardimplementering eller till och med versioner av standarder.
• de kan förmedla mellan olika meddelandestilar-RSS, SOAP, REST, POX (vanlig gammal XML).
• de kan tillhandahålla kraftfull innehålls-eller kontextbaserad routing för att leverera avancerad lastbalansering och hög tillgänglighet.

summan av kardemumman med virtuella tjänster är att de krävs för alla routing eller andra avancerade webbtjänster, och kommer snabbt att bli en viktig del av alla företag SOA.

styr

med 5 av 7 steg färdiga är enterprise SOA ganska redo att gå. Du har nu säkra, hanterade tjänster som är tillgängliga för en bred publik på ett tillförlitligt, belastningsbalanserat sätt och är lätt att upptäcka.

nästa steg är att knyta samman alla funktioner som levereras genom de första 5 stegen med en styrningsram. Styrning är ett överutnyttjat och mycket missbrukat arbete, så låt oss kortfattat titta på en definition av styrning. Återigen från Wikipedia:

termen styrning handlar om de processer och system som en organisation eller ett samhälle arbetar med. Ofta inrättas en regering för att administrera dessa processer och system.

den viktigaste punkten att ta från denna definition är att styrning handlar om processer och system. När det gäller soa-styrning diskuterar vi organisatoriska processer som en arkitekturgranskningsnämnd och system som registret, säkerhet och hanteringsteknik som diskuteras i den här bloggen.

styrning för SOA är ofta uppdelad i två separata delar, design-time governance och run-time governance. Vid designtid vill organisationer styra (styra) vilka typer av tjänster som kan publiceras, vem som kan publicera dem, vilka typer av schema och meddelanden dessa tjänster kan acceptera och en mängd andra regler om tjänster. Vid körning måste organisationer säkerställa säkerheten, tillförlitligheten och prestandan för sina tjänster och måste se till att tjänsterna följer definierade företagspolicyer. Design-time governance är intressant och hjälper till att säkerställa en organiserad, väl utformad SOA, men den bleknar i obetydlighet jämfört med aktiv kontroll av SOA vid körning.

Akanas Service Manager är branschens ledande plattform för run-time governance och erbjuder en omfattande lösning för säkerhet, övervakning, hantering, medling och register. Run-time governance ger i huvudsak en enda ram för att kontrollera och övervaka tillämpningen av de olika stegen till SOA som beskrivs i detta dokument. Det ger en enda övergripande lösning som ger övervakning i tjänsteregistret, Säkerhet, hantering och medling. En bra run-time governance-lösning kommer att manifestera sig som en form av arbetsbänk som ger verktyg för alla aktiva deltagare i en SOA.

• Tjänsteutvecklare: verktyg för att publicera, kategorisera, definiera metadata, ladda ner ”agent”, virtualisera, version, välj policy, välj synlighet/åtkomsträttigheter, delta i kapacitetsplanering och åtkomst arbetsflöde
• Servicekonsument: verktyg för att underlätta service upptäckt, urval och åtkomst arbetsflöde
• Operations Staff: verktyg för att övervaka tjänstens prestanda, felsöka problem, övervaka beroenden, versionstjänster, virtualisering, proxyhantering
• säkerhetspersonal: verktyg för policyhantering, policyrapportering, efterlevnadskontroll, säkerhetsgranskning
• företagsarkitekt: Verktyg för applikationsövervakning, relationshantering, validering och definition av designpolicy, serviceversionshantering, service till proxytilldelning, servicevirtualisering
• Enterprise IT Management: Återanvänd metrisk hantering, serviceåteranvändning, soa-statistik

soa-Integration med ESB

när vi tittar tillbaka på resultaten från de senaste 6 stegen mot en SOA, undrar vi vad mer kan det eventuellt vara. Nu har vi en uppsättning tjänster som publiceras i ett register, säkert, hanterat, pålitligt och löst kopplat, allt inslaget i en solid design och run-time governance-lösning.

det sista steget för vissa företag är att distribuera en eller flera Enterprise Services Bus (ESB) implementeringar för att integrera tjänster i sammansatta eller orkestrerade tjänster på högre nivå. Dessa ESB kommer ofta att levereras som en del av en bredare applikationssvit, till exempel Oracle eBusiness applications eller SAP. Vissa specialiserade ESB kan användas för att skapa komplexa sammansatta tjänster, och kommer att sträcka sig in i sfären av Business Process Management (BPM).

relaterad läsning:ta reda på mer om Akanas integrationslösningar.

Enterprise Service Bus (ESB) är ett allt populärare koncept. Ursprungligen tänkt som utvecklingen av både meddelandeorienterade middleware-och EAI-lösningar (enterprise application integration), betyder ESB mycket olika saker för olika organisationer. Som analytiker, leverantörer, och kunder komma till rätta med tanken på en ESB, det verkar som en ESB inkapslar 3 funktionella koncept; Adaptrar tas från en EAI verktyg för att säkerställa anslutning med äldre applikationer, meddelandetjänster tas från en meddelandeorienterad middleware plattform för att säkerställa tillförlitlig leverans, och process orkestrering för att bygga smidiga applikationer.

konsensus bland analytiker är att de flesta organisationer kommer att sluta med flera ESB-plattformar från flera leverantörer, som tillhandahåller tjänster i sitt eget sammanhang. I denna miljö är det viktigt att ESBs använder en central SOA-infrastruktur för att säkerställa konsekvent efterlevnad av säkerhets-och meddelandepolicyer för de tjänster de exponerar och konsumerar.

Akanas Service Manager och Network Director-produkter ger tillsammans en komplett lösning för styrning av och medling mellan flera ESB-instanser i ett företag.

nu när du vet mer om vad SOA står för och de viktigaste soa-stegen, kolla in Akana in action!

Starta Försök