chapter 11:understanding client-side technologies

44
1 Understanding Client-Side Technologies

Upload: it-academy

Post on 05-Dec-2014

195 views

Category:

Technology


1 download

DESCRIPTION

Exam Objective 7.1 Describe at a high level the basic characteristics, benefits, and drawbacks of creating thin-clients using HTML and JavaScript and the related deployment issues and solutions.

TRANSCRIPT

Page 1: Chapter 11:Understanding Client-Side Technologies

1

Understanding Client-Side Technologies

Page 2: Chapter 11:Understanding Client-Side Technologies

2

Page 3: Chapter 11:Understanding Client-Side Technologies

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 thin-clients using HTML and JavaScript and the related deployment issues and solutions.

Page 4: Chapter 11:Understanding Client-Side Technologies

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 browser.• HTML and JavaScript provide only limited user interface

components.

Page 5: Chapter 11:Understanding Client-Side Technologies

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.

Page 6: Chapter 11:Understanding Client-Side Technologies

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.

Page 7: Chapter 11:Understanding Client-Side Technologies

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.

Page 8: Chapter 11:Understanding Client-Side Technologies

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.

Page 9: Chapter 11:Understanding Client-Side Technologies

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.

Page 10: Chapter 11:Understanding Client-Side Technologies

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

Page 11: Chapter 11:Understanding Client-Side Technologies

11

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

Page 12: Chapter 11:Understanding Client-Side Technologies

12

The Connected Limited Device Configuration (CLDC) is a configurationused 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.

Page 13: Chapter 11:Understanding Client-Side Technologies

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.

Page 14: Chapter 11:Understanding Client-Side Technologies

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.

Page 15: Chapter 11:Understanding Client-Side Technologies

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.

Page 16: Chapter 11:Understanding Client-Side Technologies

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.

Page 17: Chapter 11:Understanding Client-Side Technologies

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.

Page 18: Chapter 11:Understanding Client-Side Technologies

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.

Page 19: Chapter 11:Understanding Client-Side Technologies

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.

Page 20: Chapter 11:Understanding Client-Side Technologies

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

Page 21: Chapter 11:Understanding Client-Side Technologies

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.

Page 22: Chapter 11:Understanding Client-Side Technologies

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 plug-in, 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.

Page 23: Chapter 11:Understanding Client-Side Technologies

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.

Page 24: Chapter 11:Understanding Client-Side Technologies

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.

Page 25: Chapter 11:Understanding Client-Side Technologies

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.

Page 26: Chapter 11:Understanding Client-Side Technologies

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.

Page 27: Chapter 11:Understanding Client-Side Technologies

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

Page 28: Chapter 11:Understanding Client-Side Technologies

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.

Page 29: Chapter 11:Understanding Client-Side Technologies

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.

Page 30: Chapter 11:Understanding Client-Side Technologies

30

Page 31: Chapter 11:Understanding Client-Side Technologies

31

Page 32: Chapter 11:Understanding Client-Side Technologies

32

Page 33: Chapter 11:Understanding Client-Side Technologies

33

Page 34: Chapter 11:Understanding Client-Side Technologies

34

Page 35: Chapter 11:Understanding Client-Side Technologies

35

Page 36: Chapter 11:Understanding Client-Side Technologies

36

Page 37: Chapter 11:Understanding Client-Side Technologies

37

Page 38: Chapter 11:Understanding Client-Side Technologies

38

Page 39: Chapter 11:Understanding Client-Side Technologies

39

Page 40: Chapter 11:Understanding Client-Side Technologies

40

Page 41: Chapter 11:Understanding Client-Side Technologies

41

Page 42: Chapter 11:Understanding Client-Side Technologies

42

Page 43: Chapter 11:Understanding Client-Side Technologies

43

Page 44: Chapter 11:Understanding Client-Side Technologies

44