RE: Topic number ONE -- JAVA400-L

I am just in the beginning stages and finding out what Java can do for us.
But I am leaning toward a fat client using the Client/Server model.  Like
Joe mentioned, it seems to be a nice middle ground, and it will allow us to
better leverage the existing legacy system and employee's skills.



-----Original Message-----
From: owner-java400-l@midrange.com
[mailto:owner-java400-l@midrange.com]On Behalf Of
pluta@nexgensoftware.com
Sent: Friday, July 16, 1999 2:15 PM
To: JAVA400-L@midrange.com
Subject: Topic number ONE





Alright, folks, I'm back and finally caught up from my week in Israel.
While I
was preparing, I noticed a little lag in discussion here, so I thought it
was
time to spice things up a little bit.  In keeping with my philosophy that
this
is more than just a "fix list", I'm going to throw out a topic or three for
discussion.  Then we'll back it up with some actual real-life work.

Okay, topic one:

Who is planning on using which connectivity technology, and for what?
=========
Big question, I know.  But let's break it down real quick.  The two PRIMARY
technologies are ultra-thin client (or anorexic client, as Don Denoncourt
calls
it, or browser) and "fat" client.  There are no other viable options.  NONE.
(This should spike a bit of controversy <wicked grin>).
----------------
Within browser technology are the following:

1. HTML
2. JavaScript
3. CGI
4. Servlets
5. Active Server Pages
6. Java Server Pages

HTML is a completely static page.  JavaScript allows some dynamism based on
the
user's input, but basically affords no connection to any host data.  SO for
all
intents and purposes, both are static.

CGI and servlets are pretty much two sides of the same coin: web requests
are
passed to a program on the host, which in turn generates HTML dynamically
for
the browser to display.  CGI usually calls an HLL program, such as RPG,
while
servlets are specifically Java programs.

Finally, ASP and JSP are the Microsoft and Sun versions of extended
scripting
languages.  Microsoft has basically included Visual Basic programming in its
ASP
scripting language, along with support for various host functions, such as
session information and SQL access.  Sun, on the other hand, simply decided
to
incorporate direct calls to JavaBeans.  Both solutions have control features
like IF and SELECT and allow creation of program-like constructs within the
HTML
page.  The choice there is primarily one of which technology you want to go
with: Microsoft or Java.

Oh yeah, I left one off: JWalk and it's equivalents, which are basically
5250
screen-scrapers.  Those or even 5250-emulation-in-a-browser are certainly
options for those who are looking merely to facelift part or all of their
existing legacy systems and/or deploy them on the net.
----------------
Okay, on to fat clients.  Fat clients are applications written on a
workstation
that is typically connected to the local LAN (although you can be connected
to
the LAN via dial-up, so geographical proximity is not an issue, except as it
pertains to moving large amounts of data over the wire).  These are not
applications run over the internet, although they can be provided your
firewall
will support them.  However, for security reasons they are usually run only
locally.  They are usually executive information systems, simulations or
modeling programs, although they can also be desktop integration programs
(for
example, you may be able to drag a customer order onto your Email icon in
order
to send mail to a customer - or maybe to the salesman responsible for that
customer!).

There are several flavors of these as well:

1. Direct data access (via SQL or native I/O)
2. Client/server access
3. Remote method access
4. Detached processing

Direct data access should be reserved for inquiry applications, since you
have
much weaker control over your database access.  If workstations can directly
update databases, you can have some serious integrity issues.

Client/server and RMI are provide indirect access to data, either through
servers or through objects.  If you believe that the eventual "universal
connectivity language" is going to be Java, RMI is your end goal.
Client/server
access is the "middle" ground between legacy applications and RMI.  You can
break your existing code apart into user interface (clients) and business
logic
(servers) and attach them using some sort of queueing mechanism.  Then, you
can
rewrite the various pieces as time permits, focusing first on your user
interface in order to give your end users a graphical interface without
having
to completely rewrite your entire system.  Once both clients and servers are
completely rewritten in Java, you can then replace messaging with RMI.

Detached processing has to do with downloading a bunch of data to your PC
and
going off and doing remote things with it.  As connectivity increases, this
becomes less of an issue, but your field sales and support personnel won't
always have constant access to a dial-up at a client site, in which case it
would be nice for them to be able to download information (such as customer
information for sales or maintenance information and diagrams for support)
the
night before.
--------------

There are probably other paradigms, but these are the most important ones.
If
you have others, please share.
========

Okay, this being the case, what are you all doing?  My current direction is
supporting fat clients, because everybody and their brother are supporting
browsers.  Me and MY brother believe in the little guy <grin>.  Anyway, hope
this will stir up a little discussion.

See yas!


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---

+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---