hur man bygger en Service Oriented Architecture (SOA)

hur man bygger en Service Oriented Architecture (SOA)

i den här artikeln fokuserar vi på ämnet Service Oriented Architecture (SOA). Vi börjar med ett djupt dyk i 1) SOA: en beskrivning och går sedan för att diskutera 2) bygga en serviceorienterad arkitektur.

Service ORIENTED ARCHITECTURE: en beskrivning

Vad är SOA?

SOA eller serviceorienterad arkitektur är en metod genom vilken olika typer av tjänster kan interagera med varandra oberoende. En tjänst är en fristående del av funktionaliteten, och flera tjänster kan kombineras för att ge användning och funktionalitet av en programvara i stor skala. Vad SOA gör är att det gör det enklare för programvarudelar på datorer som är anslutna till ett nätverk att interagera och samarbeta. Designmönstret för SOA är sådant att applikationskomponenter i det kan erbjuda tjänster till andra sådana komponenter mestadels över ett nätverk. Varje datorsystem kan köra valfritt antal tjänster, som var och en är byggd för att utbyta information med någon annan tjänst i ett nätverk utan mänsklig hjälp.

i affärsterminologi är SOA en uppsättning affärsanpassade IT-tjänster som tillsammans adresserar företagets mål och processer. Den strukturella utformningen av SOA ser till att det finns en anpassning till kraven i verksamheten samt den tekniska lösningen av samma.

de viktigaste delarna av SOA

här är de viktigaste delarna av SOA:

• SOA – förare-SOA-förare eller företagsförare inkluderar saker som konkurrens, strategi, reglerande krafter och marknadskrafter. Alla dessa saker samlas för att driva affärsarkitekturen och ge en form till hela verksamheten performance management
• SOA enablers – de fem viktigaste SOA enablers är Enterprise business model, Business performance optimization, Portfolio Rationalization, Enterprise semantik definition och Key performance indicators. Att ha en affärsmodell är viktigt för en korrekt anpassning av tjänster med målen och målen för verksamheten. Den semantiska informationsmodellen ger den gemensamma och allmänna affärsrelaterade informationen för ett visst företag. Nyckeltal eller nyckeltal gör bedömningen av SOA: s inverkan möjlig och gör mätningen av affärsprocesser enklare. Å andra sidan möjliggör portfölj rationalisering konsolidering och förenkling av applikationer, data och infrastruktur.
• soa – implementering-när det gäller implementering är företagstjänster och processer de viktigaste aspekterna. Affärsprocesser är oftast förknippade med affärsmål och verksamhetsmål medan å andra sidan företagstjänster måste vara väl anpassade och är kritiska för flexibel och framgångsrik soa-implementering. Några av de andra aspekterna relaterade till soa-implementering är Företagsinnehållsförvar, semantiska meddelanden och integrationstjänster. Informationen representerar företagets dataresurser, och dessa data skickas i form av dokument som ger ett slags semantiska meddelanden mellan tjänster och processer.
• SOA Support – alla funktioner och element från befintliga applikationer och system görs tillgängliga och användbara för tjänsterna med stöd av vissa integrationstjänster som tar bort omslag från befintliga funktioner via nya servicegränssnitt.

huvudprinciperna för SOA

följande är listan över huvudprinciperna för SOA:

• service architecture – den fysiska layouten eller utformningen av enskilda tjänster som överträffar alla resurser som användes av en tjänst.
• service composition architecture – alla tjänster som utvecklats med hjälp av serviceorienterade designmetoder är kompositionscentrerade, och detta är deras huvudsakliga funktion. Denna arkitektur är därför sammansättningen av enskilda arkitekturer för olika tjänster.
• service inventory architecture – denna arkitektur bildas från service inventory blueprint där service inventory består av tjänster som automatiserar företagens förfaranden.
• Service-oriented enterprise architecture-denna typ utgör sammansättning, service samt lagerarkitekturer.

utvecklingen av SOA – konceptet

