Programmering

Hvad er serviceorienteret arkitektur?

Serviceorienteret arkitektur (SOA) opstod i begyndelsen af ​​dette århundrede som en udvikling af distribueret databehandling. Før SOA, tjenester blev forstået som slutresultatet af applikationsudviklingsprocessen. I SOA er selve applikationen sammensat af tjenester. Tjenester kan leveres individuelt eller kombineres som komponenter i en større, sammensat service.

Tjenester interagerer over ledningen ved hjælp af en protokol såsom REST eller SOAP (Simple Object Access Protocol). Tjenester er løst forbundet, hvilket betyder, at servicegrænsefladen er uafhængig af den underliggende implementering. Udviklere eller systemintegratorer kan komponere en eller flere tjenester i en applikation uden nødvendigvis at vide, hvordan hver tjeneste implementeres.

Denne artikel er en oversigt over Java SOA og nøglekarakteristikaene for en serviceorienteret arkitektur implementeret ved hjælp af SOAP-baserede webtjenester. Jeg sammenligner også kort SOA og mikroservices og diskuterer forskellen mellem RESTful og SOAP-baserede webtjenester i Java.

SOA og webtjenester

SOA og webtjenester er ofte sammensmeltede, men de er ikke det samme. SOA er en arkitektur, der giver udviklere mulighed for at kombinere flere applikationstjenester til en større, sammensat tjeneste. SOA kan implementeres ved hjælp af SOAP-baserede webtjenester eller REST API'er eller undertiden en kombination af begge. Det er vigtigt at forstå det i SOA, a service er en ekstern tilgængelig ressource, der kan svare på anmodninger. EN webservice implementeres ved hjælp af specifikke protokoller.

Hvorfor serviceorienteret arkitektur?

SOA løser tre almindelige forretningsudfordringer:

  • Svar hurtigt på forretningsændringer.
  • Udnyt eksisterende infrastrukturinvesteringer.
  • Støt nye kanaler for interaktion med kunder, partnere og leverandører.

Virksomhedsinfrastruktur er heterogen på tværs af operativsystemer, applikationer, systemsoftware og applikationsinfrastruktur. Som et resultat består mange forretningssystemer af komplekse og inkonsekvente applikationer, der leverer en række indbyrdes afhængige tjenester. Eksisterende applikationer, der kører nuværende forretningsprocesser, er kritiske, så det er en delikat forslag at starte fra bunden eller ændre dem. Men virksomheder skal være i stand til at ændre og udvide teknisk infrastruktur for at imødekomme forretningskrav.

SOA og mikrotjenester

Microservices er en arkitektonisk stil udviklet fra SOA. Begge er distribuerede arkitekturer, og begge tilbyder et afkoblet paradigme. Mens serviceorienteret architecure er tungere for infrastruktur, tilbyder mikroservices en mere fleksibel og let udviklingsstil. Der er fordele og ulemper ved begge, og begge bruges i vid udstrækning. Generelt implementeres eller vedligeholdes SOA oftere af etablerede virksomheder, der har ressourcerne til at understøtte mere formalitet. Microservices appellerer ofte til nye eller voksende organisationer, der kræver smidighed.

Sammenlignet med en monolitisk arkitektur gør SOAs løst koblede natur det relativt problemfrit at tilslutte nye tjenester eller opgradere eksisterende tjenester til nye forretningskrav. Det giver også mulighed for at gøre tjenester forbrugelige på tværs af forskellige kanaler og eksponere ældre applikationer som tjenester og derved beskytte infrastrukturinvesteringer.

Fordi de er løst koblet, kan SOA-komponenter ændres med minimal indvirkning på andre komponenter. Komponenter kan også føjes til arkitekturen på en standardiseret måde, og de kan skaleres til at adressere belastningen.

Overvej som et eksempel, hvordan en virksomhed kan bruge et sæt eksisterende applikationer til at oprette en ny, sammensat forsyningskædeapplikation. Mens de eksisterende applikationer er heterogene og distribueret på tværs af forskellige systemer, eksponeres og åbnes deres funktionalitet ved hjælp af standardgrænseflader.

Matthew Tyson

Nøgleegenskaber ved SOA

SOA kan være så simpelt som en enkelt komponentsforbrugende tjenester leveret af en anden komponent eller så sofistikeret som en række komponenter, der interagerer via en enterprise-servicebus, såsom MuleSofts ESB. Uanset hvad skalaen er, er nøglen til en vellykket SOA-implementering at bruge så lidt kompleksitet som muligt for at nå dine mål. Dit første og sidste spørgsmål skal altid være: Opfylder dette design vores forretningskrav?

Uanset skala eller kompleksitet er mønsteret for en serviceorienteret arkitektur stort set det samme:

  • Tjenesteudbydere udsætter slutpunkter og beskriver de tilgængelige handlinger ved hvert slutpunkt.
  • Serviceforbrugere udsteder anmodninger og forbruger svar.
  • Tjenesteudbydere genererer meddelelser til håndtering af anmodninger.

