[Java] Client-side data abstraction framework

[Eelke Spaak]

Ik ga binnenkort waarschijnlijk beginnen aan applicatie die zeer sterk afhankelijk gaat zijn van een database. Er komt een website aan te hangen die voor klanten toegankelijk is. Ook komt er een administration tool (hiervoor wil ik een programma schrijven; geen web-interface) die de medewerkers van het bedrijf kunnen gebruiken om orders te raadplegen, inkopen door te geven, etc.

Omdat ik vrij veel ervaring heb met de programmeertaal Java, en ik vaag op de hoogte was van J2EE, heb ik besloten het geheel in Java te gaan realiseren. Ik verdiepte me enigszins in het J2EE-platform en het hele idee van EntityBeans om abstract met je database (waarschijnlijk een MS SQL Server) te communiceren sprak me erg aan; dit zou het ontwikkelproces een flink stukje versnellen. Dezelfde EntityBeans kon ik gebruiken in zowel de administration client als in de website, d.m.v. Servlets.

Nu is het alleen zo dat deze dingen een Sun Application Server (of een andere Java Application Server) nodig hebben, en de hosting provider waar de server-side van het geheel waarschijnlijk op gaat draaien wil geen Java software op hun Managed Dedicated Servers hebben. Een volledige, self-serviced Dedicated Server zit er waarschijnlijk niet in vanwege verantwoordelijkheids-aspecten.

Nou vraag ik me af of er een soort van data-abstraction framework voor Java bestaat dat client-side werkt. Het moet dus (vrijwel) alle database-communicatie voor z'n rekening nemen en door middel van getter- en setter-methods de onderliggende database automatisch updaten.

Voor de mensen die geen ervaring hebben met J2EE EntityBeans, even een voorbeeldje voor wat ik bedoel:

Stel, er is een tabel customers, met velden: customerId, lastName, emailAddress. Dan wil ik dat het framework mij automatisch (of in ieder geval met weinig db-level gepriegel van mij) objecten van het type Customer aanbiedt, waarop ik getLastName() etc. kan invoken.

Alvast heel erg bedankt voor jullie hulp . Oja, andere suggesties om dit op te lossen zijn natuurlijk ook welkom.

[Gert]

Je beschrijving is meer een tool die objecten naar een rdbms mapt, automatisch. Je zit in principe dan nog steeds rechtstreeks in de database te harken omdat het enige wat de OR-mapping tool doet is object omzetten naar sql statements, net alsof je een odbms hebt, zegmaar.
Je kan daar dan zelf een laag omheen bouwen natuurlijk.
Een enterprise bean houdt ook reking met beveiliging bijv en werkt in een apparte applicatie server, wat als het client-side is niet echt kan natuurlijk.

[Alarmnummer]

Als je dus niets op een server kan draaien, krijg je automatisch te maken met extreem vette clients. En op dat moment kan je dus het meeste van j2ee laten varen.

Voor een or mapper zou ik kijken naar hibernate, jdo, ojb etc.

Een enterprise bean houdt ook reking met beveiliging bijv en werkt in een apparte applicatie server, wat als het client-side is niet echt kan natuurlijk.

Waarom zou een client side applicatie nu ineens zo slecht zijn? Authorisatie/authenticatie kan je ook via de database krijgen, en daarmee kan je op db nivo regelen wie waarbij kan komen.

[ Voor 45% gewijzigd door Alarmnummer op 17-07-2004 17:16 ]

[Gert]

Ik zeg niet dat het slecht is, alleen dat het niet mogelijk is om enterprise beans te gebruiken bij een volledig clientside implementatie.

[Alarmnummer]

Gert schreef op 17 juli 2004 @ 17:19:
Ik zeg niet dat het slecht is, alleen dat het niet mogelijk is om enterprise beans te gebruiken bij een volledig clientside implementatie.

Ik heb niet goed gelezen *schenkt zichzelf ff verse bak koffie in*

[Eelke Spaak]

Gert schreef op 17 juli 2004 @ 17:19:
Ik zeg niet dat het slecht is, alleen dat het niet mogelijk is om enterprise beans te gebruiken bij een volledig clientside implementatie.

Klopt, daar was ik ook al achter.

Ik ben dus op zoek naar een soort van vervanging voor de data-representerende enterprise beans, die client-side kan werken.

[Alarmnummer]

