Spring Framework

Spring Framework, meestal afgekort tot Spring, is een vrij framework gericht op ontwikkeling van software in de programmeertaal Java. Het framework combineert API's en ideeën waardoor het een alternatief biedt voor de standaard manier van ontwikkelen. Dankzij diverse uitbreidingen wordt het vooral gebruikt als alternatief voor of uitbreiding op technologieën uit J2EE-platform. Versie 3.1, die uitgegeven werd op 13 december 2011, bracht ondersteuning voor Java 7. Spring Framework versie 4 ondersteunt Java 6, 7 en 8. Versie 5 ondersteunt Java 8, 9 en 11.^[2]

Spring Framework
Ontwikkelaar(s)	VMware
Uitgebracht	16 november 2002 (22 jaar geleden)
Recentste versie	6.2.1 (12 december 2024)[1]
Status	Actief
Besturings­systeem	Multiplatform
Geschreven in	Java
Categorie	Framework
Licentie(s)	Apache Licentie v2.0
Versiebeheer	Officiële broncode
Website	(en) Projectpagina
Portaal    Informatica Javaplatform

Geschiedenis

De eerste versie werd ontwikkeld door Rod Johnson en verscheen bij de publicatie van zijn boek "Expert One-on-One J2EE Design and Development"^[3] in 2002. Het framework werd voor het eerst uitgebracht in 2003, onder de Apache License.

J2EE

De normale manier van werken

Het J2EE-platform is gericht op het ontwikkelen van complexe applicaties, voornamelijk voor de zakelijke markt. Het architecturele idee achter dit platform is dat applicaties ontwikkeld worden volgens een functionele opdeling in een aantal lagen (tiers genaamd) en dat iedere laag geïmplementeerd wordt door een aantal componenten. Elke laag heeft een eigen soort component: een servlet of EJB. Deze dienen om zakelijke functionaliteit aan te bieden omkleed met een technische infrastructuur die ervoor zorgt dat andere applicaties en gebruikers de functionaliteit van iedere component kunnen aanspreken.

De technische architectuur bestaat uit een verzameling van technische "dienstverlening": toegang tot databases, communicatiemechanismen en transactiemechanismen. De dienstverlening wordt aangeboden aan het zakelijke gedeelte van een component via een standaard faciliteit, een "container" geheten. Deze container accepteert als invoer een stukje software van een programmeur met daarin de implementatie van de zakelijke functionaliteit en omkleedt deze dan met toegang tot de technische infrastructuur.

Bij het J2EE-platform hoort, naast de API's en andere faciliteiten, een verzameling afspraken over hoe de technische infrastructuur aangesproken en bediend hoort te worden vanuit de zakelijke functionaliteit. Daarnaast zijn er afspraken over hoe de zakelijke functionaliteit aangesloten hoort te worden op de container.

Met deze afspraken in de hand is het in principe mogelijk om de zakelijke functionaliteit zo te schrijven dat deze zonder verandering ingevoerd kan worden in iedere containerimplementatie en transparant toegang kan krijgen tot de specifieke faciliteiten van die container (de zakelijke functionaliteit weet dat er een database is met een bepaalde verzameling tabellen, maar de details (zoals het type database) zijn onbekend - die regelt de container). Daarnaast kan andere software transparant gebruikmaken van de zakelijke functionaliteit -- deze wordt op een standaard manier aangeboden ("gepubliceerd") binnen het systeem en kan dus op een standaard manier benaderd worden.

Kritiek

Op het bovenstaand systeem is vrij veel kritiek te leveren. Met name op het gebied van complexiteit en limitaties van het systeem zijn hele boekwerken van kritiek verschenen.

• Zakelijke functionaliteit in een container krijgen is te ingewikkeld: om transparant te kunnen ontwikkelen, leunt J2EE sterk op configuratie door middel van XML-bestanden. Deze bestanden, ook wel "deployment descriptors", zijn vaak complex omdat ze zeer veel informatie bevatten.
• EJB's zijn ingewikkeld en zwaar: de ontwikkeling van EJB's gaat veel verder dan alleen het definiëren van de zakelijke functionaliteit. Om een EJB goed aan te laten sluiten op de container, moet een EJB uitgerust worden met verschillende extra zaken -- niet alleen een deployment descriptor, maar ook minstens twee interfaces die synchroon gehouden moeten worden met de EJB als deze verandert. Voor bepaalde soorten EJB's komen daar nog extra interfaces en hulpklassen bij.
• EJB's zijn zwaar in gebruik door de manier waarop de container ermee omgaat: de container voegt allerlei nuttige functionaliteit toe, maar deze functionaliteit neemt geheugen en processortijd in beslag. Voor dienstverlening neemt het ook bandbreedte van het netwerk en databasetijd in beslag. Dit laatste kan dusdanig extreme vormen aannemen dat betwijfeld kan worden of EJB's, destijds ontwikkeld als manier om makkelijk veilige databasetoegang en dienstverlening op te zetten, wel geschikt zijn als middel om toepassingen te ontwikkelen die zeer databasegericht zijn.
• De standaard manier om dienstverlening te publiceren is aardig -- maar heeft wel als gevolg dat het gebruiken van diensten de code vastpint op een enkele installatie en ook dat het opvragen van diensten door de hele code heen verspreid wordt.

Om diensten te kunnen gebruiken moet de toegang tot die diensten altijd met naam opgevraagd worden. Dit is een repetitieve aangelegenheid die het ook nog eens nodig kan maken om de software die diensten gebruikt hard vast te pinnen aan een bepaalde containerimplementatie en -installatie. Transparantie houdt op buiten de container; een stuk software van buiten de container dat de diensten van binnen de container wil gebruiken, moet alles bij naam en specifiek adres opvragen.