• monolitisk design – Denna design var relaterad till relativt ostrukturerad procedurkodning
• objekt-och strukturorienterad design-Detta är designen som involverar programenheter baserade på funktioner.
• Client-server design (two-tier design) – Detta är begreppet distribuerad design och är relaterad till buntning av funktioner i två nivåer.
• distribuerad objektdesign (multitier design) – Denna design involverar objektinteraktioner i en heterogen miljö och distribuerad objektdesign.
• Komponentobjektmodellarkitektur – Detta är en design där det finns en aggregering av objekt i logikbaserade delar med starka typer samt ett väldefinierat gränssnitt.
• Service oriented architecture-Detta är en design som involverar interaktioner och kommunikation mellan grovkorniga tjänster med standardgränssnitt för flexibla interoperationer.

SOA och JAVA

många utvecklare tror att SOA, liksom webbtjänster, är synonymt med varandra, men det är inte sant. De kan också tro att det bara inte är möjligt att bygga SOA utan att använda webbtjänster, men i verkligheten är SOA en designprincip men webbtjänster är en slags implementeringsteknik. Detta innebär att SOA faktiskt kan byggas utan att använda implementeringsteknik av ett visst slag. Men Java är en annan typ av traditionell teknik som kan användas för att utveckla eller bygga serviceorienterad arkitektur.

huvudsyftet med SOA är att utveckla en lös koppling mellan moduler, och en applikation kan byggas där modulerna inte är kopplade till varandra för hårt. Denna typ av struktur kan byggas eller formas med hjälp av JAVA.

vilka är egenskaperna hos SOA?

• lös anslutning-tjänsterna i SOA är löst sammanlänkade för att bilda en anslutning. Detta ger en förutsättning för modicum av det ömsesidiga beroendet mellan varje tjänst. Huvudtanken är att minska det ömsesidiga beroendet till den nivå där kompatibiliteten fortfarande upprätthålls.
• gränssnittet för standardiserade tjänster – ett grundläggande krav för SOA är behovet av standardisering av gränssnitt samt detaljer. Detaljerna måste innehålla vilka uppgifter som behövs, hur en tjänst kan användas och hur regler måste tillämpas.
• återanvändbarhet – i SOA är återanvändbarhet av tjänster möjlig även i processkedjan av andra parter och för andra typer av ändamål också.
• sökbarhet för en tjänst – en annan egenskap är att en tjänst lätt måste hittas för att kunna använda den. För alla konsumenter görs serviceförvar tillgängliga, och sådana förvar består av gränssnittet och implementeringsmetoden för tjänsten.
• serviceautonomi – varje tjänst måste kunna fungera och fungera självständigt. Denna term pekar på de tjänster som är självförsörjande och kan hantera resurser, logik och miljö på egen hand.
• kapacitet för serviceorkestrering – detta är en process där en enskild tjänst kombineras med andra sådana tjänster för att resultera i större affärsprocesser eller enheter. Detta är en ytterligare egenskap eller krav för SOA.
• tjänsternas statslöshet – utförandet av tjänster bygger på konceptet att en definierad tjänst tillhandahålls. Detta tar hänsyn till lagring av uppgifter men endast om kravet specificeras eller begärs särskilt.

fördelar och fördelar med SOA

• bättre avkastning på investeringar – en av de största fördelarna med SOA är att det ger en utmärkt avkastning på investeringen. Eftersom processen innebär skapandet av robusta lager, erbjuder var och en av dessa servicelager en bättre avkastning på investeringen som gjordes för att skapa programvaran.
• Kodmobilitet – Detta är ännu en viktig fördel med SOA och är möjlig eftersom det finns en platstransparens i serviceorienterad arkitektur. De flesta kunder bryr sig inte om var tjänsterna finns eftersom det finns en dynamisk bindning samt uppslag till tjänster. Det innebär att de företag som använder SOA kan flytta tjänster till olika maskiner eller flytta dem till externa tjänsteleverantörer.
• återanvändbarheten – en annan fördel med SOA är att de olika koderna och tjänsterna kan användas om och om igen. Det finns bekvämligheten med återanvändning av körtidstjänster, och det är lika enkelt som att hitta en tjänst i katalogen och binda till den. Utvecklarna behöver inte oroa sig för plattformar och andra inkompatibiliteter.
• stöd för olika klienttyper – alla företag kan använda flera klienttyper och flera klienter för att komma åt en tjänst i SOA. Detta beror på att i en sådan struktur eller koncept har lagren delats in i service, och klientlager och olika klienttyper är enklare att implementera.
• en högre nivå av tillgänglighet – flera servrar har flera fall av tjänster som använder dem på grund av att SOA stöder platstransparens. Detta innebär att den totala tillgängligheten är mycket hög. Till exempel, om en maskin eller en del av ett nätverk slutar fungera eller har något problem, kan förfrågningarna omdirigeras till andra tjänster utan att klienten vet det eller störs av det.
• färre defekter – Detta är en stor fördel med SOA. Sannolikheten för defekter är mycket lägre och den övergripande testningen är mycket bättre på grund av publicerade gränssnitt för tjänster som enkelt kan testas. Mer testning innebär en högre noggrannhet och färre defekter.

