Java and Rich Clients for Data Processing Applications

1
Java and Rich Clients for Data Processing
Applications

• Dan Dubinsky
• SOFIA Lead Architect-Salmon LLC

2
A note about SOFIA

• SOFIA is Salmons open source framework for
  building database driven web applications in
  Java.
• For building web applications it is pretty
  mature.
• Now we are adding some rich client functionality
  to it which Ill show you as we go along.
• If you want more info on SOFIA or a demo, contact
  me (ddubinsky_at_salmonllc.com) or Ken Hoffman
  (khoffman_at_salmonllc.com) .

3
History of Business User Interfaces.

• A long time ago, in a galaxy far far away
• We had The Green Screen
• There was a central main frame or mini computer.
• Connected to it was a bunch of 80x24 character
  green on black terminals.
• User filled in a screen and hit a pf key, all the
  while the processing was done on the central
  computer.
• The good and the bad
• I.T. people liked the centralized control.
• Easy deployment of applications.
• The computer could be protected from the dumb
  users.
• But the average human still couldnt figure it
  out without a lot of training.
• Writing a screen in COBOL took a lot of code.
• But it was better than punch cards.

4
Then came the PC, the GUI and Client/Server

• PC Client / Server changed everything.
• User interfaces because beautiful to look at.
• User interfaces became (relatively) easy to use.
• User interfaces because highly interactive.
• People could run many applications at the same
  time.
• PCs were smart and could handle a lot of the
  processing so the central computer didnt get
  pounded as much.
• Writing screens in MFC was a bear, but tools like
  Powerbuilder and Visual Basic let you create
  screens in no time.
• Mainframes and minis started looking really old.
• Powerhouse mini computer companies like Dec and
  Wang pretty much evaporated in favor of PC
  companies like Microsoft, Intel and Compaq.

5
PC Client/Server Continued

• But no good deed goes unpunished.
• The rich client was good for the users, but bad
  for the I.T. department.
• Users needed an unruly and hard to maintain
  workstation instead of a bullet proof dumb
  terminal.
• Clueless users now had a gun big enough shoot
  their foot off.
• Applications had to be deployed to every
  workstation manually.
• Because stuff was hard to deploy, end users
  didnt always have access to the latest stuff.
• Stuff worked well enough in the office, but what
  about mobile workers?

6
Then came N-tier

• The end users seemed pretty happy with Client/
  Server, but IT folks were all talking about the
  evils of the fat client.
• Distributed thin client technologies like CORBA
  and DCOM were going to solve everything but
  didnt
• They were so complex that even your average
  computer guru couldnt figure them out so nobody
  really knows what they solved.
• Developers started using an ultra-thin client
  technology for business apps.
• The technology was designed to deliver static
  documents over the Internet.
• It turned out to be pretty good for dynamic and
  somewhat interactive documents also.

7
The Web Application

• Web applications solved the fat client problem
• Zero deployment cost, everything downloads on the
  fly as needed.
• People could connect from anywhere, not just in
  the office.
• User interfaces were just as nice looking or
  nicer as with client server and are easy to
  create.
• At first, writing interactive programs was very
  cumbersome with CGI, but that improved very
  rapidly with servlets.
• These days every application done at Salmon LLC
  is web based.

8
Web Applications

• But there is always the dark side
• User interfaces took a step back to a main frame
  style model.
• User fills in an entire form and clicks submit.
• The central computer processes the form and sends
  back a new one.
• The screens look good, and allow the user to use
  the mouse and keyboard for input but
• Browsers are designed for viewing static
  documents.
• They are very good displaying stuff.
• All the interactive stuff was bolted on
  afterwards.
• The server has to do almost everything.
• What if you need something more interactive?

9
Enter Java Applets

• Applets were going to solve everything.
• All the hype about applets got a lot of people
  talking about Java.
• Applets are little Java programs that download on
  the fly as part of a web page
• The good news
• No manual deployment.
• Very interactive U/I can be created.
• Applets take advantage of all the processing
  power on the client computers that is idle with
  web apps.
• The bad news
• Applets took forever to download.
• Applets took forever to launch once they did
  download.
• Applets were slow and loaded with bugs and
  browser incompatibilities (Netscape was actually
  worse then IE).
• The built-in widget toolkit (AWT) was so limited
  you couldnt create a decent user interface with
  it.

10
So the world moved on

• Applets became the road kill on the information
  super highway.
• They never really had the impact that was
  promised.
• It was just too hard to get them to work.
• Somehow Java didnt go down with the Applets.
• It turns out that Java is an excellent language
  for writing server side applications.
• The J2EE was born, works very well and has become
  very popular.
• Sun added the Swing set for client/server style
  applications to address the weaknesses in the AWT
  but
• Early versions of Swing were so full of bugs you
  couldnt really use it.
• Most Java business application development
  followed the path of least resistance and was
  wound up being built as web applications.

11
So what about the Rich Client?

• These days, developers use Java rich client
  technologies for Client/Server style
  applications.
• The only way to get browser delivered rich client
  over has been to fake it
• Dynamic HTML (basically style sheets and
  JavaScript) provide some rich functionality but
• JavaScript only does so much.
• JavaScript is hard to debug.
• JavaScript behaves differently on every browser.
• Show Navigation Bar example.
• If you are really clever with the HTML, you can
  disguise the fact that you are making a round
  trip to the server each time.