Vladimir G. schreef op 17 juli 2004 @ 18:07:
[...]

Klopt, daar was ik ook al achter.

Ik ben dus op zoek naar een soort van vervanging voor de data-representerende enterprise beans, die client-side kan werken.

Een aantal zaken kan je zelf wel realiseren. De Object Relationeel mapping kan je via een OR mapper voor elkaar krijgen. En door de concurrency levels van de db connectie aan te sturen heb je ook controle over hoe de concurrency control gaat plaats vinden. Kijk eerst eens naar Hibernate.

[misfire]

Ik weet niet wat je bedoelt met "client side" OR mapping in combinatie met een web applicatie. Als het probleem is dat je geen J2EE hosting provider hebt dan zul je daar ook geen Web Module met Servlets/ JSP en/of POJO's kunnen hosten, dus los je het probleem niet op door geen ejb's te gebruiken.

Ik weet niet of je nu als alternatief een rich java client (Swing) of Applet wilt maken. Naar een database communiceren vanuit een applet mag niet zo maar, je moet daar wel rekening houden met de security constraints die voor applets gelden. In beide gevallen moet je echter ook een directe database koppeling tussen je clients en je db mogelijk maken, dus het is dan extra belangrijk dat de db zeer goed beveiligd/gepatched is. Ik weet ook niet of je hosting provider de database beheert en het toestaat deze remote te benaderen, ik kan me voorstellen dat ze ook dat niet toestaan...

[zneek]

Vladimir G. schreef op 17 juli 2004 @ 16:16:
Ik ga binnenkort waarschijnlijk beginnen aan applicatie die zeer sterk afhankelijk gaat zijn van een database. Er komt een website aan te hangen die voor klanten toegankelijk is. Ook komt er een administration tool (hiervoor wil ik een programma schrijven; geen web-interface) die de medewerkers van het bedrijf kunnen gebruiken om orders te raadplegen, inkopen door te geven, etc.

Omdat ik vrij veel ervaring heb met de programmeertaal Java, en ik vaag op de hoogte was van J2EE, heb ik besloten het geheel in Java te gaan realiseren. Ik verdiepte me enigszins in het J2EE-platform en het hele idee van EntityBeans om abstract met je database (waarschijnlijk een MS SQL Server) te communiceren sprak me erg aan; dit zou het ontwikkelproces een flink stukje versnellen. Dezelfde EntityBeans kon ik gebruiken in zowel de administration client als in de website, d.m.v. Servlets.

Nu is het alleen zo dat deze dingen een Sun Application Server (of een andere Java Application Server) nodig hebben, en de hosting provider waar de server-side van het geheel waarschijnlijk op gaat draaien wil geen Java software op hun Managed Dedicated Servers hebben. Een volledige, self-serviced Dedicated Server zit er waarschijnlijk niet in vanwege verantwoordelijkheids-aspecten.

Nou vraag ik me af of er een soort van data-abstraction framework voor Java bestaat dat client-side werkt. Het moet dus (vrijwel) alle database-communicatie voor z'n rekening nemen en door middel van getter- en setter-methods de onderliggende database automatisch updaten.

Voor de mensen die geen ervaring hebben met J2EE EntityBeans, even een voorbeeldje voor wat ik bedoel:

Stel, er is een tabel customers, met velden: customerId, lastName, emailAddress. Dan wil ik dat het framework mij automatisch (of in ieder geval met weinig db-level gepriegel van mij) objecten van het type Customer aanbiedt, waarop ik getLastName() etc. kan invoken.

Alvast heel erg bedankt voor jullie hulp . Oja, andere suggesties om dit op te lossen zijn natuurlijk ook welkom.

Schaamteloze commerciele actie, maar als je zoiets op een shared server wil kan ik het wel voor je regelen. Wij bieden (nog niet expliciet, maar dat komt nog) J2EE shared server hosting aan, bij voorkeur JBoss (IMHO een prima J2EE server platform). We doen dit samen met een professionele JBoss beheer club, dus ook voor achtergrond kennis kun je bij ons terecht
[/einde reclame]

[Eelke Spaak]

Ik wil voor de website, waar klanten reizen kunnen boeken en reserveren etc. (het gaat om een reisbureau) waarschijnlijk iets van ASP pakken. In combinatie met JavaScript heb ik hier al veel ervaring mee.

