Vad är serviceorienterad arkitektur?

Serviceorienterad arkitektur (SOA) uppstod i början av detta århundrade som en utveckling av distribuerad databehandling. Innan SOA förstås tjänster som slutresultatet av applikationsutvecklingsprocessen. I SOA består själva applikationen av tjänster. Tjänster kan levereras individuellt eller kombineras som komponenter i en större sammansatt tjänst.

Tjänster interagerar över kabeln med ett protokoll som REST eller SOAP (Simple Object Access Protocol). Tjänster är löst kopplade , vilket innebär att tjänstgränssnittet är oberoende av den underliggande implementeringen. Utvecklare eller systemintegratörer kan komponera en eller flera tjänster i en applikation utan att nödvändigtvis veta hur varje tjänst implementeras.

Den här artikeln är en översikt över Java SOA och de viktigaste egenskaperna hos en tjänstorienterad arkitektur implementerad med SOAP-baserade webbtjänster. Jag ska också kort jämföra SOA och mikrotjänster och diskutera skillnaden mellan RESTful och SOAP-baserade webbtjänster i Java.

SOA och webbtjänster

SOA och webbtjänster är ofta sammansatta, men de är inte samma sak. SOA är en arkitektur som gör det möjligt för utvecklare att kombinera flera applikationstjänster till en större sammansatt tjänst. SOA kan implementeras med SOAP-baserade webbtjänster eller REST API: er, eller ibland en kombination av båda. Det är viktigt att förstå att i SOA är en tjänst en fjärr tillgänglig resurs som kan svara på förfrågningar. En webbtjänst implementeras med specifika protokoll.

Varför serviceorienterad arkitektur?

SOA hanterar tre vanliga företagsutmaningar:

  • Svara snabbt på affärsförändringar.
  • Utnyttja befintliga infrastrukturinvesteringar.
  • Stöd nya kanaler för interaktion med kunder, partners och leverantörer.

Företagsinfrastruktur är heterogen mellan operativsystem, applikationer, systemprogramvara och applikationsinfrastruktur. Som ett resultat består många företagssystem av komplexa och inkonsekventa applikationer som levererar en rad ömsesidigt beroende tjänster. Befintliga applikationer som kör nuvarande affärsprocesser är avgörande, så att börja om från början eller ändra dem är ett känsligt förslag. Men företag måste kunna modifiera och utöka teknisk infrastruktur för att möta företagets krav.

SOA och mikrotjänster

Microservices är en arkitektonisk stil som utvecklats från SOA. Båda är distribuerade arkitekturer och båda erbjuder ett frikopplat paradigm. Medan serviceinriktad arkitektur är tyngre för infrastruktur, erbjuder mikrotjänster en mer flexibel, lättviktsutvecklingsstil. Det finns fördelar och nackdelar med båda, och båda används ofta. Generellt sett implementeras eller underhålls SOA oftare av etablerade företag som har resurser för att stödja mer formalitet. Mikrotjänster tilltalar ofta nya eller växande organisationer som kräver smidighet.

Jämfört med en monolitisk arkitektur gör SOAs löst kopplade karaktär det relativt sömlöst att koppla in nya tjänster eller uppgradera befintliga tjänster för nya affärsbehov. Det ger också möjlighet att göra tjänster förbrukningsbara över olika kanaler och att exponera äldre applikationer som tjänster och därigenom skydda infrastrukturinvesteringar.

Eftersom de är löst kopplade kan SOA-komponenter ändras med minimal påverkan på andra komponenter. Komponenter kan också läggas till i arkitekturen på ett standardiserat sätt och de kan skalas för att adressera belastningen.

Som ett exempel kan du överväga hur ett företag kan använda en uppsättning befintliga applikationer för att skapa en ny, sammansatt försörjningskedjeapplikation. Medan de befintliga applikationerna är heterogena och distribuerade över olika system, exponeras deras funktioner och nås med standardgränssnitt.

Matthew Tyson

Viktiga egenskaper hos SOA

SOA kan vara så enkelt som en enskild komponents konsumtionstjänster som tillhandahålls av en annan komponent eller så sofistikerad som en rad komponenter som interagerar via en företagstjänstbuss som MuleSofts ESB. Oavsett vilken skala, nyckeln till en framgångsrik SOA-implementering är att använda så lite komplexitet som möjligt för att uppnå dina mål. Din första och sista fråga bör alltid vara: Uppfyller denna design våra affärsbehov?

Oavsett skala eller komplexitet är mönstret för en serviceorienterad arkitektur mer eller mindre detsamma:

  • Tjänsteleverantörer exponerar slutpunkter och beskriver tillgängliga åtgärder vid varje slutpunkt.
  • Servicekonsumenter utfärdar förfrågningar och konsumerar svar.
  • Tjänsteleverantörer genererar meddelanden för att hantera förfrågningar.

Implementera serviceorienterad arkitektur

