The document discusses different client-side technologies for creating thin, fat, and rich clients: HTML/JavaScript can create thin clients through web pages but are limited by browser capabilities. J2ME MIDlets allow native-like apps on mobile devices but vary across models. Java applets embed rich functionality in web pages but require network access. Swing provides full-featured desktop apps with native look and feel but may not run well on all systems. Each option has tradeoffs around capabilities, deployment, and network dependence.

1. Understanding Client-Side Technologies
1

2. 2

3. Using Thin Clients with HTML and the
JavaScript API
• Exam Objective 7.1 Describe at a high level the basic
characteristics, benefits, and drawbacks of creating thinclients using HTML and JavaScript and the related
deployment issues and solutions.
3

4. HyperText Markup Language
• HTML is a markup language used to present static content in the
form of web pages.
• JavaScript is different than Java; it is a scripting language used to
provide interactivity in web pages.
• A thin client is an application that is not much more than a user
interface that connects to an enterprise server for its data and
processing.
• HTML and JavaScript are useful for creating user interfaces.
• All the user needs to access an HTML application is a web browse
• HTML and JavaScript provide only limited user interface
components.
4

5. Thin-Client
+HTML used with JavaScript can create a very rich and
dynamic web site.
+This site can be used as the front-end of an enterprise
application.
• However,
- this application will not have the same feel as a native
application designed for a target environment.
-It will be constrained to run inside a web browser and will
have some limitations as to what can be done with the
user interface.
5

6. --An advanced or very custom interface may be impossible or
buggy to implement across different web browsers.
--Users must always have a network connection to the enterprise
server that is hosting the web application. There is no possibility
of deploying the application locally on a user’s system.
--If the client system has a slow network connection, the
responsiveness of the web application will suffer.
6

7. Using J2ME MIDlets
• Exam Objective 7.2 Describe at a high level the basic
characteristics, benefits, drawbacks, and deployment
issues related to creating clients using J2ME midlets.
7

8. J2ME and MIDlets
• J2ME is a subset of the standard Java APIs.
• The exact subset is dependent on the profile and
configuration of the devices.
• The configuration is a general description of the device. A
profile is used to define the features of a device and may
contain more or less of the Java class libraries based on the
resources of the device.
• A profile may also be different based on available hardware
components.
> For example, an embedded device with no screen would have no
use for the user interface Java class libraries.
8

9. • Mobile phones and PDAs are the most common places to
use J2ME. These devices use the Mobile Information
Device Profile (MIDP). Applications created with this
profile are often called MIDlets.
• MIDlets can also be used for enterprise applications that
connect to a backend enterprise server.
9

10. J2ME makes use of configurations and
profiles to classify a nearly infinite
number of devices into a few groups
that share common features
• A configuration is the most basic and general description
of the minimum required Java class libraries and includes
features that the Java Virtual Machine must support
10

11. there are two J2ME configurations:
Connected Limited Device Configuration
and
Connected Device Configuration.
11

12. The Connected Limited Device
Configuration (CLDC) is a configuration
used for resource-limited devices.
• It dictates a minimum level of features that the Java Virtual
Machine must provide and contains the most basic Java class
libraries.
• The Mobile Information Device Profile or MIDP is a CLDC
profile.
• It is the profile nearly all mobile phones implement.
• Another common CLDC profile is the Information Module
Profile (IMP). IMP is designed for headless systems.
Embedded control units and vending machines are two
examples of where this profile may be found.
• In general, it is a small subset of MIDP, with its most notable
exclusion being the Java class libraries for creating graphical
user interfaces.
12

13. The second J2ME configuration is the
Connected Device Configuration (CDC).
• This configuration has a more complete set of Java class
libraries than the CLDC.
• It contains nearly the entire set of Java class libraries from
the standard edition of Java, with the exception of the
user interface libraries.
13

14. Like the CLDC, the CDC has profiles
that further define the target device .
• The Foundation Profile defines a full implementation of the
Java Virtual Machine and most of the Java class libraries,
excluding the user interface classes.
• The Personal Basis Profile adds the AWT class libraries, in
addition to what the Foundation Profile defines.
• the Personal Profile includes everything contained in the
• previously mentioned profiles, with the addition of support
for applets.
14

15. • Configurations and profiles are beneficial from a development
perspective because they allow you to group similar, but still
different, devices together and share common code between
them.
15

16. J2ME Disadvantages
• J2ME does not completely follow the Java motto of “write once, run
anywhere.”
• Mobile and embedded devices vary too much for this to be true.
• Configurations and profiles address this problem to a degree, but the
experienced J2ME developer will still find many nuances that exist
between devices, especially in areas dealing with user interfaces.
• J2ME is not intended for very complex applications. This has more to
do with the intended targeted devices than with this edition of Java.
• J2ME is ideal for creating applications to look up or record simple
information. Creating complex software such as a word processor
would quickly push up against the limitations of the device and J2ME
libraries.
16

