Wat is servicegerichte architectuur?

Servicegeoriënteerde architectuur (SOA) ontstond in het begin van deze eeuw als een evolutie van gedistribueerd computergebruik. Vóór SOA werden services gezien als het eindresultaat van het applicatieontwikkelingsproces. In SOA bestaat de applicatie zelf uit services. Services kunnen afzonderlijk worden geleverd of gecombineerd als componenten in een grotere, samengestelde service.

Services communiceren via de kabel met behulp van een protocol zoals REST of SOAP (Simple Object Access Protocol). Services zijn losjes gekoppeld , wat betekent dat de service-interface onafhankelijk is van de onderliggende implementatie. Ontwikkelaars of systeemintegrators kunnen een of meer services in een applicatie samenstellen zonder noodzakelijkerwijs te weten hoe elke service is geïmplementeerd.

Dit artikel is een overzicht van Java SOA en de belangrijkste kenmerken van een servicegeoriënteerde architectuur die is geïmplementeerd met behulp van op SOAP gebaseerde webservices. Ik zal ook kort SOA en microservices vergelijken en het verschil bespreken tussen RESTful en SOAP-gebaseerde webservices in Java.

SOA en webservices

SOA en webservices worden vaak samengevoegd, maar ze zijn niet hetzelfde. SOA is een architectuur waarmee ontwikkelaars meerdere toepassingsservices kunnen combineren tot een grotere, samengestelde service. SOA kan worden geïmplementeerd met behulp van op SOAP gebaseerde webservices of REST API's, of soms een combinatie van beide. Het is belangrijk om te begrijpen dat een service in SOA elke op afstand beschikbare bron is die op verzoeken kan reageren. Een webservice wordt geïmplementeerd met behulp van specifieke protocollen.

Waarom servicegerichte architectuur?

SOA pakt drie veelvoorkomende zakelijke uitdagingen aan:

  • Reageer snel op zakelijke veranderingen.
  • Maak gebruik van bestaande infrastructuurinvesteringen.
  • Ondersteun nieuwe interactiekanalen met klanten, partners en leveranciers.

De bedrijfsinfrastructuur is heterogeen tussen besturingssystemen, applicaties, systeemsoftware en applicatie-infrastructuur. Als gevolg hiervan bestaan ​​veel bedrijfssystemen uit complexe en inconsistente applicaties die een reeks onderling afhankelijke services leveren. Bestaande applicaties met huidige bedrijfsprocessen zijn van cruciaal belang, dus helemaal opnieuw beginnen of deze aanpassen is een delicaat voorstel. Maar ondernemingen moeten de technische infrastructuur kunnen aanpassen en uitbreiden om aan de zakelijke eisen te voldoen.

SOA en microservices

Microservices is een bouwstijl die is voortgekomen uit SOA. Beide zijn gedistribueerde architecturen en beide bieden een ontkoppeld paradigma. Waar servicegerichte architectuur zwaarder is voor infrastructuur, biedt microservices een meer flexibele, lichtgewicht ontwikkelstijl. Beide hebben voor- en nadelen, en beide worden veel gebruikt. Over het algemeen wordt SOA vaker geïmplementeerd of onderhouden door gevestigde ondernemingen die over de middelen beschikken om meer formaliteit te ondersteunen. Microservices spreken vaak nieuwe of groeiende organisaties aan die wendbaarheid nodig hebben.

In vergelijking met een monolithische architectuur, maakt SOA's losjes gekoppelde aard het relatief naadloos om nieuwe services aan te sluiten of bestaande services te upgraden voor nieuwe zakelijke vereisten. Het biedt ook de mogelijkheid om services via verschillende kanalen te gebruiken en legacy-applicaties als services te presenteren, waardoor infrastructuurinvesteringen worden veiliggesteld.

Omdat ze losjes zijn gekoppeld, kunnen SOA-componenten worden gewijzigd met minimale impact op andere componenten. Componenten kunnen ook op een gestandaardiseerde manier aan de architectuur worden toegevoegd en ze kunnen worden geschaald om de belasting aan te pakken.

Bedenk bijvoorbeeld hoe een onderneming een set bestaande applicaties zou kunnen gebruiken om een ​​nieuwe, samengestelde supply chain-applicatie te maken. Hoewel de bestaande applicaties heterogeen zijn en verdeeld over verschillende systemen, wordt hun functionaliteit getoond en benaderd via standaard interfaces.

Matthew Tyson

Belangrijkste kenmerken van SOA

SOA kan zo simpel zijn als het verbruiken van services voor één component die door een andere component worden geleverd, of zo geavanceerd als een reeks componenten die samenwerken via een enterprise-servicebus zoals MuleSoft's ESB. Ongeacht de schaal, de sleutel tot een succesvolle SOA-implementatie is om zo min mogelijk complexiteit te gebruiken om uw doelen te bereiken. Uw eerste en laatste vraag zou altijd moeten zijn: voldoet dit ontwerp aan onze zakelijke vereisten?

Ongeacht de schaal of complexiteit, het patroon van een servicegeoriënteerde architectuur is min of meer hetzelfde:

  • Serviceproviders stellen eindpunten bloot en beschrijven de beschikbare acties op elk eindpunt.
  • Serviceconsumenten dienen verzoeken uit en consumeren reacties.
  • Serviceproviders genereren berichten om verzoeken te behandelen.

