[J2EE] Complexe architectuur

[JKVA]

Momenteel zit ik op mijn werk op een vrij complex project met een hele korte doorlooptijd. Vanuit de klant zijn onder andere de volgende eisen/wensen naar voren gekomen:
- Struts Shale (is al afgevallen, gezien gebrek aan expertise)
- J2EE compliant
- MEGA performance (zeer belangrijk punt gezien de hoeveelheid data-afhandeling)

Hiervoor hebben we de volgende architectuur ontwikkeld.

- Weblaag (MyFaces, Facelets, etc)
- Service en domein (Spring + EJB)
- Persistentie Hibernate

Het probleem begint voornamelijk met de keuze Spring + EJB. Deze werken op de volgende manier samen.
- Interface BlaBlaService
- Klasse BlaBlaServiceImpl
- EJB BlaBlaServiceBean

De klasse BlaBlaServiceImpl is een gewone POJO en bevat de logica. Deze kan aangesproken worden via Spring, want hij implementeert BlaBlaService, maar ook via de EJB.
De EJB BlaBlaServiceBean is een Stateless Session Bean en doet niets meer dan delegeren naar de POJO.
Vanuit die POJO gaat de logica weer wat dieper richting Hibernate.

Deze opzet is bedacht om zo veel mogelijk gebruik te kunnen maken van de services die de EJB container biedt.

Echter, hebben we al gemerkt. Het is heel complex en foutgevoelig. Bovendien kost het veel werk om te maken, wat de doorlooptijd weer nadelig beinvloedt. Eén property toevoegen aan het domein betekent het aanpassen van verschillende bestanden. Tel daarbij op dat er nog meer bestanden bij komen, zoals web.xml en spring.xml plus de bestanden die je sowieso moet aanpassen, zoals in de persistentielaag.

We hebben twee alternatieven op het oog, namelijk:
1 JSF + Spring + Hibernate
Voordelen:
* testbaarheid
* kan zelfs in tomcat deployen lokaal
* sneller ontwikkelen
Nadelen:
* Minder J2EE compliant
* Geen J2EE faciliteiten, zoals meerdere fysieke tiers

2 JSF + EJB + Hibernate
Voordelen:
* 'Meer' J2EE Compliant
Nadelen:
* testbaarheid
* zware appserver nodig
* complex

Na dit hele betoog is mijn vraag of jullie al eens een dergelijke opzet geprobeerd hebben en voor welke van de alternatieven je zou gaan. Of een derde optie.

Kortom, het gaat dus om een zo lichtgewicht mogelijke oplossing die snel te realiseren is, maar tegelijkertijd ook uiterst stabiel is, aangezien er een heel bedrijf op gaat draaien en het veel data te verwerken krijgt.

[Alarmnummer]

Waarom wil je EJB gebruiken? Puur en alleen omwille van J2EE compliant? Of zijn er nog andere redenen?

En wat versta je onder performance? Hoge throughput? Lage responsetime? Goeie performance kan je ook realiseren door horizontaal of verticaal te schalen.. mag dit? Wat zijn de eisen waarop het moet draaien? Wat voor type applicatie is het?

