Webdiensten en microdiensten

Er zijn verschillende manieren om een SOA-integratie te implementeren, maar laten we ons concentreren op twee.

• Webdiensten

Webservices zijn de meest gebruikelijke manier om een SOA te implementeren. Ze zijn gebaseerd op protocollen als HTTP, FTP en SMTP. Er zijn twee hoofdstijlen van webdiensten, SOAP en REST.
De SOAP-webdiensten maken gebruik van een reeks op XML gebaseerde open normen zoals SOAP, WSDL en UDDI om een gemeenschappelijke aanpak te bieden voor het definiëren, publiceren en gebruiken van webdiensten [1].
SOAP is een standaard lichtgewicht protocol voor de uitwisseling van informatie in een gedistribueerde omgeving. Het is een op XML gebaseerd protocol dat uit drie delen bestaat: een enveloppe die een kader definieert om te beschrijven wat er in een bericht staat en hoe het moet worden verwerkt, een reeks coderingsregels om instanties van door toepassingen gedefinieerde datatypes uit te drukken, en een conventie voor het weergeven van remote procedure calls en antwoorden. SOAP kan worden gebruikt in combinatie met verschillende protocollen (HTTP, SMTP, enz.) [2].
De definitie van de SOAP-webdienst staat in de WSDL (Web Services Description Language). Een WSDL-document beschrijft netwerkdiensten als een reeks eindpunten die werken op berichten die ofwel documentgerichte ofwel proceduregerichte informatie bevatten. De operaties en berichten worden abstract beschreven, en vervolgens gebonden aan een concreet netwerkprotocol en berichtformaat om een eindpunt te definiëren. Verwante concrete eindpunten worden gecombineerd tot abstracte eindpunten (diensten). WSDL is uitbreidbaar zodat eindpunten en hun berichten kunnen worden beschreven, ongeacht de berichtformaten of netwerkprotocollen die worden gebruikt om te communiceren [3].
Aangezien gegevens in XML worden uitgewisseld, kunnen zich bij een groot aantal berichten prestatieproblemen voordoen, maar het is mogelijk SOAP te gebruiken met Web Services Security, een standaard voor het ondertekenen en versleutelen van berichten voor een veiliger informatie-uitwisseling [1].
De REST (Representational State Transfer) webdiensten kunnen, in tegenstelling tot de SOAP-diensten, verschillende gegevensformaten aan (XML, JSON, enz.); is gebaseerd op het concept "resource". De dienst is een reeks bronnen die worden geïdentificeerd door de URI (Universal Resource Identifiers). Deze bronnen worden aangeroepen met behulp van HTTP GET, PUT, POST en DELETE (SOAP gebruikt alleen POST) [4].
REST webdiensten vereisen weinig infrastructuurondersteuning behalve standaard HTTP. Ze zijn eenvoudig en doeltreffend omdat HTTP de meest algemeen beschikbare interface is, en die is goed genoeg voor de meeste toepassingen. In veel gevallen weegt de eenvoud van HTTP gewoon op tegen de complexiteit van de invoering van een extra transportlaag [5].
De keuze voor REST of SOAP hangt af van de behoeften en beperkingen van een organisatie. Soms is het beter gebruik te maken van de ondernemingsmogelijkheden die SOAP biedt, of misschien heeft men baat bij een performanter en lichter alternatief zoals REST [1].
Voordat we ingaan op micro services, laten we het hebben over een platform dat geassocieerd wordt met SOA en SOAP web services, de ESB (Enterprise Services Bus).
De ESB is een standaardplatform dat berichtenverkeer, webdiensten, gegevenstransformatie en intelligente routering combineert om het toepassingsuniversum te verbinden en te coördineren met transactionele integriteit in een SOA. Een ESB biedt een sterk gedistribueerde integratieomgeving die het bereik van hub-and-spoke-architecturen overstijgt, en een duidelijke scheiding tussen bedrijfslogica en integratielogica zoals routing en datatransformatie. Een ESB vormt een onderling verbonden raster van berichtenhubs en integratiediensten, waarbij de intelligentie en functionaliteit van het integratienetwerk overal verspreid zijn [6]. Met ESB is de vervanging van een service-implementatie door een andere mogelijk zonder gevolgen voor de afnemers van de service. Dit vereist zowel de dienstinterfaces die door SOA-normen worden gespecificeerd als dat de ESB consumenten in staat stelt diensten aan te roepen op een manier die onafhankelijk is van de plaats waar de dienst zich bevindt en het communicatieprotocol dat wordt gebruikt [7].
 

