Door Krakatau: Het deel dat in de platform abstractie draait hoeft niet te worden aangepast wanneer het platform wijzigt, wat de problemen beperkt tot de HAL, die (mits goed opgezet) redelijk eenvoudig kan worden aangepast.
...
Met die HAL
http://en.wikipedia.org/wiki/Hardware_abstraction (OS - hardware) en de PAL
http://www.stridewiki.com/index.php?title=Platform_Abstraction_Layer -
https://code.google.com/p/pal/ ben ik het helemaal met je eens. De PAL is echter minder bekend en meer specifiek voor een toepassingsgebied.
Het past in de hype dat een ieder zjin eigen API's zou moeten gaan bouwen en zien te verkopen. Alleen is die hype een ongestructureerde aanpak. Het lijkt meer op het SOA idee en het debacle er van (Service Oriented Architecture).
Maar goed..
1/ .Net Het is een runtime en je kan er in bouwen. Koop je iets (COTS) dan moet je de specfieke er bij horende runtime beheren. In beide gevallen moet je hopen (in huis / extern) dat de leverancier goede werkende versies levert voor nieuwe OS releases met nieuwe runtime versies.
2/ Java Het is een virtueel OS (virtuele machine) in een OS. Je kan er een JPRE van maken die bij de applicatie apart staat. Ook hier: nieuwe versie van JAVA en de applicatie (extern/intern) zouden gelijk op moeten lopen.
Het zou allemaal inderdaad redelijk eenvoudig aan te passen moeten zijn.
Ik denk we dat het nog steeds eens zijn met elkaar.
De praktijk
1/ .Net heeft vele versies en wat voor 1 of 2 gemaakt is draait niet zomaar met 3 dan wel 4. Wegens andere issues kan de 1 of 2 versie niet meer op het laatste OS release. Je moet de nieuwste runtime gebruiken. Ergo de business applicaties moeten ook even over. En zie hier het issue ontstaan doordat de businessaplicatie om een of andere reden niet omgezet worden (kosten) of omgezet kunnen worden (leverancier verdwenen, source code niet beschikbaar)
2/ Java komt met de installatie mee met een binding naar de webbrowser, dat is nodig als je java applicaties start onder die browser. Echter een JPRE heeft dat helemaal niet nodig. Ook hier als er een nieuwe java-versie uitkomt verwacht je van de business-applicatie leverancier de er bij horende actie zodat dt blijft lopen. En zie hier nog een uitdaging ontstaan.
(Veel meer voorbeeldsituaties).
Nu ben ik niet meer met je eens.
a/ Er moet niet gewezen worden naar het OS maar naar het falen van de business applicatie leveranciers om aan hun verantwoordelijkheid te voldoen. Dat zou de gangbare houding moeten zijn.
b/ Als gebruiker van de applicatie (afnemersrol) heb je een overeenkomst met de leverancier de maker van jouw applicaties als die de verwachting niet nakomt moet je hem daarop aanspreken, desnoods droppen. Niet gaan vasthouden aan oude omgevingen omdat die het nog doen in jouw situatie. (vastgelegde uitzonderingen daargelaten).
Laten we eens kijken naar andere bedrijfstakken.
Als je een vlucht met een DC3 maakt moet dat ding inclusief voldoen aan de laatste eisen niet aan die van de jaren 1930. Als je met een vrachtauto de weg op wilt heb je ook aan eisen te voldoen, je wordt er anders vanaf gehaald.
In beide voorbeelden alles ondersteund met een juridische insteek.
Kennelijk zijn we met ICT nog niet zo ver dat we zoiets ook gewoon vinden. Waarom eigenlijk niet?