Rich Clients for Web Services

Howard Rosen, Hans Muller, Scott Violet

Java Client Group

Sun Microsystems

Summary: Rich Clients + Web Services = Best Web Experience

• Web services should offer something for everyone:

  • Basic HTML clients for kiosks and surfers
  • Rich clients for PCs, real users, business

• Rich clients for web services are easier to build with Java™ technology

• You can Web deploy clients with Java Web Start software

Overview

• Background: web services, rich clients

• Building rich clients

• Deploying rich clients

• Demo

• Guide to client talks

• Call to Action

Remember WORA?

• Write Once, Run Anywhere™

• It still matters

• Solaris™ OS, Windows, Linux, HP-UX, AIX, Tru64 UNIX, ...

• ... and once again: Apple!

Apple Demo

Last Year: “WebAwareWare”

• Guerrilla clients for unsuspecting services

  • Dictionary, Language translation, etc.

• Service characteristics

  • Variable bandwidth, high latency, HTTP
  • Poor error reporting, recovery
  • HTML data, screen scraping

Last Year: “WebAwareWare” BLOGGER Demo

This Year: Rich Clients for Consenting Servers

• Basic client/server communication protocol is still HTTP

• Many higher level protocols emerging

  • HTTP is just transport
  • XML encoding for messages
  • Real error reporting/recovery

• Good web services are not designed for a specific client or client technology

Java™ Technology Web Services Model

Web Services

• Web Services can provide leverage

  • Context (identity, role, location, etc.)

• Service to Service interactions benefit from “smarts”

• Services shouldn’t try to get smarter than the users—it can get ugly...

How Smart Is Smart Enough?

Why Build/Deploy Rich Clients

• Dynamic, responsive, easy to use

• Competitive edge / just another HTML page

• Real-time visualization

• Data sorting, filtering, direct manipulation

• Decouple server performance from the GUI

• Support offline usage

• Because they’re just better

Building Rich Clients

• Mechanics of communicating with a service

  • Using HTTP post, get
  • Decoding XML responses

• Rich Client Construction

  • The N commandments for good GUIs
  • Threads and work queues

• Deployment

iPlanet™ Calendar and Directory Servers

• Basis for our examples and demo

• Directory Server support LDAP

  • Used by Calendar for user authentication, preferences

• Calendar (5.0) protocol is WCAP

  • based on HTTP get/post
  • Responses are XML iCalendar format

Calendar HTML/JavaScript™ GUI Login

Calendar HTML/JavaScript GUI Month View

Working with HTTP

• Mechanics of communicating with a service

  • Using HTTP post, get
  • Decoding XML responses

Calendar Request: Login

• URL to login to the Calendar server: http://host:port/login.wcap?user=jdoe&password=foo&fmt-out=text/xml

  • Similar to a server "method call"
  • Method is login.wcap
  • Keyword instead of positional parameters
  • Values must be encoded

• HTTP post form is similar

Calendar Login Response

Request Generation and Parsing— Create the URL

Request Generation and Parsing— Get the XML Document

Request Generation and Parsing— Extract Document Data

Server Requests and Responses Review

• HTTP server requests are easy

  • java.net.URL

• Many options for parsing responses

  • Rough and ready
  • DocumentBuilder to DOM (javax.xml.parsers)
  • JAXB API

Building the Rich Client GUI

• Focus on how to build a compelling client

  • Low bandwidth connection to the server
  • One second round trips typical

• And users are not patient

Motivation: The N Commandments

• Don’t stare at the user

• Let them know what's going on

• Stay in sync with the data

• If the application looks idle, it should be idle

• You are not a graphics artist

Typical Rich Client GUI Task

• Collect user input

• First pass at validating the input

• Server request based on input

• Handle servers response

  • Errors: invalid input, runtime problems
  • Normal response, update GUI

Typical Rich Client GUI Task: Literal Implementation

Literal Implementation: Fatal Flaw

• One fatal flaw: server request is synchronous

  • Blocks GUI
  • User can’t tell what’s going on (no activity monitor)
  • User can’t interrupt what’s going on

Fatal Flaw: server.login() Blocks

Using a Work Queue

Building a Work Queue

The WorkQueue Thread

Server Request on the WorkQueue

Server Request on the WorkQueue (Cont.)

Event Dispatching and Worker Queue Threads

Activity Monitor, Cancellation

• Support for an activity monitor

  • Start activity monitor before server request begins
  • doHandleReponse is responsible for shutting the activity monitor off

• Cancellation

  • Short circuit pending requests
  • Don't try and interrupt active requests

New Base Class Does the Work

• Plumbing can be hoisted into a base class:

  abstract class ServerAction implements ActionListener {
  boolean isInputValid();
  void serverRequest();
  void handleResponse(); }

  • isInputValid runs synchronously on the event dispatching thread
  • serverRequest runs asynchronously from the WorkQueue, and then:
  • handleResponse runs on the event dispatching thread

ServerAction in Action

Responsive GUI— Use a WorkQueue Review

• Use a WorkQueue for server requests

  • Simple thread based primitive
  • Insulates GUI from tasks that may block
  • Serializes request processing
  • Communicates with the event dispatching thread via EventQueue.invokeLater()

• Factor common GUI Action plumbing

Web Deploying a Rich Client Java Web Start software

• Single click deployment:

  • User clicks on a link in a browser
  • Application starts

• Eliminates the install step

• Based on JSR-56: Java Network Launching Protocol and API

Web Deployment Basics HTML File

Web Deployment Basics JNLP API File

Web Deployment Review

• It’s easy!

• On the web server

  • Application jar files
  • JNLP API file
  • HTML file that contains JNLP file link

• MIME type of the JNLP file:

  • application/x-java-jnlp-file

Motivational Reminder

• OK, that’s enough plumbing details for today

• Why go through the trouble? The answer is to build incredible Rich Client applications

• You can't do this in HTML

• But you can do it with the JFC/Swing API + AWT + Java 2D™ API + “Java i18n”!

Demo!

Java™ Technologies for the Desktop: Web to PC

• This track is all things J2SE™ technology on the client: AWT, JFC, 2D, 3D, Media, Deployment, Apple Mac OS/X

• For J2SE technology client developers, Hall B is your home base this week!

• Key Sessions:

  • What’s New on the Client (TS-1309)
  • Java Web Start or JSP™ components? (TS-1828)
  • J2SE v1.3 release on Mac OS/X (TS-2813)
  • The Java™ Image I/O API (TS-600)*

Call to Action

• You have all the pieces—go do it!

• Deploy with the J2SE 1.3.1 release and Java Web Start software

• Start developing with project “Merlin” (J2SE 1.4 Beta release)

• Don't let HTML rule the world