Re: JPA and desktop apps - Mailing list pgsql-jdbc

> 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 have 565 stored procedures and if the square peg issues were our only
problems then we wouldn't be considering moving away from this architecture.
The square peg issue is a minor inconvenience compared to the rest of the
problems.

>> 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?

There are so many flavours of enterprise architecture that claim to solve
all your problems that you have to look at what you think are your most
difficult problems and do they solve them.
As far as I can tell there are still a lot of naming conventions required
for JSF2 and boiler plate code to map things.
I'm reading a lot of forums to see what issues people have and what they
think of these technologies.
People that were once JSF2 ambassadors that have moved to Wicket claim it to
be so much better, hence why its not in my short list. I might be wrong but
you have to start somewhere and have some system of reducing your short list
before one waists a lot of time in writing test apps to really find what the
issues are. In short we are looking at key areas that we think are the
problem areas and investigating these issues. Namingly we would like a pure
message based system which requires ajax technology to make it work on the
thin client. So we are focusing on the ajax problem areas to see whether
these technologies cut it or not...

> 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.
Here here!

> 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.

We're pretty green on the server side Java too having spent the last 10
years working entirely on our two-tier systems.
We do have server side code for automation, however this is pretty simple
code that only uses the Java SE VM.
So we were pretty taken back when we loaded up GlassFish and started reading
up on what it has to offer. We could spend the next 6 months just learning
the in and outs of this JEE platform and is this the right JEE platform to
use? Yet another decision to make.

> Perhaps I should've just written the whole thing in PHP :S
Yes, our web-server code is PHP and we recently reworked the entire site so
that it is completely OO.
Its crossed my mind several times to say lets just write it all in PHP but I
have faith that these new technologies will work for you if you use them how
they were intended to be used. If only I had more 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.

On top of the firewall/proxy server issues you have the session connection
management problems.
We limit each individual user to only one connection and because we are
using a normal TCP socket connection, most of the time, things work OK.
However when a connection is dropped over the internet the server will keep
the connection open until it knows otherwise. This causes problems when the
user tries to re-establish a connection. Unless you have session management
in place you don't know which connections need cleaning up... All of this
code had to be written in C, as a plug-in to the PostgreSQL server.
If I was to do this part of our app again I wouldn't use JDBC directly. I
would use a message bus to deliver the SQL requests / results sets. Your
users then scale better. Most message buss implementations have the option
to use the HTTP protocols as a delivery mechanism which makes tunnelling out
of firewall/proxy servers easy. Single sign on - not a problem, Sun
implemented this with the HTTP connection classes (If only the source code
to this was available...)

> 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.

It does seem that we have a lot in common and have come to many of the same
conclusions.
I too would be interested in sharing experiences. What pit-holes did we
uncover etc...

I'll keep you posted on any significant findings.
Regards
Donald