Self-Service Applications using IBM WebSphere V5.0 and IBM MQSeries Integrator

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).