Hvordan Bygge En Tjenesteorientert Arkitektur (SOA)

Hvordan Bygge En Tjenesteorientert Arkitektur (SOA)

i denne artikkelen fokuserer vi på Temaet Tjenesteorientert Arkitektur (SOA). Vi starter med et dypdykk i 1) SOA: en beskrivelse og går deretter for å diskutere 2) bygge En Serviceorientert Arkitektur.

TJENESTEORIENTERT ARKITEKTUR: EN BESKRIVELSE

Hva ER SOA?

Soa Eller Serviceorientert Arkitektur er en metode der ulike typer tjenester kan samhandle med hverandre uavhengig. En tjeneste er en selvstendig del av funksjonaliteten, og flere tjenester kan kombineres for å gi bruk og funksjonalitet av et program i stor skala. HVA SOA gjør er at det gjør det enklere for programvaredeler På Pcer som er koblet til et nettverk for å samhandle og samarbeide. DESIGNMØNSTERET TIL SOA er slik at applikasjonskomponenter i DEN kan tilby tjenester til andre slike komponenter, hovedsakelig over et nettverk. Hvert datasystem kan kjøre et hvilket som helst antall tjenester, som hver er bygget for å utveksle informasjon med andre forskjellige tjenester i et nettverk uten menneskelig hjelp.

I forretningsterminologi ER SOA et sett MED FORRETNINGSJUSTERTE IT-tjenester som sammen adresserer bedriftens mål og prosesser. Den strukturelle utformingen AV SOA sørger for at det er en justering med kravene i virksomheten, så vel som den teknologiske løsningen av det samme.

de viktigste elementene I SOA

Her er de viktigste elementene I SOA:

• SOA – drivere-SOA-drivere eller bedriftsdrivere inkluderer ting som konkurranse, strategi, reguleringskrefter og markedskrefter. Alle DISSE tingene kommer sammen for å drive forretningsarkitekturen og gi en form til bedriftsomfattende ytelsesstyring
• SOA enablers-de fem VIKTIGSTE SOA enablers er Enterprise business model, Business performance optimization, Portfolio Rationalization, Enterprise Semantics definition og Key performance indicators. Å ha en forretningsmodell er viktig for riktig tilpasning av tjenester med mål og mål for virksomheten. Den semantiske informasjonsmodellen gir felles og generell forretningsrelatert informasjon for en gitt bedrift. Nøkkelindikatorer eller Kpier gjør vurderingen av VIRKNINGEN AV SOA mulig og gjør måling av forretningsprosesser enklere. På den annen side gjør porteføljerasjonalisering konsolidering og forenkling av applikasjoner, data og infrastruktur mulig.
• Soa Implementering – når det gjelder implementering, er forretningstjenester og prosesser de viktigste aspektene. Forretningsprosesser er for det meste knyttet til forretningsmål og mål for driften, mens forretningstjenester på den annen side må være godt justert og er avgjørende for fleksibel og vellykket SOA-implementering. Noen av de andre aspektene knyttet TIL soa implementering Er Enterprise content repositories, semantisk meldinger og integrasjonstjenester. Informasjonen representerer dataressursene til selskapet, og disse dataene sendes i form av dokumenter som gir en slags semantiske meldinger mellom tjenester og prosesser.
• SOA-Støtte – alle funksjoner og elementer fra eksisterende applikasjoner og systemer gjøres tilgjengelig og kan brukes til tjenestene med støtte fra noen integrasjonstjenester som tar av deksler fra eksisterende funksjoner via nye tjenestegrensesnitt.

HOVEDPRINSIPPENE I SOA

følgende er listen over HOVEDPRINSIPPENE I SOA:

• Tjenestearkitektur – Den fysiske utformingen eller utformingen av individuelle tjenester som overgår alle ressursene som ble brukt av en tjeneste.
• tjenestesammensetningsarkitektur – alle tjenestene som er utviklet ved hjelp av serviceorienterte designmetoder, er komposisjonssentriske, og dette er deres hovedtrekk. Denne arkitekturen er derfor sammensetningen av individuelle arkitekturer av ulike tjenester.
• service inventory architecture – denne arkitekturen er dannet fra service inventory blueprint hvor service inventory består av tjenester som automatiserer prosedyrene for bedrifter.
• Tjenesteorientert bedriftsarkitektur – denne typen utgjør komposisjon, service og lagerarkitekturer.

Utviklingen AV SOA-Konseptet

