QUESTION 1

1. Explain in your own words the diffrerences between client side & Server side
technologies

The differences between client side and server side technologies:

Objective:

- Client side technologies refer to technologies (or code) implemented and used by
client such as web Browsers and application software client.
- Server side technologies refers to technologies used on the back end server to execute
requests sent by client side.

Goals:

- Client side technologies:

oAdd interractivity to user interface
oDynamic page content
oAdd multimedia
oReduce download time
oReduce client-server contacts.
oDisadvantage when the client side program is dependent upon having
technology available and anabled in the client’s browser/client application.
o Need to upgrade and create multiple versions of the contents due to
different use of versions and technologies.
o Difficult or impossible to perform tasks that demand writing and reading
to files or local databased.
- Server side technologies:
o Restrict external accesses local file system, web file system
o Robust and reliable
o Optimizing code for fast processing
o Independent from the variability of broswer at the client side
o Wider range of development tools on the server side
o Access to much broader range of resoures and fast performance to write &
read local database.
o Disadvantage when need to traffic back and forth to the server more often,
and hence inrease the level of complexity and processing time.

Processing steps:

- Client side technologies:

o Client requests page from server
o Server sends page with appropriate code embedded/attached
o Client processes code as needed, including during page events (moving
from one field to another, pressing a button, etc)
You may also run into an issue that even if the technology is available, it might be an
older version that won't work with your site, and you will have to force the user into an
upgrade or create multiple versions of your content.

- Server side technologies:

o Client requests page from server
o Server "hands" page to processing server or module
o Processing server/module returns processed code output
o Server sends completely processed page

Reference:
Server-Side vs Client-Side Development
What They Are

Client-side development refers to code implemented on a web site that is processed by

your local browser and/or plug-ins. Javascript is the classic example of a client-side
mechanism... the Javascript code is written into the web page, but it is processed
(executed) but the Javascript interpreter within the browser. On most class pages for
example (including this one), Javascript is used to create the link for bookmarking the
current page. If you view the source you can see the code that checks the browser version
and writes a link appropriately. Other client-side technologies include Flash, Quicktime,
Jscript, etc.
Server-side development refers to code that is executed on the web server (or in
combination with another server) rather than on the user's browser. Again on most class
pages, the document information above the bookmark link is generated using PHP code,
which executes on the server itself and send the results to the specified spot on the web
page. There are many server-side languages such as: PHP, ASP, Cold Fusion, Perl, and
Java Server Pages.

Advantages and Disadvantages

Choosing an appropriate technology means understanding not just the differences

between the options available to you, but also understanding the advantages and
disadvantages of each. Here are some notes to help guide you in this process.

Client Side

