[java] Grote applicatie opdelen

[flowerp]

Bij het bedrijf waar ik werk is ons 'core' team al enkele jaren bezig met 1 grote java web applicatie. Vanwege de grote van het geheel vroeg ik me af of het niet beter is om de applicatie op te delen in aparte sub projecten. Elk sub-project zou dan een .jar kunnen genereren die in de main applicatie als lib gebruikt wordt.

Sommige van die sub-projecten kunnen dan complete standalone dingen worden, zoals een eigen editor die we hebben. Deze hoeft (natuurlijk) nix van het hoofdproject te gebruiken. Het voordeel van deze in een apart project en .jar zetten is dat we hem eventueel zo kunnen re-usen in een project(je) dat we voor een klant doen.

Wat minder duidelijk wordt het als we grote stukken bussiness logica hebben, die logischer wijs een enkele 'unit' vormen, maar wel dependencies hebben op andere onderdelen van de applicatie. Deze staan nu in aparte packages. Ze zouden naar aparte projecten kunnen waardoor de code dan weer in aparte jars komt, maar kwa dependencies is er dan eigenlijk geen verschil met toen ze in aparte packages in het main project zaten.

Een voordeel van die laatste situatie zou kunnen zijn dat iemand die in 'unit' A werkt, iets minder snel geneigd zal zijn om iets in 'unit' B te gaan veranderen als dat betekent dat je helemaal een .jar overniew moet deployen. Hoewel dat in de praktijk niet meer dan een ant scriptje runnen is, zou er wellicht toch iets van een psychologische grens zijn.

Een heel ander probleem kom je tegen bij het opdelen van JSP pagina's. Deze kun je niet makkelijk in .JARs stoppen. Een oplossing zou zijn om deze ook via ant te deployen naar het main project.

Zijn er hier mensen die ervaring hebben met het opdelen van een grote web applicatie in kleinere stukken? Onder groot versta ik btw een slordige 400.000 regels (java + sql + jsp + xml files).

[JKVA]

J2EE projecten kun je in een EAR project maken. Deze kun je weer uit meerdere subprojecten laten bestaan, zoals een standaard java project voor de domeinlaag en een webproject voor de weblaag. Die eerste wordt een JAR en de tweede een WAR. Deze worden in een EAR gestopt en de EAR wordt gedeployed naar bijv. WebSphere of JBoss ofzo.

J2EE Eclipse plugins maken dit vrij gemakkelijk. Bijvoorbeeld IBM WSAD, of MyEclipse.

---

Dit biedt zelfs nog andere handigheidjes, zoals een generieke libs waarin je de libs zet die voor alle projecten gelden. Generiek het build path opzetten zodat je dat geen 5 keer moet doen.

[ Voor 19% gewijzigd door JKVA op 18-06-2006 09:32 ]

[flowerp]

JKVA schreef op zondag 18 juni 2006 @ 09:31:
J2EE projecten kun je in een EAR project maken.

Ik zat hier al met een schuin oog naar te kijken, maar was meer onder de indruk dat je een full J2EE AS alleen zou gebruiken als je het oude EJB2 nodig hebt. Aangezien full J2EE servers door bijna de hele community als 'evil' worden bestempeld wilde ik me daar nog niet aan wagen.

Btw, 'evil' omdat het volgens bijna elke poster op diverse fora log, bloated en overengineered zou zijn; we gebruiken daarom alleen een servlet container (tomcat).

Zijn er eigenlijk meer mensen die alleen omwille van de opdeling van hun project in sub-projecten overstappen van een lichte (en dus goede) oplossing als een servlet container naar een lood zware (en dus slechte (?) ) oplossing als een full blown J2EE AS?

[JKVA]

Ik zeg niet dat een complete appserver voor elk geval beter is, maar met betrekking tot grote projecten biedt het veel meer mogelijkheden met betrekking tot monitoring en configuratie. In feite, als je TomCat gebruikt, maak je er voor een deel ook een appserver van door het installeren van allemaal libs voor verschillende services zoals mail en zo. Het is dan alleen niet geintegreerd, maar een samenhang van losse dingen.

Verder kun je ook gewoon een jar maken en die in het build path van een ander project zetten. Ik denk alleen dat het niet zo heel soepel zal lopen bij wijzigingen, als in niet direct zichtbaar en zo. Maar dit is alleen maar een gedachte.

Over 'evil'. Heel veel grote bedrijven draaien op IBM WebSphere, ondanks ongeveer elke developer vindt dat het troep is. (niet compatible met andere partijen, traag, enz) Juist voor beheerders is zo'n complete managed omgeving ideaal.

Bloat hecht ik persoonlijk niet veel waarde aan, zolang het niet op mijn werkstation draait.

[flowerp]

JKVA schreef op zondag 18 juni 2006 @ 20:17:
In feite, als je TomCat gebruikt, maak je er voor een deel ook een appserver van door het installeren van allemaal libs voor verschillende services zoals mail en zo. Het is dan alleen niet geintegreerd, maar een samenhang van losse dingen.