SOA – utmaningar

• brist på testutrymme-en av de största utmaningarna i SOA är bristen på testutrymme. I en typisk arkitektur finns det inga välformade eller sofistikerade verktyg eller metoder för att testa en huvudlös tjänst som ett meddelande eller en databastjänst. Huvudsyftet med SOA är att erbjuda smidighet till företag och företag. Men på grund av brist på horisontellt förtroende måste man investera i ett testramverk som skulle underlätta utmaningen.
• hantera tjänster Metadata – detta är en vanlig och mycket uppenbar utmaning för SOA. Att hantera tjänsternas metadata är inte bara tufft utan ofta mycket komplicerat. Ett servicebaserat arkitektoniskt utrymme innebär tjänster som interagerar med varandra genom att utbyta budskap. I ett sådant scenario kan en enda tjänst ibland ha miljontals meddelanden genererade. Att hantera dessa många tjänster kan bli mycket svårt, särskilt när tjänsterna levereras av olika företag och avdelningar inom ett företag. Detta skapar många förtroendefrågor.
• tillhandahålla rätt säkerhetsnivåer – en annan utmaning med SOA är att tillhandahålla lämpliga säkerhetsnivåer. Den applikationshanterade säkerheten är inte rätt metod eller modell för att säkra tjänster eftersom säkerhetsmodeller som är utformade för applikationer inte kan räcka när applikationen visar sig för andra.
• interoperabilitet – detta blir en avgörande aspekt av SOA-implementeringar. Ofta, i strävan att minska eller minska det ömsesidiga beroendet av tjänster, kompatibiliteten mellan dem kan minska men beroendet måste minskas till en sådan nivå att kompatibiliteten fortfarande kan bibehållas.
• Leverantörshype – det finns en betydande leverantörshype relaterad till SOA, och detta skapar en viss nivå av otillbörliga förväntningar. Även om det finns många fördelar med SOA, kan det också ha flera nackdelar. Till exempel garanterar SOA inte en minskning av IT-kostnaderna och lovar inte ens förbättring av systemets smidighet. Således skulle det vara bättre om det fanns en tydlig skillnad mellan hype och verklighet.

bygga en serviceorienterad arkitektur

soa Framework

för att förstå hur SOA är byggt måste du först förstå vad dess ramverk är.

SOA ses som 5 olika horisontella lager som är:

1. Consumer interface layer – det här är de appar som får tillgång till service-eller appgränssnitt.
2. Business process layer-Detta är ett lager som är en tjänst som representerar affärsanvändningsfall när det gäller applikationer.
3. tjänster – många tjänster klubbas ihop för att skapa ett helt företag.
4. servicekomponenter – det här är de komponenter eller delar som används för att bygga tjänster som tekniska gränssnitt och tekniska bibliotek etc.
5. operativa system-det här är lagret som innehåller tekniska mönster, datamodeller och datalager etc.

följande är de vertikala skikten i SOA-ramverket som tillämpas på och stöds av de horisontella:

1. Integrationsskikt-detta lager består av protokollstöd eller plattformsintegration, dataintegration, applikations-och tjänsteintegration etc.
2. servicekvalitet-de faktorer som utgör kvaliteten på tjänsten inkluderar tillgänglighet, säkerhet, prestanda och andra.
3. information – Detta lager gör huvudsakligen jobbet med att tillhandahålla affärsrelaterad information.
4. styrning-Detta lager eller IT-strategilager styrs av horisontella lager för att nå kapacitet, såväl som operativ modell, efter behov.