In client-side programs, the web server send the client a page with the code embedded
and the client (typically the user's browser) processes the code. So the request cycle has
these steps:

1. Client requests page from server

2. Server sends page with appropriate code embedded/attached
3. Client processes code as needed, including during page events (moving from one
field to another, pressing a button, etc)

The fundamental strength of client side development is that no data has to be sent back
and forth from the user's browser to the web site for processing. For instance, if you have
a form and wish to restrict particular fields so that they can only contain numbers, it is
much more efficient to do this on the client-side using Javascript than to have the user
repeatedly submit the form and then return to to fix errors. Client-side processing
offloads some of the work associated with your development, using the CPU and memory
available on the client, who most likely many fewer processes running at any one time
than the web server.

The problem with client-side development is that you are dependent upon having the
technology available and enabled in the user's browser! Your careful form validation
does no good if your user has a browser that doesn't support Javascript or has it turned
off for some reason (and this is more common than you might think). To effectively use
client-side tools you have to check if the tool is available and then route the user
appropriately, either to a page that can accomodate their capabilities, or to a page
directing them to turn on or download and install the client-side tool(s) needed. You may
also run into an issue that even if the technology is available, it might be an older version
that won't work with your site, and you will have to force the user into an upgrade or
create multiple versions of your content.

Server Side
In server-side programs as we will be creating in this class, the process is a bit different.
Code embedded on pages is processed and output on the server and the user sees only
the completed page. So the request cycle has these steps:

1. Client requests page from server

2. Server "hands" page to processing server or module
3. Processing server/module returns processed code output
4. Server sends completely processed page

Server-side development requires more trips back and forth from the browser to the
server, but it is usually much more robust and reliable. Since the server is optimized for
the code that is running, the actual processing time for the code itself is faster than if the
same code is run on the client. As a developer, you only have to worry about a single
compatibility issue (what is available on your server) instead of the variability of ever
browser that comes to your site. There is a much wider range of development tools
available on the server side, each with their own strengths and weaknesses, and each
suited to a different kind of user.

Server-side technologies provide access to a much broader range of resources than are
easily available in most client-side tools. Javascript, for example, is severely limited for
security reasons (you don't want anyone with a web site to be able to access your local
file system, nor do you want every user to have access to your web file system!), making
it difficult or impossible to perform tasks that demand writing and reading to files or
databases.

The disadvantage of server-side technologies is the need to traffic back and forth to the
server more often (remember the form field validation scenario above?) and a generally
increased level of complexity because of the increased opportunities and capabilities. If
the language you wish to program in is only available through the older CGI protocol,
then processing time will increase greatly.

How to Choose

There is no single answer to which technology to use for every project. In general,
server-side technologies are preferred over client-side where possible, unless the
function is not vital to the use and operation of the site. For instance, on the class home
page, if a user doesn't have Javascript I am not particularly worried-- they will only be
missing a shortcut for adding a page to their bookmarks, rather than vital content (and,
since the auto-bookmark function demands Javascript anyway, the function is useless
without it). I consider the document information to be more important, particularly since
documents get printed and handed around, so I generate this from the server-side (and it
is much easier and more accurate to access things like file paths and dates from the
server side).

Sometimes you will have no choice. If you wish to use a database with your web site, you
must have access to some server side technology. If you want to provide animations,
interactive games, or audio/video content, you will have to have some kind of server side
technology like Flash, Shockwave, Quicktime, etc (sometimes in conjunction with a
special server for those file types).

Whatever you do, if you do use client-side technologies, don't rely on it alone! Javascript
security or validation is fine if you make allowances for those users who don't have it or
don't have it enabled. For instance, it is ok to validate a form with Javascript, as long as
we are sure to do something on the server side to catch the error and help the user get it
right, rather than just have your web application die with a nasty error message.

In this class, I am going to focus on server-side technologies, specifically PHP, because I

feel you will get much more mileage out of this (and because I don't like the Javascript
language and am really no good at it). Also, tools like Dreamweaver already provide
automated ways to generate client-side code for most tasks.

2. Give an example where you would use client side technologies & an example where
you could use server side technologies. Explain your example

Example where client side technology would be used in the Web Browswer is to display
data, handling events, etc.

Examples of using Javascript (client side technology) to:

1. Write Text on the Browser

<html>
<body>

<script type="text/javascript">
document.write("Hello World!")
</script>

</body>
</html>

2. Format text with HTML tabs

<html>
<body>

<script type="text/javascript">
document.write("<h1>Hello World!</h1>")
</script>
 </body>
</html>

3. Javascript in the head section

<html>
<head>
<script type="text/javascript">
function message()
{
alert("This alert box was called with the onload event")
}
</script>
</head>

<body onload="message()">

</body>
</html>

4. Javascript in the body section

<html>
<head>
</head>

<body>

<script type="text/javascript">
document.write("This message is written when the page loads")
</script>

</body>
</html>

Example where server side technology would be used in the Web Server is to query local
database for the requested data from the client side.

1.
II
Give an example for company or situation where you would use a 2-tier client-server
architect. Explain

Example:

- Technical Department: Daily Report Website. (ASP + SQL Server) at server side and
Web Browser at client side. The presentation layer (web Browser) is used to get input
from staff. The input consists of several text fields to evaluate the performance of each
input working item. The purpose of the website is just to collect the input and output
to a summary report at the end of the week. There is no clear business logic layer here
In essence, the client handles the display, the server handles the database, and the
business logic is contained on the server side.
- Example of a 2-tier approach is a specialized terminal-to-server application like FTP
client-server software application.
- Customer management website at (Mr. Ngoc Anh’s office): programming language is
VB + SQL Server. The client side has an application software and the server side has
SQL server to response to the data query request from the client side. In essence, the
client handles the display, the server handles the database, and the business logic is
contained on the server side.

Give an example for company or situation where you would use a 3-tier client-server
architect. Explain

Example:

- VDC: The customer care and billing system (CCBS) for internet telephony service
called FoneVNN. (The systems consist of 3 main components: client side (web
Browser, Webserver/Application server (writen in ASP), and Database server
(mySQL). The web browser acts as the client layer, the application layer handles the
business logic, and a separate tier (MySQL database servers) handles database
functions.
-

Explain the difference between the example you gave in part 1, part 2 of this Question
 2-Tier 3-Tier
System Admin. Complex Less complex

(more logic on the client to (the application can be centrally

manage) managed on the server –application
programs are made visible to
standard system management tools)
Security Low High

(data-level security) (fine-tuned at the service, method,

or object type level)
Encapsulation of data Low High

(data representation exported) (client invokes services or methods)

Performance Poor Good

(many SQL statements are sent (only service requests and

over the network; selected data responses are sent between client
must be downloaded for analysis on and server)
the client)
Internet support Poor(Internet bandwidth limitations Excellent(very often, only web-
make it harder to download fat browser is required as client side
clients) software)
Hetero database No Yes
support
(can use several databases within
the same business transaction)
Architecture flexibility Limited(you have a client and a Excellent(all tiers may reside on
server) different machines, or 2nd and 3rd
tier on the same machine, or the
middle-tier accross multiple
servers)

Reference:
The term n-tier refers to the number of logical levels or layers the various components of
an application occupy. An application consists of the following primary component
layers: Presentation layer, Application or Business Logic layer, and the Data layer. The
presentation layer incorporates user interface components. The user interface might
include Graphical User Interface (GUI) components or be completely text based. A user
interacts with an application through its presentation layer. The application layer or
business logic layer houses the application proper, this means any domain specific
knowledge components needed to power the functionality of the application reside at this
layer. The data layer exists to allow the application layer to capture and maintain
application state data. The data layer might take the form of one or more standalone or
geographically distributed database servers. The "n" indicates the number of levels these
components are split into. This does not mean how many physical computers an
application is spread across, for example, a 3-tier application could very well reside on
one computer but you'll see shortly why this is not usually the case. Before diving deeper
into the n-tier discussion I'd like to talk a little about the term-application.

Now consider how the knowledge contained in a computer program is updated. If the
program update requires source code to be modified, re-compiled, and redistributed to
every user of the program, and the program itself contained the user interface, the
knowledge rules or business rules, and supporting data would be an example of a 1-tier
application. In a 1-tier application, the logical layers of the application are tightly coupled
and an update made to one layer requires an update to the whole. In other words, there
are no separate, logical layers to a 1-tier application.

A 2-tier application would be split logically into 2 layers. This logical split normally
occurs between the business rules layer and the data layer. A 3-tier application would
be logically separated into three layers. As with the 2-tier application architecture, all
layers of a 3-tier application can be collocated on the same computer or each layer may
reside on geographically separated computers connected via a network. The typical
deployment of an n-tier application shows several client computers accessing an
application server. The application server, in turn, accesses the data server. Connections
can be made in the clear or by virtual private networks.

An organization stands to gain many benefits from developing and deploying n-tiered
applications, especially in the Internet age. One of the most important benefits comes
from getting out of the configuration management business. In a 1-tiered application
world, updates to applications must be distributed to every interested user. More often
than not, an application upgrade has unknown side effects on host machines. An
application that runs great in a controlled integration environment may crash a user's
computer because of some untested, Dynamic Link Library (DLL) conflict.

Migrating to an n-tiered application enterprise architecture gives greater control of the

desktop PC to IT managers by limiting the number of different, sometimes conflicting,
applications installed on them. Another significant benefit of n-tiered applications comes
from the instant availability of application updates across the entire organization. Because
business logic is located in the application layer, changes to the functionality of an
application are immediately available to users. A third benefit comes from the fact that
most of the processing occurs in the application or data layers. This can mean a reduction
in bandwidth requirements over 2-tier applications that must transfer large amounts of
data between the local application layer and remote data layer.
III
Explain why so many companies have adopted XML to discribe & store thier data

Why XML is so popular today ?

- XML was designed to describe data.

- XML tags are not predefined(k0 xác định trước) in XML. You must define your own
tags.
- XML uses a Document Type Definition (DTD) or an XML Schema to describe tags
and structure.
- XML with a DTD or XML Schema is designed to be self-descriptive.

Advantages:

- Straightforwardly (dễ làm) usable over the Internet.

- Support a wide variety of applications.
- Compatible (tương thích)with SGML.
- Easy to write programs that process XML documents.
- Human-legible and reasonably clear.
- The XML design is prepared easily.
- The design of XML is formal and concise.
- XML documents is easy to create.
- Terseness (xúc tích) in XML markup is of minimal importance.

The key features of XML that have led to its widespread adoption are:

- It is simple enough that parsers became available very quickly and were distributed in
most cases as free or open-source software. This meant that the decision to use XML
could be made in many organizations without a lengthy investment review.
- It largely gets rid of low-level character encoding problems by adopting Unicode as its
single character repertoire, allowing worldwide deployment.
- It is sufficiently flexible to handle both narrative documents intended for a human
readership (for example, Web pages) and arbitrary hierarchic data structures intended
to be processed by applications, as well as combinations of the two.
- The syntax itself is human-readable, allowing simple documents to be created or read
using nothing more than a standard text editor.
- There is no turf war: XML is supported by the entire IT industry, and the products
offered by different vendors are highly interoperable.
- These factors mean that today, XML is widely deployed not only for the original
application area of Web content management, but for a large variety of other
applications. In many of these applications, the information needs to be stored
somewhere, and this is where the requirement for XML databases comes from. The
need to store XML As the previous section shows, XML was not initially developed as
a model for storing information. But once an organization has decided to adopt XML
to underpin a key business process, the need to store the information (and, of course,
to retrieve it later) soon follows.
- There are essentially three ways that this can be done:
o Store XML as files.
o Extract the data.
 o Use an XML database.

Why can it often be useful to separate data & layout/display

- Group the same layouts in a master layout to optimise line code

- Program is neat and easier to read
- Can use different template/layout to produce output for different types of clients from
the same data.

The Extensible Stylesheet Language (XSL) makes a great solution for merging the data
with the layout to provide content. Through the nature of XML, XSL allows you to
separate the data from the layout. As long as you can provide the data in XML format,
you can use XSL to produce content.

Client
1: Client 2: Client
Mobile Browser 3: Web
Phone API

XSL 2

XSL 1 XSL 3
XSL
The kind of client Processor
is identified from
the request
received by the XML Data
server.

Reference:
The Extensible Stylesheet Language (XSL) makes a great solution for merging the data
with the layout to provide content. Through the nature of XML, XSL allows you to
separate the data from the layout. As long as you can provide the data in XML format,
you can use XSL to produce content.

Another benefit of XSL is that it allows you to produce cross-browser-compatible

HTML. Because building the pages takes place long before they are delivered, the
product of the build process can be cross-browser-compatible HTML. Additionally,
because the result of an XML/XSL merge is text, you can use XSL to build both ASP
pages and the build script itself.

In this article, XSL is used as a server-side solution. This means that the merging or
transformation of the XML/XSL to HTML or ASP occurs on the server. By contrast, you
could also build a client-side solution based on the XML Document Object Model
(DOM) in Microsoft Internet Explorer 5.0. Using this method, Web site content would be
provided separately through XML data, using XSL for layout. For the sake of cross-
browser support, however, I will concentrate on the server-side solution.
Since XSL processes well-formed XML, to use XSL your data must be provided in
XML format. Take a look at the abbreviated product catalog data that's shown in Figure
1. For ease of understanding, in this sample I will use this data in static form. In a real-
world environment you can provide the data using any back end you have at your
disposal. Some obvious alternatives are building the XML through ASP, or using the
XML ISAPI filter for SQL Server.

One of the luxuries afforded by an early render approach is flexibility in how the data is
provided. Data can be provided live at build time via the methods I've outlined, or it can
be provided through static data files. Additionally, the performance of live data is almost
a nonissue. Because each data request occurs serially, you don't have to worry about the
number of concurrent hits the data provider might incur.

You are asked to development XML tags to discribe order data for your company's new
ERP system. Pls write down the tag you would use, together with some example data. use
least 10(ten) difference tags

1. <type> Identifies the XML document type.

2. <date> Date of request
3. <company> Attribute id identifies a company
4. <query> Attribute id identifies a query
5. <period> Identifies the evaluation period for a query
6. <start_of_period> Start of evaluation period
7. <end_of_period> End of evaluation period
8. <element_set> Lists the performance measures
9. <pm> Attribute name identifies a measure
10. <value> Value of a measure (only in RESPOND type)
11. <return_url> URL address to where the ERP connector has to send the
respond XML document

Example of XML document:

<?xml version="1.0"?>
<PurchaseRequest>
<PR_Number>1234</PR_Number>
<Supplier_ID>88844321</Supplier_ID>
<Supplier_Name>Sprockley&apos;s Sprockets</Supplier_Name>
<Requested_Delivery_Date>2000-01-15T00:00:00:000</Requested_Delivery_Date>
<Shipping_Address>
<Address>
<Street>123 Main St.</Street>
<City>Austin</City>
<State>TX</State>
<Zip>75222</Zip>
</Address>
</Shipping_Address>
</PurchaseRequest>

Example of DTD document:

<!ELEMENT PurchaseRequest
(PR_Number,Supplier_ID,Supplier_Name?,Requested_Delivery_
Billing_Address,Payment_Terms,Purchase_Items)>
<!ELEMENT PR_Number (#PCDATA) >
<!ATTLIST PR_Number type CDATA #FIXED "nonNegativeInteger">
<!ELEMENT Supplier_ID (#PCDATA) >
<!ATTLIST Supplier_ID type CDATA #FIXED "nonNegativeInteger">
<!ELEMENT Supplier_Name (#PCDATA) >
<!ATTLIST Supplier_Name type CDATA #FIXED "string">
<!ELEMENT Requested_Delivery_Date (#PCDATA) >
<!ATTLIST Requested_Delivery_Date type CDATA #FIXED "timeInstant">
<!ELEMENT Shipping_Address (Address)>
<!ELEMENT Address (Street,City,State,Zip)>
<!ELEMENT Street (#PCDATA) >
<!ATTLIST Street type CDATA #FIXED "string">
<!ELEMENT City (#PCDATA) >
<!ATTLIST City type CDATA #FIXED "string">
<!ELEMENT State (#PCDATA) >
<!ATTLIST State type CDATA #FIXED "string">
<!ELEMENT Zip (#PCDATA) >
<!ATTLIST Zip type CDATA #FIXED "nonNegativeInteger">

Example of XML schema:

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<xsd:annotation>
<xsd:documentation>
This schema created for MFL MessageFormat PurchaseRequest.
</xsd:documentation>
</xsd:annotation>
<xsd:element name="PurchaseRequest">
<xsd:complexType content="elementOnly">
<xsd:sequence>
<xsd:element ref="PR_Number" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="Supplier_ID" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="Supplier_Name" minOccurs="0" maxOccurs="1"/>
<xsd:element ref="Requested_Delivery_Date" minOccurs="1" maxOccurs="1"/>
<xsd:element ref="Shipping_Address" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="PR_Number" type="xsd:nonNegativeInteger"/>
<xsd:element name="Supplier_ID" type="xsd:nonNegativeInteger"/>
<xsd:element name="Supplier_Name" type="xsd:string"/>
<xsd:element name="Requested_Delivery_Date" type="xsd:timeInstant"/>
<xsd:element name="Shipping_Address">
<xsd:complexType content="elementOnly">
<xsd:sequence>
<xsd:element ref="Address" minOccurs="1" maxOccurs="1"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
IV
Explain the process & impotance of quality control in IT project. Give example, if you
want.

Process:

Proces
Input s Output

Quality Control

Importance of quality control in IT project:

You & your team have developed an accounting system for your company. However , the
employees resist the change from their old. hand written system to the new one. What
would you do to over come the resistance? Explain your actions.