hvordan man opbygger en serviceorienteret arkitektur (SOA)

hvordan man opbygger en serviceorienteret arkitektur (SOA)

i denne artikel fokuserer vi på emnet serviceorienteret arkitektur (SOA). Vi starter med et dybt dyk i 1) SOA: en beskrivelse og går derefter for at diskutere 2) Opbygning af en serviceorienteret arkitektur.

serviceorienteret arkitektur: en beskrivelse

hvad er SOA?

SOA eller serviceorienteret arkitektur er en metode, hvorigennem forskellige typer tjenester kan interagere med hinanden uafhængigt. En tjeneste er en selvstændig del af funktionaliteten, og flere tjenester kan kombineres for at give brug og funktionalitet af et program i stor skala. Hvad SOA gør, er, at det gør det enklere for programmeldele på pc ‘ er, der er forbundet til et netværk, at interagere og samarbejde. DESIGNMØNSTERET for SOA er sådan, at applikationskomponenter i det kan tilbyde tjenester til andre sådanne komponenter for det meste over et netværk. Hvert computersystem kan køre et hvilket som helst antal tjenester, som hver er bygget til at udveksle information med enhver anden anden tjeneste i et netværk uden menneskelig hjælp.

i forretningsterminologi er SOA et sæt forretningsjusterede IT-tjenester, der tilsammen adresserer forretningsvirksomhedens mål og processer. Det strukturelle design af SOA sørger for, at der er en tilpasning til virksomhedens krav såvel som den teknologiske løsning af det samme.

de vigtigste elementer i SOA

her er de vigtigste elementer i SOA:

• SOA Drivers – SOA drivers eller enterprise business drivers omfatter ting som konkurrence, strategi, regulatoriske kræfter og markedskræfter. Alle disse ting kommer sammen for at drive forretningsarkitekturen og give en form til forretningsomfattende performance management
• SOA enablers-de fem vigtigste SOA enablers er Enterprise business model, Business performance optimering, portefølje rationalisering, Enterprise semantik definition og nøgleindikatorer. At have en forretningsmodel er vigtig for korrekt tilpasning af tjenester med virksomhedens mål og mål. Den semantiske informationsmodel giver den fælles og generelle forretningsrelaterede information for en given virksomhed. Nøglepræstationsindikatorer eller KPI ‘er gør vurderingen af SOA’ s indvirkning mulig og gør måling af forretningsprocesser lettere. På den anden side muliggør porteføljerationalisering konsolidering og forenkling af applikationer, data og infrastruktur.
• SOA implementering – hvad angår implementering er forretningsservice og processer de vigtigste aspekter. Forretningsprocesser er for det meste forbundet med forretningsmål og målsætninger for operationer, mens forretningstjenester på den anden side skal være godt tilpasset og er kritiske for fleksibel og vellykket SOA-implementering. Nogle af de andre aspekter relateret til SOA-implementering er virksomhedsindholdsopbevaringssteder, semantisk besked og integrationstjenester. Oplysningerne repræsenterer virksomhedens dataressourcer, og disse data overføres i form af dokumenter, der giver en slags semantiske meddelelser mellem tjenester og processer.
• SOA Support – alle funktioner og elementer fra de eksisterende applikationer og systemer stilles til rådighed og kan bruges til tjenesterne med understøttelse af nogle integrationstjenester, der tager covers fra de eksisterende funktioner via nye servicegrænseflader.

hovedprincipperne for SOA

følgende er listen over hovedprincipperne for SOA:

• Servicearkitektur – det fysiske layout eller design af individuelle tjenester, der overgår alle de ressourcer, der blev brugt af en tjeneste.
• service composition architecture – alle de tjenester, der er udviklet ved hjælp af serviceorienterede designmetoder, er kompositionscentriske, og dette er deres vigtigste funktion. Denne arkitektur er derfor sammensætningen af individuelle arkitekturer af forskellige tjenester.
• Service inventory architecture – denne arkitektur er dannet ud fra Service inventory blueprint, hvor service inventory består af tjenester, der automatiserer virksomhedernes procedurer.
• serviceorienteret virksomhedsarkitektur-denne type udgør sammensætning, service såvel som lagerarkitekturer.

udviklingen af SOA Concept