• Monolitisk design – dette designet var relatert til relativt ustrukturert prosedyrekoding
• Objekt – og strukturorientert design-dette er designet som involverer programenheter basert på funksjonalitet.
• Client-server design – to-tier design) – dette er konseptet med distribuert design og er relatert til bunting av funksjoner i to nivåer.
• Distribuert objektdesign (multitier design) – dette designet innebærer objektinteraksjoner i et heterogent miljø og distribuert objektdesign.
• Component object model architecture – Dette Er et design der det er en aggregering av elementer i logikkbaserte deler med sterkt typer, samt et veldefinert grensesnitt.
• Tjenesteorientert arkitektur-Dette er et design som involverer samhandling og kommunikasjon mellom grovkornede tjenester med standard grensesnitt for fleksible interoperasjoner.

SOA og JAVA

Mange utviklere tror AT SOA, så vel som webtjenester, er synonymt med hverandre, men dette er ikke sant. De kan også tro at DET bare ikke er mulig å bygge SOA uten å bruke webtjenester, men I virkeligheten ER SOA et designprinsipp, men webtjenester er en slags implementeringsteknologi. DETTE betyr at SOA faktisk kan bygges uten å bruke implementeringsteknologi av en bestemt type. Men Java er en annen type tradisjonell teknologi som kan brukes til å utvikle Eller bygge Tjenesteorientert Arkitektur.

hovedmålet MED SOA er å utvikle en løs kobling mellom moduler, og en applikasjon kan bygges der modulene ikke er koblet til hverandre for tett. Denne typen struktur kan bygges eller dannes ved HJELP AV JAVA.

hva er EGENSKAPENE TIL SOA?

• Løs tilkobling-tjenestene I SOA er løst koblet sammen for å danne en tilkobling. Dette gir en forutsetning for modicum av gjensidig avhengighet mellom hver tjeneste. Hovedideen er å redusere gjensidig avhengighet til nivået der kompatibiliteten fortsatt opprettholdes.
• det standardiserte tjenestegrensesnittet – et grunnleggende KRAV TIL SOA er behovet for standardisering av grensesnitt samt detaljer. Detaljene må inneholde hvilke data som trengs, hvordan en tjeneste kan brukes og hvordan regler må brukes.
• Gjenbrukbarhet – I SOA er gjenbruk av tjenester mulig i prosesskjeden av andre parter også og for andre typer formål også.
• Finnbarhet av en tjeneste-En annen egenskap er at en tjeneste lett må bli funnet for å kunne bruke den. For alle forbrukere blir servicebeholdninger gjort tilgjengelige, og slike depoter består av grensesnittet og implementeringsmetoden for tjenesten.
• tjenesteautonomi – hver tjeneste må kunne arbeide og fungere uavhengig. Dette begrepet peker på de tjenestene som er selvforsynte og er i stand til å håndtere ressurser, logikk og miljø alene.
• kapasitet for tjenesteorganisering – dette er en prosess der en individuell tjeneste kombineres med andre slike tjenester for å resultere i større forretningsprosesser eller enheter. Dette er en ytterligere karakteristikk eller krav TIL SOA.
• tjenestenes Statsløshet-Tjenestenes Ytelse er basert på konseptet om at en definert tjeneste ytes. Dette tar hensyn til oppbevaring av data, men bare hvis kravet er spesifisert eller forespurt spesielt.

Fordeler og fordeler MED SOA

• Bedre avkastning på investeringen-En av DE største fordelene MED SOA er at DEN gir en ypperlig avkastning på investeringen. Siden prosessen innebærer opprettelse av robuste lag, gir hvert av disse servicelagene en bedre avkastning på investeringen som ble gjort for å lage programvaren.
• Kode mobilitet-Dette er enda en viktig fordel MED SOA og er mulig fordi Det er en plassering åpenhet I Serviceorientert Arkitektur. De fleste kunder bryr seg ikke hvor tjenestene er plassert fordi det er en dynamisk binding samt oppslag til tjenester. Dette betyr at bedriftene som bruker SOA kan flytte tjenester til forskjellige maskiner eller flytte dem til eksterne tjenesteleverandører.
• gjenbrukbarheten – EN annen fordel MED SOA er at de ulike kodene og tjenestene kan brukes om og om igjen. Det er bekvemmeligheten av run-time service gjenbruk, og det er like enkelt som å finne en tjeneste i katalogen og bindende til den. Utviklerne trenger ikke å bekymre seg for plattformer og andre inkompatibiliteter.
• Støtte for ulike klienttyper – ethvert selskap kan bruke flere klienttyper og flere klienter for å få tilgang til en tjeneste I SOA. Dette skyldes at lagene i en slik struktur eller et konsept er delt inn i service, og klientlag og ulike klienttyper er enklere å implementere.
• et høyere tilgjengelighetsnivå-Flere servere har flere tilfeller av tjenester som bruker dem på grunn av AT SOA støtter gjennomsiktighet. Dette betyr at den generelle tilgjengeligheten er svært høy. For eksempel, hvis en maskin eller en del av et nettverk slutter å fungere eller har noe problem, kan forespørslene omdirigeres til andre tjenester uten at klienten vet det eller blir plaget av det.
• Færre feil – Dette er en stor fordel MED SOA. Sannsynligheten for feil er mye lavere, og den generelle testingen er mye bedre på grunn av publiserte grensesnitt av tjenester som kan testes enkelt. Mer testing betyr større nøyaktighet og færre feil.