Implementering af serviceorienteret arkitektur

For at implementere SOA starter du med den grundlæggende servicearkitektur og leverer derefter infrastrukturen, hvilket betyder protokoller og andre værktøjer, der muliggør kommunikation og interoperabilitet. Figur 2 viser et diagram over en typisk servicearkitektur.

Matthew Tyson

I dette diagram påkalder tre forbrugere tjenester ved at sende meddelelser til en virksomheds servicebus, som omdanner og dirigerer meddelelserne til en passende serviceimplementering. EN forretningsregler motor inkorporerer forretningsregler i en tjeneste eller på tværs af tjenester. EN servicestyringslag administrerer aktiviteter som revision, fakturering og logning.

Komponenter i denne arkitektur er løst koblet, så de kan slukkes eller opdateres med relativt minimal indvirkning på applikationen som helhed. Dette giver virksomheden fleksibilitet til at tilføje eller opdatere forretningsprocesser efter behov. For det meste bør ændringer i individuelle tjenester ikke i høj grad påvirke andre tjenester.

SOAP vs RESTful webtjenester

Det er muligt at vedtage SOA-stilen og implementere den med REST, for eksempel ved hjælp af JAX-RS API eller Spring Boot Actuator, men denne diskussion er uden for denne artikels anvendelsesområde. Se "SOAP vs REST vs JSON" for en nyttig sammenligning af SOAP vs RESTful webtjenester. Der er også en vis overlapning mellem RESTful webtjenester og den mere lette stil, der er forbundet med mikrotjenester.

SOAP-baserede webtjenester

Webtjenester implementeret ved hjælp af SOAP er stadig mere stive end en RESTful implementering af webtjenester eller mikrotjenester, men langt mere fleksible end SOAs tidlige dage. Her ser vi bare på de protokoller på højt niveau, der kræves til SOAP-baserede webtjenester.

SÆBE, WSDL og XSD

SOAP, WSDL og XSD er den grundlæggende infrastruktur for en SOAP-baseret implementering af webservices. WSDL bruges til at beskrive tjenesten, og SOAP er transportlaget til afsendelse af meddelelser mellem serviceforbrugere og udbydere. Tjenester kommunikerer med meddelelser, der er formelt defineret ved hjælp af XML Schema (XSD). Du kan tænke på WSDL som tjenestens grænseflade (løst analogt med en Java-grænseflade). Implementeringen sker i Java-klasser, og kommunikation på tværs af netværket sker via SOAP. Funktionelt ville en forbruger søge efter en tjeneste, få WSDL til denne tjeneste og derefter påkalde tjenesten ved hjælp af SOAP.

Webservicesikkerhed

WS-I Basic Profile 2.0-specifikationen adresserer beskedssikkerhed. Denne specifikation fokuserer på legitimationsudveksling, beskedintegritet og meddelelseshemmelighed.

Web service opdagelse

Når hjørnestenen i opdagelsen af ​​webservices er UDDI (Universal Description, Definition and Integration) forsvundet i historien. I dag er det almindeligt at udsætte en SOAP-baseret webtjeneste, som du ville gøre med enhver anden tjeneste, via en slutpunkts-URL. Som et eksempel kan du bruge JAX-WS Service Endpoint Interface og dets @WebService og @WebMethod kommentarer.

Opbygning og implementering af webtjenester

Java-udviklere har flere muligheder for at opbygge og implementere SOAP-baserede webtjenester, herunder Apache Axis2 og Spring-WS; Java-standarden er dog JAX-WS, Java API til XML Web Services. Kerneideen bag JAX-WS er ​​at oprette Java-klasser og kommentere dem for at skabe de krævede artefakter. Under emhætten bruger JAX-WS flere Java-pakker, herunder JAXB, et bibliotek til generelle formål til binding af Java-klasser til XML.

JAX-WS skjuler den underliggende kompleksitet og protokoller fra udvikleren og strømliner dermed processen med at definere og implementere Java-baserede SOAP-tjenester. Moderne Java IDE'er som Eclipse inkluderer fuld support til udvikling af JAX-WS webtjenester. JAX-WS-specifikationen er også valgt til løbende udvikling i Jakarta EE.

Konklusion

Tjenesteorienteret arkitektur implementeret med SOAP-baserede webtjenester kræver mere stive og formelle definitioner af service end RESTfulde webtjenester eller mikrotjenester. Imidlertid foretrækker nogle større organisationer fortsat den mere formelle stil, der håndhæves af SOAP. Mange store ældre systemer er også bygget på SOAP, og nogle B2B og interne systemer vælger SOAP-baserede webtjenester til deres mere formelt definerede API-kontrakter. Uanset om du udvikler eller vedligeholder et større virksomhedssystem, vil forståelse af SOA-mønsteret og være i stand til at evaluere dine muligheder for at implementere det tjene dig godt i din programmeringskarriere.

Denne historie, "Hvad er serviceorienteret arkitektur?" blev oprindeligt udgivet af JavaWorld.

$config[zx-auto] not found$config[zx-overlay] not found