SOA (Service Oriented Architecture) versus API’s

SOA (Service-oriented architecture) is een ontwikkelmodel voor business software met gedistribueerde applicatiebouwstenen. SOA kent functies voor detectie, autorisatie, data mapping en security. 

Een enterprise SOA model specificeert drie belangrijke eigenschappen:

1. Een ​​breed architectonisch IT model dat het doel van de verschillende applicaties in beeld brengt.
2. De manier waarop we die doelen moeten bereiken.
3. De implementatiespecificaties die meestal gekoppeld zijn aan de formele Web Services Description Language (WSDL) en aan het Simple Object Access Protocol (SOAP).

De behoefte aan gedistribueerde bouwstenen

In de softwareontwikkeling gebruiken we al tientallen jaren programma bouwstenen die op verschillende plaatsen binnen een applicatie een specifieke taak uitvoeren. Toen de behoefte aan applicatie-integratie voor het delen van die bouwstenen op kwam, ontstonden er ideeën over koppelingen van hosting-resources en gedistribueerde databases. Daarom hadden organisaties een concept nodig waarmee ze hun op procedures gebaseerde ontwikkelingsmodel konden aan te passen aan het gebruik van externe, gedistribueerde bouwstenen. Eenvoudige modellen zoals de RPC (Remote Procedure Call ) waren al een goed begin. RPC miste echter de beveiliging en data onafhankelijke bouwstenen die nodig zijn voor het uitvoeren van echt open en gedistribueerde verwerkingen.

De opkomst van SOA

Om SOA aan de zwaardere eisen te laten voldoen moest de IT het oude servicemodel echter volledig herzien. Er was behoefte aan een brede stack aan services die ontwikkelaars aan een applicatie konden leveren met behulp van volledig gedistribueerde softwarebouwstenen. De architectuur die deze services aanbiedt is:

• Open in gebruik.
• Volledige beveiliging.
• Ondersteunt governance.

De naam is Service Oriented Architectuur ofwel SOA. IT bedrijven introduceerden SOA eind jaren negentig als een complete aanpak met principes en requirements.

Belangrijke SOA principes

SOA kent drie belangrijke principes. Die zijn ieder gericht zijn op een ander deel van de levenscyclus van de toepassing:

1. Het eerste principe is een ​​mechanisme te bieden voor het publiceren van beschikbare services, inclusief hun functionaliteit en input / output (I / O) -vereisten. Services publiceert men tevens zo dat ontwikkelaars deze gemakkelijk in applicaties kunnen opnemen.
2. Het tweede principe geeft aan dat procedures en softwarebouwstenen als services gestructureerd moeten worden. De services zijn daarom ontworpen om eenvoudig aan applicaties te koppelen. We kunnen ze alleen gebruiken als dat nodig is.
3. De bouwstenen zijn zo ontworpen dat softwareontwikkelaars ze gemakkelijk kunnen (her)gebruiken, zodat die op een consistente manier applicaties kunnen maken.
4. Het vierde principe is het beheersen van het gebruik van deze services om beveiligings- en besturingsproblemen te voorkomen. Beveiliging in SOA draait sterk rond de beveiliging van de afzonderlijke bouwstenen en het beveiligen van de feitelijke verbindingen tussen de bouwstenen van de architectuur. Dit slaat namelijk terug op de architectuur, identiteits- en authenticatieprocedures die betrekking hebben op de bouwstenen.

Microservices

De opkomst van virtualisatie en cloud moedigden softwareontwikkelaars aan om applicaties te bouwen bestaande uit kleinere functionele bouwstenen. Microservices, een van de laatste kritische softwaretrends, zijn het uitvloeisel van dat ontwikkelingsmodel. Meer bouwstenen en meer interfaces betekenen een ingewikkelder softwareontwerp. Deze complexiteit en foutgevoeligheid is een kenmerk van de meeste SOA-implementaties.

Microservice-gebaseerde software-architecturen zijn feitelijk gemoderniseerde implementaties van het SOA-model. De softwarebouwstenen zijn ontwikkeld als services die API’s op een vereiste manier kunnen aanroepen. Een API-makelaar bemiddelt over de toegang tot bouwstenen en zorgt ervoor dat iedereen de beveiligings- en besturingsinstellingen naleeft. Er zijn ook softwaretechnieken opgenomen om verschillende I/O-formats van microservices aan te passen aan de applicaties die ze gebruiken.

Webservices- en WSDL-modellen

Aanvankelijk was SOA gebaseerd op de RPC- en object-broker-technologieën die rond 2000 beschikbaar waren. Maar de community splitste zich al snel in twee kampen. De eerste is het webservices-kamp, ​​dat een sterk architectonisch en geformaliseerd beheer van procedures en bouwstenen op afstand voorstaat. De tweede is het API-kamp. Dat richt zich op het gebruik van internettechnologie voor toegang tot op afstand gehoste bouwstenen van applicaties.

Het webservicesmodel gebruikte de WSDL om interfaces met services en de SOAP te maken. Zo kan de software procedure- en bouwstenen aanroepen. Webservices werden gebruikt om applicaties te koppelen via een Enterprise Service Bus (ESB). Bedrijven konden hiermee hun applicaties integreren, de efficiëntie garanderen en het gegevensbeheer verbeteren .

Een hele reeks webservices-standaarden werd ontwikkeld en gepromoot door industrieleiders, zoals IBM en Microsoft. Deze standaarden boden een veilige en flexibele manier om software te verdelen in een reeks aparte stukken. Het model was echter moeilijk te gebruiken en het introduceerde vaak aanzienlijke vertragingen in de workflows die tussen de bouwstenen van een applicatie liepen.

SOA versus API’s

Het webservices-model heeft nooit de voorspelde acceptatie bereikt. In feite kwam het in botsing met een ander model met externe bouwstenen op basis van internet: Application Program Interfaces (API’s). API’s bieden weinig overhead en zijn gemakkelijk te begrijpen. Naarmate meer en meer applicaties via het internet werden geïntegreerd, werden API’s als de toekomst gezien.

SOA nog steeds in gebruik

SOA is tegenwoordig nog even krachtig als in het begin. De SOA-principes hebben ons de cloud gebracht en SOA ondersteunt de meest geavanceerde cloud-technieken die tegenwoordig worden gebruikt.

Discussieer mee op LinkedIn.