Een meerdere tiers (dus echt op verschillende processen) wil niet altijd iets schaalbaars opleveren. je kan bv goed schaalbare applicaties maken als je niet al te veel data in je sessies bewaard en dus niet als een idioot data hoeft te repliceren tussen de nodes in je cluster. Als je wilt doorschalen is het gewoon kwestie van nieuwe nodes toevoegen en die achter een loadbalancer te plakken (totdat je database in de knoei begint te raken, maar die kan je ook gaan schalen). lang leve stateless apps.. check PEAA en Distributed systems.. (sowieso minder last van dto's als je niet met tiers hoeft te werken).

[ Voor 106% gewijzigd door Alarmnummer op 06-07-2006 18:54 ]

[JKVA]

Alarmnummer schreef op donderdag 06 juli 2006 @ 18:45:
Waarom wil je EJB gebruiken? Puur en alleen omwille van J2EE compliant? Of zijn er nog andere redenen?

Voornamelijk omdat het te schalen is, mocht er een grotere verwerkingssnelheid benodigd zijn, kortom oog op de toekomst.

En wat versta je onder performance? Hoge throughput? Lage responsetime? Goeie performance kan je ook realiseren door horizontaal of verticaal te schalen.. mag dit? Wat zijn de eisen waarop het moet draaien?

Alle dingen die je noemt: Ja, maar dan vrij extreem. De responsetijd mag eigenlijk nooit boven de seconde liggen, inclusief de (denk ik trage) draadloze verbindingen met scanners, die ook met het systeem communiceren.
M.b.t. hardware hoeven wij alleen een advies te doen, maar we komen momenteel uit op een dikke HP bak waarbij we rekening houden met het eventueel bijplaatsen van extra hardware in de (nabije) toekomst.

Een meerdere tiers (dus echt op verschillende processen) wil niet altijd iets schaalbaars opleveren. je kan bv goed schaalbare applicaties maken als je niet al te veel data in je sessies bewaard en dus niet als een idioot data hoeft te repliceren tussen de nodes in je cluster. Als je wilt doorschalen is het gewoon kwestie van nieuwe nodes toevoegen en die achter een loadbalancer te plakken (totdat je database in de knoei begint te raken, maar die kan je ook gaan schalen). lang leve stateless apps.. check PEAA en Distributed systems.. (sowieso minder last van dto's als je niet met tiers hoeft te werken).

Ons team gaat ook het liefst voor de meest rechttoe-rechtaan oplossing, vandaar Spring, maar we hebben bovenstaande punten nog in beraad.
Over de database, we verwachten ook dat dit een bottleneck kan worden, gezien de data doorvoer.
We hebben daarom ook expres voor Oracle gekozen, maar willen ook qua applicatie veilig zitten qua schaalbaarheid.

[Alarmnummer]

Schaalbaarheid kan je ook perfect realiseren door stateless server nodes naast elkaar te plaatsen. Voor de gevallen waar je wel state hebt (soms kun je niet zonder) zou je er zelf voor kunnen gaan om een dedicated netwerk te gebruiken voor replicate. Als je verder een groot aantal machines gaat krijgen en replicatie een bottleneck gaat vormen, zou je altijd nog een cluster van clusters kunnen maken. Bij een cluster van 5 nodes hoef je alleen maar naar 4 andere nodes te repliceren. Al deze subclusters kun je dan weer achter load balancers plaatsen.

Weet je al precies wat de throughput en responsetimes moeten zijn die het systeem aan moet kunnen? Zorg er voor dat je vanaf dag 1 performance test mee neemt in je continuous build omgeving (snachts kunnen ze mooi draaien), dan kan je meteen performance problemen detecteren.

Ik neem verder aan dat ik je niets hoef te vertellen over Oracle RAC (en de prijs )

[ Voor 18% gewijzigd door Alarmnummer op 06-07-2006 19:39 ]

[JKVA]

Ik weet bijna niks van de prijzen van die dingen. Alles m.b.t. Oracle laten we onze Oracle unit uitvoeren, dus ook die schaling en het kostenplaatje. Af en toe een query bouwen ofzo vind ik wel leuk, maar over het algemeen bemoei ik me alleen met de J2EE kant.

Maar ik krijg de indruk dat jij wel redelijk voor de JSF + Spring + Hibernate combi bent? Hoe ervaar je deze wanneer samen gebruikt? Dus Spring je Hibernate zaken laten beheren en Spring tot in de weblaag laten "doordringen".

[Alarmnummer]

JKVA schreef op donderdag 06 juli 2006 @ 19:43:
Ik weet bijna niks van de prijzen van die dingen. Alles m.b.t. Oracle laten we onze Oracle unit uitvoeren, dus ook die schaling en het kostenplaatje. Af en toe een query bouwen ofzo vind ik wel leuk, maar over het algemeen bemoei ik me alleen met de J2EE kant.

Maar ik krijg de indruk dat jij wel redelijk voor de JSF + Spring + Hibernate combi bent?

Ik bouw gelukkig weinig presentation layer meuk Andere mensen kunnen dat sneller dan ik en vinden het minder irritant Ik gebruik zelf veel Spring-MVC maar we gebruiken het voor meer dingen dan html op te bouwen (ook pdf/xml/excel etc).

Hoe ervaar je deze wanneer samen gebruikt? Dus Spring je Hibernate zaken laten beheren en Spring tot in de weblaag laten "doordringen".

Ik vind de combinatie van tools prachtig. Ik ken ze vrij goed. En ik lijm veel meuk op in Spring en declaratief transacties toevoegen mbv Spring is echt een timesaver. Maar wat bedoel je met Spring in de weblaag laten doordringen?

[edit]
post de vraag anders maar eens op het spring forum.

[ Voor 6% gewijzigd door Alarmnummer op 06-07-2006 20:00 ]

[JKVA]

Ehm, bijvoorbeeld het gerbruik van een Spring VariableResolver in je JSF actions om de beans op te zoeken.

Dit uit zich dan in een applicationContext.xml in de weblaag, wat direct opvalt, aangezien we voor de weblaag een ander project gebruiken dan voor de service-/domeinlaag.

Op zich is het niets anders dan een declaratief vastgelegde dependency, maar het voelt niet helemaal lekker.
Voornamelijk omdat de spring configuratie nu verspreid staat over de projecten.
Ik bedenk me dat die config ook gewoon in de servicelaag gezet kan worden, aangezien naar dat project gerefereerd wordt. (maar het voelt nog steeds niet super )

[Apache]

Zware app server ... je kan mss eens kijken naar Geronimo, J2EE certified application server, ik heb hem gebruikt als vervanger van WebSphere, moest een workshop geven dit jaar maar voor een publiek dat beperkt was qua resources, tenzij je 2gb ram hebt moet je niet denken aan ff websphere installeren.

Ik heb er toen wat over gesproken met iemand van IBM die zei dat ze ook support gingen leveren voor geronimo naast WebSphere. Als je toch echt J2EE wilt gaan is dat een optie die je kan overwegen.

[JKVA]

Idd, daarom gebruiken we ook JBoss lokaal en wordt via Continuum naar WAS gedeployed. Als we EJB droppen, kunnen we volgens mij zelfs gewoon lokaal Tomcat gebruiken.

Als er iets lichtgewicht is...

[-FoX-]

Let op met het gebruik van verschillende platformen tussen development / test omgeving, vooral daar JBoss nogal aan redelijke exotisch classloading doet en dit bij WAS niet het geval is.

Wat versta je onder MEGA performance? Hoeveel concurrent users worden er verwacht? Wordt de applicatie 24/24 gebruikt?

Is het nodig dat de applicaties op verschillende tiers geclustered kunnen worden? Of is het al voldoende om aan loadbalancing te doen (en de state dus niet te delen)?

[JKVA]

Voorlopig zal er denk ik niet geclusterd worden, maar de kans is groot dat dit in de toekomst wel nodig is. Waarschijnlijk eerst de database, dus ik twijfel aan het grote voordeel van EJB's in dit geval.

Er werken verschillende mensen vanuit 120 lokaties op de applicatie, dus enkele honderden, maar dit is voornamelijk een piek 's-ochtends, waarna het afzakt. Tijdens die piek moet er echter een flink snelle response zijn. Er wordt steeds "< 1 seconde" geroepen, dus er worden redelijk eisen gesteld.

Een collega is nu aan het overleggen met een aantal andere collega's met meer Spring ervaring, aangezien bij ons bijna iedereen nog in EJB denkt.

[JKVA]

Helaas, persoonlijk had ik wel Spring gewild zonder EJB, maar het mocht niet zo wezen. Het wordt EJB onder het motto: "Over 5 jaar is Spring er niet meer en wordt EJB nog ondersteund."

Ik hoop het maar.

Overigens is het EJB 2.1, dus ik twijfel er een beetje aan...

[Alarmnummer]

Sterkte

[-FoX-]

JKVA schreef op vrijdag 07 juli 2006 @ 20:16:
Helaas, persoonlijk had ik wel Spring gewild zonder EJB, maar het mocht niet zo wezen. Het wordt EJB onder het motto: "Over 5 jaar is Spring er niet meer en wordt EJB nog ondersteund."

Ik hoop het maar.

Overigens is het EJB 2.1, dus ik twijfel er een beetje aan...

Beetje kip-zonder-kop keuze, imho.

En het argument is zeker ook zo lek als een zeef. Over 5 jaar zitten we aan EJB4 of 5 en heb je er een aantal dure migratie-trajecten op zitten om dan niet te spreken over de onderhoudskosten; dure keuze dan wel. Niet dat je perse hoeft te migreren, maar je software kan wel mee evolueren met de technologie. Anyway... ik durf er eigenlijk wel geld op inzetten dat Spring er over 5jaar nog steeds zal zijn (Kijk bvb naar Struts; nog altijd het meest gebruikte framework en gaat al meer dan 6 jaar mee)

Het feit dat EJB3 de eigenschappen van Spring1.0 overneemt, geeft alleen maar hun zwakte toe in de vorige releases. Maar ik hoef jou daar vast niet meer van te overtuigen

Ik begrijp de keuze ergens wel, op politiek niveau, maar daar houdt het dan ook wel weer op.

[Scare360]

JKVA schreef op vrijdag 07 juli 2006 @ 10:09:
Een collega is nu aan het overleggen met een aantal andere collega's met meer Spring ervaring, aangezien bij ons bijna iedereen nog in EJB denkt.

Reden te meer om EJB te doen!

[JKVA]

De keuze voor EJB is ook misschien iets veiliger, aangezien het nu eenmaal een standaard is. Het is alleen aan de andere kant ook zo dat er veel frameworks uit de open source wereld even populair zijn en dat ook een tijd blijven, zoals Struts idd.

Bovendien wordt er wel Spring gebruikt, maar dat is alleen om de EJB laag te abstraheren zodat de weblaag niets van EJB weet.

Dus in plaats van één groot risico is nu gekozen voor twee (iets minder) grote risico's.

Maar goed, de keuze is gemaakt. Nu er maar het beste van maken...