• Show the SOFIA tree example.
• But you can only stretch the metaphor so far

12
The holy grail!

• To be be able to
• Deliver applications to end users where they
  dont have to install anything and cant mess
  things up.
• Not have a full screen refresh and trip to the
  server every time the user clicks a button.
• Provide rich U/I functionality
• Allow direct manipulation of the user interface
  (scrollbars, split panes).
• Provide the user immediate feedback for
• Errors
• Data Transformations
• Available Functions
• Keyboard shortcuts for commonly used actions.
• Is it possible to get everything?

13
Well lets see!!!

• Contact Manager as a Rich Client
• Harder to write, but provides a better user
  experience.
• Contact Manager in HTML/JSP
• Easier to write, but not as interactive

14
So how did we do the rich client?

• Some interesting technology from Sun has been
  quietly creeping up that makes this feasible.
• The Java Plug-In for Applets
• Makes applets run consistently across browsers
• They actually seem to run pretty well
• Use the ltjspplugingt tag or the ltsalmonappletgt
  tag in a JSP page.
• Java Web Start for Applications
• Downloading Java apps on the fly from a web
  server.
• Caches the application jar and only load changes.
• To deploy, create a JNLP file on the web server.
• As a static XML file
• As a JSP file with some dynamic elements
• Lets see some code!

15
Unfortunately the plug-in and Java Web Start
isnt universal.

• To get this to work, you need to install the JDK
  from Sun on every workstation.
• Its a big download.
• Users may not be able to install it.
• Users may not want to.
• At this point, Java browser delivered rich
  clients are better suited to controlled
  environments like the intranet.
• If Sun wins its case against Microsoft, this may
  change, but I wouldnt hold my breath
• Still, we now have something viable for use
  inside the company.

16
So should we use web applications or rich client.

• We think there is room for both in a typical
  business application.
• Do an HTML based user interface for casual users.
• Its easier to develop.
• More likely to work in the uncontrolled
  environment of the Internet.
• Do a rich client for key areas of the application
  or for power users.
• Where the environment is controlled, or where
  people would be willing to download the JDK for
  the extra functionality.

17
So now we can deliver it, how do we build it?

• The Swing Set is one way to build it.
• A full set of pretty good U/I widgets for Java.
• Learning curve is steep.
• With JDK 1.4 (finally) Swing is pretty stable and
  pretty fast
• It was pretty slow and buggy before that
• Swing applets are still a bit scruffy compared
  to native applications especially with the Metal
  Look and Feel.
• Development takes longer than web apps.
• Layout Managers are the biggest problem
• Grid Bag Layout is really difficult to use.
• Box Layout seems to work best.
• There arent a lot of good GUI painters out there
  for Swing so for the most part you have to hand
  code it.

18
Taking the teeth out of Swing

• Swing has a pretty bad rep, but it isnt that bad
  once you learn it. Swings biggest problem (in my
  opinion) are really
• The default Metal Look and Feel is ugly.
• Bad layout managers.
• Table Layout Manager
• java.sun.com/products/jfc/tsc/articles/tablelayout
  /
• A Free Layout Manager for Swing that acts like an
  HTML table.
• JGoodies
• www.jgoodies.com
• Layout managers and skins that make Swing
  applications look really good.

19
The SWT

• IBMs SWT
• IBMs answer to the Swing Set.
• Eclipse was built with it.
• It uses native widgets for each OS.
• Swing uses emulated widgets, not native.
• SWT works well on Windows, but so as well in
  other Operating Systems (from readings).
• SWT isnt suitable for applets.
• A real religious war is going on out there
  between the SWT people and Swing people.
• It works well from Java Web Start but you must
  sign the jars.
• SWT example.

20
What if I want to deploy something on the
Internet?

• Macromedia Flash
• Flash has been a tool for delivering interactive
  presentations and games via the web.
• The Flash plug-in is installed on just about
  every browser out there and if not the download
  is painless.
• The graphics capabilities are terrific.
• Flash Movie Downloads are fast.
• Macromedia is now pushing Flash for business
  applications with with Flash remoting.
• The problems
• Flash is proprietary to Macromedia.
• Development and deployment tools are expensive
  and pretty bad for coders.
• Java people will need to learn a new language and
  paradigm (ActionScript and Timelines).

21
Some Other Technologies worth noting.

• Thinlets
• www.thinlet.com
• A widget toolkit that uses XML definition files
  to create the screens instead of Java code.
• Seemed a bit thin to me.
• Zaval
• www.zaval.org
• An open source light weight widget toolkit.
• Works well from Applets
• XForms
• www.w3.org/Markup/Forms/
• A W3C initiative to improve some of the
  shortcomings of HTML forms using XML.
• Very bleeding edge.

22
What is Salmon doing with all this stuff.

• Quite a bit of research at this point.
• We are building Swing bindings to SOFIA.
• Allow Swing components to be bound to database
  tables and columns.
• Allow Swing components to do automatic data
  validation based on data model objects.
• Added some little U/I enhancements (right click,
  auto select text, error message bubbles).
• Swing Code Example.
• Stuff we are thinking about.
• SWT integration.
• Flash integration (as long as nobody has to use
  the Flash IDE and Action Script but us).
• A Swing GUI painter.

23
Where to get this presentation.

• Download the slides from
• http//www.salmonllc.com/JUG/RichClient.pdf