• monolitisk design – dette design var relateret til relativt ustruktureret procedurekodning
• objekt – og strukturorienteret design-Dette er designet, der involverer programenheder baseret på funktionaliteter.
• Client-server design (to-tier design) – Dette er begrebet distribueret design og er relateret til bundling af funktionaliteter i to niveauer.
• distribueret objektdesign (multitier design) – dette design involverer objektinteraktioner i et heterogent miljø og distribueret objektdesign.
• Component object model architecture – dette er et design, hvor der er en sammenlægning af elementer i logikbaserede dele med stærkt typer samt en veldefineret grænseflade.
• serviceorienteret arkitektur – Dette er et design, der involverer interaktioner og kommunikation mellem grovkornede tjenester med standardgrænseflader til fleksible interoperationer.

SOA og JAVA

mange udviklere mener, at SOA såvel som internettjenester er synonyme med hinanden, men det er ikke sandt. De kan også tro, at det bare ikke er muligt at bygge SOA uden at bruge internettjenester, men i virkeligheden er SOA et designprincip, men internettjenester er en slags implementeringsteknologi. Det betyder, at SOA faktisk kan bygges uden at gøre brug af implementeringsteknologi af en bestemt art. Men Java er en anden form for en traditionel teknologi, der kan bruges til at udvikle eller opbygge serviceorienteret arkitektur.

hovedformålet med SOA er at udvikle en løs kobling mellem moduler, og der kan bygges en applikation, hvor modulerne ikke er koblet for tæt sammen. Denne form for struktur kan bygges eller dannes ved hjælp af JAVA.

hvad er egenskaberne ved SOA?

• løs forbindelse – tjenesterne i SOA er løst knyttet sammen for at danne en forbindelse. Dette giver en forudsætning for modicum af den indbyrdes afhængighed mellem hver tjeneste. Hovedideen er at reducere den indbyrdes afhængighed til det niveau, hvor kompatibiliteten stadig opretholdes.
• den standardiserede servicegrænseflade – et grundlæggende krav til SOA er behovet for standardisering af grænseflader såvel som detaljer. Detaljerne skal indeholde, hvilke data der er behov for, hvordan en tjeneste kan bruges, og hvordan regler skal anvendes.
• genanvendelighed – i SOA er genanvendelighed af tjenester også mulig i proceskæden af andre parter og også til andre typer formål.
• Findbarhed af en tjeneste – et andet kendetegn er, at en tjeneste let skal findes for at kunne bruge den. For alle forbrugere stilles servicelagre til rådighed, og sådanne lagre består af grænsefladen og implementeringsmetoden for tjenesten.
• service autonomi – hver tjeneste skal kunne arbejde og fungere uafhængigt. Dette udtryk peger på de tjenester, der er selvforsynende og er i stand til at styre ressourcer, logik og miljøet alene.
• kapacitet til serviceorkestrering – dette er en proces, hvor en individuel service kombineres med andre sådanne tjenester for at resultere i større forretningsprocesser eller enheder. Dette er et yderligere kendetegn eller krav til SOA.
• statsløshed af tjenester – udførelse af tjenester er baseret på konceptet om, at en defineret tjeneste udføres. Dette tager højde for opbevaring af data, men kun hvis kravet er specificeret eller anmodet specielt.

fordele og fordele ved SOA

• bedre investeringsafkast – en af de største fordele ved SOA er, at det giver et fremragende investeringsafkast. Da processen indebærer oprettelse af robuste lag, giver hvert af disse servicelag et bedre afkast af den investering, der blev gjort for at oprette programmet.
• Kodemobilitet – dette er endnu en vigtig fordel ved SOA og er mulig, fordi der er en placeringsgennemsigtighed i serviceorienteret arkitektur. De fleste kunder er ligeglad med, hvor tjenesterne er placeret, fordi der er en dynamisk binding såvel som opslag til tjenester. Det betyder, at de virksomheder, der bruger SOA, kan flytte tjenester til forskellige maskiner eller flytte dem til eksterne tjenesteudbydere.
• genanvendeligheden – en anden fordel ved SOA er, at de forskellige koder og tjenester kan bruges igen og igen. Der er bekvemmeligheden ved genbrug af run-time service, og det er lige så let som at finde en service i biblioteket og binde til den. Udviklerne behøver ikke at bekymre sig om platforme og andre uforeneligheder.
• Support til forskellige klienttyper – enhver virksomhed kan bruge flere klienttyper og flere klienter til at få adgang til en tjeneste i SOA. Dette skyldes, at lagene i en sådan struktur eller et koncept er opdelt i service, og klientlag og forskellige klienttyper er enklere at implementere.
• et højere niveau af tilgængelighed – flere servere har flere tilfælde af tjenester, der bruger dem på grund af det faktum, at SOA understøtter placeringsgennemsigtighed. Det betyder, at den samlede tilgængelighed er meget høj. For eksempel, hvis en maskine eller en del af et netværk holder op med at arbejde eller har noget problem, kan anmodningerne omdirigeres til andre tjenester uden at klienten ved det eller bliver generet af det.
• færre fejl – Dette er en stor fordel ved SOA. Sandsynligheden for fejl er meget lavere, og den samlede test er meget bedre på grund af offentliggjorte grænseflader af tjenester, der let kan testes. Mere test oversætter til et større niveau af nøjagtighed og færre fejl.