SOA Utfordringer

• Mangel På Testplass – en AV DE største utfordringene I SOA er mangelen på testplass. I en typisk arkitektur er det ingen velformede eller sofistikerte verktøy eller metoder for å teste en hodeløs tjeneste som en melding eller databasetjeneste. HOVEDMÅLET MED SOA er å tilby smidighet til bedrifter og bedrifter. Men på grunn av mangel på horisontal tillit må man investere i et testramme som vil gjøre utfordringen enklere.
• Administrer Tjenester Metadata – DETTE er en vanlig og veldig åpenbar utfordring FOR SOA. Administrere tjenester metadata er ikke bare tøff, men ofte svært komplisert. Et tjenestebasert arkitektonisk rom innebærer tjenester som samhandler med hverandre ved å utveksle melding. I et slikt scenario kan enkelte tjenester noen ganger ha millioner av meldinger generert. Administrere disse mange tjenestene kan bli svært vanskelig, spesielt når tjenestene leveres av ulike selskaper og avdelinger i et selskap. Dette skaper mange tillitsspørsmål.
• Å Gi riktige nivåer av sikkerheten – EN annen utfordring MED SOA er å gi passende sikkerhetsnivåer. Den programstyrte sikkerheten er ikke den riktige metoden eller modellen for å sikre tjenester fordi sikkerhetsmodeller utformet i applikasjoner ikke kan være tilstrekkelig når applikasjonen viser seg for andre.
• Interoperabilitet-dette blir et viktig aspekt VED SOA-implementeringer. Ofte, i jakten på å redusere eller redusere gjensidig avhengighet av tjenester, kan kompatibiliteten mellom dem redusere, men avhengigheten må reduseres til et slikt nivå at kompatibiliteten fortsatt kan opprettholdes.
• Leverandørhype – DET er en betydelig leverandørhype relatert TIL SOA, og dette skaper et visst nivå av utilbørlige forventninger. MENS DET er mange fordeler MED SOA, kan det også ha flere ulemper. FOR EKSEMPEL GARANTERER SOA ikke en reduksjon I IT-kostnader og lover ikke engang forbedring i smidighet av systemer. Dermed ville det være bedre om det var et klart skille mellom hype og virkelighet.

BYGGE EN TJENESTEORIENTERT ARKITEKTUR

SOA Framework

for å forstå HVORDAN SOA er bygget, må du først forstå hva rammen er.

SOA er sett på som 5 forskjellige horisontale lag som er:

1. Consumer interface layer-dette er appene som har tilgang til service-eller appgrensesnitt.
2. Forretningsprosesslag-Dette er et lag som er en tjeneste som representerer forretningsbrukssaker når det gjelder applikasjoner.
3. Tjenester-Mange tjenester er slått sammen for å skape en hel bedrift.
4. tjenestekomponenter-dette er de komponentene eller delene som brukes til å bygge tjenester som teknologiske grensesnitt og tekniske biblioteker, etc.
5. Operativsystemer – dette er laget som inneholder tekniske mønstre, datamodeller og datalager, etc.

følgende er de vertikale lagene AV SOA framework som brukes på og støttes av de horisontale:

1. Integrasjonslag-dette laget består av protokollstøtte eller plattformintegrasjon, dataintegrasjon, applikasjons-og tjenesteintegrasjon, etc.
2. tjenestekvalitet-faktorene som utgjør kvaliteten på tjenesten inkluderer tilgjengelighet, sikkerhet, ytelse og andre.
3. Informasjons-dette laget gjør hovedsakelig jobben med å gi forretningsrelatert informasjon.
4. Styring – dette laget eller it-strategilaget styres av horisontale lag for å nå kapasitet, samt driftsmodell, etter behov.

