JavaBeans
Uit Wikipedia, de vrije encyclopedie
| Portaal Javaplatform |
JavaBeans (ook wel verkort tot Beans) zijn een vorm van component-gebaseerde softwaretechnologie gedefinieerd binnen het Java platform. Een JavaBean is een softwarecomponent dat bepaalde afspraken volgt en zo past binnen een API. Door het volgen van deze afspraken en het gebruikmaken van de faciliteiten van de JavaBeans API, worden JavaBeans tot herbruikbare componenten die configureerbaar zijn op de plaats waar ze uiteindelijk toegepast worden, gemanipuleerd kunnen worden met behulp van softwaretools en die gekoppeld kunnen worden aan andere stukken software (JavaBeans, andere componenten of clientsoftware).
Door hun naam worden JavaBeans vaak verward met Enterprise JavaBeans. Hoewel deze beide componenttechnologieën conceptueel verwant zijn, zijn het uitgesproken aparte zaken.
Inhoud |
[bewerk] Definitie van JavaBeans
In de officiële API specificatie worden JavaBeans gedefinieerd als
-
- Een Java Bean is een herbruikbaar software component die visueel bewerkt kan worden met een ontwikkeltool.
Uit deze definitie volgt direct de noodzaak van de meeste eigenschappen die JavaBeans volgens de specificatie hebben:
- JavaBeans zijn componenten
- Een JavaBean is een afzonderlijk stuk software, een afgebakend en compleet stuk functionaliteit dat in een enkel pakketje samengepakt is.
- JavaBeans zijn herbruikbaar
- Een JavaBean moet generiek zijn in zijn opbouw. Het is niet de bedoeling dat een stuk software dat maar op één plaats en op één manier gebruik kan worden, verwerkt wordt tot JavaBean. Tegelijkertijd betekent het dat een JavaBean configuratiefaciliteiten moet bieden om zijn functioneren aan te kunnen passen aan de specifieke stuatie waarin de Bean ingezet wordt — uiteraard zonder dat daarvoor de code van de Bean aangepast moet worden.
- JavaBeans kunnen visueel bewerkt worden met een ontwikkeltool
- Een JavaBean moet geconfigureerd kunnen worden en wel volgens een algemene manier. Het bestaan van een algemene manier van configureren maakt het mogelijk dat ontwikkeltools deze configuratie aan kunnen spreken zonder precies te weten hoe een specifieke Bean in elkaar zit.
[bewerk] Eigenschappen van een JavaBean
De API specificatie legt vast dat een JavaBean al zijn configureerbare eigenschappen moet benoemen: de zogeheten properties van een JavaBean.
Properties kunnen primitieve types zijn of klassen. Ze kunnen ook geïndexeerd zijn, wat neerkomt op het idee dat een eigenschap uit meerdere delen bestaat met een bepaalde, onderlinge volgorde. Een property hoeft echter niet letterlijk een veld te zijn in een klasse: het mag ook een waarde zijn die samengesteld wordt op het moment dat hij nodig is. Om dit onderscheid mogelijk te maken en verborgen te houden voor gebruikers van een JavaBean, legt de specificatie de afspraak vast dat een property van een Bean niet direct aangesproken hoort te worden, maar uitgelezen en aangepast wordt door middel van gepaste methoden: de zogeheten getter en setter methoden. Ten behoeve van tools geldt daarvoor de harde afspraak voor de namen van getters en setters voor een gegeven property: als een Bean een property prop bezit, dan is er een getter getProp en een setter setProp.
Een Bean definieert zijn eigen getters en setters en de bijbehorende logica. Omdat een Bean helemaal zelf moet weten hoe een property werkt, mag de Bean ook beslissen dat bepaalde waarden voor een property niet toegestaan zijn: de Bean kan zijn veto uitspreken over een aangevraagde verandering in een eigenschap, door middel van een PropertyVetoException.
Naast het stelsel van getters en setters kunnen JavaBeans uitgebreide informatie over hun properties publiceren door middel van het vastleggen van BeanInfo en BeanDescriptor klassen bij JavaBeans. De laatste geeft algemene informatie over de Bean (naam, naam voor weergave, eventuele iconen), de eerste is een optionele klasse die dieper ingaat op de individuele properties.
[bewerk] Events in JavaBeans
De meeste gebruikers van Beans (andere stukken software) vinden het niet alleen interessant om de properties van Beans uit te lezen en aan te passen, maar ook om ervan op de hoogte gesteld te worden als er iets gebeurt waardoor de waarde van een property verandert. De API specificatie legt hiervoor een event model vast.
Binnen dit event model kunnen stukken software aan een Bean aangeven dat ze op de hoogte willen gesteld worden van veranderingen in de eigenschappen van die Bean. Het is aan de Bean om hiervoor te zorgen, eventueel door middel van een hulpklasse die de API hiervoor vastlegt. De Bean mag het eventueel ook mogelijk maken voor externe software om een specifieke property te volgen en niet alle. Om dit alles mogelijk te maken legt de API specificatie vast dat er PropertyChangeEvents zijn en ook PropertyChangeListeners.
Als uitvloeisel van dit mechanisme kan een Bean ook laten weten wanneer het zijn veto over een verandering uitgesproken heeft. Hiertoe dienen de zogeheten VetoableChangeListeners.
[bewerk] Opslag en verzending van JavaBeans
Het is de bedoeling dat JavaBeans het mogelijk maken om hun interne toestand op te slaan en als component op afstand bediend te kunnen worden. Het is daarom de bedoeling dat JavaBeans serializeerbaar zijn.
[bewerk] Eigenverantwoordelijkheid van de programmeur
De JavaBeans component technologie leunt sterk op de eigen verantwoordelijkheid van de programmeur. Het doel van de specificatie is een zo open en flexibel mogelijke API op te stellen die de ontwikkelaars en gebruikers van componenten zo min mogelijk beperkt.
Het wordt daarom aan de programmeur zelf overgelaten om ervoor te zorgen dat een component een goede JavaBean is die zich aan alle afspraken houdt. Descriptors en Infos zijn naar eigen keuze, er zijn nauwelijks interfaces die een bepaald stempel op Beanklassen of ondersteuningen ervoor drukken. Ook moet een programmeur er helemaal zelf voor zorgen dat een Bean goed werkt: ondersteuning van bediening op afstand, multithreading en dergelijke zijn allemaal voor rekening van de programmeur.
[bewerk] Gebruik van een JavaBean
De JavaBeans specificatie legt erg de nadruk op het idee van een JavaBean als een visuele component (hoewel dat niet verplicht is). Zowel het idee dat een JavaBean via een visueel tool geconfigureerd wordt als zelf een interface aanbiedt, is sterk verweven in de standaard. Wat dat betreft is het duidelijk dat JavaBeans een standaard zijn uit de tijd dat de aandacht van het Java Platform veel meer gericht was op desktopapplicaties dan nu.
Het idee achter de specificatie is dat een JavaBean uiteindelijk een component is dat direct in andere software geplugd kan worden. Het is een op zichzelf staand stuk functionaliteit dat gebruikt wordt en alleen geconfigureerd hoeft te worden (al dan niet met een eigen interface in een grafisch programma). De standaard voorziet in JavaBeans als componenten van iedere schaal, van een simpele widget als een knop tot een complete spreadsheet die van zichzelf weer gebruik maakt van andere JavaBeans (via configuratie). Ook voorziet de standaard in een brug naar andere vormen van componenten als COM en ActiveX componenten (maar definieert niet hoe die brug moet werken).
Daarnaast is een kernpunt van de specificatie dat een JavaBean configureerbaar moet zijn bij middel van visuele tools. Vrijwel iedere klasse en interface rond de JavaBeans specificatie is daarop gerich t: klassen en interfaces om vast te leggen wat de properties van een Bean zijn, wat ze voorstellen en hoe ze weergegeven moeten worden. Klassen om te laten weten wanneer ze veranderen. Klassen om van die andere klassen en interfaces gebruik te maken om Beans te configureren.
[bewerk] JavaBeans componenten in de praktijk
JavaBeans zijn, hoe je het ook wendt of keert, niet geworden wat Sun Microsystems ervan gehoopt had. Bij de introductie van de API in versie 1.1 van het Java Platform had Sun gehoopt een impuls te geven aan een componentenmarkt voor Java vergelijkbaar met de COM, COM+ en ActiveX-markt van Microsoft. Dat is niet gelukt.
Daarvoor zijn een aantal redenen aan te wijzen. Om te beginnen werd de specificatie door Sun opgesteld in een tijd dat Java nog te nieuw was om echt voet aan de grond te hebben bij de commerciële spelers. Ten tweede kampte Java met allerlei problemen die het platform niet aantrekkelijker maakten (een slechte reputatie op het gebied van prestaties, juridische problemen tussen Sun en Microsoft).
Daarnaast hielp het niet echt dat Sun tegelijkertijd op een vrij vage en ondoorzichtige wijze bezig was met allerlei zaken die erg op elkaar leken, waardoor de positionering van bepaalde technieken en technologieën niet erg duidelijk was. JavaBeans hadden met een slechte start te maken en toen kwam Sun aanzetten met Servlets en vooral met Enterprise JavaBeans. Gegeven het feit dat een JavaBean nauwelijks meer is (in principe) dan een "normale" klasse (of groep normale klassen) en wat afspraken, werd opeens heel onduidelijk wat het voordeel was ten opzichte van EJBs en alles wat daardoor aan faciliteiten geboden werd. Bovendien verplaatste de aandacht zich opeens naar webapplicaties en J2EE en verslapte de aandacht voor de desktop — en daarmee ook voor JavaBeans, waarbij de nadruk erg sterk lag op de grafische kant (al dan niet terecht).
Toch hebben JavaBeans en hun faciliteiten een enorme weerslag gehad op het Java Platform en wel op een manier die Sun nooit had kunnen voorzien. Namelijk door het idee van een vaste afspraak over het aanspreken van properties via getters en setters. De oorspronkelijke API specificatie voorzag al in het gebruik van reflectie om de properties van een JavaBean in te stellen, maar leunde erg sterk op allerlei beschrijvingsklassen om het geheel bruikbaar te maken. Sindsdien zijn er echter veel interessante APIs, tools en hele frameworks ontstaan die de beschrijving laten voor wat het is en volledig op reflectie terugvallen om properties in te stellen volgens het getter en setter principe. Tot de interessantere frameworks die hier zwaar op leunen behoren Hibernate, iBatis en Spring, naast bijvoorbeeld JMX.
| Bronnen, noten en/of referenties: |
|
