Re: How would YOU write a client/server Java applet today?

java400-l-bounces@xxxxxxxxxxxx wrote on 07/27/2004 12:02:10 PM:

> We have a requirement to develop a new GUI add-on for our system.  We 
have 
> investigated doing this using CGI but HTML is simply not going to give 
us 
> the same selection of components and rich interface that we need so we 
> decided to create an applet using a Swing user interface (our target 
> deployment already runs the Sun Plugin in their browser so we have all 
the 
> javax classes).  I have done some testing and downloading the jt400 
> classes as needed is not going to be a problem for us thanks to applet 
> caching, etc.
> 
> My question to anyone who would care to give me some advice is - what 
> would you use for database access?  We have a sort of bad taste from 
> updating the database directly using JDBC from a previous project and 
> would like to move to something else, perhaps stored procedures.  Is 
this 
> the way to go?  If so, would you recommend SQL or External Stored 
> procedures?  We have a requirement for accessing several files and 
> possibly calling programs in the business logic of this applet.  (which 
> sort of leans me toward External RPGLE stored procedures)
> 
> As far as I can tell, you can't update a resultset (using JDBC) that is 
> created external stored procedures stored in db2/400, but you can do 
this 
> with SQL stored procedures?  I haven't been able to find a lot of 
> information on updating using stored procedures in this particular 
> scenario on the web or the forums/newsgroups and am just trying to get a 

> feel of what is best to do here.  Is updating a resultset considered a 
> good idea when it is created from a stored procedure?
> 

I obviously do not know all of your business requirements so it is hard to 
pass judgement, but I think you are heading down the wrong path.  My 
primary concern, is that I think it is a mistake to allow the clients to 
talk directly to the server.  Even if you use Swing, I would recommend 
that the client talk only to the application server over HTTP/HTTPS and 
that the server then execute the business logic (JDBC, program calls 
etc..)  Otherwise, I think you are opening up a lot of potential security 
and deployment issues.

Also, there are some pretty decent projects out there now that can render 
fairly advanced UI's in HTML.  I wouldn't completely discount using HTML 
for the UI.  I certainly recognize there are cases where using Swing could 
make sense, however.  I just would not want a browser-delivered Swing 
client to be executing JDBC statements or Program Calls. 

Mark