[Java/Webservice] return database table via webservice

[Verwijderd]

Ik heb een server waarop een webservice draait. Deze webservice kan communiceren met een database op dezelfde server.

Hiernaast heb ik een client pc op een andere locatie. Deze client moet via een java applicatie een database tabel kunnen opvragen. Nu heb ik dit geprobeerd door het versturen van de CachedRowSetImpl. Echter geeft de client dan aan dat het een incompatible type is (casten naar een com.sun.rowset.WebRowSetImpl werkt ook niet).

Na het één en ander aan zoekwerk blijkt dat alleen simple types direct gebruikt kunnen worden en geen complex types. Wat blijkbaar de CachedRowSetImpl is.

Nu kan ik wel met lists alle data ontvangen, maar dat werkt erg omslachtig.

Bestaat er een mogelijkheid dat ik een database table kan opvragen?

En is überhaupt de CachedRowSetImpl een juiste keuze? Of zou ik een WebRowSet ofzo moeten gebruiken?

Alvast bedankt.

[Janoz]

CachedRowSetImpl is niet een ding met enkel data. Het is (kort gezegd) een object met functionaliteit die rechtstreeks aan de database gekoppeld is. Hierdoor kun je een row opvragen en deze wordt dan onderwater uit de database gehaald. Er is dus constant communicatie heen en weer tussen de cachedRowSetImpl en de database. Om deze te laten werken moet er dus een rechtstreekse verbinding met de database blijven.

Het zomaar over de lijn gooien van het object gaat natuurlijk niet werken. Het is dan compleet van de database (driver) losgekoppeld. Je stuurt enkel de data die op dat moment in het object zit (let op, dit is enkel wat state data, niet de data die in de database zit) over, en niet de functionaliteit.

Je zegt dat lists je omslachtig lijken, maar dat is waarschijnlijk toch echt de richting die je moet zoeken. Wat ik me echter wel afvraag is of je de 'knip' op de juiste plek aan het maken bent. Het lijkt er namelijk op alsof je een webservice gemaakt hebt die iets als een query accepteert en vervolgens een lijst gegevens terug geeft. Het lijkt me handiger wanneer je in de service methoden implementeerd alla 'getAllUsers()' die vervolgens een lijst met users teruggeeft.

[Verwijderd]

Beste Janoz,

Allereerst bedankt voor je reactie!

Het is jammer dat de tabel niet overgezet kan worden. Dan maar met de lists.

Janoz schreef op dinsdag 28 juli 2009 @ 16:06:
Je zegt dat lists je omslachtig lijken, maar dat is waarschijnlijk toch echt de richting die je moet zoeken. Wat ik me echter wel afvraag is of je de 'knip' op de juiste plek aan het maken bent. Het lijkt er namelijk op alsof je een webservice gemaakt hebt die iets als een query accepteert en vervolgens een lijst gegevens terug geeft. Het lijkt me handiger wanneer je in de service methoden implementeerd alla 'getAllUsers()' die vervolgens een lijst met users teruggeeft.

Bedoel je dan dat de getAllUsers() een methode is van de webservice?

Dank je!

[Verwijderd]

Als je een hele tabel over wil zetten, waarom zou je dan een webservice gebruiken? Als je toch al de hele tabel overzet kun je net zo goed rechtstreeks verbinding maken met die database.

Janoz heeft echter een heel goed punt: Waarom wil je een hele tabel overzetten? Heb je de hele tabel nodig, of maar een deel ervan? Als je maar een stukje nodig hebt, vraag dan ook maar een stukje op. Met andere woorden, als je alle users wilt hebben die beginnen met een 'A', laat de webservice dan die users teruggeven en niet een hele tabel die je vervolgens zelf gaat filteren.

[Standeman]

Verwijderd schreef op dinsdag 28 juli 2009 @ 16:27:
Beste Janoz,

Allereerst bedankt voor je reactie!

Het is jammer dat de tabel niet overgezet kan worden. Dan maar met de lists.


[...]

Bedoel je dan dat de getAllUsers() een methode is van de webservice?

Dank je!

Kijk even naar 3-tier architecture, dan wordt het wel wat duidelijker, denk ik. Alleen zal in jouw geval er geen presentation tier zijn, maar een service tier. Je wilt de database laag afschermen van de rest van de wereld. Wanneer je bijvoorbeeld een tabelnaam zou veranderen (of misschien niets eens meer JDBC gebruiken), moet je al je webservice clients gaan aanpassen die er gebruik van maken. Lijkt mij een vervelend werkje, voornamelijk omdat je vaak niet eens weet hoeveel clients er zijn van je webservice.

[ Voor 4% gewijzigd door Standeman op 28-07-2009 17:00 ]

[Verwijderd]

Verwijderd schreef op dinsdag 28 juli 2009 @ 16:53:
Als je een hele tabel over wil zetten, waarom zou je dan een webservice gebruiken? Als je toch al de hele tabel overzet kun je net zo goed rechtstreeks verbinding maken met die database.

Janoz heeft echter een heel goed punt: Waarom wil je een hele tabel overzetten? Heb je de hele tabel nodig, of maar een deel ervan? Als je maar een stukje nodig hebt, vraag dan ook maar een stukje op. Met andere woorden, als je alle users wilt hebben die beginnen met een 'A', laat de webservice dan die users teruggeven en niet een hele tabel die je vervolgens zelf gaat filteren.

De client heeft idd niet een hele tabel nodig. Het gaat om ongeveer vier kolommen uit drie verschillende tabellen. In een rowset is dit makkelijk te plaatsen en op te vragen. Maar aangezien dat niet werkt, moet ik het toch maar met meerdere lists opvragen.

[Verwijderd]

Standeman schreef op dinsdag 28 juli 2009 @ 16:59:
[...]

Kijk even naar 3-tier architecture, dan wordt het wel wat duidelijker, denk ik. Alleen zal in jouw geval er geen presentation tier zijn, maar een service tier. Je wilt de database laag afschermen van de rest van de wereld. Wanneer je bijvoorbeeld een tabelnaam zou veranderen (of misschien niets eens meer JDBC gebruiken), moet je al je webservice clients gaan aanpassen die er gebruik van maken. Lijkt mij een vervelend werkje, voornamelijk omdat je vaak niet eens weet hoeveel clients er zijn van je webservice.

Ik ga ernaar kijken.

Dank je wel!

[chime]

Verwijderd schreef op dinsdag 28 juli 2009 @ 18:57:
[...]


De client heeft idd niet een hele tabel nodig. Het gaat om ongeveer vier kolommen uit drie verschillende tabellen. In een rowset is dit makkelijk te plaatsen en op te vragen. Maar aangezien dat niet werkt, moet ik het toch maar met meerdere lists opvragen.

Waarom zou je meerdere lists opvragen?
Je gaat dan je joins in je code leggen?

Het meest performante is om de data in 1 keer op te halen en de joins in de database af te handelen.

Indien mogelijk:
- Steek de data in een record (de 4 kolommen)
- Stuur een List met deze records terug.

Vervolgens moet je client de data alleen nog maar tonen of verder verwerken.

[Standeman]

Verwijderd schreef op dinsdag 28 juli 2009 @ 18:58:
[...]


Ik ga ernaar kijken.

Dank je wel!

Als je voldoende tijd hebt, kan je voor de datalaag hier ook nog naar kijken: DAO pattern. Dat is een "standaard" en imo goedwerkende manier om je data te ontsluiten naar de rest van je applicatie.