Figuur 1. SOA en ESB

De ESB lijkt een oplossing voor veel van de integratieproblemen. Maar omdat hij technologie agnostisch is en zijn functies, evenals de diensten die hij levert, incrementeel kunnen worden toegevoegd, zal de ESB, als de organisatie erg groot is, tot uiting komen in de complexiteit en zwaarte ervan, waardoor hij veel van zijn effectiviteit en prestaties verliest.

• Microdiensten

De term "microdienst" is relatief nieuw. Hij werd besproken tijdens een workshop van softwarearchitecten in de buurt van Venetië in mei 2011 om te beschrijven wat de deelnemers zagen als een opkomende gemeenschappelijke architectuur. In mei 2012 besloot dezelfde groep dat de term "micro services" deze nieuwe opkomende trend dekt en beschouwd wordt als een vorm van SOA [8].
Een "microdienst" is een enkele toepassing als een reeks kleine diensten, die elk in een eigen proces draaien en communiceren met lichtgewicht mechanismen, vaak een HTTP resource API. Deze diensten zijn opgebouwd rond zakelijke mogelijkheden en onafhankelijk inzetbaar en schaalbaar. Er is een minimum aan gecentraliseerd beheer van deze diensten, die in verschillende programmeertalen kunnen zijn geschreven en verschillende gegevensopslagtechnologieën kunnen gebruiken. Ze zijn componentized, een belangrijke reden om services als componenten te gebruiken is dat services onafhankelijk inzetbaar zijn, en dus onafhankelijk gewijzigd kunnen worden [8].
 

Figuur 2. Microdiensten

Toepassingen die zijn opgebouwd uit "microdiensten" gebruiken een aanpak die is ontworpen als "smart endpoints and dumb pipes", zij streven naar een zo groot mogelijke ontkoppeling en samenhang bij het ontvangen van een verzoek, het toepassen van de nodige logica en het produceren van een antwoord, waarbij REST de voorkeur geniet. De twee meest gebruikte protocollen zijn HTTP request-response met resource API's en messaging over een lichtgewicht message bus. De gekozen infrastructuur is typisch dom, en maakt gebruik van slimme eindpunten die berichten produceren en consumeren, waarbij het gebruik van een ESB uitdrukkelijk wordt vermeden. Het gegevensbeheer wordt gedecentraliseerd, met één database voor elke dienst. Nu bedrijven als Amazon en Netflix "microservices" invoeren, zou deze integratiestijl de volgende stap van SOA kunnen zijn [8].
 

Ricardo Santos

EAI Consultant en IoT Evangelist bij Polarising
Referenties

1. Servicegerichte architectuur en legacysystemen, http://www.infoq.com/articles/service-oriented-architecture-and-legacy-systems
2. Simple Object Access Protocol (SOAP) 1.1, www.w3.org/TR/2000/NOTE-SOAP-20000508/
3. Web Services Description Language (WSDL) 1.1, https://www.w3.org/TR/wsdl
4. Ramanathan, R.: Service-Driven Approaches to Architecture and Enterprise Integration. IGI Global (2013)
5. Servicegerichte architectuur, http://www.xml.com/pub/a/ws/2003/09/30/soa.html
6. Chappel, D. A.: Enterprise Service Bus: Theorie in de praktijk, O'Reilly Media, Inc.(2004).
7. Acharya, A., Bishop, S., Hopkins, A., Milinski, S., Nott, C., Robinson, R., Adams, J., Keen, M., Verschueren, P.: Patronen: Implementing an SOA Using an Enterprise Service Bus, IBM (2004).
8. Microservices, http://martinfowler.com/articles/microservices.html

Figuur 2 - http://martinfowler.com/articles/microservices.html