Topic 1: Intro to Software Architecture
and Client-Server Architecture and the
World-Wide-Web
Sub Topic 2: Client-Server Architecture and the World Wide Web
Copyright By PowCoder代写 加微信 powcoder
ICT373: Software Architectures
Recap: Week 1
• Basics of software architectures
• Software development life cycles
• Various models e.g., pipe and filter
• Overview • HTML
• JavaScript
Learning objectives
• Introduce the Client-Server architecture using WWW..
• Describe the use of the Web to support a client-server system.
• Describe the roles and operations of browsers, HTML, links, URLs, forms and MIME.
• Give reasons for using client-side programming and explain how it can be done.
• Explain the concepts of objects and events on an HTML page (as used by JavaScript).
• Describe the use of batch and run-time validation.
• Be able to implement simple batch and run-time validation using
JavaScript.
• Give reasons for choosing between HTML, JavaScript and Java Applets in client-side programming.
Client-Server Architecture
• central repository of information
• centrally located so it can contain
the latest info and can be changed easily
• consists of
• the information,
• the software to manage the information,
• the software to manage the distribution of information and
• the central machine(s)
Clients: each consists of:
• software that communicates with the server, fetches the information, processes this information and displays it for the user of the remote machine,
• and the remote (consumer) machine.
Client-Server Architecture
• distribution of data (e.g., stock market, scientific, government),
• taking online orders and credit-card transactions.
Challenges:
Overloaded servers; congestion
• We want error-free, fair processing.
• Simultaneous transaction processing (two transactions in a bank account).
Supporting multiple types of client machines and multiple types of client operating systems.
Supporting software changes especially if the clients also have to change.
Client-Server Architecture
Performance issues:
• Eg, if the clients or connections are unreliable then the server cannot delay responding to client A while it waits for some answer from client B.
• Eg, if there are many clients involved then the server processing has to be very efficient.
Server-client processing is very important and becoming increasing popular.
The World-Wide-Web as a Client- Server System
• The Internet is the network formed by millions of computers
• In the early 1990’s the WWW was added.
• It uses a client-server model (defined by HTTP) to allow a number of pages of information (containing text, pictures, sound, video, etc) with links to other pages to be set up on a server.
• The information can be read by a client (anywhere else on the Internet) using a commonly available piece of software – the web browser.
• Despite many more recent exciting developments in this set up, the basic WWW client-server arrangement is still used as the underlying architecture for many applications.
• We will discuss a client-server relationship using a WWW set up when designing a piece of software.
Browsers and HTML
• Basic mode of operation:
• To make this work on various types of client machines requires a standard language (protocol) for specifying the formatting of the information in a way that can be sent by the server, and browsers capable of interpreting the language faithfully on the various client machines with their various operating systems.
• The standard language used is HTML (or XHTML), the HyperText Markup Language, which is specified by the W3C (World Wide Web Consortium).
• New versions of HTML are published every so often by the W3C to keep up with the rapidly developing technology.
• HTML5 (released in October 2014) is the new markup language which has both a regular text/html serialization and an XML serialization.
• Anyone is free to answer web page requests in any format they want but, since the browser manufacturers (MS, Mozilla and Google) respect HTML specs, a different format will probably not be able to be displayed by many clients.
Basic HTML: an example
ICT373T2Ex1.html
Multipurpose Internet Mail Extensions (MIME)
• MIME is an Internet standard
• MIME extends the format of email to support
• Text in character sets other than ASCII
• Non-text attachments: audio, video, images, application programs..
• Message bodies with multiple parts
• Header information in non-ASCII character sets
• Location of the picture: When the browser constructs such a web page it will notice if it has to insert pictures at appropriate places.
• Additional information: another request off to get the image file from a place specified by the SRC tag. The image is decoded and displayed in the right place.
• Image types: The image file will also have to be sent from a server to the client browser. Thus HTTP must be able to cope with (still) images of several different formats (as well as text, special characters, and audio and video).
• MIME is mainly designed for email protocols (SMTP)
• Also important for communication protocols, e.g., HTTP, WWW. • Servers insert the MIME header at the beginning of any Web
transmission.
• each image in a webpage thus requires a new client server connection to be made with a separate message sent each way.
• MIME messages involve several headers giving details about the format and content of the message and then a suitably encoded message body.
HTML: Links
• When the client’s user clicks on the hypertext link text (which could also be a picture), the browser arranges for the specified file to be requested from the server, interpreted and displayed.
• Links to other pages appear in HTML pages within tags (
here is the blue clickable text
and here is the following text.
…or, for a more distant transfer example, …
here is the blue clickable text
• In this example, click on the linking text causes a page from a completely different server to be requested and displayed.
• The server and the particular HTML page kept on it are specified by the string defined as href in the opening tag.
Uniform Resource Locators (URLs)
• Each page on the web is specified by a unique URL which allows a user of a browser to find it and allows it to be linked to from other pages on the web. e.g.,
http://www.it.murdoch.edu.au/~psd/addr.html
• comes in three parts:
• a protocol (eg, http)
• a name of the host server (eg, www.it.murdoch.edu.au)
• the file specification (eg, ~psd/addr.html)
When such a link is clicked on,
• the browser finds out an IP (Internet Protocol) address of the host server (by asking, across the internet, another machine known as the domain name system or DNS – which has a list of all such names).
• Using this address it can establish a connection with the server using the specified protocol (eg, HTTP) to get the specified file.
• The way the host server actually finds the file varies from server to server (and the client does not need to know the system). Eg,
• ~psd/addr.html might mean the file called addr.html within the directory public_html within the home directory of the user psd.
• giving no file name usually means the file called index.html
Interactivity
• HTML 1.0, the HTML version used by the first browsers (Mosaic), was a one-way language.
• great interests which it (and the early web) caused, led to demand for full two-way client-server capabilities.
• People wanted to send information back to the server, for example, to look up information in a central database or even to add information to a central database.
• There were many commercial (as well as scientific) applications.
• HTML version 2.0 included forms. Forms contain boxes and buttons of a few useful types which can be filled in by the browser user.
• A SUBMIT button causes the collected information to be sent to a specified URL.
Interactivity
• There may be several forms on an HTML page. If it is to allow sending of information, each needs to include
• a METHOD for communication,
• a destination URL (which does not have to be on the host
server) and
• a SUBMIT button.
Interactivity: an example
ICT373T2Ex2.html
Interactivity
• Press SUBMIT -> the values entered on the form are sent to the server specified in the ACTION URL via the HTTP METHOD (either GET or POST) specified.
• GET – Requests data from a specified resource
• POST – Submits data to be processed to a specified resource
Interactivity: requesting data
• The server passes the message on to the file specified in the URL.
• The GET method in HTTP is meant to be only for getting web pages from a server but can be used in a tricky way to pass information to a program on a server.
• A GET message will be in the (ASCII) form “GET URL” with obvious meaning.
• If the GET method is used for submission of a form then the input values are actually sent in this message appended after a ‘?’ at the end of the ACTION URL. The server finds the file specified by the URL string before the ‘?’.
• http://www.it.murdoch.edu.au/cgi- bin/reply1.pl?name=ferdous&opsys=Unix&comments=Hello
Interactivity: sending data
• The POST method is more common.
• HTTP’s POST was designed for adding info to a web page. The message sent contains a header “POST URL” followed by a coded version of the input values.
• The HTTP POST message is capable of sending all sorts of information (text, sound, video) via an encoding to ASCII. To send the input values of a form the encoding is a simple text encoding.
• http://www.it.murdoch.edu.au/cgi-bin/reply1.pl
• In either GET or POST methods the values are put together into
one string such as
• name=john&opsys=Linux&comments=no+comment
GET VS POST
Self study for fun: http://www.diffen.com/difference/GET-vs-POST- HTTP-Requests
Server-side Programming and CGI
• A common set up for receiving such information is to use the Common Gateway Interface (CGI) provided on all servers.
• The “cgi-bin” directory is the location you will use to store your Perl or compiled script files. Any files you place in it will be treated as programs (instead of HTML pages or images), and will be “run” by the server instead of displayed normally.
• When the server gets a request to apply a method to a page in a directory called “cgi-bin”, it interprets the file name as an executable program (or script) and starts it up.
• The body of the message is passed to the running program as its standard input.
• The program can do whatever it wants with the input (eg, interact with a local database) and if it produces some text on its standard output then that is sent to the client’s browser to be displayed.
Server-side Programming and CGI
• Such a CGI script is commonly written in one of the following languages: Perl, PHP, Python, ASP (and ASP.Net).
• C and C++ can also be used to set up more complicated server programs.
• Java is increasingly used. Java-based Web servers allow you to perform all your server-side programming in java by writing servlets, JSPs and JSFs.
We will return to server-side programming much later in the unit.
Client-side programming: why?
• Sending all data back to the server for all processing is not efficient. For example,
• if there is a simple mistake on the form making it unacceptable then there can be delays while information is sent to the server, checked, and an error information page prepared and sent back.
• This is a waste of resources as the browser is most likely running on a machine quite able to check a form for valid input.
• The solution is client-side programming, i.e.,
• giving the browser the ability to run programs and allowing the server to send programs along with the HTML page.
Client-side programming
• plug-ins: extra bits of software that can be added to browser software to give the browser extra capabilities.
• Plug-ins were already being used to cope with all the new formats for sending information across the web, e.g., pictures, audio, video.
• Instead of getting a new browser every time a new format is available, users could just get the extra plug-in software.
• The plug-in itself was often able to be downloaded over the web and installed easily.
• The plug-in could be made available without the involvement (or permission) of the software manufacturer.
• Several client-side programming languages arrived as plug- ins, e.g., flash player.
Scripting Languages
• These are interpreted client-side programming languages with the source being sent as part of an HTML page.
• The interpreter (either a plug-in or built-in to the browser) runs the code as it displays the HTML page.
• The source code is quick to get from the server (part of the HTML text) and quick to load.
• Scripting languages are usually quite simple to learn and understand, allow fast development of software and are designed to solve the kind of programming tasks needed to make nice GUIs for client use.
• If you need to produce a web-based client-server system then it is a good idea to consider using a scripting language for the client side.
Scripting Languages
• Scripting languages are not general purpose programming languages. Eg, no writing to disk is allowed. Also, they are interpretive languages.
• JavaScript, the most common, built-in on Netscape, Explorer and Firefox (and nothing to do with JAVA)
• VBscript (like Visual Basic) • Tcl/Tk
JavaScript
• JavaScript can be used to validate a form on the client’s browser before it is sent to the server.
• The script forms part of an HTML page. A chunk can appear in the body for processing during the page’s construction.
• we will just see how to put functions (i.e. procedures) in the head and brief event-activated calls to these procedures in the body.
• The script is really about the objects on the page, i.e. the HTML elements like links, forms and buttons within forms.
• It is useful to NAME the objects in their tags.
JavaScript
• Events happen to the objects on the page as the user interacts with it.
• JavaScript event handlers allow script to be executed in response to an event. Event handlers include:
• onClick in response to a click on a button
• onSubmit in response to clicking on the submit button on a
• onMouseOver in response to the cursor being over an object
• onChange in response to the text being changed in a text area.
Functions: alert_example1.html
• To define a function we give its name, formal parameters and body within script tags in the head of the HTML page
• We can then simply mention the function name (with arguments) to call it.
Functions can return values.
Function explained
• alert(“text”) pops up a window containing “text” (which can be a number)
• var variableName = value create and initialize
• variableName = value assignment (can use arithmetic, logic,
string operators)
• if … else, while, for, switch similar to C++/Java; Comments as in Java // or /* */
• To get access to user entered information on a document either refer to the .value member of a hierarchy of names, eg, if the form named “myForm” has a text line called “fred”, then you can write x=document.myForm.fred.value
Function explained
• or, pass an object to a function using the this variable and look up its value, eg, put
• x=g.fred.value in the function mary(g) and call by