|
midrange.com
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.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