Dat klopt ja, we hebben inderdaad het activation framework geinstalleerd (activation.jar & mail.jar) alsmede JSF (tegenwoordig ook standaard bij EE 5 servers) en EJB3 (via hibernate, we gebruiken het alleen voor JPA), en dan een grote sloot libs zoals veel dingen van apache. Bij elkaar mischien wel meer libs dan bij een kale install van een full AS zit.

Het is eigenlijk een beetje zo dat iedereen altijd roept dat full blown AS evil is (bv alarm nummer die hier veel post zegt ook vaak iets in die richting), en als je het maar vaak genoeg hoord wordt je er vanzelf mee geindoctrineerd en ga je het niet gebruiken. Mijn collega's lezen ook veel fora, en hun eerste reactie zal dan ook zijn als ik voorstel om een full AS te gaan gebruiken: "huh!? maar die zijn toch 'evil", zonder dat je eigenlijk echt rationeel hebt afgewogen -waarom- ze nu evil zouden zijn.

Verder kun je ook gewoon een jar maken en die in het build path van een ander project zetten. Ik denk alleen dat het niet zo heel soepel zal lopen bij wijzigingen, als in niet direct zichtbaar en zo. Maar dit is alleen maar een gedachte.

Ik doe het nu een beetje met kleine stukjes code, die ik in aparte Eclipse projecten zet en dan build en copy naar het main project via een ant-scriptje.

Mischien toch eens naar Jboss kijken dan

[Alarmnummer]

Ik zeg niet dat grote app servers bad zijn, maar hoe meer meuk er op zit, hoe complexer het is (dus hoe lastiger het is om problemen te fixen). En verder zit er enorm veel zooi bij dat je gewoon niet gebruikt. Daarom pak ik meestal een eenvoudige servlet container want de rest ben ik niet nodig. Maar op het moment dat je ook veel andere features nodig bent die je op full blown app servers tegenkomt, dan is eventueel een fullblown app server ook een oplossing (dan heb je tenminste iets dat op elkaar afgestemt is ipv een bij elkaar geraapt zootje).

En waarom maak je niet meerdere wars? Onder een servlet container zoals tomcat kun je gerust meerdere applicaties (wars) naast elkaar draaien. Je kunt zelfs aangeven onder welke url ze moeten draaien. Ik zie de meerwaarde van een ear hier nog niet.

[ Voor 19% gewijzigd door Alarmnummer op 19-06-2006 05:50 ]

[-FoX-]

Een EAR file heb je inderdaad niet nodig. Op een vorig groot project bouwden we ook alles zeer modulair op en deployden deze in verschillende WAR's. Er was dan 1 aanspreek-punt-WAR die de aansturing naar de verschillende andere WARs voor zijn rekening nam. Dit werkte op zich wel vrij goed. Complete losstaande modules kan je misschien wel best onderbrengen in een aparte jar die dan door je build omgeving gemanaged wordt (bvb breadcrumbs oid, om maar een stom voorbeeld te geven..)

[PhoneTech]

Ik ben zelf een groot voorstander van de EAR files omdat het deployen en de distributie van de app zo verschrikkelijk makkelijk is. Het project waar ik nu al een tijdje werk, bestaat uit zo een 4 a 5 sub projecten en allemaal hebben ze wel wat met elkaar te maken. Door onze scheiding van de client en server jars (we gebruiken een Swing client) is het aantal jarretjes behoorlijk gestegen (stuk of 20 eigen jars en een zooi 3d party jars). Voor zover mogelijk stoppen we de jars die alleen voor 1 sub app gebruikt worden ook indezelfde jar als die app.

De client maakt ook deel uit van de EAR file. Deze staat in een WAR file met 1 servlet met content-type jnlp. Deze servlet preset de velden van de RMI server in de jnlp bestand wat het voor de client ook een stuk makkelijk maakt.

Een ear file maken is net zo makkelijk (misschien wel makkelijker) dan een WAR file.

[JKVA]

PhoneTech schreef op maandag 19 juni 2006 @ 16:53:
Een ear file maken is net zo makkelijk (misschien wel makkelijker) dan een WAR file.

Daarom riep ik het ook. Een EAR is er tenslotte voor gemaakt.

Je zult het alleen niet onder TomCat werkende krijgen denk ik. Ik heb het nooit geprobeerd, maar het lijkt me niet mogelijk.

[PhoneTech]

JKVA schreef op maandag 19 juni 2006 @ 21:44:
[...]

Daarom riep ik het ook. Een EAR is er tenslotte voor gemaakt.

Je zult het alleen niet onder TomCat werkende krijgen denk ik. Ik heb het nooit geprobeerd, maar het lijkt me niet mogelijk.

Dan kan je toch een app server gebruiken? Als je bijvoorbeeld JBoss pakt, dan zit daar tomcat al in. Als je de minimale server configuratie pakt, dan hoeft het echt geen bloatware te zijn