Service-georiënteerde architectuur implementeren

Om SOA te implementeren, begint u met de basisdienstarchitectuur en levert u vervolgens de infrastructuur, dat wil zeggen protocollen en andere tools die communicatie en interoperabiliteit mogelijk maken. Figuur 2 toont een diagram van een typische service-architectuur.

Matthew Tyson

In dit diagram roepen drie consumenten services aan door berichten naar een bedrijfsservicebus te sturen, die de berichten omzet en naar een geschikte service-implementatie stuurt. Een business rules engine neemt bedrijfsregels op in een service of tussen services. Een servicebeheerlaag beheert activiteiten zoals auditing, facturering en logboekregistratie.

Componenten in deze architectuur zijn losjes gekoppeld, zodat ze kunnen worden uitgeschakeld of geüpdatet met relatief minimale impact op de applicatie als geheel. Dit geeft de onderneming de flexibiliteit om bedrijfsprocessen naar behoefte toe te voegen of bij te werken. Veranderingen in individuele services zouden voor het grootste deel geen grote invloed moeten hebben op andere services.

SOAP versus RESTful webservices

Het is mogelijk om de SOA-stijl over te nemen en te implementeren met REST, bijvoorbeeld met behulp van de JAX-RS API of Spring Boot Actuator, maar die discussie valt buiten het bereik van dit artikel. Zie "SOAP vs REST vs JSON" voor een handige vergelijking van SOAP vs RESTful webservices. Er is ook enige overlap tussen RESTful-webservices en de lichtere stijl die bij microservices hoort.

SOAP-gebaseerde webservices

Webservices die met SOAP worden geïmplementeerd, zijn nog steeds stijver dan een RESTful-implementatie van webservices of microservices, maar veel flexibeler dan de vroege dagen van SOA. Hier zullen we alleen kijken naar de protocollen op hoog niveau die vereist zijn voor op SOAP gebaseerde webservices.

SOAP, WSDL en XSD

SOAP, WSDL en XSD vormen de fundamentele infrastructuur van een op SOAP gebaseerde webservice-implementatie. WSDL wordt gebruikt om de service te beschrijven en SOAP is de transportlaag voor het verzenden van berichten tussen serviceconsumenten en providers. Services communiceren met berichten die formeel zijn gedefinieerd met behulp van XML Schema (XSD). U kunt WSDL zien als de interface van de service (losjes analoog aan een Java-interface). De implementatie gebeurt in Java-klassen en communicatie over het netwerk gebeurt via SOAP. Functioneel gezien zou een consument naar een service zoeken, de WSDL voor die service ophalen en de service vervolgens aanroepen met SOAP.

Beveiliging van webservices

De WS-I Basic Profile 2.0-specificatie heeft betrekking op berichtbeveiliging. Deze specificatie is gericht op het uitwisselen van inloggegevens, berichtintegriteit en vertrouwelijkheid van berichten.

Ontdekking van webservices

UDDI (Universal Description, Definition and Integration), ooit de hoeksteen van het opsporen van webservices, is in de geschiedenis verdwenen. Tegenwoordig is het gebruikelijk om een ​​op SOAP gebaseerde webservice weer te geven zoals elke andere service, via een eindpunt-URL. Als voorbeeld, kon u de JAX-WS dienst Endpoint Interface en te gebruiken @WebServiceen @WebMethodannotaties.

Webservices bouwen en implementeren

Java-ontwikkelaars hebben verschillende opties voor het bouwen en implementeren van op SOAP gebaseerde webservices, waaronder Apache Axis2 en Spring-WS; De Java-standaard is echter JAX-WS, de Java API voor XML Web Services. Het kernidee achter JAX-WS is om Java-klassen te maken en deze te annoteren om de vereiste artefacten te creëren. Onder de motorkap gebruikt JAX-WS verschillende Java-pakketten, waaronder JAXB, een bibliotheek voor algemene doeleinden om Java-klassen aan XML te binden.

JAX-WS verbergt de onderliggende complexiteit en protocollen voor de ontwikkelaar, waardoor het proces van het definiëren en implementeren van op Java gebaseerde SOAP-services wordt gestroomlijnd. Moderne Java IDE's zoals Eclipse bieden volledige ondersteuning voor het ontwikkelen van JAX-WS-webservices. De JAX-WS-specificatie is ook geselecteerd voor voortdurende ontwikkeling in Jakarta EE.

Conclusie

Servicegeoriënteerde architectuur geïmplementeerd met SOAP-gebaseerde webservices vereist meer rigide en formele servicedefinities dan RESTful webservices of microservices. Sommige grotere organisaties blijven echter de voorkeur geven aan de meer formele stijl die wordt afgedwongen door SOAP. Veel grootschalige legacy-systemen zijn ook gebouwd op SOAP, en sommige B2B- en interne systemen kiezen voor SOAP-gebaseerde webservices voor hun meer formeel gedefinieerde API-contracten. Of u nu een grootschalig bedrijfssysteem ontwikkelt of onderhoudt, het begrijpen van het SOA-patroon en het kunnen evalueren van uw opties om het te implementeren, zal u goed van pas komen in uw programmeercarrière.

Dit verhaal, "Wat is servicegerichte architectuur?" is oorspronkelijk gepubliceerd door JavaWorld.