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





I used an applet approach a year or two back for intercepting incoming
phone calls, interrogating our customer data-base and displaying customer
details to the target user.
A log of all inbound calls was kept within the applet so that users could
just click on a previous call to dial out.

I wanted to be able to make use of all our RPGLE service programs for
various customer logic, but make the interface as simple and user-friendly
as possible.

The mix was:
1) A thin applet using swing classes that dealt only with interacting with
the user - transactions were dispatched using sockets to a dedicated job
running on the as400.
2) The job running on the 400 was a java class listening for incoming
transactions from the applet client on a dedicated port. Once a request was
received, a thread was started to carry out the requested transaction and
let the listener get back to listening.

Having a job running on the 400 listening on a port gives you the sort of
control you normally need vis-a-vis library lists, user profiles etc.
As complex as it sounds, the entire java code for listening to a port, and
initiating helper threads runs to less than 80 lines of code.
I borrowed it from one of numerous examples of java chat applications that
can be found with google.

Regards,
John

jthompson@xxxxxxxxxxx
Ph (09) 372-5010


|---------+------------------------------>
|         |           dclowe@xxxxxxxxxx  |
|         |           Sent by:           |
|         |           java400-l-bounces@m|
|         |           idrange.com        |
|         |                              |
|         |                              |
|         |           28/07/2004 04:55 AM|
|         |           Please respond to  |
|         |           Java Programming on|
|         |           and around the     |
|         |           iSeries / AS400    |
|         |                              |
|---------+------------------------------>
  
>--------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                 |
  |       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?  
                                 |
  
>--------------------------------------------------------------------------------------------------------------|




Ok,  really I was only planning on using the browser as a deployment
mechanism for our internal users, it could have all been done as a fat
swing client in the first place (in fact our previous Java project is
deployed in this manner) but that's not to say 100% that we would never
deploy to remote users, I think if we did it would have to be through VPN
anyway.  For all intensive purposes on this thread assume that this is a
fat client but I want the browser/plugin to be my deployment mechanism so
I am making it a signed applet.





Mark Phippard <MarkP@xxxxxxxxxxxxxxx>
Sent by: java400-l-bounces@xxxxxxxxxxxx
27/07/2004 04:38 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 02:53:25 PM:

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

I just re-read this and wanted to clarify something.  If someone were to
say they were going to write a fat client Swing app (which is essentially
what you are saying) that uses jt400 to run JDBC and ProgramCalls, I would

not have any specific concerns about that.  I think all of the technical
pieces are fairly sound.  This is more or less what we are doing in our
applications, we are just using Eclipse/SWT instead of Swing for the
framework.

It is just that since you specifically talk about delivering it via a
browser, it implies that this application has reach that extends outside
of your internal network, or at least could someday.  In that scenario, I
think you would be better off if you only let the client and server
communicate via HTTP/HTTPS.

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.


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