Serviceorienteret arkitektur (SOA) opstod i den tidlige del af dette århundrede som en udvikling af distribueret computing. Før SOA blev tjenester 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 tjeneste.
Tjenester interagerer over ledningen ved hjælp af en protokol såsom REST eller SOAP (Simple Object Access Protocol). Tjenester er løst koblet, 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øglekarakteristika for en serviceorienteret arkitektur implementeret ved hjælp af SOAP-baserede webtjenester. Jeg vil også kort sammenligne SOA og mikrotjenester og diskutere forskellen mellem RESTful og SOAP-baserede webtjenester i Java.
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.
Enterprise-infrastruktur er heterogen på tværs af operativsystemer, applikationer, systemsoftware og applikationsinfrastruktur. Som et resultat består mange enterprise-systemer af komplekse og inkonsekvente applikationer, der leverer en række af indbyrdes afhængige tjenester. Eksisterende applikationer, der kører aktuelle 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.
Som sammenlignet med en monolitisk archi Tecture, SOAs løst koblede natur gør det relativt problemfrit at tilslutte nye tjenester eller opgradere eksisterende tjenester til nye forretningskrav. Det giver også mulighed for at gøre tjenester forbrugere 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 belastning.
Som et eksempel kan du overveje, hvordan en virksomhed kan bruge et sæt eksisterende applikationer til at oprette en ny, sammensat forsyningskædeanvendelse. Mens de eksisterende applikationer er heterogene og distribueret på tværs af forskellige systemer, eksponeres og tilgås deres funktionalitet ved hjælp af standardgrænseflader.
Figur 1. Forsyningskædeanvendelse i en serviceorienteret arkitektur
Nøglekarakteristika for SOA
SOA kan være så simpelt som en enkelt komponent, der forbruger 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 omfanget 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 størrelse eller kompleksitet er mønsteret af en serviceorienteret arkitektur er mere eller mindre det samme:
- Tjenesteudbydere udsætter slutpunkter og beskriver tilgængelige handlinger ved hvert slutpunkt.
- Tjenesteforbrugere udsteder anmodninger og forbruger svar.
- Tjenesteudbydere genererer meddelelser til håndtering af anmodninger.
Implementering af service- orienteret 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.
Figur 2. En eksempel på servicearkitektur
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 forretningsregelmotor inkorporerer forretningsregler i en tjeneste eller på tværs af tjenester. Et 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-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 vil vi bare se på de høje planprotokoller, der kræves til SOAP-baserede webtjenester.
SOAP, WSDL og XSD
SOAP, WSDL og XSD er den grundlæggende infrastruktur af en SOAP-baseret implementering af webservice. 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 den pågældende tjeneste og derefter påkalde tjenesten ved hjælp af SOAP.
Webservicesikkerhed
WS -I Basic Profile 2.0 specifikation adresserer besked sikkerhed. Denne specifikation fokuserer på udveksling af legitimationsoplysninger, beskedintegritet og fortrolighed med meddelelser.
Opdagelse af webservice
Når hjørnestenen i opdagelse af webservice er UDDI (Universal Description, Definition and Integration) forsvundet ind 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 kunne du bruge JAX-WS Service Endpoint Interface og dens @WebService og @WebMethod kommentarer.
Opbygning og implementering af webtjenester
Java-udviklere har flere muligheder for at opbygge og implementere SOAP-baseret webtjenester, inklusive Apache Axis2 og Spring-WS; Java-standarden er dog JAX-WS, Java API til XML Web Services. Kerneidéen bag JAX-WS er at oprette Java-klasser og kommentere dem for at skabe de krævede artefakter. Under hæ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 at definere og implementere Java-baserede SOAP-tjenester. Moderne Java IDEer som Eclipse inkluderer fuld support til udvikling af JAX-WS-webtjenester. WS-specifikation er også valgt til løbende udvikling i Jakarta EE.
Konklusion
Serviceorienteret arkitektur implementeret med SOAP-baserede webtjenester kræver mere stiv og formelle tjenestedefinitioner end RESTfulde webtjenester eller mikrotjenester. Imidlertid foretrækker nogle større organisationer fortsat den mere formelle stil, der håndhæves af SOAP. Mange ældre store 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.