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

Hi Mark,

Thanks for your response.  I should have qualified that we do have other 
reasons for selecting a Java user interface - Swing in particular, as our 
legacy app (which is currently deployed in a swing based applet using 
JWalk) will be pretty integrated with this new app in regards to 
navigating through screens, running in the same frame and calling legacy 
lookup programs etc.  We want it to appear as one big applet which is 
certainly understandable.

However, I am very interested in the concept of having the Swing applet 
talk to the HTTP server rather than directly to the database this 
certainly would resolve some possible firewall issues that we have 
anticipated (we currently were planning to require VPN access to the 
server).  If you have any more info on this it would be appreciated!!!

Thanks,
Dean



Mark Phippard <MarkP@xxxxxxxxxxxxxxx> 
Sent by: java400-l-bounces@xxxxxxxxxxxx
27/07/2004 04:23 PM
Please respond to
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>


To
Java Programming on and around the iSeries / AS400 
<java400-l@xxxxxxxxxxxx>
cc

Subject
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

--
This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) 
mailing list
To post a message email: JAVA400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/java400-l.