17. J2ME Deployment
• J2ME MIDlets are generally deployed over a network.
They can be manually loaded onto a device, but that isn’t
very useful for a large install base.
• Typically, they will be loaded by a web server, serving
them to clients upon their request.
• A MIDlet on a web server will consist of at least two files:
a Java Application Descriptor, or JAD, and the Java
Archive, or JAR file.
• The JAD file is used to describe the MIDlet. It
• is a text file that contains information such as the MIDlet’s
version, the location of the JAR, the location of the icon (if
it exists), and many other attributes.
17

18. Using Java Applets as Fat Clients
• Exam Objective 7.3 Describe at a high level the basic
characteristics, benefits, drawbacks, and deployment
issues related to creating fat-clients using Applets.
18

19. • An applet’s advantage is its ability to be embedded in a
web page but still retain powerful features that would
normally be found in a standard desktop application.
• The main difference between the two is the way the code
is invoked.
• An applet will allow the client to access backend
enterprise servers such as web servers, web services,
and databases.
• It also can make use of advanced Java user interface
elements such as Swing and multimedia libraries for
media playback.
19

20. Java Applet Disadvantages
• As stated earlier, to execute the applet the Java Virtual
Machine must be used.
• It also must be a current version. If an applet is executed
on an out-of-date Virtual Machine, the applet will attempt
to download the latest version. This may create a
substantial delay in the startup time of the applet.
• Applets have much tighter runtime restrictions than a
standard Java application.
• They also are executed in a sandbox that gives them
limited access to the client-side system.
•
20

21. • And even if more than one applet is embedded in the same page,
intercommunication is impossible. These restrictions may be
relaxed but the user must agree to it via a prompt from the Java
Virtual Machine.
• Since applets are often located inside web pages, they are not
able to be executed offline.
• The user must have a network connection to the server that
contains the applet.
• If the user does have a network connection but limited
bandwidth, the user may suffer from very slow load times since
the applet is reloaded each time it is run.
• Some cache is available to help speed up this process, but this is
unreliable since it can easily be cleared.
21

22. Java Applet Deployment
• Applets are easy to deploy. They reside on the web
server and are embedded in the web page. When the
user accesses the web page, as long as the user has the
Java Virtual Machine installed with the Java browser plugin, the applet will load.
• The advantage of this system of deployment is that the
user never needs to install an application.
• From the user’s perspective, they are just visiting a web
page. This also allows the programmer to control the
deployed version of the applet.
• When a new version is released, it can be loaded on the
web server and the next time the user visits the site and
loads the applet, the newer version will be used.
22

23. Using the Java Swing API as a Fat Client
• Exam Objective 7.4 Describe at a high level the basic
characteristics, benefits, drawbacks, and deployment
issues related to creating fat-clients using Swing.
23

24. Using the Java Swing API as a Fat
Client
• Swing extends some of the classes of AWT. However,
there is a vast difference on how they render their
components.
• AWT is considered heavyweight.
• This means that they rely on the native system’s
windowing components.
• An AWT component will utilize the native system to
render and control each component used.
24

25. • Swing does have the advantage of being skin-able. Skin-able
is a term that means the developer can change the look and
feel of Swing without having to modify its components.
• The source code of a component does not require
modification to change its look andfeel. It is distributed with
different skins that give it the appearance of a native
application on different platforms.
25

26. • Swing is a standard part of J2SE. It allows for the creation of fully
featured desktop applications.
• These applications are often designed to run on a client’s system
just like they run on any other native program—oftentimes being
indistinguishable.
• Swing offers the richest set of user interface components. The
applications have full access to the system they are executed on,
and can feature a complex interface for performing more
demanding tasks.
• The only requirement to run a Swing application is to have the
Java Virtual Machine installed.
• It does not require a network connection unless it is required to
connect to a server during runtime.
26

27. Java Swing API Disadvantages
• Swing has default skins that resemble the native look of many
platforms. However, users still may notice subtle differences
between a Swing application and a native
• or AWT one.
• Since Swing is a full-blown toolkit for creating user interfaces, it
may not run as well on older hardware or systems that have
limited resources.
• If your application is simple, sometimes a full Swing application
introduces more complexity to a project than needed.
• It may be easier for the developer, and user, to create a simple
web application with an HTML interface
27

28. Java Swing API Deployment
• The first method, and the traditional method, is to release
your software as a package distributed by CD or for
download over the network. The user will then run some
form of installer to load the software onto their system.
This is good if the software rarely changes.The user
will have the software on their computer and will not have
to worry about having a good network connection or
reloading it from the enterprise server every time.
28

29. • The second way to deploy a Swing application is to use
Java Web Start.
• Java Web Start is a technology developed by Sun
Microsystems to deploy Java applications like a Java
applet. It allows a full desktop application to be launched
from a web browser.
• Like an applet, it downloads all of the required files from a
remote server. However, unlike an applet, it does not run
inside the browser.
• It runs on the system similar to a native application. By
default, a Web Start application is restricted from
accessing the local file system and is limited as to which
remote servers it can connect to.
• These restrictions can be overcome if the user allows it.
29

30. 30

31. 31

32. 32

33. 33

34. 34

35. 35

36. 36

37. 37

38. 38

39. 39

40. 40

41. 41

42. 42

43. 43

44. 44