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 systeemintegratoren 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 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.
Waarom servicegeoriënteerde architectuur?
SOA pakt drie veelvoorkomende zakelijke uitdagingen aan. :
- Reageer snel op zakelijke veranderingen.
- Maak gebruik van bestaande infrastructuurinvesteringen.
- Ondersteun nieuwe kanalen voor interactie 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 van onderling afhankelijke services. Bestaande applicaties waarop huidige bedrijfsprocessen worden uitgevoerd, 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.
Als vergeleken met een monolithische archi tecture, maakt de losjes gekoppelde aard van SOA 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 investeringen in infrastructuur 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 te adresseren.
Bedenk bijvoorbeeld hoe een onderneming een set bestaande applicaties zou kunnen gebruiken om een nieuwe, samengestelde supply chain-toepassing. Hoewel de bestaande applicaties heterogeen zijn en over verschillende systemen worden gedistribueerd, wordt hun functionaliteit weergegeven en geopend met behulp van standaardinterfaces.
Figuur 1. Supply-chain applicatie in een service-georiënteerde architectuur
Belangrijkste kenmerken van SOA
SOA kan zo simpel zijn als diensten die door een andere component worden gebruikt voor een enkele component, of zo geavanceerd als een reeks componenten die samenwerken via een enterprise-servicebus zoals de ESB van MuleSoft. 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 schaal of complexiteit, het patroon van een servicegerichte 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 af te handelen.
Implementatie van service- georiënteerde architectuur
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.
Figuur 2. Een voorbeeld van een service-architectuur
In dit diagram roepen drie consumenten services aan door berichten naar een enterprise-servicebus te sturen, die de berichten omzet en naar een geschikte service-implementatie stuurt . Een business rules engine integreert business rules 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 omgeschakeld of bijgewerkt 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. Voor het grootste deel zouden wijzigingen in afzonderlijke services geen grote invloed moeten hebben op andere services.
SOAP-gebaseerde webservices
Webservices die met SOAP worden geïmplementeerd, zijn nog steeds stijver dan een RESTful-webservices of microservices-implementatie, maar veel flexibeler dan de vroege dagen van SOA. Hier kijken we alleen 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). Denk aan WSDL als de interface van de service (losjes analoog aan een Java-interface). De implementatie gebeurt in Java-klassen en communicatie via het netwerk gebeurt via SOAP. Functioneel gezien zou een consument naar een service zoeken, de WSDL voor die service ophalen en vervolgens de service aanroepen met SOAP.
Webservicebeveiliging
De WS -I Basic Profile 2.0-specificatie adresseert berichtbeveiliging. Deze specificatie is gericht op de uitwisseling van inloggegevens, berichtintegriteit en vertrouwelijkheid van berichten.
Detectie van webservices
Ooit de hoeksteen van het opsporen van webservices, is UDDI (Universal Description, Definition and Integration) vervaagd in de geschiedenis. Tegenwoordig is het gebruikelijk om een op SOAP gebaseerde webservice weer te geven zoals elke andere service, via een eindpunt-URL. U kunt bijvoorbeeld de JAX-WS Service-eindpuntinterface en de bijbehorende @WebService en @WebMethod annotaties.
Bouwen en implementeren van webservices
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-webservices. 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 algemeen gebruik om Java-klassen aan XML te binden.
JAX-WS verbergt de onderliggende complexiteit en protocollen voor de ontwikkelaar, waardoor het proces wordt gestroomlijnd van het definiëren en implementeren van op Java gebaseerde SOAP-services. Moderne Java-IDEs zoals Eclipse bevatten volledige ondersteuning voor het ontwikkelen van JAX-WS-webservices. De JAX- De 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.