Hi jm,
Yes and thank you to everyone. I only need the applet because I need
a richer graphical environment than a regular webpage, and I don't
want to use Flash, Flex, or Silverlight. I thought about JavaFX, but
not sure and the tools are all there yet. Plus I just want to use
Java (and associated variations, jsp, etc.)
<<<<<<<<
Look, this is gonna be one of those really annoying posts that tells you
what you explicitly didn't ask for; sorry about that. But for the benefit of
others who may read this later and are wondering whether some combination of
Java Applets and Flex/Flash may be possible, let me please offer the example
(and pointer to source code) below. To me RIA is a broad church; not a case
of either/or but rather a case of best tool for the job. (In my example, I
found Flex Socket support to be not up to scratch and therefore wanted to
stick with my Java Applet for network comms to the DB, but still use Flex
for what it's brilliant at!)
Cheers Richard Maher
PS. Scanning through NASDAQ.COM recently, I see they're starting to do
similar things with stock charts no longer being static. (If only Adobe
fixed their FABridge example link then NASDAQ may discover the wonders of
the FABridge (or external interface direct) rather the Web1.5
"chartHolder.innerHTML=showChart(blah)".
PPS. Let me point out a *HUGE* problem with Silverlight. It not only
restricts you to Ajax as a datasource; it restricts you to *Microsoft's*
version of Ajax! Adobe says "Do whatever you like!".
PPPS. Is there not a Socket or BufferedInputStream flag I can toggle that
says don't return until "N" bytes or Error? Arne, if you're reading, similar
to ucx$c_msg_blockall. No real hardship to loop till full or error, but this
is a pretty common TCP/IP stream requirement.
PPPPS. Aparently it *doesn't* work on Safari (but does on the same box OS-X,
JVM, FlashPlayer with FireFox), if someone knows why please tell me.
EXAMPLE: Anyway, here 'tis : -
If you'd like to see an example of a browser-based Flex/HTML/Javascript GUI
client talking to a VMS 3GL server, please click on: -
http://manson.vistech.net/t3$examples/demo_client_flex.html
and have a gander.
Username: TIER3_DEMO
Password: QUEUE
You *must* be running: -
.. The *latest* version of Adobe's Flash Player (Adobe and FlexBuilder
generate the code for version checking and auto-download but I left it out
of the example for brevity)
.. JVM 1.4-2 or later (Java 6 has been out for over a year; what's wrong with
ya
.. If you are behind a firewall that disables outgoing connections then you
must open up to destination port 5255.
.. You must have Javascript and Applets enabled for your browser
.. Apart from that I've tested it with IE6/7 and Firefox and others have it
working on Safari and Opera
Now, sadly, I was unable to obtain any sort of Rdb Hobbyists license for the
Deathrow Cluster so I've had to provide a fudge in that the data is
hard-coded in DEMO_UARS.COB :-( But if you want to see what the Rdb code on
our machines looks like then peruse: -
http://manson.vistech.net/t3$examples/
For all of the source code: -
Server: -
demo_flex.cob (Cobol server code)
build_flex_demo.com (Creates the UAR shareable)
demo_flex_sql.sqlmod (SQL you guessed it)
Client: -
demo_client_flex.html }
employee_lookup.html } All the Application-specific html
avoidpatent.js }
bridgetest.mxml } The Flex driving logic (I can't believe it's that small!)
Those who are familiar with demo_client_web.html are already familiar with
the example Java classes and CornuCopiae.html. NB: *NO* new Java was created
for the new application! Code reuse and modularity set to maximum!
Cheers Richard Maher
ps. If you'd like to see this on HP's TestDrive Cluster *with* Rdb then tell
me (or better still tell your HP rep!) Maybe it's just me, but surely you'd
be forgiven for wondering why Oracle/Rdb or HP/VMS would not seize on this
opportunity to promote and support their wares?
pps. If you haven't worked it out yet
hover over the pie charts and
click for data drill-down.
I was kinda confused by Arne first comment too, but "user specific
accounts" in his second reply makes it plain what he is getting at here.
If your applet or JWS program can access a database, so can anyone else.
Your database is "bare" on the 'net and anyone at all can connect to
it anytime he or she wants. It's a security hole.
So, with that in mind: servlets can be one way to implement the
protection needed on your server to prevent unauthorized access your
database.
However, especially in the case of JWS, the answer might even be
"probably not" with respect to using servlets as middleware. Certainly
it possible to write your own protection layer in Java, deamonize it,
and then let it listen for connections and provide the level of security
desired.
Servlets do have some built-in advantages. The networking code is done
for you already. Port 80 is almost always allowed on client system.
And SSL provides encryption, which will be necessary for any real form
of security. But using servlets should be weight against all other
options. It's not a given and definitely not the only choice.
Well I hope this was at least partly clear....
Yes and thank you to everyone. I only need the applet because I need
a richer graphical environment than a regular webpage, and I don't
want to use Flash, Flex, or Silverlight. I thought about JavaFX, but
not sure and the tools are all there yet. Plus I just want to use
Java (and associated variations, jsp, etc.)
