Re: JPA and desktop apps

On 27/07/10 18:39, Donald Fraser wrote:

> The company I work for (cisx.com) wrote an entire suit of desktop
> applications using Swing, JDBC and PostgreSQL.

The design you chose is similar to what I ended up with, except I was
using JPA instead of using JDBC directly. I, like you, have most
business logic directly in the database, though some has
non-authoritative duplicate checks in the client where it permits me to
offer earlier or better error reporting for the user.

I'm using a lot of stored procs as well as using views and HQL joins, so
I don't have the same square peg issues you've encountered. I sure do
have the Swing issues, though...

> We are currently embarking on moving to a three-tier system using the
> thin client model (web-server). The two technologies that we are
> considering are GWT and Wicket.

Out of interest, why not JSF2?

I'm seriously considering dropping my own app completely in favour of a
server-side rewrite, as I'm increasingly coming to see that while JPA
makes some Swing issues worse, and it has some big problems in the
desktop app context no matter what toolkit is used, a fair chunk of my
problem is with Swing not JPA.

( Session lifetime issues are one of the fun all-JPA problems not
contributed to by Swing or inherent to blocking database access. )

Anyway, GWT and Wicket are two on my short list. I considered testing
with Grails too, but I'm smelling a lot of hype, a lot of yelling about
how anything Grails doesn't play well with is "legacy", and other
warning signs that it's perhaps not as flexible as I might need. I also
have JSF2 on the shortlist and am wondering why you've ruled it out.

Note that I'm completely, 100% green on server-side Java, to the point
where I'm still wondering if Java is the right choice - perhaps I should
throw out my JPA/Hibernate mappings, validators, etc and re-plan the
whole affair entirely. So perhaps it's obvious why JSF2 is a bad choice,
and I'm just too green to know it.

Perhaps I should've just written the whole thing in PHP :S

> We chose PostgreSQL purely on its LISTEN/NOTIFY capabilities such that
> we have implemented an event driven model so that table views update
> automatically (we modified the JDBC driver to get non-polling
> asynchronous events from the server).

Listen/notify is a significant part of why I chose my current structure.
Little did I know that Hibernate and JPA want to get in the way of using
it every way they can, to the point where I'd have to write my own
simplistic single-connection pool and Hibernate pool provider so I could
keep an eye on notifications without having to maintain a dedicated JDBC
connection for the purpose.

> - Maintenance is hard work when you have 100+ tables.

Using JPA certainly does help there, at least a bit. Pity Java doesn't
have true properties, so you still have to write and maintain legions of
accessors, which is OK first time (code generation) but unpleasant to
maintain as types and field names change.

> - Swing is badly written and I would avoid it at all costs if we were to
> start again. We had to modify JTable to get virtual views however the
> model still requires in advance the number of rows in the table. COUNT
> is an expensive operation on tables that have millions of records in them.
> The number of "hoop jumping" and "hacking" you have to do to get
> everything working nicely with the AWT event queue is ridiculous.
> I could go on an on about the problems with Swing. The main thing to
> note is that you don't have to be using JPA to be having problems with it.

While true, I think JPA is a really good way to highlight its issues and
limitations. The lazy loading stuff in particular really shows how
painful Swing can be to use when you have to deal with an API that may
block at unpredictable points in time.

> - Remote client connections via firewalls / proxy servers is
> problematic. Again we modified the JDBC driver so that we could use
> tunnelling techniques. This required us to redirect port 443 on our
> incoming firewalls to port 5432 on the database server, meaning we
> cannot host a secure web-server on the same IP address. That aside, all
> works reasonably well, however a lot of clients use "single sign on"
> for connecting to their proxy servers and our application is
> non-compliant here because the amount of work to modify the JDBC driver
> for this is beyond our available resources and knowledge base. End
> result: a lot of clients have to have special proxy settings just for
> our application, which they complain about endlessly...

Interesting issue. Thanks for bringing it up. I never really considered
over-paranoid outbound packet filters as a likely issue when using
PgJDBC, but given my intended use case involves a lot of roaming users I
can see it would've potentially become a support concern.

> I guess you have to evaluate how complex the system you are building is
> and whether it is worthy of a two-tier or three-tier architecture.
>
> What ever you choose good luck!

Thanks for your time and comments. Good luck to you too with your redesign.

I'd be really interested in sharing experiences down the track on the
web framework side of things, as it sounds like we have similar needs
and I'm about to start writing a test app in each candidate framework
(!!) to see which sucks the least for my purposes.

--
Craig Ringer