Soa Implementation Framework (SOAIF)

SOA-implementering trenger og krever infrastrukturell programvare og verktøy for kjøring. Dette kan kollektivt refereres til som serviceorientert arkitektur implementeringsramme ELLER SOAIF. Dette konseptet tar sikte på et omfattende rammeverk som tilbyr alle typer teknologi som en bedrift kan kreve å ikke bare bygge, men også kjøre SOA. EN SOAIF består av og inkluderer både kjøretid og design-tid evner. Det inkluderer også programvarefunksjonalitet som et selskap kan trenge å kjøre EN SOA og også bygge den, inkludert serviceorientert:

• Modellering
• Integrasjon
• Verktøy
• Ledelse
• Sikkerhet
• Prosesser

Tilnærminger TIL SOA

det er tre hovedtyper eller metoder eller tilnærminger som har oppstått for klubbinformasjon, ulik og systemer i en bedrift. Som ulike tjenesteleverandører og bedrifter rase mot å tilby løsninger til kunder og forbrukere, disse tilnærmingene bidra til å møte kravene til grovkornet, løst clubbed og asynkrone tjenester.

1. Enterprise Service Bus

den første tilnærmingen som bidrar til å bygge og implementere en optimal SOA er enterprise service bus eller ESB. Denne tilnærmingen bidrar til å koordinere og ordne de ulike elementene som er i form av distribuerte tjenester på et nettverk. Denne tilnærmingen anser systemene å være diskrete og distribuerte tjenester som kobles til hverandre gjennom meldingsorientert infrastruktur som er asynkron. Denne typen meldingsorientert infrastruktur gjør det mulig å ha løst koblede forbindelser mellom uavhengige tjenester eller moduler.

2. Business Process Management

Mange selskaper, i mange år nå, har forsøkt å løse forretningsprosesser problemer ved gjennomføring Av Business Process Management tilnærming. Denne tilnærmingen tar HENSYN TIL IT-eiendeler og systemer som aktiviteter eller oppgaver som deltar i godt synkronisert og godt orkestrert forretningsprosedyrer. Bpm-verktøy brukes hovedsakelig på tidspunktet for modellering og utforming av prosedyrer i stedet for å bruke dem til å konstruere prosesser som kan nå integrasjonsmål. Dette er HOVEDUTFORDRINGEN TIL BPM. Ved BPM løsninger på egen hånd er nok til å møte SOA krav fordi de ikke består av runtime miljøet som er nødvendig for løst koblede moduler.

3. Tjenesteorientert Integrasjon

den tredje og siste tilnærmingen til riktig implementering AV SOA er den serviceorienterte integrasjonstilnærmingen. Denne spesielle tilnærmingen gjør bruk av de arkitektoniske veiledende regler eller prinsipper for å bygge et miljø eller økosystem av tjenester som bedrifter kan kombinere dynamisk og skape overlegen nivå prosesser som kan møte stadig skiftende og utviklende krav. Denne tilnærmingen beveger seg forbi tett koblede og sprø moduler ved å skape et skille mellom forbruker og produsent av en tjeneste. Det pålegger dermed aspektet av løs kopling som er nødvendig for å implementere SOA riktig for å møte forretningsbehov. Selv denne tilnærmingen i seg selv er ikke tilstrekkelig til å garantere lang tid kjører interaksjoner mellom tjenester.

Beste praksis for å bygge EN SOA

mens du bygger EN SOA, må man følge noen av de beste og mest fordeler praksis. Disse praksisene er gitt som følger:

1. Implementeringsteknologier er mye hyped, og man må huske å ikke hoppe til dem på grunn av deres popularitet. Man må vurdere nøye hvorvidt web-tjenester gjøre mer fornuftig for deres behov og behov. Det er viktig å huske at å bygge serviceorienterte applikasjoner ved å bruke teknologier som RMI kan være mer egnet for en bedrifts sak i stedet for webtjenester.
2. man må huske å ikke lage eller bygge svært tett koblede eller koblede moduler, da dette fører til en sprø oppsett eller infrastruktur.
3. det er viktig å opprettholde interoperabilitet, og for disse må MAN følge WS-I beste praksis.
4. hvis du ikke ser noen mening i å bruke webtjenester, så er det mange andre alternative alternativer også som kan velges.