Serice Oriented Architecture en Object Oriented Programming hebben veel dingen gemeen. Onder andere dat beide termen te veel woorden bevatten. Zijn er nog meer overeenkomsten?
Service Oriented Architecture zou gewoon Architecture moeten zijn en SOA zou A moeten zijn. Het zelfde geldt voor OOP. P of Programming is hier voldoende omdat geen enkele zichzelf respecterende ontwikkelaar tegenwoordig nog code schrijft die niet object georienteerd is.
Net als bij Architeture is bij Programming het "contract first" principe zeer belangrijk; het contract wordt eerst geschreven alvorens men over gaat tot de implementatie van het component of de dienst. Dit verhoogt de kans op goede interoperabiliteit omdat het altijd duidelijk is wat de bedoeling is. De implementatie kan ook perfect worden afgestemd op het contract en dat verhoogt de kwaliteit.
Naast 'contract first' zijn er nog twee belangrijke principes die ik wat extra aandacht wil geven: Abstraction en Reusability (voor de overige 6 principes – lees Principles of Service Design door Thomas Erl).
Abstraction is belangrijk omdat hiermee de implementatie van een component of service niet bekend is voor degene die de service of component aanroept.
Reusability is natuurlijk belangrijk omdat hergebruik kostenbesparing op de implementatie van nieuwe business processen mogelijk maakt. Dit wordt bewerkstelligd door de component of service zo te implementeren dat het niets van de context afweet.
Zo zullen we zien dat de overige 6 principes voor zowel services als componenten geldt. Nergens zullen de principes principieel afwijken van wat er voor component ontwikkeling geldt.
Het enige verschil is dat componenten aan elkaar worden geregen door een programmeur die in een tekstverwerker code ontwikkelt en dat services gebruikt worden door flexibel in te richten bedrijfsprocessen (Business Process Management, Orchestration, Business Rules, etc.). In het ene geval is het de programmeur die procedurele code schrijft in het andere geval is het de business analist die oplossingen ontwikkelt door services "aan elkaar te klikken".
Maar wacht eens even, als dat het enige verschil is… wordt het dan niet tijd dat we dit gaan combineren tot een totaal oplossing? Het beste van beide werelden? P zorgt voor herbruikbare, abstracte componenten en A zorgt voor de orchestratie van de componenten. En we noemen het: Software Architecture 2.0 of SA 2.0?