Voor de interface van de medewerkers (die veel uitgebreidere functies krijgt dan de website) wil ik een thick client met Java in elkaar bouwen. Waar ik alleen niet zoveel behoefte aan heb is voor elk simpel update/select sql-statementje een lap code en exception-handling te gaan typen. Hiervoor ben ik op zoek naar een framework dat deze dingen voor zijn rekening neemt, en waar ik op 'data-niveau' (i.p.v. op db-connectie-niveau) mee kan communiceren.

Edit: Alarmnummer, dank je voor de tip; ik zal zeker eens naar Hibernate kijken. Nu ga ik slapen .

[ Voor 9% gewijzigd door Eelke Spaak op 18-07-2004 01:06 ]

[Verwijderd]

probeer de Hibernate (hibernate.org) - Spring (www.springframework.org) combinatie eens?
Spring is een extra abstractielaag die Inversion of Control (IoC) aanlevert waardoor je applicatie makkelijker te scalen/aan te passen is. Spring wordt wel eens een lightweight container genoemd. Dus de EJB container zonder al de overheid gelieerd aan CMP's. Het principe van Spring is eenvoudigweg beans wiren (dus zeggen welke bean (bijvoorbeeld een Business Logic klasse) welke andere beans (bijvoorbeeld DAO, Logging, ... nodig heeft. Je kan daar zo ver in gaan als je wil, maar ik raad aan het niet al te absurd te maken (bijv logging gewoon log4j zonder Spring)

Met HibernateDAOSupport heb je een héél mooie superklasse voor je DAOs naar Hibernate. Met TransactionProxyFactoryBean heb je iets héél eenvoudig om je transacties te beheren met dezelfde mgoelijkheden dan CMP's (die heden ten dage door elke J2EE ontwikkelaar afgeraden zullen worden tenzij je distributed transactions hebt, en dan kan je in Spring JTA (== zwaar !!) als transactionmanager gebruiken).


Maar het idee om de website in ASP te doen en de beheertool in Swing/SWT lijkt me nogal dubbel werk. Ik zou echt wel op zoek gaan naar een applicatieserver om alles server side te kunnen doen. Spring+struts+hibernate is een mooie combinatie om snel en net te werken (voor Struts zullen er misschien mensen zijn die je tegenspreken, en op die kritiek kan ik niet antwoorden, ik heb enkel Struts 'ervaring').

[zneek]

Verwijderd schreef op 18 juli 2004 @ 19:53:

Met HibernateDAOSupport heb je een héél mooie superklasse voor je DAOs naar Hibernate. Met TransactionProxyFactoryBean heb je iets héél eenvoudig om je transacties te beheren met dezelfde mgoelijkheden dan CMP's (die heden ten dage door elke J2EE ontwikkelaar afgeraden zullen worden tenzij je distributed transactions hebt, en dan kan je in Spring JTA (== zwaar !!) als transactionmanager gebruiken).

Waarom worden CMP's afgeraden? Ik heb er een paar projecten mee gedaan, en om eerlijk te zijn vind ik het wel prettig werken.

[Verwijderd]

zneek schreef op 19 juli 2004 @ 11:23:
[...]


Waarom worden CMP's afgeraden? Ik heb er een paar projecten mee gedaan, en om eerlijk te zijn vind ik het wel prettig werken.

overhead.
Sessionbeans worden ook her en der afgeraden, maar DIE vind ik echt wel handig om alle logic te abstraheren (ouw, neem daar aub geen Van Daele bij ).
Maar Hibernate is veel performanter dan CMP's, ejb-ql is te beperkt (probeer maar eens een case-insensitive search met ejb-ql, dat is een probleem waar ik vorige week nog op stootte), de inleiding van het boek J2EE Development without EJB. (ik neem dat boek omdat ik weet dat de eerste versie van dat boek, waar Spring framework de kaas haalde) alle voor- en nadelen van CMP in de verf zette. (het was géén rant...er zijn wel degelijk voordelen als je distributed transacties hebt). Ik heb wel enkel de inleiding van de vorige versei gelezen, en ik heb gezien dat het tweede boek net zo'n hoofdstuk over architectuur bevat).
Maar bij ons is ook alles gebaseerd op CMP omdat voor 20000 gebruikers niet al te licht over een overstap>Hibernate/... gegaan mag worden. (maar onder WL6.1 hebben we al héél wat irritante dingen gevonden )