Momenteel ben ik bezig met een applicatie die op het J2EE Platform gebouwd wordt. Als applicatie server gebruiken we hiervoor JBoss 4.0.1 met SP1. De applicatie zelf is opgedeeld in onder andere een Web Archive , een EJB jar en een utility package die onder andere toegang bied tot de EJB's.
Vanwege de opzet de van de applicatie en structuur van de database willen we gebruik maken van meerdere databases. Een gedeelte van de EJB's ( de klantgegevens ) komt in één database te staan. Via de applicatie is het mogelijk om een set met vragen te beantwoorden. Deze set met vragen heeft altijd dezelfde structuur die zich over meerdere tabellen bevind. Omwille van de beheersbaarheid van de vragen willen we deze per set scheiden, namelijk elke set vragen krijgt zijn eigen database. Naast de beheersbaarheid bied dit ook voordelen op schaalbaarheid en performance. Het opzetten van een nieuwe structuur in de huidige database is relatief kostbaar als je vergelijkt met het kopieren naar een nieuwe database en vervolgens aanpassen van de vragen.
Nu willen we de applicatie zo opzetten dat er in feite een nieuwe database kan worden aangemaakt en met zo min mogelijk aanpassingen de nieuwe vragen geintegreerd kan worden. Wij hadden zelf de volgende oplossing in gedachten:
Elke database met vragen krijgt een eigen EJB jar, in deze archive definieren we in jboss.xml de verschillende JNDI names om de LocalHomes te localiseren. Tevens geven we in jbosscmp-jdbc.xml de database op waar de tabellen in moeten worden gemaakt. De JNDI name is dan zo opgebouwd: vragensetA/VraagEJBLocalHome, waar vragensetA een prefix is. Mocht er een nieuwe vragenset worden toegevoegd dan maken we een nieuwe EJB archive en passen vervolgens de JNDI names aan naar vragensetB/VraagEJBLocalHome.
Via de webapplicatie weten we met welke vragenset we gaan werken, dus vanaf die kant is het makkelijk om de JNDI te prefixen. Door deze stap is het dus voor de webapplicatie onbekend waar de data vandaan komt. De volgende afbeelding maakt het hopelijk duidelijker.

Het probleem is alleen dat nu de EJB-jars behoorlijk redundant zijn. Ze bevatten dezelfde classes, de ejb-jar.xml descriptor is identiek en ook de relaties gedefinieerd in jbosscmp-jdbc.xml zijn hetzelfde. Het enige waar de jar's in verschillen is de JNDI name mapping en de datasource mapping in de jbosscmp-jdbc.xml .
Is er misschien een manier om deze vorm van redundante configuratie aan te pakken? Wat denken jullie over de opzet zoals ik deze omschreven heb?
Vanwege de opzet de van de applicatie en structuur van de database willen we gebruik maken van meerdere databases. Een gedeelte van de EJB's ( de klantgegevens ) komt in één database te staan. Via de applicatie is het mogelijk om een set met vragen te beantwoorden. Deze set met vragen heeft altijd dezelfde structuur die zich over meerdere tabellen bevind. Omwille van de beheersbaarheid van de vragen willen we deze per set scheiden, namelijk elke set vragen krijgt zijn eigen database. Naast de beheersbaarheid bied dit ook voordelen op schaalbaarheid en performance. Het opzetten van een nieuwe structuur in de huidige database is relatief kostbaar als je vergelijkt met het kopieren naar een nieuwe database en vervolgens aanpassen van de vragen.
Nu willen we de applicatie zo opzetten dat er in feite een nieuwe database kan worden aangemaakt en met zo min mogelijk aanpassingen de nieuwe vragen geintegreerd kan worden. Wij hadden zelf de volgende oplossing in gedachten:
Elke database met vragen krijgt een eigen EJB jar, in deze archive definieren we in jboss.xml de verschillende JNDI names om de LocalHomes te localiseren. Tevens geven we in jbosscmp-jdbc.xml de database op waar de tabellen in moeten worden gemaakt. De JNDI name is dan zo opgebouwd: vragensetA/VraagEJBLocalHome, waar vragensetA een prefix is. Mocht er een nieuwe vragenset worden toegevoegd dan maken we een nieuwe EJB archive en passen vervolgens de JNDI names aan naar vragensetB/VraagEJBLocalHome.
Via de webapplicatie weten we met welke vragenset we gaan werken, dus vanaf die kant is het makkelijk om de JNDI te prefixen. Door deze stap is het dus voor de webapplicatie onbekend waar de data vandaan komt. De volgende afbeelding maakt het hopelijk duidelijker.

Het probleem is alleen dat nu de EJB-jars behoorlijk redundant zijn. Ze bevatten dezelfde classes, de ejb-jar.xml descriptor is identiek en ook de relaties gedefinieerd in jbosscmp-jdbc.xml zijn hetzelfde. Het enige waar de jar's in verschillen is de JNDI name mapping en de datasource mapping in de jbosscmp-jdbc.xml .
Is er misschien een manier om deze vorm van redundante configuratie aan te pakken? Wat denken jullie over de opzet zoals ik deze omschreven heb?