Serviceorientert arkitektur (SOA) dukket opp i begynnelsen av dette århundret som en evolusjon av distribuert databehandling. Før SOA, tjenester ble forstått som sluttresultatet av applikasjonsutviklingsprosessen. I SOA består selve applikasjonen av tjenester. Tjenester kan leveres individuelt eller kombineres som komponenter i en større, sammensatt tjeneste.
Tjenester samhandler over ledningen ved hjelp av en protokoll som REST eller SOAP (Simple Object Access Protocol). Tjenester er løst koblet, som betyr at tjenestegrensesnittet er uavhengig av den underliggende implementeringen. Utviklere eller systemintegratorer kan komponere en eller flere tjenester i en applikasjon uten nødvendigvis å vite hvordan hver tjeneste implementeres.
Denne artikkelen er en oversikt over Java SOA og nøkkelegenskapene til en serviceorientert arkitektur implementert ved bruk av SOAP-baserte webtjenester. Jeg vil også kort sammenligne SOA og mikrotjenester og diskutere forskjellen mellom RESTful og SOAP-baserte webtjenester i Java.
SOA og webtjenester
SOA og webtjenester er ofte sammenslåtte, men de er ikke det samme. SOA er en arkitektur som lar utviklere kombinere flere applikasjonstjenester til en større, sammensatt tjeneste. SOA kan implementeres ved hjelp av SOAP-baserte webtjenester eller REST APIer, eller noen ganger en kombinasjon av begge. Det er viktig å forstå det i SOA, a service er en hvilken som helst ekstern ressurs som kan svare på forespørsler. EN nettjeneste er implementert ved hjelp av spesifikke protokoller.
Hvorfor serviceorientert arkitektur?
SOA adresserer tre vanlige bedriftsutfordringer:
- Svar raskt på forretningsendringer.
- Utnytt eksisterende infrastrukturinvesteringer.
- Støtt nye kanaler for interaksjon med kunder, partnere og leverandører.
Bedriftsinfrastruktur er heterogen på tvers av operativsystemer, applikasjoner, systemprogramvare og applikasjonsinfrastruktur. Som et resultat består mange bedriftssystemer av komplekse og inkonsekvente applikasjoner som leverer en rekke gjensidig avhengige tjenester. Eksisterende applikasjoner som kjører nåværende forretningsprosesser er kritiske, så å starte fra bunnen av eller endre dem er et delikat forslag. Men bedrifter må være i stand til å modifisere og utvide teknisk infrastruktur for å møte forretningsbehov.
SOA og mikrotjenester
Microservices er en arkitektonisk stil utviklet fra SOA. Begge er distribuerte arkitekturer, og begge tilbyr et frakoblet paradigme. Mens serviceorientert arkitektur er tyngre på infrastruktur, tilbyr mikrotjenester en mer fleksibel, lett utviklingsstil. Det er fordeler og ulemper med begge deler, og begge er mye brukt. Generelt sett implementeres eller vedlikeholdes SOA oftere av etablerte virksomheter som har ressurser til å støtte mer formalitet. Mikrotjenester appellerer ofte til nye eller voksende organisasjoner som krever smidighet.
Sammenlignet med en monolitisk arkitektur, gjør SOAs løst koblede natur det relativt sømløst å koble til nye tjenester eller oppgradere eksisterende tjenester for nye forretningskrav. Det gir også muligheten til å gjøre tjenester forbrukbare på tvers av forskjellige kanaler, og å avsløre eldre applikasjoner som tjenester, og dermed sikre infrastrukturinvesteringer.
Fordi de er løst koblet, kan SOA-komponenter endres med minimal innvirkning på andre komponenter. Komponenter kan også legges til arkitekturen på en standardisert måte, og de kan skaleres til for å adressere belastningen.
Som et eksempel kan du vurdere hvordan en bedrift kan bruke et sett med eksisterende applikasjoner for å opprette en ny, sammensatt forsyningskjedeapplikasjon. Mens eksisterende applikasjoner er heterogene og distribueres over forskjellige systemer, blir funksjonaliteten deres eksponert og tilgjengelig ved hjelp av standardgrensesnitt.
Matthew Tyson Nøkkelegenskaper ved SOA
SOA kan være så enkelt som en enkeltkomponentkrevende tjenester levert av en annen komponent eller så sofistikert som en rekke komponenter som samhandler via en bedriftstjenestebuss som MuleSofts ESB. Uansett hvilken skala, er nøkkelen til en vellykket SOA-implementering å bruke så lite kompleksitet som mulig for å nå dine mål. Ditt første og siste spørsmål bør alltid være: Oppfyller dette designet våre forretningskrav?
Uavhengig av skala eller kompleksitet er mønsteret til en serviceorientert arkitektur mer eller mindre det samme:
- Tjenesteleverandører avslører sluttpunkter og beskriver tilgjengelige handlinger ved hvert sluttpunkt.
- Tjenesteforbrukere sender forespørsler og bruker svar.
- Tjenesteleverandører genererer meldinger for å håndtere forespørsler.
Implementering av serviceorientert arkitektur
For å implementere SOA starter du med den grunnleggende tjenestearkitekturen, og gir deretter infrastrukturen, det vil si protokoller og andre verktøy som muliggjør kommunikasjon og interoperabilitet. Figur 2 viser et diagram over en typisk tjenestearkitektur.
Matthew Tyson I dette diagrammet påkaller tre forbrukere tjenester ved å sende meldinger til en bedriftstjenestebuss, som transformerer og dirigerer meldingene til en passende tjenesteimplementering. EN forretningsregler motor inkorporerer forretningsregler i en tjeneste eller på tvers av tjenester. EN service management lag administrerer aktiviteter som revisjon, fakturering og logging.
Komponenter i denne arkitekturen er løst koblet, slik at de kan slås av eller oppdateres med relativt minimal innvirkning på applikasjonen som helhet. Dette gir virksomheten fleksibilitet til å legge til eller oppdatere forretningsprosesser etter behov. For det meste bør endringer i individuelle tjenester ikke påvirke andre tjenester i stor grad.
SOAP vs RESTful webtjenester
Det er mulig å ta i bruk SOA-stilen og implementere den med REST, for eksempel ved bruk av JAX-RS API eller Spring Boot Actuator, men den diskusjonen er utenfor omfanget for denne artikkelen. Se "SOAP vs REST vs JSON" for en nyttig sammenligning av SOAP vs RESTful webtjenester. Det er også noe overlapp mellom RESTful webtjenester og den mer lette stilen som er knyttet til mikrotjenester.
SOAP-baserte nettjenester
Webtjenester implementert ved bruk av SOAP er fortsatt stivere enn en RESTful implementering av webtjenester eller mikrotjenester, men langt mer fleksible enn SOAs tidlige dager. Her ser vi bare på høynivåprotokollene som kreves for SOAP-baserte nettjenester.
SOAP, WSDL og XSD
SOAP, WSDL og XSD er den grunnleggende infrastrukturen for en SOAP-basert nettjenesteimplementering. WSDL brukes til å beskrive tjenesten, og SOAP er transportlaget for sending av meldinger mellom tjenesteforbrukere og leverandører. Tjenester kommuniserer med meldinger som er definert formelt ved hjelp av XML Schema (XSD). Du kan tenke på WSDL som tjenestens grensesnitt (løst analogt med et Java-grensesnitt). Implementeringen gjøres i Java-klasser, og kommunikasjon på tvers av nettverket skjer via SOAP. Funksjonelt vil en forbruker lete etter en tjeneste, få WSDL for den tjenesten, og deretter påkalle tjenesten ved hjelp av SOAP.
Webservicesikkerhet
WS-I Basic Profile 2.0-spesifikasjonen adresserer meldingssikkerhet. Denne spesifikasjonen fokuserer på legitimasjonsutveksling, meldingsintegritet og meldingskonfidensialitet.
Funn av nettjeneste
Når hjørnesteinen i oppdagelsen av webtjenester har UDDI (Universal Description, Definition and Integration) bleknet inn i historien. I dag er det vanlig å eksponere en SOAP-basert nettjeneste slik du ville gjort med en hvilken som helst annen tjeneste, via en sluttpunkt-URL. Som et eksempel kan du bruke JAX-WS Service Endpoint Interface og dets @Nettjeneste og @WebMethod kommentarer.
Bygge og distribuere webtjenester
Java-utviklere har flere alternativer for å bygge og distribuere SOAP-baserte webtjenester, inkludert Apache Axis2 og Spring-WS; Java-standarden er imidlertid JAX-WS, Java API for XML Web Services. Kjernetanken bak JAX-WS er å lage Java-klasser og kommentere dem for å lage de nødvendige gjenstandene. Under panseret bruker JAX-WS flere Java-pakker, inkludert JAXB, et universalbibliotek for å binde Java-klasser til XML.
JAX-WS skjuler den underliggende kompleksiteten og protokollene fra utvikleren, og effektiviserer dermed prosessen med å definere og distribuere Java-baserte SOAP-tjenester. Moderne Java IDEer som Eclipse inkluderer full støtte for utvikling av JAX-WS webtjenester. JAX-WS-spesifikasjonen er også valgt for pågående utvikling i Jakarta EE.
Konklusjon
Tjenesteorientert arkitektur implementert med SOAP-baserte nettjenester krever mer stive og formelle definisjoner enn RESTful webtjenester eller mikrotjenester. Imidlertid fortsetter noen større organisasjoner å favorisere den mer formelle stilen som håndheves av SOAP. Mange store eldre systemer er også bygget på SOAP, og noen B2B og interne systemer velger SOAP-baserte webtjenester for sine mer formelt definerte API-kontrakter. Enten du utvikler eller vedlikeholder et storstilt virksomhetssystem, vil du forstå SOA-mønsteret og være i stand til å evaluere alternativene dine for å implementere det i din programmeringskarriere.
Denne historien, "Hva er serviceorientert arkitektur?" ble opprinnelig utgitt av JavaWorld.