soa Implementation Framework (SOAIF)

soa implementation behöver och kräver run-time infrastrukturell programvara samt verktyg. Detta kan kollektivt kallas service-oriented architecture implementation framework eller SOAIF. Detta koncept syftar till ett omfattande ramverk som erbjuder alla typer av teknik som ett företag kan kräva för att inte bara bygga utan också driva SOA. En SOAIF består av och innehåller både run-time och design-time kapacitet. Den innehåller också mjukvarufunktionalitet som ett företag kan behöva köra en SOA och även bygga den, inklusive serviceorienterad:

• modellering
• Integration
• verktyg
• hantering
• säkerhet
• processer

tillvägagångssätt för SOA

det finns tre huvudtyper eller metoder eller tillvägagångssätt som har dykt upp för klubbinformation, olika och system i ett företag. Eftersom olika tjänsteleverantörer och företag tävlar mot att tillhandahålla lösningar till kunder och konsumenter, dessa metoder hjälper till att uppfylla kraven för grovkorniga, löst klubbade och asynkrona tjänster.

1. Enterprise Service Bus

den första metoden som hjälper till att bygga och implementera en optimal SOA är enterprise service bus eller ESB. Detta tillvägagångssätt hjälper till att samordna och ordna de olika elementen som finns i form av distribuerade tjänster i ett nätverk. Detta tillvägagångssätt anser att systemen är diskreta och distribuerade tjänster som ansluter till varandra genom meddelandeorienterad infrastruktur som är asynkron. Denna typ av meddelandeorienterad infrastruktur gör det möjligt att ha löst kopplade anslutningar mellan oberoende tjänster eller moduler.

2. Business Process Management

många företag, under många år nu, har försökt att lösa affärsprocessproblem genom genomförandet av Business Process Management strategi. Detta tillvägagångssätt tar hänsyn till IT-tillgångar och system som aktiviteter eller uppgifter som deltar i väl synkroniserade och väl orkestrerade affärsprocedurer. BPM-verktyg används huvudsakligen vid modellering och utformning av procedurer snarare än att använda dem för att konstruera processer som kan nå integrationsmål. Detta är den största utmaningen för BPM. Genom BPM lösningar på egen hand är tillräckligt för att uppfylla SOA krav eftersom de inte består av runtime miljö som behövs för löst kopplade moduler.

3. Serviceorienterad Integration

den tredje och sista metoden för korrekt implementering av SOA är den serviceorienterade integrationsmetoden. Detta tillvägagångssätt använder sig av de arkitektoniska vägledande reglerna eller principerna för att bygga en miljö eller ett ekosystem av tjänster som företag kan kombinera dynamiskt och skapa processer på överlägsen nivå som kan möta ständigt föränderliga och utvecklande krav. Detta tillvägagångssätt går förbi tätt kopplade och spröda moduler genom att skapa en åtskillnad mellan konsumenten och producenten av en tjänst. Det ställer således den aspekt av lös koppling som behövs för att implementera SOA korrekt för att uppfylla affärskraven. Även detta tillvägagångssätt i sig är inte tillräckligt för att garantera långa löpande interaktioner mellan tjänster.

de bästa metoderna för att bygga en SOA

medan man bygger en SOA måste man följa några av de bästa och mest fördelarna. Dessa metoder ges enligt följande:

1. Implementeringsteknologier är mycket hypade, och man måste komma ihåg att inte hoppa till dem på grund av deras popularitet. Man måste noga överväga huruvida webbtjänsterna är mer vettiga för deras krav och behov. Det är viktigt att komma ihåg att bygga serviceorienterade applikationer genom att använda teknik som RMI kan vara mer lämpade för ett företags fall snarare än webbtjänster.
2. man måste komma ihåg att inte skapa eller bygga mycket tätt kopplade eller kopplade moduler eftersom detta leder till en spröd installation eller Infrastruktur.
3. det är viktigt att upprätthålla interoperabilitet och för dessa måste man följa ws-I bästa praxis.
4. om du inte ser någon mening med att använda webbtjänster finns det också många andra alternativ som kan väljas.