Chapter 5. Technology options 61
5.1 Web client
Figure 5-2 shows the recommended technologies for Web clients.
Figure 5-2 Web client technology model
The clients are “thin clients” with little or no application logic. Applications are
managed on the server and downloaded to the requesting clients. The client
portions of the applications should be implemented in HTML, dynamic HTML
(DHTML), XML, and Java applets.
The selection of client-side technologies used in your design will require
consideration for the server side, such as whether to store, or dynamically
create, elements for the client side.
The following sections outline some of the possible technologies that you should
consider, but remember that your choices may be constrained by the policy of
your customer or sponsor. For example, for security reasons, only HTML is
allowed in the Web client at some government agencies.
Browser/Web Top
Java VM
Applets
and
JavaBeans
Protocols - HTTP, IIOP, ...
Network Infrastructure
Native Apps
Shrink
Wrapped
Custom
CREDIT CARD
1234 5678 90121234 5678 901 2
VALID FROMGOOD THRU
XX/X X/ XX X X/ XX/X X
P AUL FI S CHER
XX/ XX/ XX XX/XX/XX
PAUL FI SCHER
Pervasive
NC
Managed PC
PC
TCP/IP, WAP ...
HTML, DHTML, XML, WML
62 Self-Service Applications using IBM WebSphere V5.0 and IBM MQSeries Integrator
We also touch on some of the current technology choices in the wireless area.
5.1.1 Web browser
A Web browser is a fundamental component of the Web client. For PC-based
clients, the browser typically incorporates support for HTML, DHTML, JavaScript,
and Java. Some browsers are beginning to add support for XML as well. Under
user control, there is a whole range of additional technologies that can be
configured as “plug-ins”, such as RealPlayer from RealNetworks or Macromedia
Flash.
As an application designer, you must consider the level of technology you can
assume will be available in the user’s browser, or you can add logic to your
application to enable slight modifications based upon the browser level. For
Internet users, this is especially true. With intranet users, you can assume
support for a standard browser. Regarding plug-ins, you need to consider what
portion of your intended user community will have that capability.
Cross-browser strategies are required to ensure robust application development.
Although many of these technology choices are maturing, they continue to be
inconsistently supported by the full range of browser vendors. Developers must
know browser compatibility for all features being exploited by the application. In
general, developers will need to code to a lowest denominator or at least be able
to distinguish among browser types using programmatic techniques. The key
decision here is to determine the application requirements and behavior when
handled by old browsers, other platforms such as Linux and Mac, and even the
latest browsers.
In the J2EE model, the Web browser plays the role of client container. The model
requires that the container provide a Java Runtime Environment as defined by
the Java 2 Platform, Standard Edition (J2SE). However, for an e-business
application that is to be accessed by the broadest set of users with varying
browser capabilities, the client is often written in HTML with no other
technologies. On an exception basis, limited use of other technologies, such as
using JavaScript for simple edit checks, can then be considered based on the
value to the user and the policy of the organization for whom the project is being
developed.
The emergence of pervasive devices introduces new considerations to your
design with regard to the content streams that the device can render and the
more limited capabilities of the browser. For example, WAP (Wireless Application
Protocol) enabled devices render content sent in WML (Wireless Markup
Language).

Get Self-Service Applications using IBM WebSphere V5.0 and IBM MQSeries Integrator now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.