Topic number ONE -- JAVA400-L




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