SOA udfordringer

• manglende testplads – en af de største udfordringer i SOA er manglen på testplads. I en typisk arkitektur er der ingen velformede eller sofistikerede værktøjer eller metoder til at teste en hovedløs tjeneste, såsom en besked eller databasetjeneste. Hovedformålet med SOA er at tilbyde agility til virksomheder og virksomheder. Men på grund af manglende horisontal tillid skal man investere i en testramme, der vil gøre udfordringen lettere.
• Administrer tjenester Metadata – dette er en fælles og meget indlysende udfordring SOA. Administration af tjenester metadata er ikke bare hård, men ofte meget kompliceret. Et servicebaseret arkitektonisk rum involverer tjenester, der interagerer med hinanden ved at udveksle besked. I et sådant scenario kan en enkelt tjeneste undertiden have millioner af meddelelser genereret. Håndtering af disse mange tjenester kan blive meget vanskeligt, især når tjenesterne leveres af forskellige virksomheder og afdelinger i en virksomhed. Dette skaber mange tillidsproblemer.
• tilvejebringelse af de rette sikkerhedsniveauer – en anden udfordring ved SOA er at tilvejebringe passende sikkerhedsniveauer. Den applikationsstyrede sikkerhed er ikke den rigtige metode eller model til sikring af tjenester, fordi sikkerhedsmodeller designet til applikationer ikke kan være tilstrækkelige, når applikationen viser sig for andre.
• interoperabilitet – dette bliver et afgørende aspekt af SOA-implementeringer. Ofte, i bestræbelserne på at reducere eller mindske den indbyrdes afhængighed af tjenester, kompatibiliteten mellem dem kan reducere, men afhængigheden skal reduceres til et sådant niveau, at Kompatibilitet stadig kan opretholdes.
• Leverandørhype – der er en betydelig leverandørhype relateret til SOA, og dette skaber et vist niveau af unødige forventninger. Selvom der er mange fordele ved SOA, kan det også have flere ulemper. For eksempel garanterer SOA ikke en reduktion i IT-omkostninger og lover ikke engang forbedring af systemernes smidighed. Således ville det være bedre, hvis der var en klar skelnen mellem hype og virkelighed.

opbygning af en serviceorienteret arkitektur

SOA-ramme

for at forstå, hvordan SOA er bygget, skal du først forstå, hvad dens ramme er.

SOA ses som 5 forskellige vandrette lag, som er:

1. Consumer interface layer – dette er de apps, der får adgang til service-eller appgrænseflader.
2. Business process layer-dette er et lag, der er en tjeneste, der repræsenterer business use-cases for så vidt angår applikationer.
3. Services – mange tjenester er clubbed sammen for at skabe en hel virksomhed.
4. Servicekomponenter – dette er de komponenter eller dele, der bruges til at opbygge tjenester som teknologiske grænseflader og tekniske biblioteker osv.
5. operationelle systemer – dette er laget, der indeholder tekniske mønstre, datamodeller og datalager mv.

følgende er de lodrette lag af SOA-rammer, der anvendes på og understøttes af de vandrette:

1. Integrationslag – dette lag består af protokolstøtte eller platformintegration, dataintegration, applikations-og serviceintegration osv.
2. servicekvalitet – de faktorer, der omfatter servicekvaliteten, omfatter tilgængelighed, sikkerhed, ydeevne og andre.
3. Information – dette lag gør hovedsageligt jobbet med at levere forretningsrelateret information.
4. styring – dette lag eller IT-strategilag styres af vandrette lag for at nå kapacitet såvel som driftsmodel efter behov.

