[Java-JDBC-ORM] remote JDBC access probleem

[hobbit_be]

voor een project willen we gebruik maken van ORM [Object/Relational Modelling]. Deze implementatie (van apache) gebruik JDBC access voor de database -which is nice. Het probleem zit in het feit dat de client applicatie (een Swing geval) ook dit zou moeten gebruiken. Maar de JDBC Server zit natuurlijk op een Webserver (Tomcat/Cocoon) waardoor een direct communicatie onmogelijk wordt (ie we kunnen niet de poort openen van de JDBC driver aangezien alleen de enige manier om met de server te communiceren via servlets is (XSP,JSP,etc).

Nu vroeg ik me af of er een JDBC 'driver' bestaat die een andere JDBC driver wrapt in een servlet zodat the ORM deze driver can gebruiken en deze alles dan door het 'tunneltje' stuurt.

dus: Applicatie -> ORM -> JDBC(wrapper) -> some HTTP protocol (port -> servlet -> echte JDBC Driver -> HTTP resukt -> JDBC(wrapper) -> ORM -> Application.

het enige wat ik vond dat erop leek is een RMIJDBC driver maar deze start zelf een Server op de Server (wat dus niet mag) en communiceert via port 80. Ik zoek dus meer een XML-RPC-JDBC wrapper. Maar vinden doe ik het niet.

Enig Idee Iemand - ook om misschien toch de gewone JDBC Driver (MySQL) direct aan te spreken door poort 80... ?

[ Voor 5% gewijzigd door hobbit_be op 25-02-2003 14:52 ]

[wasigh]

Iets met SOAP misschien?

[mbravenboer]

Aardig idee. Toen ik het las zat ik inderdaad ook gelijk aan de RMI-JDBC driver te denken, maar dat is dus geen optie. Ik heb wat rond gezocht, maar heb helaas niets kunnen vinden.

Misschien is het na nog wat meer zoeken een idee om het zelf op te zetten?

[Nexopheus]

Mischien een beetje off-topic. Maar waarom zou je zoiets willen doen? Gaat een beetje tegen de principes van een n-tier systeem in. toch?

[Nexopheus]

Update:
eventueel interessant?: http://forums.devworld.com/webx?14@@.ee6b80a/1743

[ Voor 7% gewijzigd door Nexopheus op 27-02-2003 10:14 ]

[hobbit_be]

yow bedankt voor de replys! ik heb ook nog een daje verder gezocht zonder succes overigenes.

mbravenboer:
tja een full JDriver 3.0 in elkaar kloppen is natuurlijk mogelijk zeker met Nexopheus last post. Dan is er natuurlijk het probleem om te zien wat de ORM nu eigenlijk gebruikt van de JDBC om het te downscalen. Het transferren van resultset doe ik zowieso al via XML-RPC (met base64 binary encoding voor Parse/Unparse speed) dus op zich geen probleem - maar de JDBC driver moet wel andere dingen en dat zie ik niet direct zitten: eg stel je doet een Select Query met 10000 results. en je gaat dat lijstje af een per een (een getNextRow) maar dat zou dus telkens een VOLLEDIGE query moeten uitvoeren (met een Limit) of je stuur de hele boel ineens door. Je hebt aan de server-side echt session managment nodig (persitance of the result) (maar dat is dan eigenlijk een server . Al mijn request worden naar een servlet gestuurd (die tevens de XML-RPC server is) maar om bij te houden dat ie van dezelfde client (alleen de client app heeft access) weet ik te weinig van Servlets. (vandaar dat ze me op de client side hebben gezet ..

Nexopheus:
waarom?: omdat het niet anders kan. wees gerust als ik de jdbc poort van de driver open zou krijgen doe ik gewoon een jdbc:://myserver.com:4444/.... maar echt secure is dat niet he? en bovendien zitten we niet op een private server...

Dit allemaal omdat de client een HTML editor nodig had in zijn CMS (en niemand dat wou implementeren in een een pure HTML environment) - ik heb er nu al spijt van gewoon geen ACtiveX te hebben gekocht en de rest gewoon in VB (ook als Activex) te hebben geimplement. De client is toch Win32. Maar dus nogmaals bedankt ben al blij dat niemand anders meer success had met google (dan doe ik dat toch goed:)

Als ik toch een XML-RPC (SOap kan ook maar veel te veel overhead imho) opzet zal ik in ieder geval posten ... Helaas nu terug naar XML-based (SQL) files voor modifiying ... sniff...

[Nexopheus]

Nexopheus:
waarom?: omdat het niet anders kan. wees gerust als ik de jdbc poort van de driver open zou krijgen doe ik gewoon een jdbc:://myserver.com:4444/.... maar echt secure is dat niet he? en bovendien zitten we niet op een private server...

Ok,

Suc6 ermee! lijkt me niet echt triviaal om dit op te lossen......