För att implementera SOA börjar du med den grundläggande tjänstearkitekturen och tillhandahåller sedan infrastrukturen, vilket innebär protokoll och andra verktyg som möjliggör kommunikation och interoperabilitet. Figur 2 visar ett diagram över en typisk servicearkitektur.

Matthew Tyson

I detta diagram anropar tre konsumenter tjänster genom att skicka meddelanden till en företagstjänstbuss, som omvandlar och dirigerar meddelandena till en lämplig tjänstimplementering. En motor för affärsregler innehåller affärsregler i en tjänst eller över flera tjänster. Ett servicehanteringslager hanterar aktiviteter som revision, fakturering och loggning.

Komponenter i denna arkitektur är löst kopplade så att de kan kopplas bort eller uppdateras med relativt minimal inverkan på applikationen som helhet. Detta ger företaget flexibilitet att lägga till eller uppdatera affärsprocesser efter behov. För det mesta bör ändringar av enskilda tjänster inte påverka andra tjänster i hög grad.

SOAP vs RESTful webbtjänster

Det är möjligt att anta SOA-stilen och implementera den med REST, till exempel med JAX-RS API eller Spring Boot Actuator, men den diskussionen är utom räckhåll för denna artikel. Se "SOAP vs REST vs JSON" för en användbar jämförelse av SOAP vs RESTful webbtjänster. Det finns också viss överlappning mellan RESTful webbtjänster och den lättare stilen som är förknippad med mikrotjänster.

SOAP-baserade webbtjänster

Webbtjänster som implementeras med SOAP är fortfarande styvare än en RESTful implementering av webbtjänster eller mikrotjänster, men mycket mer flexibla än SOAs tidiga dagar. Här tittar vi bara på de protokoll på hög nivå som krävs för SOAP-baserade webbtjänster.

SOAP, WSDL och XSD

SOAP, WSDL och XSD är den grundläggande infrastrukturen för en SOAP-baserad webbtjänstimplementering. WSDL används för att beskriva tjänsten och SOAP är transportlagret för att skicka meddelanden mellan servicekonsumenter och leverantörer. Tjänster kommunicerar med meddelanden som formellt definierats med hjälp av XML Schema (XSD). Du kan tänka på WSDL som tjänstens gränssnitt (löst analogt med ett Java-gränssnitt). Implementeringen sker i Java-klasser och kommunikation över nätverket sker via SOAP. Funktionellt skulle en konsument leta efter en tjänst, få WSDL för den tjänsten och sedan anropa tjänsten med SOAP.

Säkerhet för webbtjänster

WS-I Basic Profile 2.0-specifikationen adresserar meddelandesäkerhet. Denna specifikation fokuserar på autentiseringsutbyte, meddelandets integritet och meddelandesekretess.

Webbtjänst upptäckt

När hörnstenen i upptäckten av webbtjänster har UDDI (Universal Description, Definition and Integration) bleknat in i historien. Idag är det vanligt att exponera en SOAP-baserad webbtjänst på samma sätt som med någon annan tjänst, via en slutpunkts-URL. Som ett exempel kan du använda JAX-WS Service Endpoint Interface och dess @WebServiceoch @WebMethodkommentarer.

Bygga och distribuera webbtjänster

Java-utvecklare har flera alternativ för att bygga och distribuera SOAP-baserade webbtjänster, inklusive Apache Axis2 och Spring-WS; dock är Java-standarden JAX-WS, Java API för XML-webbtjänster. Kärnidén bakom JAX-WS är att skapa Java-klasser och kommentera dem för att skapa de nödvändiga artefakterna. Under huven använder JAX-WS flera Java-paket, inklusive JAXB, ett allmänt bibliotek för att binda Java-klasser till XML.

JAX-WS döljer den underliggande komplexiteten och protokollen från utvecklaren, vilket effektiviserar processen för att definiera och distribuera Java-baserade SOAP-tjänster. Moderna Java IDE som Eclipse inkluderar fullt stöd för att utveckla JAX-WS webbtjänster. JAX-WS-specifikationen har också valts för pågående utveckling i Jakarta EE.

Slutsats

Tjänsteorienterad arkitektur som implementeras med SOAP-baserade webbtjänster kräver mer rigida och formella definitioner än RESTful webbtjänster eller mikrotjänster. Vissa större organisationer fortsätter dock att gynna den mer formella stil som tillämpas av SOAP. Många stora äldre system är också byggda på SOAP, och vissa B2B och interna system väljer SOAP-baserade webbtjänster för sina mer formellt definierade API-kontrakt. Oavsett om du utvecklar eller underhåller ett storskaligt företagssystem, kommer du att förstå SOA-mönstret och kunna utvärdera dina alternativ för att implementera det väl i din programmeringskarriär.

Denna berättelse, "Vad är serviceorienterad arkitektur?" publicerades ursprungligen av JavaWorld.