SOA Implementeringsramme (SOAIF)

SOA implementeringsbehov og kræver driftstid infrastrukturelle programmer samt værktøjer. Dette kan kollektivt betegnes som serviceorienteret arkitektur implementeringsramme eller SOAIF. Dette koncept sigter mod en omfattende ramme, der tilbyder alle former for teknologi, som en virksomhed kan kræve for ikke kun at bygge, men også køre SOA. En SOAIF består af og omfatter både run-time og design-time kapaciteter. Det inkluderer også programmelfunktionalitet, som en virksomhed muligvis har brug for at køre en SOA og også bygge den, inklusive serviceorienteret:

• modellering
• Integration
• værktøjer
• Ledelse
• sikkerhed
• processer

tilgange til SOA

der er tre hovedtyper eller metoder eller tilgange, der er opstået for klubinformation, forskellige og systemer i en virksomhed. Da forskellige tjenesteudbydere og virksomheder kæmper mod at levere løsninger til kunder og forbrugere, hjælper disse tilgange med at opfylde kravene til grovkornede, løst klumpede og asynkrone tjenester.

1. Enterprise Service Bus

den første tilgang, der hjælper med at opbygge og implementere en optimal SOA, er enterprise service bus eller ESB. Denne tilgang hjælper med at koordinere og arrangere de forskellige elementer, der er i form af distribuerede tjenester på et netværk. Denne tilgang betragter systemerne som diskrete og distribuerede tjenester, der forbinder hinanden gennem meddelelsesorienteret infrastruktur, der er asynkron. Denne form for en meddelelsesorienteret infrastruktur gør det muligt at have løst koblede forbindelser mellem uafhængige tjenester eller moduler.

2. Business Process Management

mange virksomheder har i mange år nu forsøgt at løse forretningsprocesproblemer ved implementering af Business Process Management-tilgang. Denne tilgang tager hensyn til IT-aktiver og systemer som aktiviteter eller opgaver, der deltager i godt synkroniserede og velorganiserede forretningsprocedurer. BPM-værktøjer bruges hovedsageligt på tidspunktet for modellering og design af procedurer snarere end at bruge dem til at konstruere processer, der kan nå integrationsmål. Dette er den største udfordring for BPM. Ved BPM løsninger på egen hånd er nok til at opfylde SOA krav, fordi de ikke består af runtime miljø, der er nødvendig for løst koblede moduler.

3. Serviceorienteret Integration

den tredje og sidste tilgang til korrekt implementering af SOA er den serviceorienterede integrationsmetode. Denne særlige tilgang gør brug af de arkitektoniske vejledende regler eller principper til at opbygge et miljø eller økosystem af tjenester, som virksomheder kan kombinere dynamisk og skabe processer på overlegen niveau, der kan imødekomme stadigt skiftende og udviklende krav. Denne tilgang bevæger sig forbi tæt koblede og sprøde moduler ved at skabe en sondring mellem forbrugeren og producenten af en tjeneste. Det pålægger således det aspekt af løs kobling, der er nødvendigt for at implementere SOA korrekt for at imødekomme forretningskravene. Selv denne tilgang i sig selv er ikke tilstrækkelig til at garantere lang tid at køre interaktioner mellem tjenester.

de bedste fremgangsmåder til opbygning af en SOA

mens man bygger en SOA, skal man følge nogle af de bedste og mest fordele praksis. Denne praksis er givet som følger:

1. Implementeringsteknologier er meget hypede, og man skal huske ikke at hoppe til dem på grund af deres popularitet. Man skal overveje nøje, om internettjenesterne giver mere mening for deres krav og behov. Det er vigtigt at huske, at opbygning af serviceorienterede applikationer ved at gøre brug af teknologier som RMI kan være mere egnet til en virksomheds sag snarere end internettjenester.
2. man skal huske ikke at oprette eller bygge meget tæt forbundne eller koblede moduler, da dette fører til en skør opsætning eller infrastruktur.
3. det er vigtigt at opretholde interoperabilitet, og for disse skal man følge bedste praksis i vs.
4. hvis du ikke ser nogen mening i at bruge internettjenester, er der også mange andre alternative muligheder, som kan vælges.